By Chandra Mohan Rajasekharaiah

Need for EA

With the rampant global expansion of IT shriking the planet and breaking down the rules for business models, modern enterprises are facing new challenges. Their enterprise strategies and business requirements have changed significantly. At one end of the spectrum, they have at their disposal multitude of paths to choose for growth, and on the other, they have large inventory of isolated and out-of-context legacy that weighsd own on resources. With the requirement of speed becoming ever so important, enterprises need to architect themselves into a seamlessly integrated form that enables the enterprise to grow in accordance with an overall vision. The enterprises need methodology to develop to realize this overall architecture vision [MSD]. This is the offering of enterprise architecture.

Enterprise architecture is a complete expression of the enterprise: collaborating goals, visions, strategies, business operations, organization structures, process and data [SCH]. It is a meta-model, complete with architecture framework, methodology, best practices, and governance frameworks. EA attempts to be an overarching ‘meta-approach’ that models and ties together all the best approaches of the enterprise [BER]. EA attempts to optimize the legacy and new processes by bringing them under an integrated environment, and by breaking silos that might exist in the organization [GRI].

The EA Approaches

The modern enterprises are complicated. They comprise of organizations, lines of businesses, functional segments, business units; sometimes, even external entities are tightly interwoven or coupled into the various business units. In such a scenario, an enterprise’s goal would be to have a mature, broad, and hierarchical architecture, which incorporates all of the enterprise’s aspects.
To deal with the complexity and chaos of streamlining and smoothly operating a business, EA has become quintessential. EA is a meta-model complete with architecture framework, methodology, best practices, and governance framework. EA attempts to be an overarching ‘meta-approach’ that models and ties together all the best approaches of the enterprise [BER]. EA attempts to optimize the legacy and new processes by bringing them under an integrated environment. These EA attributes create flexibility for change, and make technology supportive of the strategy.
Over the past thirty years, many EA frameworks have been defined and developed: some through consortia (TOGAF, RM-ODP, GERAM, etc.,) some by the Department of Defense (DoDAF, FIAF, etc.,) and a few individual efforts (Zachman, EA³, etc.) This article focuses on two of these approaches. TOGAF is an EA approach that stems from TAFIM, a US government research project, which is heavily used in the industry, and has evolved from years of usage and experience. The EA³ is an EA architecture approach that comes with solid theory from the academia, and years of author’s personal experience, both on field, and as a key contributor of FEAF-II.

EA³

The EA³ is an open enterprise architecture framework that was developed in 2004 by Dr. Scott Bernard. The framework is designed as a cube, with some key ideas:

1. Hierarchies are needed to avoid disjunct sub-architectures.
2. Defining common methodology and repository for enterprise allows the enterprise’s technology to be driven by business changes, and business to be driven by strategic decisions.
3. Enforcing common principles to all the different types and segments of the enterprise is useful.
4. Enabling smooth information flow is quintessential for growth.
5. Allowing outcomes to be measured is advantageous: as a form of feedback process for future work, estimating ROI, capital planning, et.c,.

The EA³ is based on the primary function of organizing and planning IT resources and documentation of the Enterprise Architecture. The EA³ attempts to track and manage the assets across the enterprise; additionally, it also structures them by lines of businesses and functional units as well [SWE].

TOGAF

TOGAF (The Open Group Architecture Framework) is an EA approach developed by The Open Group. It comprises of a detailed method and a set of supporting tools for developing enterprise architecture. TOGAF is designed with the key idea to allow an IT enabled enterprise to streamline business requirements and directions to periodically drive the IT. TOGAF understands that an EA supports the business by providing the fundamental technology and process structure for an IT strategy. TOGAF also focuses on reuse of entire architectures to the largest extent possible, by providing a rich library of architectures – varying from the ones most specific to the domain, to very generic architectures. TOGAF draws upon its years of existence and continuously building library of frameworks that can adopted as is, or tailored to meet the needs of the enterprise.

EA Space

An enterprise architecture approach should provide

1. a methodology to create an architecture for an enterprise
2. a frameworka structure/set of structures for developing the architecture
3. artifacts, that describe various aspects of the architecture, and hence form the unit of knowledge
4. common diction for standardization across the enterprise
5. ways to assess existing capability, maturity and measure outcomes
6. reference models, set of reusable tools for building the architecture

