8037T – IT Strategic Plan and

Enterprise Architecture
Week 8 – Session 9
Method and Framework of EA
 Outline

• IEEE 1471
• Framework Zachman, TOGAF, Archimate
• Federal Enterprise Architecture (FEA)
• Framework Model Driven Architecture (MDA)
• Geram
IEEE 1471-2000/ISO/IEC 42010 Standard
Conceptual Model of Architecture Description
(IEEE Computer, 2000)
Zachman ISA Framework
Zachman ISA Framework
• In the 1997, Zachman framework the rows
are described as follows:
 Planner’s View (Scope)
 Owner’s View (Enterprise or Business Model)
 Designer’s View (Information Systems Model)
 Builder’s View (Technology Model)
 Subcontractor View (Detailed Specification)
 Actual System View of the Functioning Enterprise.
TOGAF 9 (Open Group, 2009)
 The Open Group Architecture Framework (TOGAF)

• History:
– “ … based on the Technical Architectural
Framework for Information Management
(TAFIM). The U.S. DoD gave The Open Group
explicit permission and encouragement to
create TOGAF by building on the TAFIM, which
itself was the result of many years of
development effort and many millions of
dollars of U.S. Government investment …”
 TOGAF Architecture
Development Method
Archimate
Archimate
Archimate
Archimate
Archimate
Archimate
Archimate
Archimate
Archimate
Archimate
Archimate
Archimate
Archimate
Archimate
OMG’s Model Driven Architecture (MDA)
Model-Driven
Architecture

Model Transformation
in MDA
 Reference Model for Open
Distributed Processing (RM-ODP)
• ISO/ITU Standard 1996
• Framework for Architecture specification of Large
Distributed Systems.
• Standard aims to provide support for
internetworking, interoperability, portability, and
distribution, and therefore to enable the building of
open, integrated, flexible, modular, manageable,
heterogeneous, secure, and transparent systems.
The RM-ODP view model, which provides five generic
and complementary viewpoints on the system
and its environment.
• The standard has four parts:
– Part 1: Reference, containing a motivational overview of the
standard and its concepts (ITU 1996)
– Part 2: Foundations, defining the concepts, the analytical
framework for the description of ODP Systems, and a general
framework for assessment and conformance (ITU 1995a)
– Part 3: Architecture, describing the ODP framework of viewpoints
for the specification of ODP systems in different viewpoint
languages (ITU 1995b). It defines 5 viewpoints on a system and its
environment: enterprise, information, computation, engineering,
and technology.
– Part 4: Architectural semantics, showing how the modelling
concepts from Part 2 and the viewpoint languages from Part 3 can
be implemented in a number of formal description techniques, such
as: LOTOS, Estelle, SDL, and Z (ITU 1997)
GERAM (Generic Enterprise Reference Architecture
and Methodology) (IFIP-IFAC Task Force 1999)
• defines the enterprise related generic concepts
recommended for use in enterprise engineering and
integration projects.
• These concepts can be categorised as:
– Human-oriented concepts to describe the role of humans as an integral
part of the organisation and operation of an enterprise and to support
humans during enterprise design, construction, and change.
– Process-oriented concepts for the description of the business processes
of the enterprises;
– Technology-oriented concepts for the description of the suppporting
technology involved in both enterprise operation and enterprise
engineering efforts (modelling and model use support).
• GERAM model has three dimensions:
– the life cycle dimension,
– the instantiation dimension allowing for different
levels of controlled particularisation, and
– the view dimension with four views:
• Entity Model Content view,
• Entity Purpose view,
• Entity Implementation view, and
• Entity Physical Manifestation view.
• Each view is further refined and might have a number
of components.
 Federal Enterprise Architecture (FEA)
• Technical Architecture Framework for Information
Management (TAFIM) was one of the first attempts at
enterprise architecture by the Department of Defense in
the mid 90’s
• Influenced the Clinger-Cohen Act which stated that federal
agencies should improve their IT investments
• Over time Federal Government efforts in enterprise
architecture lead to the creation of FEA
 FEA: How it works?

