A common challenge among architects and architecture organizations is the challenge of properly understanding the landscape of architecture assets within and external to the enterprise. With all the different definitions, hierarchy and levels of abstraction it can be difficult to really get your arms this problem space.
At an architecture summit were questions like:
What is a pattern?
Is there a difference between a reference architecture and a pattern?
How would you classify an architecture asset?
What is the difference or the line between architecture and implementation?
These are all great questions and I am sure there are questions asked by many others as well.
There are things you can do to alleviate this pain. Below are four activities I have used to help clear up the confusion:
Lock on Vocabulary - A large part of the problem (not the only) is one of vocabulary. Having a common definition for these terms goes a long way. After walking through the questions above with architects what we quickly found was that we were actually deriving to the same definition but using different terms.
Classification – As you go through the terms there will be quite a bit of iteration on the relationships of these terms. This classification or taxonomy is important to lock for your organization. It helps you understand the context and the relationships of the asset to all other things.
Leverage Mainstream Vocabulary and Classification – In a past experience of mine (7 or so years back) when aiding in building an Office of Enterprise Architecture we found this same issue of locking on terms we can all understand as an enterprise. We spent the better part of 6 months (in duration not effort) just trying to lock on terms. This involved passionate debates and religious wars on how people understood the space and their personal preferences. Save yourself the heartache and leverage an existing standard. It will be better for your organization in the long run.
Provide Examples – Run through a few scenarios to exercises the vocabulary and classification system. This will accelerate the end users understanding of the concepts.
There has actually been quite a bit of work done in this space. The Open Group’s TOGAF 9 has defined this space really well at the macro level. This is what they call the Enterprise Continuum. There site has a lot of detail on this and you can find more on the Enterprise Continuum Online Book Chapter.
The definition of the Enterprise Continuum is: a view of the Architecture Repository that provides methods for classifying architecture and solution artifacts as they evolve from generic Foundation Architectures to Organization-Specific Architectures
So essentially it is providing a classification and common set of definitions for the space. There is a small bit of taxonomy work here but it is inferred not in a typical taxonomy format but the outcomes are that of a taxonomy.
I really like that this framework accommodates real world challenges such as regulatory compliance, business change, technology disruptors and competitive forces. This is all rationalized in the context of business and IT strategy which is a first class citizen in the framework.
This is demonstrated in the diagram below when you look at the traceability aspects of the framework.
Above shows abstraction at a high-level and below is an exercised high-level architecture partitioning of the model that can be mapped to the ADM methodology. This is what makes the model actionable as it leverages the deep definition of an architecture method to make the classification implementable.
If you are looking to supplement TOGAF or look at other perspectives there are great resources at the OMG, IEEE, FODA, and others. Of all the sources TOGAF (in my opinion) is by far the most complete across the spectrum and is the highest used by both enterprises and tools vendors.
Another helpful piece of context setting which isn’t necessarily in the Enterprise Continuum is the notion of an Architectural Style. I talk about his in a post I wrote a couple years back in “What is an Architectural Style” . I think that this is complementary to the Enterprise Continuum as it is more of guiding principles of the Architecture and Solution Continuum.
I define an architecture style as:
An Architecture Style is a logical grouping of patterns or architecture references that is implemented through cohesive methods for solving a problem area with a unique set of concerns.
At the time this was a way to reduce confusion around key macro technology patterns such as SOA, now this has shifted to another amorphous concept of Cloud Computing. See below for an example:
Additionally, J.D. Meier has a good post on Reference Models, Reference Architectures and Reference Implementations that could be either worked into the TOGAF vocabulary but also used independently if need be. The reason I bring this post up is that he has some good definitions that could be an alternative or provide additional context.
See J.D.’s descriptions below:
Reference Model - A Reference model is a model of something that embodies the basic goals or ideas, and you can use it at as a reference for various purposes. It’s like holding up a diamond and looking at the different facets. It basically serves as a backdrop or canvas, or a foundation and springboard for deeper dives. They are also useful for pulling together a bird’s-eye view of a domain or problem space. A well-known example is the OSI model. Key Attributes include: abstract, entities and Relationships, technology agnostic, and they clarify things within a context. By using a model, you can focus on higher-level concepts, ideas, and decisions.
Reference Architecture - A reference architecture provides a proven template solution for an architecture for a particular domain. It’s the high-level “blue prints” for putting the pieces of the puzzle together.
Reference Implementation - A reference Implementation goes beyond a reference architecture and is an actual implementation. This is where the rubber meets the road and it serves as an exemplar down at the implementation level.
Technorati Tags: Enterprise Architecture,EA,Open Group,TOGAF,Taxonomy
Comments