Both EA³ and TOGAF lay emphasis on most of these, but structure them differently.
The clear demarcation of various elements of EA can be understood by looking at the EA³‘s definition of EA.

EA³ structures all these, and places these inside a governance boundary to enable smooth execution of EA work. For comparing the two, we will follow this model, and focus on the Methodology, Framework, Artifacts, Repository and Governance aspects of the EA in both approaches.

TOGAF’s structure of EA places emphasis on how these various structures revolve around IT.

TOGAF’s EA approach focuses on process and content, with the business drivers and vision driving the future, and the current state of the enterprise reflected by business capabilities. The TOGAF is built as a capability framework, where current capabilities are measured, required capabilities are discovered and IT projects spun off to complete the work.
The rest of this paper attempts to compare the two with respect to their different strengths and weakness of being a complete and comprehensive EA approach.

Methodology

Methodology is a generic term that can describe any structured approach for solving some, or all, of the problems in a particular problem space. Specifically, Methodology of an EA approach identifies the particular steps that establish a new EA program, and implement the documentation method specified by the approach.
Neglecting the details, both EA³ and TOGAF target the enterprise architecture methodology to be driven by analyzing the existing architecture, identifying the target architecture, and identifying the gaps. The next steps also aim at plotting a course from existing to target architecture fulfilling the gaps, and following the course.

EA³ Methodology

EA³‘s methodology is a 20 step process, segmented into four phases. The highlight of the methodology is the inclusion of a higher-order business direction, the strategy of the enterprise.
The initial phase is the establishment of an EA Program. This involves the steps required to identify the executive committee for the EA (possibly an architecture board with a chief architect,) and the stakeholders for the EA (who would benefit from EA, and hence would fund the EA efforts.) This requires a buy in from stakeholders and the management. The actual methodology is tailored in this phase adapting to the needs of the enterprise. The phase also identifies and establishes the channels of communication and feedback between every department and role of the EA effort – from the executives of the enterprise to the individual teams.
The second phase is the process of selection of EA Framework and Tools. The EA³ is flexible enough to accommodate external frameworks, and pick tools from existing solutions of the organization. The phase also deals with identifying the lines of business and various segments of the enterprise. The initial version of an architecture repository (possibly The Living Enterprise) is established in this phase.
The phase III deals with documentation of the EA process. As the first step of this phase, the existing architecture is identified, evaluated, documented, and brought into the architecture repository. The next step is to create several business and technology operating scenarios. This brings intuition about the future of the entire enterprise into the EA methodology. The phase also emphasizes on software applications and tools that can support automated EA documentation.

The final phase of the EA³‘s methodology is the actual use and maintenance of EA by the enterprise. This phase is the actual implementation phase, where the documentation and knowledge that was accrued in the prior phases is put to use. The EA documentation will aid as a planning tool for future expansions (in terms of resources, organizations, etc.,) and serves a guideline for making informed decisions. This phase is the ‘running’ phase of the EA process, where the enterprise has created a self-sustaining information base which is updated automatically. Once the enterprise enters the Phase IV, it can harvest the knowledge from the repository. The phase also imposes importance to manage the EA, by adding a separate step in the methodology to plan updates to (at least) EA annually.

The ADM

TOGAF’s methodology, termed as ADM ñ Architecture Development Method, is an iterative process that identifies a cyclical sequence of steps to address needs of each of the different segments of the enterprise. The focus of the ADM is to create a process that fits into the enterprise’s release cycles; hence, ADM’s customization to suit the enterprise’s needs is encouraged. The methodology is amenable for change at every cycle, at the beginning of which the scope can be fixed.
The ADM has eight phases that comprise a cycle, and some preparatory work before beginning the ADM cycles.
The very first phase of ADM is a Preliminary Phase, wherein the scope, participants, and sponsors are identified. This decides the feasibility and scope of architecture work based on the existing constraints on the enterprise, such as budget, time among other factors. This phase also involves (a) creating an architecture repository, (b) defining architecture principles and business goals/drivers, including any modifications to ADM, and (c) selecting the appropriate architecture frameworks. This is a one-time phase that decides the strategy of the entire EA approach, and lays a baseline for expectations and measures.
Once the scope and expectations/measures are decided, the iterative ADM process is triggered with the Phase A, the Architecture Vision phase. As a part of the first steps of this phase, various capabilities of the enterprise are assessed, the results of which lead to defining the scope: the scope could be ranging anywhere from small subset of activities to a big-bang EA implementation. Once a scope is set, the cycle’s goals, principles, measures, risks and activities are identified. This is followed by creating a statement of architecture work and getting a sign-off from the stakeholders.

