Sunteți pe pagina 1din 110

Page: 1

Zachman, Spewak, and their Legacies

Zachman & Spewak


and their Legacies
Department of Engineering Management & Systems
Engineering (EMSE)

Dr. Tim Eveleigh, CSEP


Page: 2
Zachman, Spewak, and their Legacies

Agenda

• Zachman’s Framework
• Spewak’s EAP
• Legacy Architectural Frameworks:
• TISAF
• IAF
• E2AF
• EA3
• xAF
Page: 3
Zachman, Spewak, and their Legacies

Learning Objectives
• Understand the Principles and Structure of the Zachman
Framework
• Understand the Principles and Structure of Spewak’s Enterprise
Architecture Planning (EAP)
• Recognize and be familiar with the business and IT aspects of
Zachman’s and Spewak’s architectures
• Recognize and be familiar with some of the architectural
frameworks that evolved from Zachman’s and Spewak’s
architectures
• Know the intent and impacts of the Clinger-Cohen Act
Page: 4
Zachman, Spewak, and their Legacies

Course Roadmap (Lecture 3)

1990 1995 2000 2005 2010 - 2017


Page: 5
Zachman, Spewak, and their Legacies

Mr. Zachman’s Framework


Page: 6
Zachman, Spewak, and their Legacies

The Zachman Framework for


Information Systems Architecture
• A Framework for Information Systems
Architecture
• IBM Systems Journal 1987
• Looked at classical architecture
(building a house)
• Saw the process as a dialogue
• Basically a series of
questions that narrow in
on a design
• Each question adding
more information
Page: 7
Zachman, Spewak, and their Legacies

Zachman’s Framework
• Architect must convince the owner
that their needs are understood
before building begins.

• Gradually becomes more and more


detailed as first the architect’s
concept, then the architect’s
drawings, and then the architect’s
plans are agreed to.

• The plans then become the basis of


negotiation with the builder.
Source: Framework for Info Systems Architecture: Zachman, 1987
Page: 8
Zachman, Spewak, and their Legacies

Zachman’s Framework
• Argued that the same approach could
be made for engineered systems
• Also argued that the traditional
systems design approach typically
leaves off the conceptualization steps
• Three fundamental representations:
owner, architect, builder
– Each has a different nature
• Also needed was a “ballpark”
representation to scope it right
• … and the lower level details of the
final design and finished object
Source: Framework for Info Systems Architecture: Zachman, 1987
Page: 9
Zachman, Spewak, and their Legacies

Levels of Representation
• Each representation was not just a higher detailed
version of the one preceding it, it has different content
and semantics

Source: Framework for Info Systems Architecture: Zachman, 1987


Page: 10
Zachman, Spewak, and their Legacies

Combined as a Framework (version 1)

• He put the two dimensions


together and proposed it as a
framework for information
systems architecture(s)

• Zachman also suggested, and


provided examples of different
models and diagrams that went
in each cell

Source: Framework for Info Systems Architecture: Zachman, 1987


Page: 11
Zachman, Spewak, and their Legacies

Growth of the Early Framework

• Despite reaffirming several 1960s era systems planning ideas, Zachman’s


framework touched a nerve as it unified many difficult concepts into a simple
framework
- Views – beyond just the architect/builder pair
- A comprehensive coverage of concerns
- An embedded hierarchy
- A prescriptive “when to use what diagram to say what to whom”
- The sense that there are representations out there we need to explore

• The upper levels came to represent the (scoping) business concerns that
drive engineering

• He continued to grow the framework until he had added the full set of
interrogatives: What, Why, When, How, Where, and Who giving him a
symmetric 6 x 6 matrix we now call the Zachman framework:
The Zachman FrameworkTM (version 2)
Page: 12
Zachman, Spewak, and their Legacies
'Published with the permission of John A. Zachman and Zachman International®, Inc.'
version
Page: 13 3
Zachman, Spewak, and their Legacies
Page: 14
Zachman, Spewak, and their Legacies

Framework Details: Rows


 The rows represent the points of view of different players in the
systems development process, while columns represent
different aspects of the process

Row 1. Scope (Ballpark view)


• Definition of the enterprise's
direction and business purpose
• An industry view, concerned with the
things that define the nature and
purpose of the business
• Is necessary to establish the context
for any system development effort

Source: The Zachman Framework: An Introduction, Hay 1997


Page: 15
Zachman, Spewak, and their Legacies

Framework Details: Row 2


