For the second post in the TOGAF Demystification series, let's tackle the common topic of TOGAF to other frameworks. Over the years I've heard the debates between passionate EA's and seen the seemingly endless posts on LinkedIn and blogs on this topic. One thing is for sure, this is a topic of much interest.
While the driver is often to figure out if there is a better enterprise architecture framework out there, sometimes our enthusiasm gets the better of us and turns into a heated debate with a lose of the original reason why we need to choose a framework.
This post will not go into:
TOGAF compared to
Detailed comparison of all frameworks
Why TOGAF is better or worse than other frameworks
TOGAF features and evaluation to other frameworks
Rather than directly evaluate or compare, I think it is more beneficial to take a step back. The goal here is to provide a way to think about comparing TOGAF. I do believe that not all roads lead to TOGAF. That is the reason for not publishing the reason why all of you should adopt TOGAF. I believe that is fundamentally wrong. You must look at what is important to your organization and make the call based on all those drivers.
So in this post will will look at the following:
what are the common misconceptions when evaluating
what approach should we use
is there a comparison frame of a mental frame for evaluating these frameworks.
Simply put, this post serves as a way to think about comparing and contrasting frameworks.
If you are looking for an evaluation of frameworks, I have a resource for you. Back in 2007, I ran the practice of Enterprise Architecture for the Architecture Strategy Team at Microsoft. At the time, my team contracted Roger Sessions to write, "A Comparison of the Top Four Enterprise-Architecture Methodologies" to be hosted on the Microsoft Enterprise Architecture portal that I ran. Since then it has gotten quite a bit of attention. It is due for a refresh as it is clearly out of date now. It was a good first start but needs more quantification and classification to really do these justice. I am looking at a refresh of that whitepaper and will have an update soon. Stay Tuned!
Apples and Oranges
I would like to start us off with the notion that not all frameworks are the same and not all serve the same purpose. In many ways these comparisons have been like comparing apples and oranges. For a number of years I have observed that architects tend to compare these frameworks as if they all were built with the same goal in mind. With this logic there is no real winners in the comparison, just confusion.
TOGAF is routinely compared to other frameworks. In many instances it is unfairly compared to other frameworks that serve another purpose and/or outcome. We first have to split these into two areas:
Area of Focus - Defines the disciplined area of focus of the framework. Examples would be: Service Management, Program Management, Architecture Development, Software Development, etc.
Type of Architecture Framework - A defined set of segmentations to identify the logical groupings of frameworks with similar origins, goals and outcomes.
We first want to look at the area of focus when comparing frameworks. We want to make sure we are in the "same ballpark" when we compare. By looking at this we can use it as the qualifier to quickly see if we compare at all. For example, if you wanted to determine what is the idea EA framework for your orginization it doesn't make much sense to compare frameworks ITIL vs. TOGAF or COBIT vs. TOGAF (outside edge cases where this is done deliberately). These frameworks have completely different:
problems it trying to solve
outcomes
supporting processes
stakeholders, suppliers and customers
deliverables
When we evaluate frameworks that were built to support a different outcome than the outcome we are looking for in EA the comparison is fundamentally flawed.
Once we determine that we are "in the same ballpark" and comparing architecture frameworks, we then can look at the the types of architecture frameworks.
Three major types of architecture frameworks:
General Purpose - frameworks that are purposefully generic in application and built to be highly reusable and modular to support a broad range of outcomes, industries, skills and maturity levels. Examples include: TOGAF, Zachman
Business Specific - frameworks driven by a set of defined business or industry concerns. Examples include: MODAF, FEAF, TEAF, DODAF
Vendor Specific - frameworks that are aligned to specific offerings provided by that vendors. Examples include: Oracle EA, Microsoft Value Realization Framework, Cap Gemini IAF (deprecated and merged w/ TOGAF)
Making Comparisons
So far we haven't really talked about evaluating or comparing frameworks. What we have done is set some important data points for us that will be a large part of our evaluation.
According to Wikipedia, evaluation is defined as such:
Evaluation is a systematic determination of a subject's merit, worth and significance, using criteria governed by a set of standards. It can assist an organization to assess any aim, realisable concept/proposal, or any alternative, to help in decision-making; or to ascertain the degree of achievement or value in regard to the aim and objectives and results of any such action that has been completed.
There are two key points that I've highlighted, merit (what I want to get out of this) and structured and governed criteria.
A simple 7 step full lifecycle evaluation process that I use for an evaluation of an architecture framework has the following steps:
Rational - Why I'm evaluating architecture frameworks and what are the key drivers. This typically will result in a set of the critical questions that need answered with some well structured criteria.
Identification - The goal of this step is to quickly and qualitatively to identify a "short list" of architecture frameworks that align to the problems we are trying to solve with the architecture framework (Step 1 - Rational). We do this by:
Apply the rational or value driver statements to the list of frameworks available.
Architecture Framework Area of Focus (discussed above) - This allows us to quickly get to a smaller set of frameworks to evaluate
Architecture Framework Type (discussed above) - This further cuts the list down to a finite set of frameworks.
Trade-Offs - With the short list of architecture frameworks go through a well disciplined trade-off analysis with the identification criteria above. This should identify all the change management challenges that you will encounter with people (maturity level, skills, etc.), tools / technology and process changes that will be needed. This should lead to the overall costs and benefits that address the rational subsequent value drivers.
Selection - The selection of the architecture framework with well defined implications of the decision with the criteria of selection.
Implementation - Phased implementation of the architecture framework.
Govern - Established body that governs the architecture framework health with measurements of effectiveness in the organization.
Validity - After a period of time has elapsed (sometimes yearly) a life-cycle is implemented around the architecture framework to ensure that that the organization is getting maximum value out of the framework.
Conclusion
When you are evaluating TOGAF for your needs there isn't an easy or direct answer. You have to go through a process to determine what framework is right for you. This post nor a LinkedIn forum will be able to answer that question for you. Start with what is important for your organization. Meaning, what drives value for you. If you're a government agency, it makes sense to start off with one of the popular government EA frameworks such as: DODAF, MODAF, TEAF, FEAF etc. If you are in an industry segment which has a framework defined like telecommunications then TMForum is a leading candidate.
Since TOGAF is a general purpose framework, I tend to look at TOGAF as a framework of frameworks. It is really built to be the "platform". It was designed with reusability, modularity and assembly as first class citizens. It will not give you the prescriptive process, rather it is descriptive of the areas of concern and YOU choose what is "fit for purpose" for your problem set. As I mentioned in my last post, this does add a layer of complexity but I do believe it provides the ability to come to the fastest possible value to market in an architecturally rigorous way.
If you are comparing TOGAF to FEAF or a vendor framework you are not comparing apples to apples. These architecture frameworks have different inputs and outputs in mind. Comparing TOGAF to Zachman is a closer fit. However there isn't many more general purpose frameworks that are "open source" like TOGAF. A fair comparison would be MODAF vs. FEAF or Microsoft VFR to Oracle EA Framework. These are comparing the same value drivers. But when you mix these types it causes confusion and endless debate.
If you are looking for extended information on this topic I will be writing a full whitepaper going into an extended look into the process, the framework and a EA Framework Evaluation Matrix that will compare a set of the common EA frameworks on the market based on a set of attributes (outside a specific EA organization need) in a qualitative and quantitative way. If you want a sneak peak at the drafts or you want input into the process leave a comment below.
Comments