Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member

Introduction

Definition

Enterprise Architecture's history is 23 year old when John Zachman first introduced the word "Information System Architecture" which later renamed to "Enterprise Architecture" (Refer section: Zachman Framework).

There are numerous definitions available for term "Enterprise Architecture" and in this section I listed two most relevant definitions:

  • Definition 1: Simply stated, enterprise architectures are "blueprints" for systematically and completely defining an organization's current (baseline) or desired (target) environment. Enterprise architectures are essential for evolving information systems, developing new systems, and inserting emerging technologies that optimize their mission value (A Practical Guide to CIO Council - Federal Enterprise Architecture)

 

  • Definition 2: The process of describing, and the description of, the desired future state of an organization's business process, technology and information to best support the organization's business strategy. The definition of the steps required, and the standards and guidelines to get from the current state to the desired future state. [Gartner: ID Number: G00138626. March 28, 2006]

 

In nutshell an Enterprise Architecture is the way to build and manage complex information System landscape in a structured manner to support business strategy in a cost effective way.

 

Business, Technology and Information System Architectures are subset of an Enterprise Architecture.

 

 

Why Enterprise Architecture needed?

CIOs priorities are now shifting from "resource based IT" to "result based IT" and top priority is now "IT contributes to the business" from "IT enables the business"[1], this is where Enterprise Architecture comes in. Enterprise Architecture tries to address main challenges CIOs are facing today like: simplifying complex and unmanageable IT systems, control spiralling IT cost, bridge the communication gap between Business and IT organization, and derive business value from emerging technologies (Virtualization, Cloud and Web2.0 etc). Managing complexity itself will deliver substantial business value assert Roger Sessions in his article "The more complex a system, the less likely it is that it will deliver maximum business value. As you better manage complexity, you improve your chances of delivering real business value"[2]

Just like Project Management, Enterprise Architecture should also be integral practice of mid to large size enterprise because with business growth (organic or otherwise) new sets of business requirements will emerge, and to fulfil these requirements cohesive approach is required to build and deploy new IT components otherwise ad-hoc and quick-fix solutions will emerge which often become permanent solutions, this ad-hoc approach results in Information System Chaos which ultimately translates into significant increment in operational cost.

The purpose of enterprise architecture is to optimize across the enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment that is responsive to change and supportive of the delivery of the business strategy (TOGAF version 9 Enterprise Edition).

I can safely summarize that top two important motivations behind Enterprise Architecture are:

  • Manage System Complexity
  • Align Business and IT

Enterprise Architecture Framework (s)

Enterprise Architecture Framework is the template which guides development and management of Enterprise Architecture. An Architecture framework should provide:

  • Processes to build, manage and evaluate Enterprise Architecture
  • Best practices, reference architecture and model for quick and consistent architecture development and
  • Tools to model and manage building blocks and artefacts

This section will discuss two popular Enterprise Architecture Frameworks: Zachman Framework and The Open Group Architecture Framework (popularly known as TOGAF). 

Zachman Framework

Zachman Framework is an oldest Enterprise Architecture Framework named after its developer John Zachman, basic Zachman framework first introduced by John Zachman in his article "A Framework for Information Systems Architecture" published in a 1987 article in the IBM Systems journal[3], since then Zachman Framework is revised several time and latest version was release in 2008. 

The Zachman Framework is the ontology for describing the Enterprise. It describes "what" artefacts should be produced in Enterprise Architecture but not how to produce them. "The Zachman Framework typically is depicted as a bounded 6 x 6 "matrix" with the Communication Interrogatives (What, How, Where, Who, When, Why) as Columns and the Reification Transformations (Contextual, Conceptual, Logical, Physical, Detailed) as Rows"  (Zachman)

                              Figure 1: Zachman Framework

Note:  High resolution image is available for download on http://www.zachmaninternational.us/.

What is TOGAFTM?

