EA - Enterprise Architecture or Extreme Aggravation

The second challenge is describing the architects in standard ways that are well understood by everyone using the architectures.  Here there are some good works to start with:

• The TOGAF Technical Reference Model defines a core taxonomy for describing the components and conceptual structure of an architecture.  http://www.opengroup.org/architecture/togaf9-doc/arch/chap43.html
• FEA (Federal Enterprise Architecture) defines a set of Reference Models for describing the important elements of architecture in consistent ways. http://www.whitehouse.gov/omb/e-gov/fea/
• There are several good catalogs of common enterprise architecture patterns:

• Fowler: Patterns of Enterprise Application Architecture” http://martinfowler.com/eaaCatalog/

• Hohpe & Woolf: “Enterprise Integration Patterns” http://www.eaipatterns.com/

The last part of the problem is even more challenging:  Given a problem how does one pick the appropriate architecture? 

Methods like ATAM are designed to evaluate a given architecture against a given set of requirements.  So using ATAM would require evaluating each standard architecture against the given requirement set and picking the one that fits the best; this would be impractical in the real world for more than two or three architecture.  I’m not sure that inverting the function is possible in a generalized way.  However, if as said before, one narrows the problem domain to a single enterprise and a sufficiently small set of architectures one may be able to define such a function.

The other challenge for picking an architecture based on any given problem is ensuring that the problem has been broken down appropriately first.  Most large enterprises have complex problems, but the successful solution is not an equally complex solution but rather a collection of simple solutions.  Each one of these solution components may map to a different standard architecture.  This componentizing of the solution also simplifies the process of matching problems to architectures since it means both simpler problems and simpler architectures.  Complexity is the enemy.

Another technique for managing the complexity is to divide the standard architectures into layers.  If one limit the problem domain to defining standard physical architects (disk, memory, CPU, networks, I/O, etc.) then this starts to sound a lot more doable.  This may not be the ultimate goal, but it's the start the first step in a layered approach that starts with defining standard physical architects, then standard application architectures, data architects, process architectures, security architecture, etc.  Thus the process of mapping a problem to a standard architecture would actually involve picking an appropriate architecture from each layer.  One may find that each layer has a relatively small set of standard architectures, but in combination the layered architectures represent dozens of complete architectures.  The FEA Reference Models sort of takes this approach.

So whereas the goal of defining standard architectures within an organization has many advantages not the least of which are: reduced technology complexity within the organization, increase reuse of both components and skill sets throughout the organization, decrease risk, and decrease cost.  Unless you happen to be the Federal government of the United States of America don’t look for general solution, focus on the problems in your organization and the tools already at your disposal to develop more specialized solutions that give more immediate benefit.  Where there is some effort, there is some success.