A lot of attention – in the media, on EA-oriented websites, at conferences, and in the minds of enterprise architects themselves – is devoted to EA frameworks. What are they? Should I use one? If so, which one? What do I use it for? It’s time to stop the questions and figure out once and for all – what are they good for?

EAdirections’ approach to Enterprise Architecture is framework-agnostic – that is to say, we can tailor the approach to include the use of a framework that fits your needs, or we can help you be effective without one. However, that is not to say that we think frameworks are useless. On the contrary, if you understand the strengths and background of a particular EA framework, it can be a valuable aid.

EA Frameworks, made popular first by John Zachman, and since by many different EA framework creators, tool vendors and practitioners, appear to be a very polarizing phenomenon. There are many devotees to a particular framework; others who are certain you must have one, but not sure which one to pick or how to use one they have chosen; others who could take them or leave them; with still a few who would tell you they are a big waste of time. This article is going to provide you with a way to understand and make decisions about EA Frameworks.

What is an EA Framework?

Many terms are mistaken for or considered the same thing as ‘framework’ when discussing EA frameworks. Words like taxonomy, process, and methodology, or model are often confused with framework. When defining many terms related to EA, providing just a semantic definition from a reference source such as a dictionary is not always adequate. It is often necessary to not only understand the meaning of the term(s) involved, but also to provide the context in which it is used relative to EA, as well as provide examples.

• Dictionary: framework:  n. 1) A structure for supporting or enclosing something else, especially a skeletal support used as the basis for something being constructed; 2) a simplified description of a complex entity or process (syn.: model)
• EA Context:  An EA framework is a model or outline that provides the logical structure within which EA deliverables will be created and related to each other
• Intent of EA Framework: Provide a simplified context for the scope, analysis and structure of an enterprise and its components
• Examples:  Zachman Framework for Enterprise Architecture, TOGAF, DODAF, MODAF, FEAF

Based on the semantic definitions (above) that most closely reflect the usage of the term framework in reference to EA, the key elements are ‘structure,’ ‘simplifying a complex entity,’ and ‘model.’ An EA framework is a model. The model provides the logical structure within which the outputs of the EA process (models, guidelines, documents and other deliverables) will be organized – placed in an area of the framework that gives it context to the whole and a relative place among all other deliverables. The intention of an EA Framework is to simplify the overall scope of an enterprise, as well as the complexity of the interrelated components within.

The key to using an EA framework is to understand that it provides guidance primarily in 2 areas:

• Defining the scope and breakdown of the EA effort (i.e. What areas of the enterprise are being architected? What are the components of the enterprise?)
• Categorizing deliverables to provide an organized and logical access path to them by the end-users of EA deliverables

General Characteristics of an EA Framework

There are a few characteristics that most EA Frameworks possess that make them valuable:

• Comprehensive
• Visual
• Simplification of the topic area
• Represents work not necessary to repeat, but rather as a starting point to adapt representative concepts/models to your specific enterprise

Pros: Why Use an EA Framework?

There are several reasons why you should consider the use of an EA framework:

1. An enterprise is a very complex entity.  Good frameworks simplify the complexity of the entity they represent.
2. EA needs to present a simplified version of that complexity for analysis, communication and deliverables.  Simplification of the enterprise into its elements will be a tremendous aid in breaking down areas of analysis, communicating with technical and non-technical audiences, and deciding which types of deliverables to create and how to categorize them.
3. Frameworks help to organize the huge number of complex elements and relationships that make up an enterprise.  The complexity of an enterprise is not only attributable to size and sheer number of elements, but also the number of relationships that exist organizationally, between business processes and other processes, as well as the relationship among business processes and the supporting information, applications, and infrastructure, and finally the interrelationships among information, applications and infrastructure components.  Frameworks help in identifying and simplifying the relationships, allowing you to organize them into areas of interest for analysis, communication and deliverable access.
4. Highlights all the areas to consider for the scope of your EA.  One of the biggest challenges for many enterprise architects is defining the scope of the EA.  Frameworks provide a
5. Why repeat work that has already been done?  While a specific framework will likely not be a perfect fit for your enterprise and your EA program, many of them are great references for creating your own or can be customized to fit your needs more closely.

Cons: Why NOT to Use an EA Framework

There are several reasons why you should NOT consider the use of an EA framework:

1. Process. Process. Process.  The process that is used to develop an EA program, develop the EA deliverables, and then integrate EA into the decision making fabric of the enterprise is more important than the framework you choose or the tools that you use.
2. You must think thoroughly through all aspects of your EA for your Enterprise – Do not let frameworks do this!  A framework really helps in thinking through the topical, functional, operational elements of the enterprise; however, many enterprise architects will miss some of the most important aspects of EA by “following a framework” – including culture, politics, leadership, maturity, communication styles, governance, and all of the unique factors of your enterprise that can’t be captured by a general purpose EA framework.
3. Your Goals & Objectives must drive WHAT you do and WHAT you model – not a framework.  The most important driver of what you do in any given iteration of your EA process is the set of goals and objectives you are trying to meet.  EA frameworks are not always tolerant of a less than complete scope and objectives.
4. “Just enough architecture, just in time” Being pragmatic is one of the most critical characteristics of an effective enterprise architect.  Big Bang doesn’t work – you don’t get extra benefits for completing a part of a framework compared to delivering what a business unit or project team needs now.
5. Enterprise Architecture is still more of an art than a science, and demands creativity.  The demand for creativity cannot be satisfied with someone else’s framework.  Today’s environmental forces will continue to drive the need for quicker, more adaptive decision making, and conforming to the artificial and rigid constraints of an EA framework can be an obstacle to agility.

Choosing a Framework

There are many different EA frameworks available in the public domain. A list of the most well known frameworks and web links to some useful sites for these well-known links are available in the Appendix of this article.

• What are you trying to accomplish?  The framework must fit your needs, not vice versa, or be customized to meet your needs.
• What industry are you in?  There may be industry reference models that can provide a basis for your own framework.
• Are you federal or state/provincial government?  There are specific frameworks for some federal and state/provincial governments, such as Department of Defense Architecture Framework (DODAF) for US Department of Defense, NASCIO Enterprise Architecture Framework for US state governments, and Standards and Architectures for e-Government Applications (SAGA) for German agencies.
• What was the candidate EA Framework intended for?  Every framework had a design point (or problem it was designed to address) when it was initially created.  Understanding the initial intention for candidate frameworks will enable you to compare it to your intended usage.  For instance, the FEA Reference Models are primarily intended to help US government agencies meet the OMB requirements for EA to get capital investment budgets approved.   
• What level of competency do your EA resources have?  More experienced architects are liable to leverage an EA framework effectively, while less experienced architects may be misguided in their use of a framework.
• What is the scope of your EA effort?  Decide this before choosing a framework, then only concentrate on the elements with the framework that correspond to your defined scope.
• Which framework(s) resonate(s) in your organization?  Above all else, a framework must be understood by the EA team and the consumers of EA deliverables – project teams, domain working groups, infrastructure engineers and operations professionals.

Our Recommendation: Just Enough Framework

Our recommendations for using an EA Framework are born out of the experiences of our clients over the last 10 years. They are intended to drive one towards achieving benefits in a pragmatic manner.

• It’s your Framework!  Make sure you choose a framework or frameworks based on your needs, and use it (them) as reference for a framework that is more specific to your enterprise’s business model, processes, terminology and maturity.
• Scale back.  Most EA frameworks are going to be so comprehensive that it would be infeasible to attempt its entirety in any reasonable amount of time.  Your enterprise is going to be continually changing – so will the focus of your EA and the usage of an EA framework.
• Don’t be a slave to completing it.  Completing the framework should never be a goal.  The framework can provide suggestions on what models should be created for a given focus area of the enterprise, but completing the model for the sake of completing the model is not recommended.  Unless you have an identified consumer with a valuable need for a particular model or set of models, your time should be better spent elsewhere.
• Find tool support.  If you have chosen/customized a framework and are looking into an EA modeling and/or repository tool, one of your selection criteria should include the support for your chosen framework and the ability to customize its presentation and usage to fit your needs.

Conclusion

Ok, so where does that leave us. To put it simply, an EA Framework will help you answer the “What?” questions, but not the “How?” questions. An EA framework can prove to be a very valuable aid in developing and effective EA program if used with diligence and understanding.

Directions: Find an EA framework that meets your needs or can be customized into a framework that fits your situation – Do not allow a general-purpose public domain EA Framework to guide your work effort.

Appendix:

Framework Inventory – Links to Public Domain EA Frameworks

The frameworks listed below represent those developed for external consumption by other than the framework developer. Some of them are generalized frameworks applicable to most environments (i.e. Zachman, TOGAF, IAF), while others are intended for consumption by a targeted set of consumers, such as DODAF for the U.S. Department of Defense, NASCIO for individual state governments, and EIF for pan-European e-government services. Still others are targeted at a specific type of architecture, such as CIMOSA and PERA for computer-integrated manufacturing. The power of a framework, however, is in how it is applied to help a specific organization frame its own EA effort. Regardless of the intended target audience for a framework, consumers may find elements of many different frameworks to incorporate into their own customized framework.

The Zachman Institute for Framework Advancement
The Zachman Institute for Framework Advancement (ZIFA) is a network of information professionals who understand the critical role of Enterprise Architecture in the ability of the enterprise to successfully participate in the global economy of the 21st century. To this end, the mission of ZIFA is to promote the exchange of knowledge and experience in the use, implementation, and advancement of the Zachman Framework for Enterprise Architecture.
            http://www.zifa.com/
            Related Links:
                        Download a copy of the Zachman Framework for Enterprise Architecture
                        Zachman International