TOGAF is an architecture framework developed by members of Open Group, working within the Architecture Forum; it is driven by broad industry consensus, has wider acceptance, and vendor neutral, it can be freely used by any organization for internal architecture development purpose.  The original development of TOGAF Version 1 in 1995 was based on the Technical Architecture Framework for Information Management (TAFIM), developed by the US Department of Defence (DoD).

TOGAF is the process driven framework, it explains "how" to develop architecture but not explicitly mention "what" to develop. TOGAF is very generic and flexible and can be adopted to develop Enterprise Architecture in various situations.

There are four architecture domains in TOGAF: Business, Application, Data and Technology.  

Figure 2: TOGAF architecture domain

Components of TOGAF

TOGAF component
Description[4]

ADM + Guidelines and Techniques

ADM is the process to develop an Enterprise Architecture. Guidelines and techniques provided for each phase of ADM. See next section for detail on ADM.

Architecture Content Framework

The content framework provides a structural model for architectural content that allows the major work products that an architect creates to be consistently defined, structured, and presented.

Enterprise Continuum and Tools

The Enterprise Continuum provides a view of the Architecture Repository that shows the evolution of these related architectures from generic to specific, from abstract to concrete, and from logical to physical.

Reference Models

Foundation architecture TRM (Technical Reference Model) and common system architecture III-RM (Integrated Information Infrastructure - Reference Model) provided as reference architecture to guide development of more specific architectures.

Architecture Capability Framework

Provides set of reference materials to put in place appropriate organization structures, processes, roles, responsibilities, and skills to realize the architecture capability.

ADM: Architecture Development Method

ADM is a methodology (or Process) to develop an Enterprise Architecture. ADM is the core of TOGAF and it is graphically depicted in a cycle, ADM has 10 phases (Preliminary phase, Requirement Management phase and phase A to H). TOGAF also provides set of guidelines and techniques to be used in different phases.

Figure 3: TOGAF ADM

Phase
Description[4]

Preliminary

Review the organizational context for conducting enterprise architecture, main activity involves creation of architecture principle and identifies stakeholder and their requirements. Output: Request for Architecture Work

A: Architecture Vision

It is initial phase of ADM, in this phase Architecture Vision is created which describe high level "as-is" and "to-be" architecture.

B: Business Architecture

To support Architecture Vision, As-is and To-be Business Architecture is developed and gaps are identified.

C: Data Architecture

To support Business Architecture, As-is and To-be Data Architecture is developed and gaps are identified. Data entities relevant to Businesses are defined.

C: Application Architecture

To process data and support business architecture, As-is and To-be Application Architecture is developed and gaps are identified.

😧 Technology Architecture

To support Application and Data architecture, As-is and To-be Technology architecture is developed and gaps are identified.

E: Opportunities and Solutions

Gaps are consolidated from previous phases and grouped in major work packages, high level migration plan is prepared to gain consensus from Stakeholder. Series of Transition Architectures are developed which deliver incremental business value.

F: Migration Planning

The main focus of Phase F is the creation of a viable Implementation and Migration Plan in co-operation with the portfolio and project managers.

G: Implementation Governance

Actual developments are going on parallel to this phase. This phase provides architectural oversight of implementation projects to ensure architecture compliance.

H: Architecture Change Management

The goal of an architecture change management process is to ensure that the architecture achieves its original target business value. This includes managing changes to the architecture in a cohesive and architected way.

Requirement Management

Objective of this phase is to define process to manage requirements of Enterprise Architecture.  It serve as cross-phase touch point and inputs/outputs between phases

 

Related Content

Following works are cited in this article:


[1] Gartner: Leading in Times of Transition: The 2010 CIO Agenda. Jan 2010.

[2] Roger Sessions: A Comparison of the Top Four Enterprise-Architecture Methodologies (http://msdn.microsoft.com/en-us/library/bb466232.aspx)

[3] Original article can be found on: http://www.zachmaninternational.us/images/stories/ibmsj2603e.pdf

[4] http://www.opengroup.org/architecture/togaf9-doc/arch/

Last update: 14-Sep-2010: corrected link from http://www.zachmaninternational.com to http://www.zachmaninternational.us/

7 Comments