Potential Problems with Traditional Approaches to Enterprise Architecture

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:

  1. There isn't an architecture effort. Every system has an architecture whether or not the project team chooses to manage it effectively. As you will see in this chapter, architecture efforts don't need to be a complicated endeavor.

  2. 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.

  3. Developers don't know that the architecture exists. Many project teams suffer serious breakdowns in communication.

  4. Developers don't follow the architecture. Developers don't take advantage of the architecture in many projects, and more commonly they only follow part of it and reinvent other portions, due to one or more of the following problems.

  5. 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.

  6. Outdated architecture. Architecture must evolve over time to reflect new business needs and technological approaches. When architecture becomes outdated, or is perceived to be so, the chances of developers following the architecture decrease dramatically.

  7. 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.



Practical Guide to Enterprise Architecture, A
A Practical Guide to Enterprise Architecture
ISBN: 0131412752
EAN: 2147483647
Year: 2005
Pages: 148

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net