Over the years we have observed a common set of problems that organizations seem to experience when it comes to architecture. None of us has yet seen an organization that experiences all these problems, although some suffer from all but one or two. The potential problems with existing traditional approaches to architecture include the following:
Skewed focus. Architecture models act as bridges between the business and the technical sides of your project. A model that focuses primarily on business issues, or on technical issues, will not meet your real-world needs. When business stakeholders or IT professionals do not see concepts that they can understand, and mappings of those concepts to the ideas that they may not immediately comprehend, they will soon abandon the architecture efforts. You need to find the model that meets everyone's needs.
Developers don't work with the architects. Some developers will follow the architecture but will not work with the architects, stumbling a bit due to lack of guidance. The architects also suffer because they don't get the feedback they require, ensuring that their work reflects what developers actually need. Several common reasons explain this problem. First, the architects do not realize the importance of gaining concrete feedback regarding their work. Second, the architects think that coding is “beneath them” and therefore are unwilling to work closely with developers. Third, they are working in a bureaucratic environment that leads them to believe that the best way to communicate their work is through models and documentation. Unfortunately, practice shows that this is the least effective means of communication (Ambler 2002a; Cockburn 2002). Fourth, developers may have little respect for the architects, perceiving them as out of touch or overly academic.
Narrowly focused architecture models. A system is a complex entity, and a single view isn't sufficient to model it. For example, a data model can be an important part of your architecture model if you use it effectively, but it's only one of several parts. What about your network architecture? The business processes that your system supports? Your organization structure? Software architecture? Business rules? You need a robust architectural model comprised of many views that takes into account all the issues that developers face—one or two narrowly focused views are not good enough.