ESC EA Overview 08-04.ppt

8/14/2019 ESC EA Overview 08-04.ppt

1/45

Enterprise ArchitectureA General Overview

Presented to:

Enterprise Solutions Council (ESC)

August 19, 2004


2/45

What is enterprise architecture?

A method for managing your business orenterprise:

A decision making tool

A change management tool

The knowledgebase of your business or

enterprise


3/45

Enterprise architecture is not

focused on Information

Technology

(IT is only a part or subset of enterprisearchitecture)


4/45

In the Information Age

How do you manage the increasingcomplexity of your enterprise?

How do you manage the increasing rateof change?

How do you meet the demands of your

constituency (or customers) quicker andmore efficiently?


5/45

In the Information Age

When someone leaves your enterprise,do you retain their knowledge?

As of 1/04 the state of Montana has 35%of its workforce eligible for retirement

551 employees with 30+ years

An additional 3,444 employees with 2530

years


6/45

Thousands of years ofhistory would suggest theonly known strategy foraddressing complexity and

change is architecture.


7/45

Architecture

If it gets so complexyou cant rememberhow it works, you have

to write it down

If you want to changehow it works, you startwith what you have

written down


8/45

Why enterprise architecture?

It provides a method for writing things down(develop blueprints)

It shows you the impact of moving a wall(complexity and change)

It provides the plan on how to move thewall (change management)

It helps you retain employee knowledge(becomes knowledgebase of enterprise)

If you dont have architecture, you change bytrial and error (which is high risk)


9/45

The Zachman Framework forEnterprise Architecture


10/45

Zachman Framework

Developed in 1982 at IBM by JohnZachman, first published in 1987

Applies physics and basic engineeringprincipals to the enterprise as a whole

Tool for engineering and manufacturingenterprises

Has a defined set of rules to follow forsuccessful implementations


11/45

Different Perspectives (Rows)

Owner

Designer

Builder


12/45

Different Abstractions (Columns)

What (Data)

How (Function)

Where (Network)

Who (People)

When (Time)

Why (Motivation)


13/45

Other Rows Defined

Scope (Planner) RowOwnersPerspective

Detailed Representations (TechnologyUsed)

Bottom Row Functioning Enterprise orthe Systems Electronic

Manual


14/45

Functioning Enterprise Row

System down = nowork

Out of pencils = nowork

The systems are the enterprise!


15/45

Using the Zachman Framework


16/45

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)


17/45

The definition of an enterprise is not important,what is important is that all models are built onthe same standards and framework so they canbe integrated.


18/45

Implementation of theFramework

ZachmanFramework(Case Tool)

State of MontanaArchitecture

StandardsFramework

(our business rules,

policies, best practices,templates)

EnterpriseBlueprints

(Knowledgebaseof enterprise,

implementations)


19/45

The Framework

Row models are easier than columnmodels

All about standards (all engineeringassumes a set of standards)

Everyone should be on the framework

(and if they arent)


20/45

Enterprise Architecture Terms


21/45

Explicit vs. Implicit

A cell that hasnt been modeled (madeexplicit) is implicit by definition

Assumptions have to be made wheninvolving implicit cells

Assumptions generally have large

margins for error


22/45

Primitives vs. Composites

Data elements primitives versuscomposites

Primitive models are architectureComposite models are implementations


23/45

Integration vs. Interfacing

Integration:

If you start withprimitive models,integration is easy

Single source data(or integration) isoptimal

Means sharing (notduplicating)

Interfacing:

Data interfacing is

better than nothing,but not optimal

Increasescomplexity

Has maintenanceissues


24/45

Integration vs. Interfacing

Integration:

Reuse, not re-create

If you really wantintegration and not

just interfacing, theproducts (systems)

have to beengineered that way

Interfacing:

Inhibits change

Increases costsInterfacing is a shortterm strategy, not along term solution


25/45

Alignment

Key element in enterprise architecture

Means you want your functioning systems

row (row 6) to fully satisfy your enterpriseintent (row 1 and 2 models)

Manufacturing equivalent concept: Quality

If something (a process, work product, or

system feature, etc.) is not aligned with therow above it, ask why are you doing it?


26/45

