Lecture2 is353-ea(the zachma framework)

1

The Zachman Framework(Enterprise Architecture IS353)

Lecture 2

Abdisalam Issa-Salwe

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

4Abdisalam Issa-Salwe, College of Computer Science & Engineering, Taibah University

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)


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


16

Key enterprise architecture terms

� Explicit vs. Implicit

� Primitives vs. Composites

� Integration vs. Interfacing

� Alignment vs. Discontinuity

� Nature of Complexity


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


17

Enterprise Architecture Terms (cont..)

Primitives vs. Composites

� Data elements “primitives” versus

“composites”

� Primitive models are architecture

� Composite models are implementations


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


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


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


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


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


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)


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


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.


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.


Reference

� David C. Hay A Different Kind of Life Cycle: The Zachman Framework Essential Strategies, Inc.

� Abdisalam Issa-Salwe, Lecture Notes, Taibah University, 2011.


Lecture2 is353-ea(the zachma framework)

Business

Transcript of Lecture2 is353-ea(the zachma framework)