• An enterprise is built of segments:

• There are two types of segments
– Core mission area segments
– Business-services segments
• Also use enterprise services which span political
boundaries
Structure of the U.S."Federal Enterprise Architecture
Framework" (FEAF) Components, presented in
2001
Segment Map of the Federal Government

Source:http://msdn2.microsoft.com/en-us/architecture/bb466232.aspx
 FEA Process
• Step 1: Architectural Analysis—Define a simple and concise vision
for the segment, and relate it back to the organizational plan.
• Step 2: Architectural Definition—Define the desired architectural
state of the segment, document the performance goals, consider
design alternatives, and develop an enterprise architecture for the
segment, including business, data, services, and technology
architectures.
• Step 3: Investment and Funding Strategy—Consider how the
project will be funded.
• Step 4: Program-Management Plan and Execute Projects—Create
a plan for managing and executing the project, including
milestones and performance measures that will assess project
success.
 FEA: Strengths and Weaknesses
• Strengths- clearly defines output and provides a process for
creating a framework

• Weakness- Government architecture so it has not been

applied to a business before
– General Accounting Office (GAO) reported that, “Only 20 of
96 agencies examined had established at least the
foundation for effective architecture management. Further,
while 22 agencies increased in maturity since 2001, 24
agencies decreased in maturity and 47 agencies remained
the same”.
 Performance Reference Model (PRM): (FEA)
The PRM is a standardized framework to measure the performance of
major IT investments and their contribution to program performance.
 Business Reference Model (BRM): (FEA)
BRM is a function-driven framework for describing the business operations of the Federal Government
independent of the agencies that perform them.
Service Component Reference Model (FEA)
 Data Reference Model (FEA):
DRM describes, at an aggregate level, the data and information that support government program and business line
operations.
 Technical Reference Model: (FEA)
TRM is a component-driven, technical framework categorizing the standards and technologies to
support and eanble the delivery of Service Components and Capabilities.
• TRM consists of:
– Service Areas: represent a technical tier supporting the
secure construction, exchange, and delivery of Service
Components.
– Service Categories: classify lower levels of technologies and
standards with respect to the business or technology
function they serve.
– Service Standards: define the standards and technologies
that support a Service Category.
• FEA Practice Guidance (2006) defined three types of
architecture:
– Enterprise Architecture
– Segment architecture, and
– Solution Architecture
FEA: Practice Guidance
 EA Gartner
• 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.
 GEAF
• Three primary viewpoints
– enterprise business
architecture (EBA)
– enterprise information
architecture (EIA)
– enterprise technology
architecture (ETA).
• Introduces the Enterprise Solution Architecture
Framework (ESAF) - deals directly with:
– combining and reconciling
the loosely coupled and
often conflicting viewpoints
– into a unified architecture for
an enterprise solution.
Gartner process model
 Conclusions
• The architectural method is a collection of structured techniques and
process steps to create and maintain enterprise architecture.
• The method usually determines the various phases of architectural life
cycle, what shipment should be produced at each stage, and how they
are verified or tested.
• Frameworks often do not provide concepts for actual modeling, although
some frameworks are closely related to a particular modeling language
or set of languages.
• Most architectural frameworks are quite appropriate in building what
elements should be part of the company's architecture.
• However, to ensure the quality of enterprise architecture during its life
cycle the adoption of a particular framework is not sufficient.
• The relationship between different types of domains, views, or
architectural layers should remain clear, and any changes should be
methodical in all.
• To this end, a number of methods are available, which help architects
through all phases of architectural life cycle.
 References

• Enterprise Architecture at Work Modelling,

Communication and Analysis,: Lankhorst,
Marc
• An Introduction to Enterprise Architecture:
Third Edition, Scott A. Bernard, AuthorHouse