The next three stages of the ADM Phases B, C, and D (Business, Information System and Technology Architecture Phases) focus on creating the business, data, application and technology architecture to satisfy the requirements and scope defined in Phase A. The Phase B – business architecture phase – focuses on identifying the current business architecture, identifying the gap, and defining the future business architecture to address the gaps in the Architecture Definition. Similarly Phase C – Information System phase – focuses on data and application architecture and Phase D with technology architecture sections of the Architecture Definition.
The Phase E – Opportunities and Solutions Phase – centers on identifying the build/buy decisions to solve the gaps identified in the earlier phases, and also to comply and complete the Architecture Definition. This leads to Phase F – Migration Planning Phase – that deals with the detailed planning of implementing the solutions identified in the earlier phases. The various segments/lines-of-businesses’ managers are involved in the planning process to ensure feasibility.
The Phase G – Implementation Governance – involves the interaction between the EA board, the committee responsible for overlooking the architecture of the enterprise, and the implementation teams. The governance here refers to the activities of the EA board in ensuring the changes brought about in IT are in-line with the proposed architecture, using the Migration Implementation Plan.
The final phase, Phase H – Architecture Change Management – involves steps in assessing the gaps in implementation of the architecture that might have identified in the beginning of the cycle, or that might have happened (possibly unknowingly) in any of the phases. These gaps, along with the changes that might be required to support future growth result in Change-Requests, which are possibly the inputs for the next cycle.

Other notable features of ADM are

• Sequencing the phases of an ADM cycle as required: {A, B, A, B, C, B, C}
• Constant updates to the requirements of architecture

Comparison of Methodologies

To map the various phases of EA³ with ADM, the first three phases of the EA³ are roughly equivalent the Preliminary phase and some parts of the Phase A of the ADM. The fourth phase of EA³ is expanded into the Phases B through H of the ADM.
The first obvious noticeable difference in the two methodologies is TOGAF’s IT centricity, as opposed to EA³‘s focus on strategy. The methodology assumes the changes to essentially originate in business, and always end up as IT changes. This disconnects the changes to various segments from reflecting in the overall EA until a certain phase. For instance, the TOGAF’s governance, implementation touch-points, and information flow between involved parties is discrete.
The preparatory work of EA is not as well documented in ADM, as in EA³. EA³ dedicates almost three phases towards the preparatory work, whereas ADM contains a single preliminary phase, which mostly covers the tactical aspects of EA. However, on the flip side, only the steps 18 and 19 of EA³‘s Phase IV discuss the steps to implement the EA. These steps are elaborated in ADM: the ADM details the process of EA implementation, specifying steps to carry out the changes through to completion.
Both EA³ and ADM bring in good discipline into EA. Both attempt to enable boundaryless information flow in the enterprise. However, though TOGAF understands the need for boundaryless information flow, it only confines to suggesting III-RM model, not providing a model. This is probably a shortcoming in TOGAF, as in EA³, the process needs to be boundaryless, not the products.
ADM scores in the area of describing a method to adjust the enterprise’s architecture to existing IT. The problem in ADM, however, is the duration of these cycles that might delay the realization of strategy if improperly followed. The EA³, on the other hand assumes the constant update and maintenance of EA³ framework is enough for the enterprise’s architecture requirements. The reason for the difference is mainly because of the focus of TOGAF on bringing IT under the EA umbrella, whereas that EA³ is to create an EA metamodel that involves every aspect of the enterprise under one umbrella.

Framework

Framework identifies the scope of the overall architecture and the type and the relationship of the various sub-architecture levels and threads.
The EA³ has a detailed framework that defines the content, or the what, of the EA approach will document. Though TOGAF is described as a framework, the emphasis is more on the methodology (ADM,) and less on the framework aspects [MSD]. The closest things to a framework in TOGAF are the concepts of an Architecture Content Framework and Enterprise Continuum.

The EA³ Cube

