1

Enterprise Architecture

Notes accompany this presentation. Please select Notes Page view.These materials can be reproduced only with Gartner's official approval. Such approvals may be requested via e-mail — quote.requests@gartner.com.

Battleground of the Enterprise Architecture Frameworks

Deborah Weiss

2

Client Issues

1. What is an enterprise architecture framework, and why do I need one?

2. What criteria do I use to evaluate different frameworks?

3. What frameworks will we compare, and how do they measure up?

3

What Is an Enterprise Architecture Framework?

Describes a method for designing an information system in terms of a set of building blocks and for showing how the building blocks fit together (TOGAF, v.8)Consists of various approaches, models and definitions for communicating the overall organisation and relationships of architecture components (CIO Council, 1999)Describes a specific approach to organising an enterprise architecture (The Enterprise Architecture Survival Guide)Presents a common vocabulary and set of perspectives, a framework for defining and describing complex enterprise systems (www.zifa.com)

4

Defining FrameworkDerived from a search of the Oxford English Dictionary:

A framework is something that provides structure when defining how technology is organised to support the business objectives of an enterprise. Can be viewed as having two parts.

DeliverablesWho uses?

When relevant?How determined?

Enterprise Architecture Framework

ContentOrganisation

StructureHierarchy

5

Why a Framework Is Needed

Enterprise architecture (particularly at the enterprise level) is a complex and multifaceted problem:– Anything that instills consistency and discipline into the process

is good– Anything that provides a structure and defines the relationships

between the pieces is even better– An architecture is difficult enough to do if you have a framework;

don't try to develop it without some organising structure

An EA provides an agreed-upon set of constructs that can be used to express architectural concepts and a language to communicate themAll EA programs should include some notion of a process to develop an EA and clearly define the relationship with the framework

6

Defining Enterprise Architecture

Short form– Enterprise architecture is the process of translating business

vision and strategy into effective enterprise change by creating, communicating and improving the key principles and models that describe the enterprise's future state and enable its evolution.

Long form– Enterprise architecture is the process of translating business

vision and strategy into effective enterprise change by creating, communicating and improving the key principles and models that describe the enterprise's future state and enable its evolution. The scope of the enterprise architecture includes thepeople, processes, information and technology of the enterprise,and their relationships to one another and to the external environment. Enterprise architects compose holistic solutions that address the business challenges of the enterprise, and support the governance needed to implement them.

Shortest form– Enterprise architecture means … architecting the enterprise.

7

How to Evaluate Frameworks

A good enterprise architecture framework should:Have a top-down approach that encourages architecture driven out of business strategySupport abstraction to allow the removal of complicating factorsContain a robust set of constructs for all levels of the EA and a well-developed language– Coherence and cohesion

Aligned to a process for developing the EAProvide advice on architecture governance

8

Frameworks That Will Be Compared

IEEE 1471

The Open Group Architecture Framework (TOGAF)

The Zachman Framework

NASCIO Enterprise Architecture Framework

Gartner's Enterprise Architecture Framework

U.S. Federal Enterprise Architecture Program

9

IEEE 1471

To define useful terms, principles and guidelines for the consistent application of architectural precepts to systems throughout their life cycleTo elaborate architectural precepts and their anticipated benefits for software products, systems, and aggregated systems (i.e., “systems of systems”)To provide a framework for the collection and consideration of architectural attributes and related information for use in IEEE standardsTo provide a useful road map for the incorporation of architectural precepts in the generation, revision, and application of IEEE standards

IEEE Recommended Practice for Architectural Description of Software-Intensive Systems

10

How Does IEEE 1471 Stack Up?

Top down

A focus on mission and environment influencing system design but limited linkage to business strategy

Supports abstractionUses multiple levels of detail to define architectural descriptions

Constructs and languageWell-developed set of architecture constructs

ProcessLimited process

GovernanceMinimal mention

= good = caution

11

TOGAF

Developed by The Open Group in the 1990s, currently in v.8.1 (The Open Group Architecture Framework)Focus on technical architecture through v.7Focused around architecture development methodIntentionally generic — no prescribed deliverables

12

How Does TOGAF Stack Up?

Top downBusiness and information architecture recent additionsSuggests starting with the business architectureYou can enter the process anywhere along the continuum

Supports abstractionConstructs and language

Generically defined to support a wide range of deliverablesDeliverables are not prescribedDifficult to understand the relationships between different deliverables

ProcessRobust and well-defined

GovernanceRobust

= good = caution

13

Zachman Framework

Proposed by John Zachman in 1987, extended in 1992

"Supports the organisation, access, integration, interpretation, development, management and changing of a set of architectural representations of information systems"

Six "dimensions" address different subject areas of the architecture

Five "perspectives" associated with the scope of interest of a class of stakeholders

Order of dimensions is arbitrary

Order of perspectives is broad to narrow

Deliverable neutral

Sequence neutral

14

How Does Zachman Stack Up?

Top downFramework is sequence neutral, cells can be populated in any order

Supports abstractionPerspectives address different levels of abstraction corresponding to the scope of interest of different stakeholders

Constructs and languageWell-defined set of constructs and languageThe "richest" framework in terms of detail

ProcessMethod neutrality is a stated goal

GovernanceTangential reference

= good = caution

15

Government-oriented, but usable in other industries

Version 3.0: Business Architecture

Developed "in kind"

DOJ funded

Enterprise architecture maturity assessment

Source: National Association of State Chief Information Officers

NASCIO Enterprise Architecture Toolkit

16

How Does NASCIO Stack Up?Top down

Guidance is top down; however, domains are isolated from each other without treatment of their relationships and linkages

Supports abstractionPerspectives address different levels of abstraction corresponding to the scope of interest of different stakeholdersLittle to support abstraction for other complicating factors

Constructs and languageGood set of constructs and language

ProcessVery detailed process — beware overprescriptionProvides examples and templates

GovernanceIn-depth, highly detailed, and examples help different organisations choose models to suit current political environment

= good = caution

17

Gartner's Enterprise Architecture FrameworkOriginally developed in 2002

Evolved to enhance usability and join the framework with extensive process work

Basis in IEEE practices

Describes required and optional "viewpoints"

Clear top-down decomposition

18

How Does the Gartner Framework Stack Up?

Top downExplicitly drives architecture out of the business strategy

Supports abstractionMultiple levels of abstraction defined

Constructs and languageSimplified approachDefined set of constructs with relationships clearly defined

ProcessAlignment with a separate EA process

GovernanceGovernance is well supported by both the process and framework

= good = caution

19

Federal Enterprise Architecture Reference Models

U.S. Federal Enterprise Architecture Program

FEAMS: Reference Models/Business Cases

CORE.GOV:Services/Components

Inputs

Technology

Processes and Activities

Human Capital

Other Assets

Value

Value

Strategic Outcomes

CustomerResults

Mission/Business

Results

Business Cases: OMB Exhibit 300Performance Goals and Measures

Image Source: U.S. Federal Government

20

Recommendations

Every framework is different, because every enterprise is different– Culture, level of maturity, business imperatives

No framework is an island– Choose the framework that best fits your needs; then borrow from

others to fill any gaps

Proper support for abstraction is key– Deficiencies in artifacts or governance are easy to supplement

Some process is good, but beware of process that is too prescriptive

Write it down– A high-level description of your framework, key constructs and the

relationship to the EA process should be no more than 10 pages