Yesterday I attended the Architecture track at the Microsoft MVP (Most Valuable Professional) Summit. The format was quite different than other forums. The architect forums was based on a collaborative approach where three is no agenda or themes and it is up to the participants to create it. It was very effective and thought I would share my thoughts with the rest of you.
So I facilitated two sessions on Enterprise Architecture. The first asking the question, what is EA? And the second, what are the important standards in the EA space?
The goal of the second session wasn't necessarily trying to get at what are the standards but rather what are the more prevalent and most impactful.
After a bit of white-boarding with the group and dialog we quickly derived to a way to classify the standards that we have been talking about.
The image above show the segments or classification of these standards. By asking basic questions such as How, What, When, Who and Why we can also simplify this a bit. Starting from the bottom up lets talk about what was discussed and I'll add some of my thoughts as well.
Taxonomy and Ontology
Every system has an architecture. In fact, a system could have many architectures. In IEEE 1471, an architecture is a conception of a system. There may be many conceptions of a system.
What this provides to the enterprise architect, solutions architect or domain architect is a way to have a constant set of terms for describing what it is they are building. This should be at the core to your architecture activities. Downstream benefits include further reuse of architectures, design patterns, architecture modeling and traciablity of systems to business capabilities.
The beauty of all this is that this taxonomy is flexible. Meaning that System, Mission, Environment and Architecture, are all conceptual in nature. There are no requirements ("shalls") in the standard pertaining to these entities. The requirements in the standard apply to the items below which pertain to the concrete representation of an architecture.
For more information on IEEE 1471 go to their web site at: http://www.iso-architecture.org/ieee-1471/index.html
Information Model and Decision Support
The Zachman Framework was brought up many times during the conversation but in various forms. We ended up classifying Zachman as decision support. The reason for this was that Zachman and other derivatives of Zachman focus more on:
What are the right questions
How do I organize those questions
What do those answers mean
The Zachman Framework excels at these activities. However where things start to break down is how to orchestrate those questions. Meaning what is the process in which I get the information, consume it, process it and ultimately make it actionable.
The ideal goal here would be to use the Zachman Framework in conjunction with the Process Capabilities coupled with a defined Architecture Taxonomy.
For more information visit the Zachman Framework web site at: http://www.zachmaninternational.com/2/Zachman_Framework.asp
Process Framework
As mentioned above when talking about decision support, there is a need for a process to wrap how we make our decisions. This gives Enterprise Architects the ability to have repeatability in their processes.
Below you will see the TOGAF Architecture Development Method (ADM) "crop circle" which outlines the process framework.
ADM provides a framework which can support man other standards and frameworks. It is technology agnostic and is more focused on how architecture processes should be orchestrated. This allows organizations to:
Preserve existing organizational structures (if desired)
Use homegrown processes and existing frameworks and standards
Having this higher level process framework is essential to architects. Thee are a series of benefits for the organization:
Constancy in how solutions are created
The right people are selected for the right job
Proper metrics can be obtained to gauge health of the EA process
Predictability of results which lends to being able to apply some level of risk management to decisions
Actors
Out of all the topics, this was discussed the most. There is a great deal of ambiguity in the industry around what are the required skill sets of an architect. There are some bodies that help with that task.
OpenGroup ITAC Program - This is for the practitioner. When you have many years of experience and you want to be accepted in the industry as a credible architect.
IASA - For the aspiring architects that is largely academically focused. This program provides a program for those that have little architecture experience and want to get into architecture.
Both have a role and are valid in their own ways. However, each one of these has a specific niche.
Manage
This topic is indirectly related but still very relevant. This aspect covers PMO based processes, service management and IT Governance aspects. In the service management area specifically we are seeing closer alignment with EA. The latest version of ITIL has a lignment with EA practices.
See my previous blog post: http://blogs.msdn.com/mikewalker/archive/2007/07/06/itil-moving-towards-enterprise-architecture.aspx
Putting it all Together
Thankfully there have been other like minded individuals folks at OpenGroup and alike that have thought about this problem. Below are some overlays and descriptions of putting these pieces together.
TOGAF + Zachman
Read this article for more information:
TOGAF + IEEE 1471
TOGAF adoption of IEEE 1471 happened in 2000 with TOGAF version 6.0. There is a great article that gives an impact assessment on this and the benefits of using 1471 with TOGAF.
Other Important Standards & Frameworks
It's important to not that there are a lot of standards out there. We haven't scratched the surface on all the various specifications and standards for EA. Below you will find other standards that you may be interested in as well.
Other EA Frameworks
DODAF
TEAF
FEAF
CADM
MODAF
Comments