Lecture2 is353-ea(the zachma framework)

1
The Zachman Framework
(Enterprise Architecture IS353)
Lecture 2
Taibah University
College of Computer Science & Engineering
Information Systems Department
Topic subject
 Introduction
 System Development Life Cycle
 Data, Function, Network, People, Time, Motivation
 What constitutes the “enterprise”?
 Key enterprise architecture terms
 Enterprise Architecture Terms
 How do you achieve perfect alignment?
 Importance of alignment
 Lack of Alignment
 Nature of Complexity
 Lessons Learned
 Architectural Principles
Abdisalam Issa-Salwe, College of Computer Science & Engineering, Taibah University

2
3
Zachman Framework
 Developed in 1982 at IBM by John
Zachman, first published in 1987
 Applies physics and basic engineering
principals to the enterprise as a whole
 Tool for engineering and manufacturing
enterprises
 Has a defined set of rules to follow for
successful implementations
4

3
Introduction
 John Zachman represents the process as a series of
steps, as he organized it around the points of view taken
by the various players. These players included
1. the CEO or whoever is setting the agenda and
strategy for an organization, the business people who
run the organization,
2. the systems analyst who wants to represent the
business in a disciplined form,
3. the designer, who applies specific technologies to
solve the problems of the business, and
4. the system itself.
System Development Life Cycle
 Many methodologies are organized around the
"system development life cycle," an organization
of the steps required to develop systems.
 Most methodologies portray the system
development life cycle in terms approximating
these.
 Some go so far as to give it the acronym
“SDLC.”

4
System Development Life Cycle (cont…)
 Strategy – The planning of an organization's
overall systems development effort. This
includes determining the overall set of things of
significance to a business, the application areas
to be addressed, and the priorities to apply to
those priorities.
 Analysis – The detailed definition of
requirements for a particular area of the
business. At this point, the data structures are
mapped in detail, the functions of the business
are described thoroughly, and the areas to be
automated are defined.

5
 Design – The specific application of technology
to the requirements defined during analysis.
Here the data structures become database
designs and the function definitions become
program specifications. At this point attention is
paid to the human interface, in the interest of
defining the behavior of a prospective system.
 Construction – The actual building of the
system.
 Documentation – Preparation of the user
manuals, reference manuals, etc. to describe the
system.
 Transition – The implementation of the system,
so as to make it part of the infrastructure of the
organization. This involves education, training,
definition of new organizational structures and
roles, and the conversion of existing data.
 Production – The ongoing monitoring of the
system to ensure that it continues to meet the
needs of the organization.