The EA³‘s framework, termed EA³ Cube, ties together the various artifacts, responsibilities and processes of EA into a three-dimensional hierarchically arranged composite. The framework has multiple layers of depth – each layer indicating a line of business, multiple layers stacked vertically indicating the hierarchical levels of the enterprise, and cross-cutting dependencies and components forming the cube.

Each level is placed in the cube to indicate the hierarchical relation between various levels and functional areas of the enterprise. The top layer focuses on the strategic goals of the organization, and as the layers below focuses more and more on tactical goals of the enterprise. The cross cutting concerns are captured at the same hierarchical level, as the decision in one line of business, and layer might require similar alterations at the equivalent level. For example, a change in goal by a CXO might affect the functioning of another CXO at the highest level. The EA³ Cube attempts to capture such interconnections in the enterprise, and attempts to enable smooth flow of information required for decision making.
The highest level of EA³ cube deals with the goals, initiatives and other strategic directions of the enterprise. These are the critical factors that decide the survival or prosperity of the enterprise. These decisions drive the rest of the enterprise’s architecture work.
The next level deals with the business requirements. These requirements tend to focus on identifying the business solutions described by the strategic directions of the higher level of the framework.
The third level deals with the data and information requirements of the enterprise, which arise from the business requirements. The realization of business requirements is designed and spelled out by an IT department that would create data and information banks that describe and map the business problems to software.
The fourth hierarchical level describes the systems, which involves creating and hosting the software solutions and services. The creation of software is dependent on the problem space defined by business, and solution space defined by the information levels; again, the requirements are driven by the higher layers.
The fifth level is the network and infrastructure, which describes the physical realization of the software solution. This involves tasks of building the network infrastructure, maintaining server farms, and building and maintaining software infrastructure to enable the software solution requirements.
Apart from the hierarchical levels and lines of businesses, the EA³ Cube also allows capture of cross-cutting concerns, such as security, across the various levels.

ACF and Enterprise Continuum

The documentation framework of TOGAF resides in two parts: the ACF – Architecture Content Framework, and the Enterprise Continuum.
The ACF describes three different kinds of work products:
i. deliverables that are contractually required to be signed off by stakeholders indicating approval
ii. artifact describing some aspect of the architecture,
iii. building blocks, readymade solutions that can be plugged in as is.

The Architecture Metamodel defines the formal structure of how various artifacts are grouped, and how they relate to each other. This architecture metamodel identifies all of these concerns (i.e., application, data entity, technology, actor, and business service), shows the relationships that are possible between them (e.g., actors consume business services), and finally identifies artifacts that can be used to represent them.

The highest layer is the architecture vision, which attempts to capture the strategy of the enterprise. The architecture vision yields architecture requirements, which define the enterprise architecture work.
Next, the business architecture captures the business goals, affected lines of businesses and the functional requirements. The information systems architecture captures the data entities and the information system entities that operate on them. It also captures the logical and physical components that realize these entities. Finally, the technology architectures deals with the platform which enables the realization of the information systems architecture. The architecture realization captures the governance of realizing the architecture.
With the focus on maximizing reuse, TOGAF attempts to create templates of entire architectures, termed building blocks. Hence, TOGAF describes an enterprise continuum, which is the classification method of the architectural knowledge base. Everything from business principles to technical standards to third party frameworks, all those things too that are present in your enterprise are classified as per the enterprise continuum. The enterprise continuum is further classified as architectural building blocks (generalized problem statements) and solution building blocks (possible solution set.)

Comparison

The EA³ cube has a framework that stretches to cover every aspect of an enterprise, and also how the various facets of the EA are hierarchically associated. The ACF and Content Metamodel also capture similar facets, but suffer in associating these requirements in a manner to indicate the direction of dependencies. The ACF is useful in capturing and arranging the EA information, but no in enabling the enterprise in harvesting the information at every level into knowledge that can drive the enterprise strategy, and hence the business.
The TOGAF focuses on the architecture requirements, and attempts to deal with separate set of documents that capture such requirements. These are not part of the EA³ cube, as such requirements are assumed to be in the cross-cutting components of the EA³ cube. The TOGAF has a broader frameworkand attempts to encompass the implementation and governance work of the EA to be included in the framework, which is missing in EA³ Cube.
The TOGAF scores from being able to provide a large ready-made/off-the-shelf solution and direction to enterprise, and allow standardization not only across the enterprise, but also across the domain and industry. The reason for this is that TOGAF has been widely used, and for a long time, which results in the creation of a large repository of building blocks.

