|
|
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:
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 |
| Home | |