6
1. Scope (Ballpark view): Definition of the
enterprise’s direction and business purpose.
This is necessary to establish the context for
any system development effort.
2. Model of the business (Owner’s view): This
defines — in business terms — the nature of
the business, including its structure, functions,
organization, and so forth.
3. Model of the information system (Architect’s
view): This defines the business described in
step 2, but in more rigorous information terms.
4. Technology model (Designer’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.
5. Detailed representations (Builder’s view): Here a
particular language is chosen, and the program
listings, database specifications, networks, and
so forth are all produced.

7
6. Functioning system: Finally, a system is
implemented and made part of an organization.
The columns in the Zachman framework
represent different areas of interest for each
perspective. The
columns describe the dimensions of the
systems development effort.
Different Abstractions (Columns)
 What (Data)
 How (Function)
 Where (Network)
 Who (People)
 When (Time)
 Why (Motivation)
14

8
Data
 Each of the rows in this column address
understanding of and dealing with an
enterprise’s data.
 Row One: lists of the things that concern the
company and affect its direction and purpose.
 Row Two: is a contiguous model of the things
seen by the participants in the business. Many-
tomany and n-ary relationships may be present,
reflecting the way the business views them.
 Also, relationships may be shown which themselves
have attributes.
Data (cont…)
 Row Three: provides more of an information-
based perspective, resolving many-to-many and
n-ary relationships, along with relationships
containing their own attributes. Indeed, attributes
are more exhaustively defined, and unique
identifiers are specified.
 Entities are generalized to more closely reflect the
underlying structure of the business and its
relationships.

9
Data (cont…)
 Row Four, entities are converted to table definitions,
object classes, hierarchy segments, or whatever is
appropriate for the kind of data base management
system to be used.
 This is tantamount to creating the data definition
language statements.
 Row five: the tables are actually implemented on
physical disk drives, using the underlying organization of
the database management system.
 This is where tablespaces are defined, disk packs are
allocated, and so forth.
 Row six: The actual database itself is created and initial
data are converted and loaded .

10
Function
 The rows in the function column describe the
process of translating the mission of the
enterprise into successively more detailed
definitions of its operations.
 Where 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.
Function (cont…)
 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.

11
Network
 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
Network (cont…)
 In row four, this distribution is translated into the
kinds of computer facilities that are required in
each location, and 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.

12
People
 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.
People (cont…)
 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.
 What roles do each play and what data are
necessary for those roles?
 Along with this are specific definitions of security
requirements, in terms of who (which role) is
permitted access to what.

13
People (cont…)
 In row four, the actual interface between each
person and the technology is designed.
 In this row, issues of interface graphics, navigation
paths, security rules and presentation style are
addressed.
 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.
Time
 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

14
Time (cont…)
 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.
Motivation
 Here is concerned with 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.

15
What constitutes the “enterprise”?
 State Government
 A Department
 A Division
 A Bureau
 A Section
 A Unit
 IT Managers
 Lawyers
 HR Staff
 Web Developers
 A Union
 A Project
Any Natural boundary (or sameness)
The definition of an enterprise is not important,
what is important is that all models are built on
the same standards and framework so they can
be integrated. 29
The Framework
 Row models are easier than column
models
 All about standards (all engineering
assumes a set of standards)
 Everyone should be on the framework
30

16
Key enterprise architecture terms
 Explicit vs. Implicit
 Primitives vs. Composites
 Integration vs. Interfacing
 Alignment vs. Discontinuity
 Nature of Complexity
31
Enterprise Architecture Terms
Explicit vs. Implicit
 A cell that hasn’t been modeled (made
explicit) is implicit by definition
 Assumptions have to be made when
involving implicit cells
 Assumptions generally have large margins
for error
32

17
Enterprise Architecture Terms (cont..)
Primitives vs. Composites
 Data elements “primitives” versus
“composites”
 Primitive models are architecture
 Composite models are implementations
33
Enterprise Architecture Terms (cont…)
Integration:
 If you start with
primitive models,
integration is easy
 Single source data (or
integration) is optimal
 Means sharing (not
duplicating)
Interfacing:
 Data interfacing is
better than nothing,
but not optimal
 Increases complexity
 Has maintenance
issues
Integration vs. Interfacing
34

18
Importance of alignment
First, build row 1 models
Next, build row 2 models
Ensuring that the intent of each row is
successfully represented (transformed) in
the succeeding row
35
Lack of Alignment
 Lack of alignment creates discontinuity
 When there duplication, there is discontinuity
 Reduce discontinuity by reducing redundant
systems and redundant data
 Interfacing causes discontinuity – Compensate
in the short term to mix pieces
 Integrating provides alignment – Reengineer to
take out the discontinuity long term
 Exceptions to standards are business rules that
are required to deal with discontinuity
36

19
Nature of Complexity
 There is a certain amount of complexity built into
any enterprise, product or service
 Three change models for complexity without
architecture
1. Trial and error – Just do it
2. Reverse engineer – Takes time and costs a
lot of money
3. Scrap and start over
 Change can be engineer with your
architectural blueprints
37
Nature of Complexity (cont…)
 If complexity is not dealt within the enterprise, it
gets pushed to the customer
 Treating a person as an “individual” rather than
a “group” causes the complexity level to go out
of sight
 The detail and complexity doesn’t go away just
because it is dealt with:
 It gets passed onto the customer
 Different results in government than in the private
sector
38

20
Lessons Learned
 Goal is to isolate the change, estimate the
impact, and provide a tool for managing the
change for optimal success
 It is a model to come up with rational problem
solving
 Discontinuity in the framework causes
dissatisfaction among management and
customers (generally focused at IT) because IT
owns the systems
39
Lessons Learned (cont…)
 It cannot integrate systems (optimally) if they are
not build for integration (hold data once)
 Program managers need to take ownership of
their models (not IT)
 If done correctly, programming should become a
rote type position
 Technology change (row 5) should not interrupt
the enterprise (because the models don’t
change)
40

21
Lessons Learned (cont…)
 Because government is service oriented,
column 4 is most important
Example:
Column 1 – GIS, Banking, Finance
Column 2 – Manufacturing
Column 3 – Fed Ex
Column 4 – Universities, Government
Column 5 – Fire Dept., Police
Column 6 - Everyone
41
Architectural Principles
1. Make sure you have alignment through the
entire framework.
2. Make sure all models are developed based on
the same standards managed from an
enterprise-wide perspective.
3. Make sure all hardware and software is
compatible based on standards for effective
communication.
42

22
Architectural Principles (cont…)
4. Make sure business rules are enforced
consistently across the enterprise.
5. Make sure systems are defined logically (row 3
and 4 models), independent of technology (row
5) so technology can be easily changed.
6. Make sure change is incorporated as a
management criteria so any aspect of the
enterprise can be maintained in a dynamic
environment.
43
Reference
 David C. Hay A Different Kind of Life Cycle:
The Zachman Framework Essential Strategies,
Inc.
 Abdisalam Issa-Salwe, Lecture Notes, Taibah
University, 2011.

23
Practical session
Importance of data in Enterprise Architecture:
 The function within a business organisation that
facilitates data processing and enables the
resulting information to be made available to
employees who need it. Also known as
information technology.

Lecture2 is353-ea(the zachma framework)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Lecture2 is353-ea(the zachma framework)

Similar to Lecture2 is353-ea(the zachma framework) (20)

More from Taibah University, College of Computer Science & Engineering

More from Taibah University, College of Computer Science & Engineering (20)

Recently uploaded

Recently uploaded (20)

Lecture2 is353-ea(the zachma framework)