Artifacts

Architectural artifacts are created in order to describe a system, solution, or state of the enterprise. With time, the artifacts evolve beyond being simple documents, they become models that guide progress, act as indicators of capabilities, and as essential knowledge frames for strategizing the enterprise.
Good artifact collection captures the essence of the enterprise – strategy in terms of vision and mission, business ideas and opportunities, present and future capabilities, functional aspects – among many other facets.

EA³ Artifacts

EA³ describes 46 recommended documentation artifacts that capture the enterprise’s EA at strategy, business and technology level.

The artifact list is only indicative, and can be augmented, or swapped with other documentation artifacts as required.
The artifacts are classified and arranged in a hierarchical fashion, within the EA³ cube structure. The strategic artifacts discuss the plan, mission and vision of the enterprise, and how the various programs and resources in the enterprise are aligned. The business artifacts identifies the business plans, along with the stakeholders and their perspective and understanding of these business ideas. The business artifacts attempt to umabiguously capture the business requirements, so that the next sub-architecture, data sub-architecture plan can be defined correctly. The data sub-architecture plan defines the key data and information elements of the enterprise. Ensuring data models are driven by business plans ensure correctness and appropriateness of these models.
The other artifacts mostly deal with tactical work, and capture state of the enterprise in terms of its resources. The systems sub-architecture artifacts capture the information about the infrastructure of the enterprise, how the resources are connected and used, and how the resources enable the enterprise to function. The systems sub-architecture artifacts might also contain performance measures, plans for infrastructure evolution, and other such strategic documentation with the resources in perspective. The network sub-architecture artifacts depict the actual hardware the realizes the infrastructure of the enterprise. These act as inventory and capability models.
The security artifacts and workforce artifacts address cross-cutting concerns from other departments such as Security Team, HR.

Artifacts and Deliverables

As discussed in an earlier section, TOGAF classifies the documentation artifacts as artifacts, deliverables, and building blocks. Central to the concept of TOGAF documentation is the concept of views and viewpoints. The documentation always describes (viewpoint) the system from the perspective of a stakeholder (view.)
TOGAF describes 43 artifacts grouped under 23 deliverables. The deliverables, artifacts are not produced simultaneously, but from the perspective of ADM. The preliminary phase, and phases A, B, E, F, G and H produce deliverables that are essential in the progression of the ADM.

Most of the strategic artifacts are created during the preliminary phase, and small changes are allowed phase A. The deliverables of Phase A capture the scope of the EA changes, phase B addresses the business changes to the architecture, phase C addresses the data and information system changes to the architecture, and phase D addresses the technology changes to the enterprise architecture. The deliverables from phases F and G describe the tactical planning aspects of implementation. Phase H deliverable addresses measurement and gap analysis along with any failures or misses in the cycle – mostly tactical.
The artifacts contain catalogs, core diagrams, and matrices. Like EA³, the artifacts deal with various layers of the enterprise architecture and address the strategic, business, and technology aspects of the EA.

Comparison

A rough mapping of the various artifacts between EA³ and TOGAF:

Mapping of catalogs to EA³ artifacts

Mapping of TOGAF core diagrams to EA³ artifacts
Mapping of TOGAF Extension Diagrams to EA³ artifacts

