enterprise architecture
Post on 15-Jan-2015
1.120 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
top related