Merging EA Frameworks

  • Article

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.