Visible from the comparison, is the fact that though the artifacts do not match one-to-one, the intent is quite the same. It is also interesting to note that neither of the approaches mandate a particular set of artifacts. Though the artifacts are comprehensive in collecting and depicting the enterprise’s architecture, they cannot be termed as complete and exhaustive.
This is a deliberate theme in both the approaches, for many reasons. The enterprises might have (will have, in most cases) existing documentation in various formats and notations. A very good example is UML. The UML is a de-facto standard for many technology enterprises, and the enterprises have expertise and repository of such artifacts. The enterprises might have regional or domain constraints in depending on some documentation.
TOGAF documents suffer from being too focused on tactical aspects of the enterprise (for instance, consider most of the artifacts in the opportunities and solutions phase.) The documents tend to focus on iterative development and will add to the repository as versioned history of the enterprise’s path to EA. This sometimes complicates things and makes knowledge harvesting from prior experiences and work a challenge.
EA³ scores with its ideas about keeping the documentation continuous, automated, and arranged for ease of access. Though most of the documents are extremely well thought off and are to be used in their entirety, some of the documentation artifacts in the technology domain may not be suitable for every organization. This is not a shortfall, as the enterprises current documentation can be swapped into the position of the artifacts to ensure completeness.
Keeping abreast with technology is an important aspect of an EA approach [SCH]. Technologically, EA³ is more suitable for cutting edge technology. The concepts of SOA, distributed applications, web applications are part of the recommended artifacts. These technologies are accurately placed in the right layers. For instance, the SOA work is correctly identified as being driven by business requirements. This is why EA³ has an extensive set of documentation, keeping abreast with both latest technology and retaining the requirements of legacy. Among other things, EA³ tries to be thorough in definition of roles and responsibilities. For instance, what TOGAF leaves unidentified as the ‘stakeholder’ is discussed in EA³.
TOGAF artifacts score in being more suitable for large enterprises with legacy, and/or established domains. The framework and artifacts are built for reuse and sharing. This, along with the fact that TOGAF has seen wide usage, allows TOGAF to have a rich reusable artifact base. Also, the artifacts are grouped together into reusable architecture templates, which vary in specificity.

Repository

Modern enterprises seek to organize the architecture information in a disciplined and efficient way, so as to avoid replication of information, improve accessibility of information and foster consistency [MIN].

The Living Enterprise

EA³ forces the enterprise to develop documentations in an automated way, in XML/HTML format, and store them in an online repository.

The Living Enterprise, the suggested EA³‘s repository, is an excellent example of arranging the documents in an online website.
The website has multiple tabs to indicate various lines-of-businesses and functional units, and each tab contains links to the artifact(s) that are arranged hierarchically. Designed with simplicity in mind, the format is that of a flattened cube, each tab representing a different segment.

TOGAFs Architecture Repository

TOGAF’s architecture repository attempts to not only contain the artifacts generated during EA, but also the best practices, reference models, and external standards.

Though the intent is to create a repository of any and every information generated in the enterprise, or for the enterprise, a structure for storing such content is absent.

Comparison

EA³‘s Living Enterprise is a better approach than the TOGAF’s: an online website allows
1. ease of access: the information is easily navigable, searchable and accessible
2. secure: access to the web pages can be controlled based on roles
3. visible: the changes are quickly visible to the intended audience

The TOGAF repository is all encompassing, and hence will be a vast base of knowledge. Unlike EA³, in TOGAF, enterprises will have to ensure the content is current, correct and organized. If done so, the artifacts can form a much larger inforamtion base.

Governance

