I've Been Thinking

Problem Oriented Architectures
  • Home

  • I have observed first hand a number of less than successful projects. I have also studied reports of failed projects, of which there are far too many.

    I have come to the following conclusion:
    The most frequent reason why projects fail is because the project is based upon needs and requirements. Architects interview "the business" and identify requirements. For the business to supply these requirements, they must describe what they think is the solution. That is because requirements do not describe problems. A requirement is a characteristic that must be met by a person, object or system.

    This is where things go wrong. It is highly unlikely that "the business" has the skills and expertise to analyse their problem and develop an optimal solution. And as I explain in Problems and Solutions, solving a problem will always create new problems. This means that whatever "solution" the business comes up with it is probable that it will cause unintended consequences.

    People who architect solutions are only doing half the job they should be doing; In fact it is likely that they are designing a solution that has been given to them and which is based upon a set of needs and requirements that may or may not describe a good solution. Unfortunately, there is no way that the solution can be assessed against the problem, because the problem has not been documented and analysed.

    A needs and requirements based approach means that:
    1. It is likely that the solution will solve the wrong problem
    2. It will not be possible to identify that the wrong problem is being solved
    3. Problems that the solution will create are not recognised and addressed by the business
    4. The solution will be difficult to justify to the business because its value is unclear, or is based upon benefits that will not accrue

    It would be much more useful if the architect were involved in identifying the problem and worked with the business and with people knowledgable in the solution space to fully understand the problem, potential solutions and the problems that the solutions will create.

    It is proposed that a better approach is to base architecture activities on the primary input of business goals and problems. The business can then allocate business value to achieving these goals and to solving the problems that arise when achieving them.

    A problem oriented approach has the following advantages:

       1. The aim is to achive business goals
       2. Business problems - which are questions that the business has to answer to achieve its goals - are explicitly addressed
       3. The business can understand the purpose of the architecture and the solution because they relate to an environment the business understands
       4. The solution explicitly solves a well defined, documented and analysed business problem
       5. Problems that the solution will create once implemented are identified early in the problem solving process and can be accommodated when assessing solution options
       6. Implementation projects commence with a well defined solution

    I have written a paper on this subject "Beyond the Zachman framework: Problem-oriented system architecture" which has been published in the IBM Journal of Research and Development. Volume 56, Issue 5, September/October 2012

    Here is the abstract:

    The year 2012 marks the twenty-fifth anniversary of BA framework
    for information systems architecture, written by John Zachman and
    published in the IBM Systems Journal.

    The first part of this paper reviews the Zachman and similar
    frameworks and concludes that there are a number of limitations in the
    framework approach when applied to today’s technology environment
    and business problems. These include the inability of the problem owner
    to properly describe a solution, the partitioning approach, and the
    decision-making processes in the context of uncertainty and change.

    The second part of this paper analyzes today’s problems and
    allocates them to one of three classifications: tame, complex, and
    wicked, depending on the degree of certainty and stability of
    knowledge and decisions in both the problem and the solution domains.

    The final part outlines an approach to problem-solving and architecture
    development using techniques borrowed from cybernetics and control
    theory. It proposes that partitioning should be determined by the nature of
    the problem and potential solutions; that feedback loops should be
    implemented in order to control the process; that the architect should
    work across the business problem and solution spaces; and that
    decisions should be related to business value.

    This is a copy of the paper

    Much more on this topic and why there are so many large scale IT project failures will be found at my other website Problems First

    Bernard Robertson-Dunn, August 2012