2. Model of the business (Owner's view)
• Defines -- in business terms -- the
nature of the business, including its
structure, functions, organization,
and so forth

Source: The Zachman Framework: An Introduction, Hay 1997


Page: 16
Zachman, Spewak, and their Legacies

Framework Details: Row 3


3. Model of the information system (Designer or Architect's
view)
• This defines the business described in row two,
but in more rigorous information terms
• Where row two described business functions,
for example, as perceived by the people
performing them, row three describes them
specifically as transformations of data
• Where row two described all the things of
interest to the enterprise, row three describes
those things about which the organization
wishes to collect and maintain information, and
begins to describe that information

Source: The Zachman Framework: An Introduction, Hay 1997


Page: 17
Zachman, Spewak, and their Legacies

Framework Details: Row 4

4. Technology model (Builder's view)


• This describes how technology may
be used to address the information
processing needs identified in the
previous rows
• Here relational databases are chosen
over network ones (or vice versa),
kinds of languages are selected and
program structures are defined, user
interfaces are described, and so forth

Source: The Zachman Framework: An Introduction, Hay 1997


Page: 18
Zachman, Spewak, and their Legacies

Framework Details: Rows 5, 6


5: Detailed representations (Subcontractor's view)
• This is a view of the program listings,
database specifications, networks,
and so forth that constitute a
particular system
• These are all expressed in terms of
particular languages

6: Functioning system
• Finally, a system is implemented and
made part of an organization
Source: The Zachman Framework: An Introduction, Hay 1997
Page: 19
Zachman, Spewak, and their Legacies

Framework Details: Columns


 The columns in the Zachman framework represent different areas of
interest for each perspective. The columns describe the dimensions of the
systems development effort.
Column One is Data (What?):
• Each of the rows in column one address understanding of
and dealing with any enterprise's data
• This begins in Row one with an list of the things that concern
any company in this industry, affecting its direction and
purpose
• As you pass down through the rows, you move to
progressively more rigorous descriptions of the data
• Row two is the business person's view
• Row three is a disciplined translation of this
• Row four is where a specific design approach (and a specific
database management system) is specified
• Row five is the detailed representation of the data on the
computer (tablespaces and the like), and
• Row six is the working database

Source: The Zachman Framework: An Introduction, Hay 1997


Page: 20
Zachman, Spewak, and their Legacies

Column Two: Function (How?)


• The rows in the function column describe the process of
translating the mission of the enterprise into
successively more detailed definitions of its operations
• Row one is a list of the kinds of activities the enterprise
conducts
• Row two describes these activities in a contiguous
model
• Row three portrays them in terms of data transforming
processes, described exclusively in terms of the
conversion of input data into output data
• The technology model in row four then converts these
data conversion processes into the definition of
program modules and how they interact with each
other. Pseudo-code is produced here
• Row five then converts these into source and object
code
• Row six is where the code is linked and converted to
executable programs

Source: The Zachman Framework: An Introduction, Hay 1997


Page: 21
Zachman, Spewak, and their Legacies

Column Three: Network (Where?)


• This column is concerned with the geographical
distribution of the enterprise's activities
• At the strategic level (row one), this is simply a listing of
the places where the enterprise does business
• At Row two, this becomes a more detailed
communications chart, describing how the various
locations interact with each other
• Row three produces the architecture for data
distribution, itemizing what information is created
where and where it is to be used
• In row four, this distribution is translated into the kinds
of computer facilities that are required in each location
• In row five, these facilities requirements are translated
into specification of particular computers, protocols,
communications facilities, and the like
• Row six describes the implemented communications
facilities
Source: The Zachman Framework: An Introduction, Hay 1997
Page: 22
Zachman, Spewak, and their Legacies

Column Four: People (Who?)


• The fourth column describes who is involved in the business
and in the introduction of new technology
• The row one model of people is a simple list of the
organizational units and each unit's mission
• In row two, this list is fleshed out into a full organization
chart, linked to the function column. Here also,
requirements for security are described in general terms
• In row three, the potential interaction between people and
technology begins to be specified, specifically in terms of
who needs what information to do his job
• In row four, the actual interface between each person and
the technology is designed, including issues of interface
graphics, navigation paths, security rules and presentation
style
• In row five, this design is converted into the outward
appearance of each program, as well as the definitions of
access permissions in terms of specific tables and/or
columns each user can have access to
• In row six, you have trained people, using the new system
Source: The Zachman Framework: An Introduction, Hay 1997
Page: 23
Zachman, Spewak, and their Legacies

Column Five: Time (When?)


• The fifth column describes the effects of time on the
enterprise
• It is difficult to describe or address this column in
isolation from the others, especially column two
• At the strategic (row one) level, this is a description of the
business cycle and overall business events
• In the detailed model of the business (row two), the time
column defines when functions are to happen and under
what circumstances
• Row three defines the business events which cause
specific data transformations and entity state changes to
take place
• In the technology model (row four), the events become
program triggers and messages, and the information
processing responses are designed in detail
• In row five, these designs become specific programs
• In row six business events are correctly responded to by
the system
Source: The Zachman Framework: An Introduction, Hay 1997
Page: 24
Zachman, Spewak, and their Legacies

Column Six: Motivation (Why?)


• As Mr. Zachman originally described this column, it
concerned the translation of business goals and strategies
into specific ends and means
• This can be expanded to include the entire set of constraints
that apply to an enterprise's efforts
• In row one, the enterprise identifies its goals and strategies
in general, common language terms
• In row two, these are translated into the specific rules and
constraints that apply to an enterprise's operation
• In row three, business rules may be expressed in terms of
information that is and is not permitted to exist. This
includes constraints on the creation of rows in a database as
well as on the updating of specific values
• In row four, these business rules will be converted to
program design elements
• In row five they will become specific programs
• In row six, business rules are enforced
Source: The Zachman Framework: An Introduction, Hay 1997
Page: 25
Zachman, Spewak, and their Legacies

Observations
• The Zachman framework has two very distinctive features that
make it ideal for information modeling:
- The framework may be applied at any level of implementation in the
system development process, from a global enterprise, to a system,
subsystem, or major module level

- The framework also gives the modeler latitude in that any data
representation technique can be used to model the inner workings of
each cell

» Zachman calls these artifacts ‘primitives’

Source: Use of the Zachman Architecture for Security Engineering, Henning,1999


Page: 26
Zachman, Spewak, and their Legacies

Example Primitives

Source: The Zachman Framework: An Introduction, Hay 1997


Page: 27
Zachman, Spewak, and their Legacies

Observations
• The ZF is more like planned urban development than building a house

• But it is a model with only two dimensions (36 cells)


- The six types of questions
- The six types of roles

• How does such a simple model create such a phenomenal impact? Answer:
- Exhaustive coverage of two orthogonal dimensions
- The classified objects (descriptive artifacts) are critical to success of any type of
project.
- Highly extensible in many other dimensions
» Discussions usually fail to clearly identify the orthogonal dimensions (such as
languages, methods, failures, and tests)

• However, there is no guidance on sequence, process, or implementation of


the framework
Source: Introduction to the Zachman Framework, Carpenter, 1999
Page: 28
Zachman, Spewak, and their Legacies

Observations
• The major contribution of the Framework is its explicit recognition that there is more
at work here than functions and data. From the beginning, we should be recognizing
the organizational issues; from the beginning, we should be dealing with multiple
locations; from the beginning we should be explicitly concerned with timing - triggers,
schedules, and so forth.

• We do not have models, or even well developed methods for dealing with many of
the cells. Zachman does not advocate the use of any particular modeling style for
those cells where multiple techniques are available, and he is the first to recognize
that in some cells no good techniques exist. It is difficult, for example, to model the
logic (row three) of a distributed information network - at least in a way that links to
our models for functions and data.

• This represents an assignment for us all. He has pointed out things that we might
need to capture and account for – a checklist

Source: The Zachman Framework: An Introduction, Hay 1997


Page: 29
Zachman, Spewak, and their Legacies

ZF Used to Structure Business Rules


Page: 30
Zachman, Spewak, and their Legacies

ZF Healthcare Informatics Standards


Page: 31
Zachman, Spewak, and their Legacies

ZF as Products (System Architect)


• More of a UML bias

Source: Activity, Data, and Object Modeling for Enterprise Architectures, Daniel L. Spar, 2008
Page: 32
Zachman, Spewak, and their Legacies

Using ZF to Map Compliance


Sarbanes-Oxley Act (SOX) and the Basel II
Accord have generated requirements
that deeply affect a wide range of IT-
related activity within large financial
institutions
ZF can serve as an effective means to
help identify and classify these
requirements

Provides a method for business and IT to


obtain a perspective on what it will take
to fulfill these regulations

It also demonstrates how the Zachman


Framework can be practically employed
to better manage complex tasks.
Source: Zachman, Basel II and Sarbanes-Oxley, Dinner & Kolber 2005
Page: 33
Zachman, Spewak, and their Legacies

Zachman Framework Fundamentals -1

• The Zachman Framework™ is the fundamental structure for


Enterprise Architecture and thereby yields the total set of
descriptive representations relevant for describing an Enterprise

• More specifically, the Zachman Framework™ is an ontology


- A theory of the existence of a structured set of essential components of
an object for which explicit expressions is necessary and perhaps even
mandatory for creating, operating, and changing the object

• The Zachman Framework™ is NOT a methodology for creating


the implementation (an instantiation) of the object

© 2008 John A. Zachman, CEO Zachman International®, Inc.


Page: 34
Zachman, Spewak, and their Legacies

Zachman Framework Fundamentals - 2


• The Framework is the ontology for describing the Enterprise.
- The Framework (ontology) is a STRUCTURE; whereas a methodology is a
PROCESS. A Structure is NOT a Process.

• The Zachman Framework™ is a metamodel and unlike a


methodology, does not imply anything about:
- Whether you do Architecture or whether you simply build
implementations
- How you do Architecture: top-down, bottom-up, left to right, right to left,
where to start, etc., etc.
- How much flexibility you want for producing composite models

• The Zachman Framework™ is the basis for Architecture…


© 2008 John A. Zachman, CEO Zachman International®, Inc.
Page: 35
Zachman, Spewak, and their Legacies

Summary
• Zachman’s framework went on to influence much thought about
“the layers above the system design”

• These layers are needed to couple systems to enterprises and


underpin the enterprise architecting process

• While Zachman’s Framework is a great tool for conceptualizing


representation, it is process neutral

• In 1992, Steven Spewak put the ZF into a practical framework


for building and transforming enterprises with his Enterprise
Architecture Planning approach
Page: 36
Zachman, Spewak, and their Legacies

Dr. Spewak’s
Enterprise Architecture Planning
EAP
Page: 37
Zachman, Spewak, and their Legacies

Dr. Spewak
• Wrote the book on how to effect
business-driven enterprise
architecture planning
• President of Enterprise Architects,
Inc.; a firm that provided services in
EAP, data warehousing,
IS restructuring, and business re-
engineering for corporations and
government agencies
• Chief technical editor for the Data
Resource Management journal and
Data Base Management
• Many recent approaches apply
variations of Spewak’s EAP
Page: 38
Zachman, Spewak, and their Legacies

EAP Summary

• Spewak defines EAP as the “process of defining architectures for


the use of information in support of the business and the plan for
implementing those architectures”

• Architectures = data + applications + technical architecture


• Defining = defines the business and architectures - not ‘designing’
• Plan = defining when the architectures will be implemented

• The key is information; EAP is a data-driven approach


Page: 39
Zachman, Spewak, and their Legacies

Enterprise Architecture Planning

• Focus on the strategic use of technology for managing data as an


asset
• Use a standard vocabulary to facilitate communication and reduce
ambiguity
• Derive documentation to increase understanding
• Use models to explain the business and assess changes to it
• Aim to be comprehensive, objective, impartial
• Generate a long-range plan to complement business plans
• Define cost-effective long term solutions considering rate of return
Page: 40
Zachman, Spewak, and their Legacies

The Foundation of Spewak's Approach - 1


• Architectures must be founded on a functional
business model

• Classic systems planning approach:


• “What systems do you want?”
• “Which systems do you need most?”
• “Which data do you need?”
• “Are you ready to upgrade?”
• “What are your success factors?”
• “How much money do you have to spend?”
• Spewak argues that this approach only addresses short
term and ‘personal’ requirements
Page: 41
Zachman, Spewak, and their Legacies

The Foundation of Spewak's Approach - 2


• EAP asks:
• “What does your business do?”
• “What information is used to
conduct your business?”
• A model of the business is a
more stable foundation on
which to define architectures
• Support the needs of the
business, not the just
requirements of individuals
• Use a business-driven approach
Page: 42
Zachman, Spewak, and their Legacies

The Foundation of Spewak's Approach - 3

• Enterprise Architecture Planning defines data before applications


• This is the opposite of the normal (vendor-driven / technologic) approach
• Similar to systems engineering’s solution agnostic approach

• EAP uses data dependency to determine the implementation


plan

• EAP considers both


• Short term operational focus
• Long term strategic focus
… on the use of information and technology to support the business
Page: 43
Zachman, Spewak, and their Legacies

How EAP Relates to Zachman


• Spewak references the Zachman Framework and notes that EAP is focused on
defining the top two layers

E
A
P

Sys
Engr
Page: 44
Zachman, Spewak, and their Legacies

Components of the EAP

Planning
Initiation
Layer 1

Business Current
Modeling Systems & Layer 2
Technology
Data Applications Technology
Architecture Architecture Architecture Layer 3

Implementation / Migration Plans Layer 4


Page: 45
Zachman, Spewak, and their Legacies

Components of the EAP

• Planning Initiation Planning


Layer 1
Initiation
- Selection of methodology,
Business Current
people, toolset Modeling Systems &
Technology
Layer 2

- Producing a workplan Data


Architecture
Applications
Architecture
Technology
Architecture Layer 3

- Gaining management Layer 4


Implementation / Migration Plans
commitment
Page: 46
Zachman, Spewak, and their Legacies

Components of the EAP

• Where We Are Today


- Compiles a knowledge base Planning
Layer 1
about the business and the Initiation

information it uses Business


Modeling
Current
Systems & Layer 2
Technology
- Defines what is in place today Data Applications Technology
Layer 3
Architecture Architecture Architecture
for systems and technology
platforms Implementation / Migration Plans Layer 4

- Provides baseline for long-term


migration planning
Page: 47
Zachman, Spewak, and their Legacies

Components of the EAP


• Where We Want to Be in the
Future
1. Defines major kinds of data
needed to support the
Planning
business Initiation
Layer 1

2. Defines the major kinds of Business


Modeling
Current
Systems & Layer 2
Technology
applications needed to Data Applications Technology
Layer 3
manage that data and Architecture Architecture Architecture

support business functions Implementation / Migration Plans Layer 4

3. Defines the technology


platforms needed to provide
an environment for the apps
and data to support business
functions
- Serial, not concurrent
Page: 48
Zachman, Spewak, and their Legacies

Why Serial Data, Applications, Technology Architecture?

• In practice, concurrent development does not work due to:


- Different team perspectives and levels of understanding
- Architectures overlap
- No incentive to be compatible
- Methodologies, people, and toolsets will differ

Data Architecture Applications Technology


Architecture Architecture

• Data architecture, however, provides a firm foundation if it


comes first
Page: 49
Zachman, Spewak, and their Legacies

Components of the EAP

• How We Get There


- Defines the sequence for
Planning
Layer 1
implementing applications Initiation

- Defines a schedule for Business


Modeling
Current
Systems & Layer 2
Technology
implementation Data Applications Technology
Architecture Architecture Architecture Layer 3
- Cost/Benefit Analysis
Layer 4
- Proposes a clear migration Implementation / Migration Plans

path
Page: 50
Zachman, Spewak, and their Legacies

EAP and the NIST Framework

• 1989 National Institutes for


Standards and Technology
(NIST) EA framework

• Five-layered model developed


to allow for organizing,
planning, and building an
integrated set of information
and information technology
architectures

• EAP operationalizes this

Source: Federal Enterprise Architecture Framework v1.0, OMB, 1999


Page: 51
Zachman, Spewak, and their Legacies

Most Enterprises that Undertake EAP Fail

• EAP is successful when the following exist:


- EAP is actually completed (most organizations don’t finish)

- The Plan is Implemented (many become shelfware)

- The architectures are used and maintained

- The business side of the organization participates


Page: 52
Zachman, Spewak, and their Legacies

Greatest Challenges to EAP 1


• Awareness/Recognition/Acceptance by Top Management
• Commitment of Resources to EA Planning
• Arrogance of IS; Unfavorable Corporate Culture
• Political Differences Regarding Responsibilities for EA Planning
• Lack of Credibility of Planning Leaders
• Inexperience with EA Planning; Lack of Training
• Resource Shortages
Page: 53
Zachman, Spewak, and their Legacies

Greatest Challenges to EAP 2


• Finding the “Best” Methodology
• Educating IS Personnel in New Technologies
• Satisfaction With Current Applications Methods
• Few or Inadequate Tools
• Uncertain Payback and rate of Return; Expecting Immediate
Results
• Fear of Loss of Data Control / Ownership
• Substantial Upfront Costs; Benefits Difficult to Measure
• Inaccessible or Uncooperative Users; Delegation
• Delusions
Page: 54
Zachman, Spewak, and their Legacies

Reasons for EAP Success 1

• Management Commitment and Support

• End-User and Management Participation and Cooperation

• Effective Project Leadership and Workplan (Methodology)

• Acceptable Balance of Scope and Objectives vs. Level of

Detail vs. Resources and Time Committed


Page: 55
Zachman, Spewak, and their Legacies

Reasons for EAP Success 2


• Qualified, Trained Team and Use of Consultants
• Productive Documentation and Analysis Tools
• Compatible Culture
• Distribution of Intermediate Deliverables
• Business leaders engagement
• Effective Presentations
• 80/20 Principle
• There is no “perfect plan”
• Do not get bogged down in the details
• 80% completeness and accuracy in each EAP phase is “good enough” to produce
reasonable, feasible architectures and plans
• Put the detail in the systems designs that follow…
Page: 56
Zachman, Spewak, and their Legacies

Planning Initiation

• Determine Scope and Objectives


• Create a Vision Planning
Initiation
Layer 1

• Adapt a Methodology Business


Modeling
Current
Systems & Layer 2
Technology
• Arrange for Resources Data
Architecture
Applications
Architecture
Technology
Architecture Layer 3

• Assemble the Planning Team Implementation / Migration Plans Layer 4

• Prepare an EAP Workplan


• Obtain Management Approval
Page: 57
Zachman, Spewak, and their Legacies

Building The Preliminary Business Model


Planning
Layer 1
Initiation

Business Current
Modeling Systems & Layer 2
Technology
Data Applications Technology
• Document the Organizational Architecture Architecture Architecture Layer 3

Structure Implementation / Migration Plans Layer 4

• Identify and Define Business


Functions
• Document the Preliminary
Business Model and Present it
Back to the Business
Community for Comments
Page: 58
Zachman, Spewak, and their Legacies

Defining the Current Systems and


Technology Architecture
Planning
Layer 1
Initiation

Business Current
• Determine the scope, objectives, Modeling Systems &
Technology
Layer 2

and Information Resource Catalog Data


Architecture
Applications
Architecture
Technology
Architecture Layer 3
(IRC) workplan
Implementation / Migration Plans Layer 4
• Prepare for data collection
• Collect the IRC data
• Enter the data
• Validate and review the draft of the
IRC
• Draw schematics
• Distribute the IRC
• Administer and Maintain the IRC
Page: 59
Zachman, Spewak, and their Legacies

Defining the Data Architecture


Data Architecture Planning
Initiation
Layer 1

Business Current
Modeling Systems & Layer 2

• Identifies and defines the Data


Technology
Applications Technology
Architecture Architecture Architecture Layer 3
major kinds of data that
support the business Implementation / Migration Plans Layer 4

functions in the enterprise


business model

• Drives the definition of logical


and physical database design
(Zachman Rows 3, 4)
Page: 60
Zachman, Spewak, and their Legacies

Defining the Data Architecture

Percent of Effort

• List candidate data entities 10%


• Define the entities, attributes, and relationships 60%
• Relate the entities to business functions 20%
• Distribute the data architecture 10%
Planning
Layer 1
Initiation

Total Data Architecture Phase: Business


Modeling
Current
Systems & Layer 2
Technology
15% of Project Data Applications Technology
Architecture Architecture Architecture Layer 3

Implementation / Migration Plans Layer 4


Page: 61
Zachman, Spewak, and their Legacies

Defining the Applications Architecture


Applications Architecture
Planning
Layer 1
Initiation

• Defines the major kinds of Business Current


Layer 2
Modeling Systems &
applications needed to manage Technology
Data Applications Technology
the data in the data architecture Architecture Architecture Architecture Layer 3

and thus support the functions in Implementation / Migration Plans Layer 4

the business architecture


• Not a design for systems nor a
detailed requirements analysis
• Definition of what applications
will do to manage data and
provide information to people
performing business functions
Page: 62
Zachman, Spewak, and their Legacies

Defining the Applications Architecture

Percent of Effort
• List candidate applications 10%
• Define the applications 50%
• Relate applications to functions 15%
• Analyze impact to current applications 15%
• Distribute the applications architecture 10%

Planning
Layer 1
Initiation

Business Current
Modeling Systems & Layer 2
Technology
Total Applications Architecture Phase: Data Applications Technology
Architecture Architecture Architecture Layer 3
15% of Project
Implementation / Migration Plans Layer 4
Page: 63
Zachman, Spewak, and their Legacies

Defining the Technology Architecture


Technology Architecture Planning
Layer 1
Initiation

• Defines the major kinds of Business


Modeling
Current
Systems & Layer 2
Technology
technologies needed to Data Applications Technology
Layer 3
Architecture Architecture Architecture
provide an environment for
Layer 4
the applications that are Implementation / Migration Plans

managing data
• Not a detailed requirements
analysis or design
• Defines kinds of technologies
– called platforms
• Must follow, not precede the
other architectures
Page: 64
Zachman, Spewak, and their Legacies

Defining the Technology Architecture

Percent of Effort

• Identify technology principles and platforms 15%


• Define the platforms and distribution 50%
• Relate the technology platforms to 20%
applications and business functions
• Distribute the technology architecture 15%
Planning
Layer 1
Initiation

Business Current
Modeling Systems & Layer 2
Technology

Total Technology Architecture Phase: Data


Architecture
Applications
Architecture
Technology
Architecture Layer 3
10% of Project
Implementation / Migration Plans Layer 4
Page: 65
Zachman, Spewak, and their Legacies

Developing the Implementation Plan

Implementation Plan
Planning
Layer 1
Initiation

Business Current
• Purpose: Formulate and Modeling Systems &
Technology
Layer 2

prepare a plan to implement Data


Architecture
Applications
Architecture
Technology
Architecture Layer 3

the architectures Implementation / Migration Plans Layer 4

• Sometimes called the


migration strategy
• Scope is about five years out
– or longer
Page: 66
Zachman, Spewak, and their Legacies

Developing the Implementation Plan

• Sequence the applications Planning


Layer 1
• Info creators before info users Initiation

Business Current
Layer 2
• Estimate the effort and Modeling Systems &
Technology

resources, produce a Data


Architecture
Applications
Architecture
Technology
Architecture Layer 3

schedule Implementation / Migration Plans Layer 4

• Estimate the costs and


benefits of the plan
• Determine the success factors • Prepare the final report
and make recommendations • Make presentations to
management
Page: 67
Zachman, Spewak, and their Legacies

Transition to Implementation
Planning
Layer 1
Initiation

Business Current
• Plan the transition Modeling Systems & Layer 2
Technology
• Adopt a system development Data Applications Technology
Architecture Architecture Architecture Layer 3
approach
• Arrange for computer resources Implementation / Migration Plans Layer 4

• Refine the architectures


• Institute organizational changes
• Recruit implementation personnel
• Provide training
• Establish programming standards
• Establish procedural standards
• Develop a detailed schedule for the
first set of apps
• Confirm the end of transition
Page: 68
Zachman, Spewak, and their Legacies

Commentary
• Very easy to get bogged down in the process
- Desire for completeness -- vs. -- 80/20
- Slow arrival of information from surveys
- Abstraction level mismatches can really complicate matters
• Customer may see EAP as a perpetual process
- But why would humble contractor disagree?
- Conservative customer will draw EAP out for years
- Again, why would humble contractor disagree?
• Danger of: EAP for EAP’s sake -- vs. -- EAP to bring real change
• Danger of: All, but the implementation
• EAP mostly assumes clean slate
- Reality can be dominated by stronger pre-defined Tech Architecture
• EAP influence is huge; even half done, it is very useful
Page: 69
Zachman, Spewak, and their Legacies

The Legacies of Zachman & Spewak


Page: 70
Zachman, Spewak, and their Legacies

1993: Setting
1993 Congressional Findings
• Waste and inefficiency in Federal programs undermine the
confidence of the American people in the Government and
reduces the Federal Government's ability to address adequately
vital public needs
• Federal managers are seriously disadvantaged in their efforts to
improve program efficiency and effectiveness, because of
insufficient articulation of program goals and inadequate
information on program performance
• Congressional policymaking, spending decisions, and program
oversight are seriously handicapped by insufficient attention to
program performance and results
Page: 71
Zachman, Spewak, and their Legacies

GPRA 1993
Page: 72
Zachman, Spewak, and their Legacies

TISAF
• Treasury Information Systems Architecture Framework
– Developed 1992 to 1997 with help from a certain Dr. Spewak

• Intent: to help reduce the cost, complexity, and risk associated


with information technology development and operations

• In 1997, Treasury issued TISAF Version 1, consisting of three


volumes:
- Treasury Information Systems Architecture Framework (TISAF)
- Treasury Architecture Development Guidance (TADG), and the
- Treasury Architecture Development Process (TADP)
Page: 73
Zachman, Spewak, and their Legacies

TISAF Component Representations


• Work: A description of where and by
whom information systems are to be used
throughout the agency
• Functional: A representation of what the
organization does (i.e., its mission and
business processes) and how the
organization can use information systems
to support its business operations
• Information: A description of what
information is needed to support business
operations
• Infrastructure: A description of the
hardware and “services” (e.g., software
and telecommunications) needed to
implement information systems across the
agency
Page: 74
Zachman, Spewak, and their Legacies

TISAF Views
• TISAF’s functional, work, and information components together
form the logical view of the architecture

• Infrastructure represents the technical view of the architecture


Business View

Logical View

Technical View
Page: 75
Zachman, Spewak, and their Legacies

TISAF Implementation Guidance


• TISAF architecting begins with defining and describing the
agency’s major business functions
• Once this is accomplished, the agency can identify the:
- Relationships among the functions
- The information needed to perform the functions
- The users and locations of the functions, and
- The existing and needed applications and related information technology
required to execute and support the business functions
• The architecture’s infrastructure component (i.e., its systems
specifications and standards) should be derived from the other
three components
• Each element of the architecture must be integrated and
traceable, and the relationships between them must be explicit
Page: 76
Zachman, Spewak, and their Legacies

Setting: 1996
• Information Technology Management Reform Act (ITMRA)
(a.k.a. Clinger-Cohen Act)
• ITMRA establishes in law:
• Chief Information Officers (CIO) for Federal agencies
» CIOs are responsible for providing advice and assistance to agency heads on
IT acquisition and IRM (Information Resource Management)
» The CIO is responsible for developing, maintaining, and facilitating the
implementation of a sound and integrated IT architecture
» The architecture is an integrated framework for evolving or maintaining
existing IT and acquiring new IT
• The agency heads shall identify in the agency's IRM plan major IT
acquisition programs that have significantly deviated from their
respective cost, performance, or schedule goals
Page: 77
Zachman, Spewak, and their Legacies

Clinger-Cohen Act 1996


• Defines the term “information technology”:

 “… means any equipment or interconnected system or


subsystem of equipment, used in the automatic acquisition,
storage, manipulation, management, movement, control,
display, switching, interchange, transmission, or reception
of data or information by the executive agency, if the
equipment is used by the executive agency directly or is
used by a contractor under a contract with the executive
agency that requires the use.”
Page: 78
Zachman, Spewak, and their Legacies

Clinger-Cohen Act 1996


• Mandates Capital Planning and Investment Control (CPIC)

• “… develop a process for analyzing, tracking, and evaluating the


risks and results of all major capital investments made by an
executive agency for information systems

• Process shall cover the life of each system and shall include
explicit criteria for analyzing the projected and actual costs,
benefits, and risks associated with the investments
Page: 79
Zachman, Spewak, and their Legacies

Clinger-Cohen Act 1996


• Use of Standards
– “The Director shall oversee the development and implementation of
standards and guidelines pertaining to federal computer systems by the
Secretary of Commerce through the National Institute of Standards and
Technology”

• Greater use of commercial sources

• Establishes the CIO Council to explore best practices


– this group went on to develop the Federal Enterprise Architecture
Page: 80
Zachman, Spewak, and their Legacies

2000: TISAF leads to TEAF


• Treasury gained experience with TISAF and enhanced it
• They read the Clinger-Cohen tea leaves
• Released v2 as the “Treasury
Enterprise Architecture
Framework” in 2000
• More explicitly
Zachman
• We’ll go here later…

Source: TEAF v1.0 US Treasury, 2000


Page: 81
Zachman, Spewak, and their Legacies

Integrated Architecture Framework (IAF) - Capgemini

• Integrated Architecture Framework (IAF)


• Developed by Capgemini
• In use since 1993
• Covers business, information, and technology
• “Developed from the experience of practicing
architects on projects for clients across the
(Capgemini) group”
• IAF is:
- “A comprehensive framework that enables Capgemini
to deliver market-leading solutions
- 100% adaptable to the specific needs of our customers
- Scalable from individual projects to enterprise-wide transformation”
Source: Architecture and the Integrated Architecture Framework, Capgemini, 2012
Page: 82
Zachman, Spewak, and their Legacies

Integrated Architecture Framework (IAF) - Capgemini


• Uses Aspect Areas
and Abstraction
Levels
• Each “cell” in this
model has a
defined set of
Abstraction Levels

Artifacts
• Views then allow
architects to bring
together and
visualize the
artifacts to help in
modeling the
architecture and to
communicate the
architecture with Aspect Areas
the various
stakeholders Source: Architecture and the Integrated Architecture Framework, Capgemini, 2012
Page: 83
Zachman, Spewak, and their Legacies

IAF Abstraction Levels


• Abstraction Levels allow a consistent level of definition and
understanding to be achieved in each area of the architecture
• Especially useful when dealing with large and complex
architectures, as it allows for all relevant issues to be identified
before further detailing is attempted
- Contextual – “Why?”
- Conceptual - “What?”
- Logical - “How?”
- Physical - “With what?”
• Very similar to Zachman’s
rows but uses the
interrogatives here
instead

Source: Architecture and the Integrated Architecture Framework, Capgemini, 2012


Page: 84
Zachman, Spewak, and their Legacies

IAF Aspects
 Aspects break down the complexity of the Architecture
 Six “Aspect Areas” similar to Zachman’s columns
 Four of which focus exclusively on the core aspects of the
overall architecture:
- Business
- Information
- Information Systems
- Technology Infrastructure
 Two are discipline specific:
- Security
- Governance

Source: Architecture and the Integrated Architecture Framework, Capgemini, 2012


Page: 85
Zachman, Spewak, and their Legacies

IAF Views
1. Information Ownership View
- Information objects and their ownership (by actors)
2. Major Information System Interfaces Model
- Visualizes major Information System Service Interactions
3. Integration View
- Visualizes the logical components from the perspective of Collaboration Contracts, highlighting the
different integration approaches needed
4. Distribution View
- Visualizes the distribution of components of the solution, typically across topographical or
geographic areas such as data centers and office locations
5. Security View
- Focuses on how security components or requirements are overlaid on the other aspects of the
architecture
- Typically an end-to-end view across the architecture showing the security domains and security
services that are needed
6. Governance View
- Focuses on how the architecture will be governed in terms of the quality objectives such as
availability, performance, restorability will be addressed by the governance components

Source: Architecture and the Integrated Architecture Framework, Capgemini, 2012


Page: 86
Zachman, Spewak, and their Legacies

Extended Enterprise Architecture Framework – E2AF

 A communication framework
describing the topics and
relations that can be addressed
during an architecture program

 Purpose: to communicate with all the stakeholders involved in


the program

 IFEAD is an: “independent research and


information exchange organization working on
the future state of Enterprise Architecture”
 Jaap Schekkerman, President & Thought Leader
Source: Extended Enterprise Architecture Framework Essentials Guide, Schekkerman, 2012
Page: 87
Zachman, Spewak, and their Legacies

Extended Enterprise Architecture Framework – E2AF


Page: 88
Zachman, Spewak, and their Legacies

Extended Enterprise Architecture Framework – E2AF

 E2AF levels of abstraction (columns) are similar to IAF’s and


Zachman’s rows

 Principles guiding E2AF levels of abstraction


- Separate the Strategy from Requirements
- Separate Requirements from solutions
- Separate solutions from implementations
- Separate implementations from transformations

 E2AF’s Aspect Areas (rows) are similar to IAF’s Aspects and


Zachman columns

 Security, Governance, and Privacy are Viewpoints


Source: Extended Enterprise Architecture Framework Essentials Guide, Schekkerman, 2012
Page: 89
Zachman, Spewak, and their Legacies

Extended Enterprise Architecture Framework – E2AF


Abstraction Levels
 Contextual level (Why?)
- Describes the extended context of the
organization and the scope of the enterprise
architecture study
- Describes the motivations of the enterprise
- Reveals the enterprise mission, vision and
scope and the business & technology
strategy / drivers

 Environmental level (With who?)


- Describes the formal extended business
relations and the related information flows
- Represents the business & technology
relationships within the extended
enterprise
- Types of collaboration
- Design of the extended enterprise
organization has to do with the value
proposition in the net and the structure of
governance within the extended enterprise
Source: Extended Enterprise Architecture Framework Essentials Guide, Schekkerman, 2006
Page: 90
Zachman, Spewak, and their Legacies

Extended Enterprise Architecture Framework – E2AF


Abstraction Levels

 Conceptual level (What?)


- Addresses the Requirements
- Describes the goals and objectives and
the requirements of the enterprise
entities involved in each aspect area of
the enterprise

 Logical level (How)


- Addresses the ideal logical solutions
- Shows the logical solutions within each
aspect area

Source: Extended Enterprise Architecture Framework Essentials Guide, Schekkerman, 2006


Page: 91
Zachman, Spewak, and their Legacies

Extended Enterprise Architecture Framework – E2AF


Abstraction Levels
 Physical level (With What)
- Addresses the physical solution of
products & techniques
- Shows physical solutions in each aspect
area, including business &
communication changes, supporting
software products and tools, hardware
& communication products

 Transformational level (When)


- Describes the impact for the
organization of the proposed solutions
- Represents the transformation
roadmap, dependencies within aspect
areas, supported by business cases

Source: Extended Enterprise Architecture Framework Essentials Guide, Schekkerman, 2006


Page: 92
Zachman, Spewak, and their Legacies

Extended Enterprise Architecture Framework – E2AF

 Business (or Organization) Aspect Areas


- Starting point and expressing all business elements
and structures in scope
 Information
- Extracted from the business an explicit expression
of information needs, flows and relations is
necessary to identify the functions that can be
automated
 Information – Systems
- The automated support of specific functions
 Technology – Infrastructure
- The supporting technology environment for the
information systems

 All these aspect areas have to be related to


each other in such a way that a coherent set
of relations can be identified
 Integration of these aspect areas is a
necessity for an Enterprise Architectural
design
Source: Extended Enterprise Architecture Framework Essentials Guide, Schekkerman, 2012
Page: 93
Zachman, Spewak, and their Legacies

EA3 – (EA Cube)

 Dr. Scott Bernard


 Former naval aviator
 2011: Federal Chief Enterprise Architect with the Office
of Management and Budget, Executive Office of the
President
 Professor Syracuse University’s School of Information
Studies
 Carnegie Mellon University's School of Computer Science
 Invented the EA3 Cube framework and methodology
TM

 An Introduction to Enterprise Architecture: 3rd Edition, 2012


 Founding President of the Association of
Enterprise Architects
Page: 94
Zachman, Spewak, and their Legacies

EA3 – (EA Cube)


 EA = Strategy + Business + Technology
 Both a management program and a documentation method
 As a Management Program, EA provides:
- Strategic alignment: Connects goals, activities, and resources
- Standardized policy: Resource governance and implementation
- Decision support: Financial control and configuration management
- Resource oversight: Lifecycle approach to development/management

 As an Analysis and Design Method, EA provides:


- EA approach: The framework analysis/design method, and artifact set
- Current views: Views of AsIs strategies, processes, and resources
- Future views: Views of ToBe strategies, processes, and resources
- EA management plan: A plan to move from current to future EA
Source: An Introduction to Enterprise Architecture, Bernard, 2012
Page: 95
Zachman, Spewak, and their Legacies

EA3 as a Management Program

Enterprise Strategic Goals


 Strategic Alignment

Capability Alignment
- Macro and micro views of
Enterprise-Wide Strategic Initiatives
how resources are going
to be leveraged to Line of Business 1 Line of Business 2 Line of Business 3
accomplish enterprise Goals Goals Goals
goals Line of Business 1 Line of Business 2 Line of Business 3
Program Group Program Group Program Group
IT Project 1-1

IT Project 1-2

IT Project 1-3

IT Project 2-1

IT Project 2-2

IT Project 2-3

IT Project 3-1

IT Project 3-2

IT Project 3-3
Resource Alignment
Source: An Introduction to Enterprise Architecture, Bernard, 2012
Page: 96
Zachman, Spewak, and their Legacies

EA3 as a Management Program


 Standardized Policy
- Identifying strategic and operational requirements
- Determining strategy alignment of activities and resources
- Developing enterprise-wide business and technology resources
- Prioritizing the funding of programs and projects
- Overseeing the management of programs and projects
- Identifying performance metrics for programs and projects
- Identifying and enforcing standards and configuration management
 Decision Support
- Resource decision making (finding the gaps)
- Operations, maintenance, development decisions too
 Resource Oversight
- Standardized process for selecting and evaluating investment options
Source: An Introduction to Enterprise Architecture, Bernard, 2012
Page: 97
Zachman, Spewak, and their Legacies

EA3 as an Analysis and Design Method


 Derived from Architecture Description
 Essentially the scheme for organizing information
 Document Method has Six Elements:
1. The Framework
2. EA Components
3. Current Architecture
4. Future Architecture
2
5. EA Management Plan
6. Planning Threads
EA Framework

Architecture
Management &
Transition Plan
1
5

6
Multi-Level Threads (Security / Standards / Workforce)

CURRENT 3 FUTURE 4
ARCHITECTURE ARCHITECTURE

Source: An Introduction to Enterprise Architecture, Bernard, 2012


Page: 98
Zachman, Spewak, and their Legacies

EA3 Cube Documentation Framework


Segments: Vertical sub-areas of
Artifacts: Documentation of the components at
the enterprise with distinct
each level of the architecture including threads
business activities and resources

functional areas and their relationships


Lines of Business

Levels: Sub-architectures distinct


C
Goals & O
M
Initiatives
Technology – Business - Strategy

P
Security – Standards - Skills

O
Products &
N
Services E
N
Data &
T
Information S

Systems &
Applications
Networks &
Infrastructure
Source: An Introduction to Enterprise Architecture, Bernard, 2012
Page: 99
Zachman, Spewak, and their Legacies

EA3 Cube Analysis and Design Framework


 Line of Business
- A distinct area of activity within an
enterprise
- May involve the manufacture of certain
products, provision of certain services, or
certain administrative functions

 Architectural Segment
- A part of the EA that documents one of
more lines of business at all levels and
threads
- Can exist as a stand-alone part of the EA

Source: An Introduction to Enterprise Architecture, Bernard, 2012


Page: 100
Zachman, Spewak, and their Legacies

EA3 Cube Analysis and Design Framework


 Vertical Component
- Changeable goal, process,
program, or resources
(equipment, systems, data,
etc.) that serves one line of • Mission Statement
Goals &
business Initiatives
• Strategic Goals
• Strategic Initiatives

Vertical
• Manufacturing
Products &
 Horizontal (Crosscutting)
• Financial Services
Services • Marketing & Sales

Component Data &


• Knowledge Warehouse
• Databases / Data Marts
Information
- Changeable goal, process,
• Data Interchange
• Information Systems
program, or resources Systems & • Web Sites
Applications
(equipment, systems, data,
• Desktop Applications
• Intranets / Extranets
etc.) that serves several lines Technology &
• Telecommunications
Infrastructure
of business • Buildings & Equipment

- Example: email Examples


Source: An Introduction to Enterprise Architecture, Bernard, 2012
Page: 101
Zachman, Spewak, and their Legacies

EA3 Components and Artifacts


Common Threads
 Security
- Security Plan (SP-1)
- Security Solutions Description (SP-2)
- Security Accreditation Document (SP-3)
- Continuity of Operations Plan (SP-4)

Security – Standards - Skills


- Disaster Recovery Procedures (SP-5)

 Standards
- Technology Standards Profile (ST-1)
- Technology Forecast (ST-2)

 Skills
- Workforce Plan (W-1)
- Organization Chart (W-2)
- Knowledge and Skills Profile (W-3)

Source: An Introduction to Enterprise Architecture, Bernard, 2012


Page: 102
Zachman, Spewak, and their Legacies

Extensible Architecture Framework - xAF

 Goal: to develop a generic architecture framework that is theoretically solid


and practically useful
- xAF does not intend to replace current or future Architecture Frameworks
- xAF does not intend to be another Architecture Framework
- xAF will describe any Architecture Framework
 The framework must be widely applicable,
i.e. within the whole area of enterprise
engineering (business definition,
business processes, IT-applications,
organizations etc.).
 The definition of each concept must leave
space for customization within any (sub)field
 The framework should not be a rigid standard

Source: eXtensible Architecture Framework v1.1, Dietz, 2007


Page: 103
Zachman, Spewak, and their Legacies

xAF: Two Conceptual Models of Systems


 There are two fundamentally different types of conceptual
models of systems: white-boxes and black-boxes
- A white-box (WB) is most close to the system definition
» Captures the construction and the operation of a system, while abstracting
from realization details that are assumed to be irrelevant
» Example: Bohr Atom

- A black-box (BB) is an abstract conceptual system that has no direct


relation with a system's construction and operation
» Only the interactions between the composition and the environment are
taken into account
» Represented as aggregated values of input and output variables
» Example: functional model

Source: eXtensible Architecture Framework: Concept and Application, Dietz and Baldinger, 2007
Page: 104
Zachman, Spewak, and their Legacies

xAF: Two Design Perspectives

Black Boxes White Boxes


Source: eXtensible Architecture Framework: Concept and Application, Dietz and Baldinger, 2007
Page: 105
Zachman, Spewak, and their Legacies

Role of Architecture in Any System


Development Process
White boxes Black box

Source: eXtensible Architecture Framework: Concept and Application, Dietz and Baldinger, 2007
Page: 106
Zachman, Spewak, and their Legacies

Extensible Architecture Framework - xAF


 An Architecture:
- [conceptually] a normative restriction of design freedom
- [operationally] a set of design principles

 An Architectural Framework
- A checklist for issues to be taken into account / an ordering

 Structure for principles


- tuple <S, P, A> (an ordered list)
- S=System type, P=Perspective, A=Area of Concern

Source: eXtensible Architecture Framework: Concept and Application, Dietz and Baldinger, 2007
Page: 107
Zachman, Spewak, and their Legacies

Extensible Architecture Framework - xAF

Example: two “chairs”

Source: eXtensible Architecture Framework: Concept and Application, Dietz and Baldinger, 2007
Page: 108
Zachman, Spewak, and their Legacies

Extensible Architecture Framework - xAF

 Architectural extensibility
applied to chairs

 Increasingly specific
dimensionality

 Framework tree

Source: eXtensible Architecture Framework: Concept and Application, Dietz and Baldinger, 2007
Page: 109
Zachman, Spewak, and their Legacies

Extensible Architecture Framework - xAF

 Applied to IT Enterprise
- System Types: Business, Information, Document
- Perspectives: function, construction
- Areas of Concern: Reliability, Maintainability

D
D
D
D

Source: eXtensible Architecture Framework: Concept and Application, Dietz and Baldinger, 2007
Page: 110
Zachman, Spewak, and their Legacies

Summary
• What have we seen?

• A focus on framework design


• Some focus on how to fill it with good stuff
• Little said about what artifacts belong in the views
• Little said about who should do the work and how
• More like a systematic scavenger hunt than a form of
communication
• “If we build it, they will come and use it” mindset