EA Governance is the act of governing the entire EA process. EA Governance addresses managing, controlling, and guiding the various processes and workings of an enterprise. Good governance ensures the business of an entity is conducted as strategized: through guidance and by leveraging the involved resources. EA, being the `on-top’ process, deals with all the structures of the enterprise.

Governance is the effort to bring in

1. involvement from all parties by gaining commitment to comply to the process
2. transparency in decision making, and accountability of actions
3. provide independence to involved parties
4. fairness in the decisions and process to avoid unfair advantage to some

Governance in EA³

EA³ focuses on integrated governance. In EA³, EA governance is accomplished through processes that outline and guide the enterprise in its efforts to create and maintain EA, and groups that enable the process adherence and conformance in the enterprise. The governance is designed so as to coexist with, and integrate into the existing processes.
The EA governance of EA³ encompasses the Architecture Working Group that interacts with strategic planning, capital planning, workforce planning, program/portfolio management, and security governance bodies. The governance is accomplished through regular reviews of programs at the enterprise, segment, and system levels. These reviews look at both the business value in terms of priority, feasibility, risk, etc., and technology fit of the solution in terms of completeness and correctness.

The EA³‘s governance process is an iterative process, wherein the Architecture Working Group closely interacts with strategy, capital planning and IT to review programs and select for execution, to control the execution, and finally to evaluate and measure the outcome.

Governance in TOGAF

In TOGAF, governance is not addressed as a constant process, only a particular phase of ADM is earmarked for governance. The Phase G of ADM, Implementation Governance, describes the process of governing the realization of business requirements though IT. The Phase F, Migration Planning, produces an implementation and migration plan that is used as the guideline for governing the IT implementation.

The governance in TOGAF is directly under the supervision of IT, and hence headed by the CTO or the CIO. The governance activities are created and carried out by an Architecture Board, which consists of Enterprise Architects, and a Chief Architect. The goal of this Architecture Board is to create the various governance processes that are the guidance, and diffuse them into the enterprise, and enable conformance.
The governance, similar to EA³‘s governance, aims at linking IT processes resources and information to organizational strategies and objectives.

Comparison

EA³ clearly has a more involved and well directed governance framework than TOGAF. The governance in EA³ plays a central role in the organization by pushing the EA governance into the enterprise’s strategic and capital planning category, hence seamlessly integrating the entire EA governance into the enterprise governance. TOGAF’s governance is mostly limited to the IT governance, and the governance bodies do not add a ‘feedback’ value to the overall governance of the enterprise.

Conclusions

EA³ and TOGAF are both excellent EA approaches. The major differences arise from their target audience. TOGAF is more IT centric, and is in tune with the requirements of enterprises with legacy. EA³ is aimed at newer technology enterprises and enterprises where IT is considered as an extension that is directed by business and strategic requirements.
Currently, the school of thought promoting agility in IT aims at leaner documentation, increased interactions between departments[AGI]. Simultaneously, advances in software development methodology, time and money models have brought in new perspectives to the way organizations function. Though the TOGAF process is well defined, the approach continues to keep the communication between departments through a central architecture board. This weakens the requirement of quick and easy flow of communication throughout the enterprise, and also makes it hard for companies that intend to be agile. ADM is envisioned with IT in mind, hence the process focuses on collecting all the information from business, creating small ‘IT projects’, and governing them as an external entity [ROG]. TOGAF adherence relies on extensive documentation and meetings involving participants for a successful adherence to TOGAF. For instance, Architecture Review Process, Architecture Compliance entirely rely on meetings with all the involved stakeholders, architecture board, etc., Achitecure Contracts are enforced via copious documentation. Compare this with EA³: EA³‘s governance and repository, allow true boundary-less information flow across the enterprise. EA³ emphasizes on building the EA framework with enterprise’s strategy in mind.
The strength of TOGAF is its resource base – guidelines, templates, building blocks, et.c.,. Due to its emphasis on reuse, and its wide usage, coupled with the drive from TOGAF community to generalize every solution in the industry, TOGAF offers a rich library of artifacts and architecture models to use. This ensures enterprises can follow the standards of the domain, and only build things where they differ; for instance, key service offerings.
The EA³ is definitely a more accurate approach, which is devised to benefit the organization into having an excellent meta-model. Though not as thorough or vast as TOGAF, EA³ contains certain key elements that drive the enterprise into a better EA. The strength arises from the focus on strategy, being newer – hence being more apt for today’s enterprises, laying emphasis on automation and allowing constant ‘feedback-control’ from all segments. The most important aspect of EA³ is the elimination of duplicate enterprise architecture efforts by neatly connecting the various architectural efforts.

Reference

[AGI] Manifesto for Agile Software Development by Kent Beck et al
[BER] An Introduction to Enterprise Architecture by Scott Bernard [ISBN:978-1418498085] [COH] Comparison of EA³, OIO and Zachmann by Peter Flemming Teunissen Sjoeli
[GRI] An Enterprise Architecture Development Framework by Adrian Grigoriu [ISBN:978-1412086653] [MCG] A Practical Guide to Enterprise Architecture by James McGovern, Scott W. Ambler [ISBN:978-0131412750] [MIN] Enterprise Architecture A to Z by Daniel Minoli [ISBN:978-0131412750] [MSD] A Comparison of the Top Four EA Methodologies from MSDN Library
[POT] fruITion: Creating the Ultimate Corporate Strategy for Information Technology by Chris Potts [ISBN:978-0977140032] [ROG] Simple Architectures for Complex Enterprises by Roger Sessions [ISBN:978-0131412750] [ROS] Enterprise Architecture as Strategy: Creating a Foundation for Business by Jeanne W. Ross, et al [ISBN:978-0131412750] [SCH] How to Survive in the Jungle of Enterprise Architecture Frameworks by Jaap Schekkerman [ISBN:978-0131412750] [SWE] Achieving Service-Oriented Architecture: Applying an Enterprise Architecture by Rick Sweeny [ISBN:978-0131412750] [TOG] The Open Group Architecture Framework version 9.1 from The Open Group