The Open GROUP Architecture Framework (TOGAF)

TOGAF, The Open Group Architecture Framework, is an industry standard architecture framework that may be used freely by any organization wishing to develop an information systems architecture for use within that organization.  TOGAF has been developed and continuously evolved since the mid-90’s by representatives of some of the world’s leading IT customer and vendor organizations, working in The Open Group's Architecture Forum.
http://www.opengroup.org/togaf/
            Related Links:
                        Download an evaluation copy of TOGAF
                        The Open GROUP Architecture Forum

Federal Enterprise Architecture (FEA)
To transform the Federal government to one that is citizen-centered, results-oriented, and market-based, the Office of Management and Budget (OMB) is developing the Federal Enterprise Architecture (FEA), a business-based framework for government-wide improvement.
http://www.whitehouse.gov/omb/egov/a-1-fea.html
            Related Links:
                        Download FEA Reference Models
                        Overview Presentation of the FEA, February 2004

Department of Defense Architecture Framework (DODAF)  
DODAF replaces C4ISR in 2003 as the United States Department of Defense’s architecture framework, aligning more closely with the Federal Enterprise Architecture Framework. 
http://www.dod.mil/nii/global_Info_grid.html
            Related Links:
                        Download DODAF documents
                        DoD Enterprise Architecture Congruence Community

Ministry of Defence Architecture Framework (MODAF)  
This website is a public resource for the MOD Architecture Framework (MODAF). From here, you can download all the published MODAF documents, and some of the draft documents which were produced during the MODAF development process.
http://www.modaf.com/
            Related Links:
                        Download MODAF documents
                        MODAF Discussion Forum

Extended Enterprise Architecture Framework (E2AF)  
The Extended Enterprise Architecture (E2A) in the world of organizations and Technology is addressing 3 major elements at a holistic way: The element of construction, the element of function and the element of style. Style is reflecting the culture, values, norms and principles of an organization. Most of the time, the term enterprise architecture is dealing with construction and function, without any attention of the style aspect, while the style aspect reflects the cultural behavior, values, norms and principles of that organization in such a way that it reflects the corporate values of that organization.
http://www.enterprise-architecture.info/Images/Extended%20Enterprise/Extended%20Enterprise%20Architecture.htm
            Related Links:
                        View the E2AF

NASCIO Enterprise Architecture Framework  
The National Association of State CIOs Enterprise Architecture Frameworkrefers to the overarching structure that addresses all of the elements of the Enterprise Architecture. Additionally, it defines the interrelationships between these elements in a consistent and organized fashion.
http://www.nascio.org/nascioCommittees/EA/
            Related Links:
                        Download NASCIO toolkit components

Integrated Architecture Framework (IAF)  
Capgemini has developed a unique approach and common language for all stages of architecture design called the Integrated Architecture Framework (IAF).
http://www.opengroup.org/togaf/
            Related Links:
                        Capgemini’s Architecture Framework for Enterprise SOA

Computer Integrated Manufacturing Open Systems Architecture (CIMOSA) - last updated in 1996
The aim of CIMOSA is to elaborate an open systems architecture for Computer Integrated Manufacturing and to define concepts and rules to facilitate the building of future CIM systems.  It was developed by the ACIME Consortium, in and EU project.
http://cimosa.cnt.pl/      
Related Links:
                        CIMOSA Association- last updated in 1996

Purdue Enterprise Reference Architecture
This site is meant for Computer and Telecommunications Network Professionals, Control Engineers, Enterprise Management, and Project Management who are responsible for design of Industrial and Corporate Control and Communication Systems. The Purdue Enterprise Reference Architecture ( PERA ) provides a valuable tool for the design of such Enterprise Systems.
http://pera.net/
            Related Links:
                        Original Purdue University site for PERA

The Generalised Enterprise Reference Architecture and Methodology (GERAM)
The scope of GERAM encompasses all knowledge needed for enterprise engineering / integration. Thus GERAM is defined through a pragmatic approach providing a generalised framework for describing the components needed in all types of enterprise engineering/enterprise integration processes.
http://www.cit.gu.edu.au/~bernus/taskforce/geram/versions/geram1-6-3/v1.6.3.html

Standards and Architectures for e-Government Applications (SAGA)  
SAGA is primarily designed for decision-makers in the fields of organization and in-formation technology (e-government teams) in German administrations. The document is a guideline that serves as an orientation aid when it comes to developing concepts for technical architectures and general technical concepts for individual IT applications.
http://www.kbst.bund.de/saga
            Related Links:
            Download SAGA version 2.0
                        English Language site

European Interoperability Framework (EIF)
The EIF is the reference document on interoperability for the IDABC programme. It is the result of an extensive consultation process with the Member States and thus represents the highest ranking module for the implementation of European e-government services.
http://europa.eu.int/idabc/en/document/3761
            Related Links:
                        Download the EIF version 1.0
                        For more information on EIF