IMHO Architecture should be seen as a structured mechanism for documenting and analysing a problem followed by an unstructured problem solving process. At the end of the whole process is a documented problem and a specification for a solution that can be implemented. The requirements for an implementation project can then be derived from the problem/solution definition.
Architects solve problems and define solutions. Project Managers implement solutions; Expecting Project Managers to solve a problem as well as implement the solution is the most frequent cause of project failure. The problem should be solved before being given to a Project Manager to implement
There's too much Cargo Culture Architecture going on in today's business and IT departments. Cargo Cult architecture is a term I have applied to the approach where there is a belief that the application of a simplistic architecture development method will result in something useful.
The downside of TOGAF is that it misleads the naive. It is based upon needs and requirements and assumes that the business has solved its problem and that the requirements define the solution. This may be true for simple or tame problems but it is unlikely that complex or Wicked Problems can be solved in such a simplistic and linear fashion.
A better approach is described in Problem Oriented Architecture
Architecture is all about solving certain problems in a partucular way. In general there are three phases:
The first part is relatively straight forward and can be subject to a repeatable process. However it should always be directed by the problem solving phase which permits a focus to be applied to those areas where the problem is difficult.
This view of architecture is not the same as the "traditional" or common view:
See the section on problems and solutions for further discussion.
Bernard's Rules of Architecture
Here is an arcticle I wrote for MIS magazine in 1994. In spite of its age, it is still very relevant.
The Role of Architecture in Modern IT
1 February 2016