It seems that whenever someone talks about their approach to enterprise architecture it will relate to an architecture framework. The two things – method and framework –go hand-in-hand; you can’t have one without the other.
But in discussions with practising architects an architecture development method is usually seen as useful, whereas frameworks are sometimes perceived as passive and theoretical. This contrast cropped up again when I was mentoring an EA team: in this team of 8 people, opinion was very clear that the method they were using (the TOGAF Architecture Development Method) was actively useful, but the team unanimously agreed that architecture frameworks only provided interesting background theory – they weren’t actively useful!
This team were familiar with a wide range of architecture frameworks, but the key ones were TOGAF, the Zachman Framework, and US architecture frameworks such as the Department of Defense Architecture Framework (DoDAF), the Treasury Enterprise Architecture Framework (TEAF) and the Federal Enterprise Architecture Framework (FEAF).
The overall impression of these frameworks was that although they included a lot of useful material, the notion of a “framework” only referred to a container or body of knowledge, or a diagram that summarized the key concepts in enterprise architecture.
They saw the diagram that shows the structure of the TOGAF document [Figure 1-1: Structure of the TOGAF Document] as being the “framework” in TOGAF. Team members agreed that this showed a good overview of what enterprise architecture was about, and in particular it shows the structure of the TOGAF documentation, but they didn’t see the diagram as useful. In other words, it helped explain what EA was but they wouldn’t consider using the diagram as a tool to help manage the architecture or its evolution.
They saw the Zachman Framework as even more theoretical, and although several members of the team had seen John Zachman talk about his framework, they still had no idea how they might use it in a practical sense.
I was very concerned! Why? Because this year is my 30th year as an enterprise architect, and in all that time the frameworks is the most useful technique that I have come across for managing EA! This is an important point and I want to make sure that I am getting the right message across.
So I don’t mean the TOGAF or the Zachman Framework. TOGAF is really a body of knowledge (text and diagrams) about EA. TOGAF does include material that is a good basis for creating active and useful frameworks, but as presented in TOGAF it is more a passive outline of things that are important in EA.
The Zachman Framework is an altogether different beast; it is really a schema in the same way that the Periodic Table is tabular presentation of chemical elements. Again, the Zachman Framework includes material that is a good basis for creating active and useful frameworks, but as presented the Zachman Framework is once again a passive outline of things that are important in EA.
Not surprisingly, it is rare that TOGAF or the Zachman Framework is used without adaptation! So how do you turn the rather theoretical material of TOGAF or Zachman into something more useful?
4 Pointers for Active, Successful Architecture Frameworks:
- Recognize that there is no one size fits all framework. EA is multi-dimensional, but having more than two dimensions in a framework makes it impossible to use. So you need to create a tailored framework that meets your need, and bear in mind that you may need to create more than one framework.
- Be clear how you will use the framework! Knowing this it easy to create a framework that does the job. For example, you may want to keep track of the work products that you produce during the development process, or you may want to track which outputs get shown to each stakeholder.
- Decide what you things need to be included in your framework to make it active and useful for you. In our first example, to keep track of the work products that you produce during the development process, you need an Architecture Content Framework that shows domains and sub-domains on one axis and the development process, such as the Phases of the ADM, on the other axis. To track which outputs get shown to each stakeholder you need a list of outputs or deliverables on one axis mapped to a list of stakeholders on the other axis.
- Make sure that each framework uses the same concepts and language. This makes sure that all of the frameworks you create work together. The best way to do this is to have a standard set of factors that are then used to create each framework.For example, many frameworks refer to the subject matter or topics that are covered by EA. A good high-level start point for this are the four architecture domains from TOGAF – the business, data, application and technology architectures. Each of these domains can be further subdivided.Again you can use the content framework and metamodel from TOGAF to help identify sub-domains; for example, the business architecture includes things like organization and process in the TOGAF metamodel, and organization includes function, business service, organization unit and actor. I would recommend that you start with these TOGAF concepts to produce a standard subject matter list.It is also useful to arrange this list as a hierarchy – from our example this would include: Business Architecture > Organization > Organization Unit – as this makes it easier to zoom in or out, or to add further sub-domains.
If you follow these simple guidelines you will end up with a active and useful set of Multiple Integrated Architecture Frameworks (MIAF) – each one tailored to a specific need, and each one based on a standard set of EA factors!
