Enterprise ArchitectureA General Overview

Presented to:Enterprise Solutions Council

(ESC)August 19, 2004

What is enterprise architecture?

A method for managing your business or enterprise:A decision making toolA change management toolThe knowledgebase of your business or enterprise

Enterprise architecture is not…

focused on Information Technology

(IT is only a part or subset of enterprise architecture)

In the Information Age…

How do you manage the increasing complexity of your enterprise?How do you manage the increasing rate of change?How do you meet the demands of your constituency (or customers) quicker and more efficiently?

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 25 –

30 years

Thousands of years of history would suggest the only known strategy for addressing complexity and change is architecture.

Architecture

If it gets so complex you can’t remember how it works, you have to write it down…

If you want to change how it works, you start with what you have written down…

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 the wall” (change management)It helps you retain employee knowledge (becomes knowledgebase of enterprise)

If you don’t have architecture, you change by trial and error (which is high risk)

The Zachman Framework for Enterprise Architecture

Zachman Framework

Developed in 1982 at IBM by John Zachman, first published in 1987Applies physics and basic engineering principals to the enterprise as a wholeTool for engineering and manufacturing enterprisesHas a defined set of rules to follow for successful implementations

Different Perspectives (Rows)

OwnerDesignerBuilder

Different Abstractions (Columns)

What (Data)How (Function)Where (Network)Who (People)When (Time)Why (Motivation)

Other Rows Defined

Scope (Planner) Row – Owner’s PerspectiveDetailed Representations (Technology Used)Bottom Row “Functioning Enterprise” or the Systems Electronic Manual

“Functioning Enterprise” Row

System down = no work

Out of pencils = no work

The systems are the enterprise!

Using the Zachman Framework

What constitutes the “enterprise”?

State GovernmentA DepartmentA DivisionA BureauA SectionA Unit

IT ManagersLawyersHR StaffWeb DevelopersA UnionA 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.

Implementation of the Framework

Zachman Framework (Case Tool)

State of Montana Architecture Standards Framework

(our business rules, policies, best

practices, templates)

Enterprise Blueprints

(Knowledgebase of enterprise, implementatio

ns)

The Framework

Row models are easier than column modelsAll about standards (all engineering assumes a set of standards)Everyone should be on the framework (and if they aren’t…)

Enterprise Architecture Terms

Explicit vs. Implicit

A cell that hasn’t been modeled (made explicit) is implicit by definitionAssumptions have to be made when involving implicit cellsAssumptions generally have large margins for error

Primitives vs. Composites

Data elements “primitives” versus “composites”Primitive models are architectureComposite models are implementations

Integration vs. Interfacing

Integration:If you start with primitive models, integration is easySingle source data (or integration) is optimalMeans sharing (not duplicating)

Interfacing:Data interfacing is better than nothing, but not optimalIncreases complexityHas maintenance issues

Integration vs. Interfacing

Integration:Reuse, not re-createIf you really want integration and not just interfacing, the products (systems) have to be engineered that way

Interfacing:Inhibits changeIncreases costsInterfacing is a short term strategy, not a long term solution

Alignment

Key element in enterprise architectureMeans you want your functioning systems row (row 6) to fully satisfy your enterprise intent (row 1 and 2 models)Manufacturing equivalent concept: “Quality”If something (a process, work product, or system feature, etc.) is not aligned with the row above it, ask “why” are you doing it?

How do you achieve perfect alignment?

First, build row 1 modelsNext, build row 2 models

Next, build row 3 modelsNext, build row 4 models

Next, build row 5 modelsEnsuring that the intent of each row is successfully represented (transformed) in the succeeding row

Perfectly Aligned Functioning Enterprise

Change

Management’s 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 a

result?

How do you keep perfect alignment in face of change?

When change happens or is needed, go back to your blueprints (models) and change them firstTransform the change through the rest of the frameworkNet impact of the change will be your gap analysisNothing will be left out of the impact if your models are accurate

Discontinuity

Means lack of alignment somewhere in the framework (not following standards)Translates to unhappy users and disgruntled managementAny time you have duplication, you have discontinuityReduce discontinuity by reducing redundant systems and redundant data

Discontinuity

Interfacing causes discontinuity – Compensate in the short term to mix piecesIntegrating provides alignment – Reengineer to take out the discontinuity long termExceptions to standards are business rules that are required to deal with discontinuity

Nature of Complexity

There is a certain amount of complexity built into any enterprise, product or serviceThree change models for complexity without architecture Trial and error – Just do it Reverse engineer – Takes time and costs a lot

of money Scrap and start over

Or you can engineer the change with your architectural blueprints

Nature of Complexity

If you don’t deal with the complexity within the enterprise, it gets pushed to the customer IRS, Henry Ford Dell, Toyota One VA, One Stop Business Licensing

Nature of Complexity

Treating a person as an “individual” rather than a “group” causes the complexity level to go out of sightThe detail and complexity doesn’t go away just because you don’t want to deal with it It gets passed onto the customer Different results in government than in the

private sector

Key enterprise architecture terms

Explicit vs. ImplicitPrimitives vs. CompositesIntegration vs. InterfacingAlignment vs. DiscontinuityNature of Complexity

COTS (Pre-packaged) Products

Is the “average” of a business space (sometimes average is better than where you currently are)Never optimal because everyone has unique business needs (or all businesses would be alike)

COTS (Pre-packaged) Products

Two ways to get rid of the discontinuity intrinsic with a COTS product: Customize and build interfaces to the

COTS product (takes time and costs a lot of money)

Work backwards up the column(s) and change your enterprise (business practices, needs, and/or goals) to fit the COTS product

Why is IT interested?

The systems are the enterpriseMost systems are becoming automated systems IT is responsible forIT organization credibility starts to decline as employees and management become frustrated with IT systems IT systems not meeting business needs Inability to respond to short term demands

(It takes too long and costs too much)

Why is IT interested?

IT is asked to integrate systems or data that weren’t originally built for integration (settle for interfacing)Who gets blamed for discontinuity among systems? The IT organization

Lessons Learned Through Enterprise Architecture

Goal is to isolate the change, estimate the impact, and provide a tool for managing the change for optimal successIt is a model to come up with rational problem solvingDiscontinuity in the framework causes dissatisfaction among management and customers (generally focused at IT) because IT owns the systems

Lessons Learned Through Enterprise Architecture

You can’t integrate systems (optimally) if you don’t build them 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 positionTechnology change (row 5) should not interrupt the enterprise (because the models don’t change)

Lessons Learned Through Enterprise Architecture

If you implement a COTS system (average), you must change your business processes (go backward up the column)Every person (and their job function) in the organization will be on the framework somewhereProjects must be architected

Lessons Learned Through Enterprise Architecture

Because government is service oriented, column 4 is most important Column 1 – GIS, Banking, Finance Column 2 – Manufacturing Column 3 – Fed Ex Column 4 – Universities, Government Column 5 – Fire Dept., Police Column 6 - Everyone

Zachman’s 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.

Zachman’s Architectural Principles

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.

What is enterprise architecture?

A method for managing your business or enterprise:A decision making toolA change management toolThe knowledge base of your business or enterprise

“It is about the laws of nature that determine the success of an enterprise… particularly, continuing success in the turbulent times of the Information Age.”

John Zachman