Have you ever tried to compare EA frameworks? How do you compare and are all frameworks the same. The reader digest version of the answer is: No... Not all frameworks are the same but rather have there own definitions of what they are to deliver.
I have in the past and I have found it very challenging because it is a bit like comparing apples and oranges. When I talk to customers and folks internally about EA frameworks there is a great deal of confusion with current comparisons found online. Below is a common example:
source: http://www.mkern.com/whatisea/frameworks.html
This comparison really doesn't tell us much detail. Although there is a whitepaper called A Comparison of the Top Four Enterprise-Architecture Methodologies on the MSDN EA Architecture Center we have the same issue with comparing these framework with the same base criteria:
This isn't to say these don't provide value, they do from a macro level. However, the real challenge here is that these frameworks are fundamentally trying to solve different problems all together.
I see that there are two major types of frameworks:
- General Purpose Frameworks - What sets these types of frameworks apart from others is that they are trying to solve the broader problem the enterprises are having. These frameworks do so by being agnostic to any specific implementation. They have no specific business drivers (enterprise specific) but rather are capability based. These frameworks are generally driven by industry consortia such as Open Group.
- Domain Specific Frameworks - Frameworks that are derived from an EA effort are refereed to as Domain Specific. These frameworks were derived with a predefined set of business concerns in mind because they originated from an EA office or process improvement effort in a government or an enterprise. Largely these frameworks are driven by government agencies such as the US government or other geographies.
So how does the actual frameworks fit into these buckets.
| General Purpose Framework | Domain Specific Framework |
| TOGAF | FEAF |
| Agile EA | DODAF |
| Zachman | MODAF |
| TEAF | |
| ... |
Should you eliminate one of these types form your efforts? Absolutely not. These frameworks have very specific value propositions. But we first need to know how they are fundamentally different.
As shown above there are two basic characteristics. We look at the allowable level of customization vs. prescriptive guidance. These frameworks slide down the continuum from the level and ability to customize to the level of prescriptive guidance. The general purpose framework has a greater level of flexibility as it is attempting to solve all problems. Whereas the Domain Specific Framework is solving the problem with a series of predefined set of forces and attributes.
For example: A government based framework such as FEAF / TEAF / FEAF will be based on the specific government based regulatory laws (region based), a set of operating and organizational models that is specific to that agency. These will drive out the process and artifacts required to fulfil these base business drivers.
So what do you get with these different types of frameworks? With these two classifications of frameworks there are a set of artifacts, methods and tools that are derived. These are derived on the the base problem sets defined earlier. Since these are derived, the outputs can be very different. See below:
General Purpose Frameworks:
- Defines an open and consistent definition of terminology through taxonomies and ontology.
- Agnostic to organizational structure
- Low level process agnostic
- SDLC
- PMO
- Service Management
- etc.
- Very configurable to enterprises
Domain Specific Frameworks:
- Prescriptive guidance for:
- Organizational structures
- Processes
- Artifacts
- Usually deliver lots of templates
- Lots of real world examples
Is the comparison of EA Frameworks like comparing Apples and Oranges? Yes it is. When you compare these frameworks they should not be treated the same nor should be judged based on the same criteria. Rather they should be correlated with your specific requirements.