How do you achieve perfectalignment?

First, build row 1 models

Next, build row 2 models

Next, build row 3 modelsNext, build row 4 models

Next, build row 5 models

Ensuring that the intent of each row issuccessfully represented (transformed) inthe succeeding row


27/45

Perfectly AlignedFunctioning Enterprise

Change

Managements Intent (rows 1 & 2)

New design best practices (row 3)

A revolutionary technology concept (row 4)Change in technology products (row 5)

What happens as aresult?


28/45

How do you keep perfectalignment in face of change?

When change happens or is needed, go backto your blueprints (models) and change themfirst

Transform the change through the rest of theframework

Net impact of the change will be your gapanalysis

Nothing will be left out of the impact if yourmodels are accurate


29/45

Discontinuity

Means lack of alignment somewhere in theframework (not following standards)

Translates to unhappy users and disgruntledmanagement

Any time you have duplication, you havediscontinuity

Reduce discontinuity by reducing redundantsystems and redundant data


30/45

Discontinuity

Interfacing causes discontinuityCompensate in the short term to mix pieces

Integrating provides alignmentReengineerto take out the discontinuity long term

Exceptions to standards are business rulesthat are required to deal with discontinuity


31/45

Nature of Complexity

There is a certain amount of complexity builtinto any enterprise, product or service

Three change models for complexity withoutarchitecture

Trial and errorJust do it

Reverse engineerTakes time and costs a lot of

money Scrap and start over

Or you can engineer the change with yourarchitectural blueprints


32/45


If you dont deal with the complexitywithin the enterprise, it gets pushed to

the customer IRS, Henry Ford

Dell, Toyota

One VA, One Stop Business Licensing


33/45


Treating a person as an individual ratherthan a group causes the complexity level togo out of sight

The detail and complexity doesnt go awayjust because you dont want to deal with it

It gets passed onto the customer

Different results in government than in the privatesector


34/45


35/45

COTS (Pre-packaged) Products

Is the average of a business space(sometimes average is better than

where you currently are)Never optimal because everyone hasunique business needs (or all

businesses would be alike)


36/45

COTS (Pre-packaged) Products

Two ways to get rid of the discontinuityintrinsic with a COTS product:

Customize and build interfaces to the COTSproduct (takes time and costs a lot ofmoney)

Work backwards up the column(s) and

change your enterprise (business practices,needs, and/or goals) to fit the COTSproduct


37/45

Why is IT interested?

The systems are the enterprise

Most systems are becoming automated

systems IT is responsible forIT organization credibility starts to decline asemployees and management becomefrustrated with IT systems

IT systems not meeting business needs

Inability to respond to short term demands (Ittakes too long and costs too much)


38/45

Why is IT interested?

IT is asked to integrate systems or datathat werent originally built for

integration (settle for interfacing)Who gets blamed for discontinuityamong systems?

The IT organization

d h h


39/45

Lessons Learned ThroughEnterprise Architecture

Goal is to isolate the change, estimate theimpact, and provide a tool for managing thechange for optimal success

It is a model to come up with rationalproblem solving

Discontinuity in the framework causes

dissatisfaction among management andcustomers (generally focused at IT) becauseIT owns the systems


40/45

L L d Th h


41/45

Lessons Learned ThroughEnterprise Architecture

If you implement a COTS system (average),you must change your business processes (gobackward up the column)

Every person (and their job function) in theorganization will be on the frameworksomewhere

Projects must be architected


42/45


43/45

Zachmans Architectural Principles

1. Make sure you have alignment through theentire framework.

2. Make sure all models are developed basedon the same standards managed from anenterprise-wide perspective.

3. Make sure all hardware and software is

compatible based on standards for effectivecommunication.


44/45


45/45

What is enterprise architecture?

A method for managing your business orenterprise:

A decision making tool

A change management tool

The knowledge base of your business orenterprise

It is about the laws of nature that determine thesuccess of an enterprise particularly, continuingsuccess in the turbulent times of the Information Age.

John Zachman

Date post:	04-Jun-2018
Category:	Documents
Upload:	navinnaithani
View:	220 times
Download:	0 times

ESC EA Overview 08-04.ppt

Documents