I've Been Thinking
Architecture
  • Home
    		•
    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:
    1. Problem investigation and analysis - this should include an identification of the best way of modelling and understanding the problem
    2. Problem solving
    3. Solution definition
    This means that architecture is a combination of structured documentation and subsequent analysis followed by innovative problem solving.

    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:
    1. identify the "as-is" environment
    2. specify the "to-be" environment
    3. gap analysis
    the problem with this approach is that the creation of the "to-be " environment is not based upon any value to the enterprise - it's a solution.

    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

    Bernard Robertson-Dunn,
    1 February 2016