I’ve spent some time of late looking at various EA frameworks. Nothing perfect out there yet, but quite an array of useful things. But what would it take to create a single consistent framework for the IT profession? Let’s look at the stuff that’s there now. (Caveat: I reserve the right to be wrong. If you disagree with anything here, send me an e-mail and I’ll update the text).
- TOGAF – Basic strength: solution architecture. Various models and how to create them. Basic weaknesses: Planning methods and governance framework. Weak on Information Architecture
- FEAF – Basic strength: complete implementation tied to measurement framework. Basic weaknesses: very specific to government, lack of independent process taxonomy keeps processes “in the silo.”
- eTOM – Basic strength: excellent process taxonomy with rich details. Strong information architecture. Great for governing external vendors. Basic weaknesses: fairly specific to telecom industry, gaps in governance and enterprise architecture models.
- ITIL – Basic strength: excellent process framework for operations and (now) governance. Basic weaknesses: no architectural methodology to speak of. Sizeable gaps in information or application architecture.
- Enterprise Unified Process – Basic strength: soup-to-nuts coverage of enterprise software development processes, including funding and operations. Basic weaknesses: poor adoption rate and lack of a governing body to allow for growth, minimal architectural methods, no enterprise process or capability framework.
- Zachman – Basic strength: comprehensive taxonomy of architectural artifacts (to let you know when you are done). Basic weaknesses: Lack of published and vetted methods to avoid “boil-the-ocean” exercises and focus on one particular benefit. Very shallow: No detailed process, capability, or solution frameworks for “level 2” detail. Highly proprietary.
What would an ideal framework look like? It would have all of these things. This list is “off the top of my head,” so I’m going to miss a few, but this is where I’d start:
|
Capabilities / Measurement / Process model for the enterprise |
Capability and process modeling take a huge hit when trying to create an enterprise model just to create the base taxonomy. A published taxonomy, governed by a passionate community, is necessary to get enterprise architecture efforts up to speed in non-Fortune 500 organizations. |
| Service, Solution, Feature and Technology model | Application simplification and portfolio management require a base taxonomy of solutions and technologies to align the work in various divisions and speed up adoption of integrated solutions. An industry standard taxonomy is necessary to allow vendors to provide useful information up front and smooth the development of SOA services across the enterprise. |
| Detailed process descriptions for all aspects of IT | If wishes where horses, I’d merge ITIL and TOGAF and EUP and MSF and Agile processes to get a consistent, community governed, richly detailed process model for all aspects of Information Technology governance, processes, and measurement. Include measurement, planning, improvement, transition, operations, and introspection. Takes a “business of IT” approach. |
| Rich architectural methods and training for all aspects of architecture | Starting with TOGAF, I’d extend the ADM to cover, in rich detail, three subtypes of architecture (collaboration and measurement across the enterprise, governance within a functional unit, solution design and development) across three architectural “areas of focus” (business capability and processes, information design and integration, solution development and technologies). It is simple to create this “table.” Doing so allows us see the opportunity to fill out the ADM. |
| Richly detailed “Business conceptual model” | Everyone has their own ideas of what basic business terminology means. A community governed business conceptual model can be governed by, and provided to, business schools around the world to create and maintain consistent information models. This removes one of the key causes of software project failure: failure to share common context. |
| Multiple federated “common information models” | Some industry implementations of EA frameworks are already here, and some vendors provide a good starting point for the shared elements (for common, shared processes). A framework to allow not only many models, aligned by industry or attributed types, but also to allow organizations to create and manage federated models within their own walls to manage their unique value proposition while keeping their information models aligned. |
The frameworks that are there are just not ready to do everything. Only by describing what ‘everything’ would look like can we begin to fill these gaps.
Hi Nick,
Dont forget the "secretive" IAF framework from CapGemini.
/m
Hi Michael,
Microsoft has a framework as well, that we use in our consulting business. I didn’t list it. Nor did I list the framework that IBM uses.
Consulting frameworks are not something that a consuming business can leverage without purchasing consulting services. Let a book be written or some very public information made available, and then it may show up in a public comparison like this one.
That is not a slam. It is reflective of the fact that I cannot compare things without information, and these companies are not quick to make their details public, much less expose them to a comparison.
The ONLY reason I list Zachman is because he has published some materials and given sufficient information in the public domain that I can make a comparison.
— N
It is really possible to merge all the architecture into one? My thought is, there is not going to be one silverbullet that will solve the problem. Just like which project methodology is good, waterfall, iterative, agile… Architecture framework is similar to that. I would pikc the one that fits the problem statement.
Hi Gaja,
A framework is not a silver bullet. It is a tool. Right now, a set of tools (different frameworks) have been developed to solve similar problems from different viewpoints. Each tool, in its own right, is not complete, so you MUST use many tools. It is difficult to use two or three tools, because every problem has to be solved in different ways. Very disjoint.
But the tools do not have to be disjoint. There can be an integrated tool that helps solve many problems.
The frameworks are all growing to solve new problems, each to fill in their own gaps. They will each grow towards some idea of "complete." In this post, I have provided my idea (today) of what I think complete may look like.
I’m not suggesting that a silver bullet will fix things. But I am suggesting that a better understanding of common problems can lead to a consistent tool that is useful for more situations, and therefore easier for many people to use.
— N
Nick:
you should take a look at Praxeme (http://www.praxeme.org), this is a modern EA framework that was built with SOA in mind.
They have translated most of the documents now (as it was originally written in French).
Hi JJ,
Thanks for the link to Praxeme. I’ll take a look.
— N
Maybe it’s because I’m British, but I think the current version of MODAF is more SOA-friendly than DODAF. (With its emphasis on strategic capabilities, it’s also perhaps more Microsoft-Motion friendly.) See my post on MODAF Version 1.2.
http://soaprocess.blogspot.com/2008/07/modaf-version-12.html
Hi Richard,
You are correct, I should also include MODAF in any good comparison, given their public nature. I do like their SOA work. If anything, I don’t think that they went far enough in their SOA support, failing to indicate SOA services at the informational level (As far as I can tell, not being an expert on MODAF).
But their approach is much better than most.
— N
I think an ideal EA framework can start out by being generic, but gradually will move towards domain specilization. Eg: Transportation industry will have its own EA framework, that can be used within that vertical. Most of the frameworks mentioned here, suit broadly any kind of industry, and have roots based on a technology framework. Hence, we see lot of system/implementation specific details within such frameworks, but less on governance, enterprise and information aspects. I guess various organizations have to implement these frameworks, in order to come up with a COTS framework which can be plugged and played. Futuristic? 🙂
Hello BA,
I think you are saying: stuff evolves from general to specific… right?
If so, I agree. I’m hopeful that the ‘industry specific’ frameworks can be variations / adaptations built on top of a fairly solid core framework.
Right now, the core framework is lacking, but it is becoming.
— N
I curious as to why you say the Zachman Framework is highly proprietary given that it is a framework, not a application, not a methodology, and does not specify in any manner what the primative models should look like or which standard they should follow.
Hello Karen (Data Modeler),
Zachman Framework is owned and tightly controlled by ZIFA, the company run by John Zachman to this day. While John makes presentations on a regular basis, he has not released his framework into the public domain and he earns his income consulting on how to use it, leverage it, and benefit by it.
Nothing wrong with that. We call that capitalism. We also call that ‘intellectual property.’
Given that the framework components of Zachman that ARE in the public space (if not the public domain) are without guidance, but there is a great deal of information that is useful, but is only provided when you hire ZIFA, I think it is completely fair to term the Zachman framework as proprietary.
Disclosure: I work for Microsoft. We have some proprietary stuff too. I didn’t include that stuff in the comparison at all!
If I had, my adjectives would have been similar. Big difference: our framework stuff didn’t change the world. John Zachman’s work did.