Jaa

Merging EA Frameworks

  • Artikkeli

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.

Comments

  • Anonymous
    August 06, 2008
    Hi Nick, Dont forget the "secretive" IAF framework from CapGemini. /m

  • Anonymous
    August 13, 2008
    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

  • Anonymous
    August 22, 2008
    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.

  • Anonymous
    August 22, 2008
    The comment has been removed

  • Anonymous
    August 23, 2008
    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).

  • Anonymous
    August 24, 2008
    Hi JJ, Thanks for the link to Praxeme.  I'll take a look. --- N

  • Anonymous
    August 31, 2008
    The comment has been removed

  • Anonymous
    September 01, 2008
    The comment has been removed

  • Anonymous
    September 01, 2008
    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? :-)

  • Anonymous
    September 02, 2008
    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

  • Anonymous
    September 24, 2008
    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.

  • Anonymous
    September 24, 2008
    The comment has been removed