Enterprise Architecture A General Overview

What is enterprise architecture?

A method for managing your business or enterprise: A decision making tool A change management tool The 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.

If it gets so complex you cant remember how it works, you have to write it down

Architecture
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 dont 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 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

Different Perspectives (Rows)

Owner Designer Builder

Different Abstractions (Columns)

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

Other Rows Defined

Scope (Planner) Row Owners Perspective Detailed Representations (Technology Used) Bottom Row Functioning Enterprise or the Systems

Electronic Manual

Functioning Enterprise Row

The systems are the enterprise!

System down = no work Out of pencils = no work

Using the Zachman Framework

What constitutes the enterprise?

Any Natural boundary (or sameness)
State Government A Department A Division A Bureau A Section A Unit IT Managers Lawyers HR Staff Web Developers A Union A Project

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

Enterprise Blueprints

(Knowledgebase State of Montana of enterprise, Architecture implementations) Standards Framework

(our business rules, policies, best practices, templates)

Zachman Framework (Case Tool)

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 (and if they arent)

Enterprise Architecture Terms

Explicit vs. Implicit

A cell that hasnt been modeled (made explicit) is implicit by definition Assumptions have to be made when involving implicit cells Assumptions generally have large margins for error

Primitives vs. Composites

Data elements primitives versus composites Primitive models are architecture Composite models are implementations

Integration vs. Interfacing

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

Integration: Reuse, not re-create If you really want integration and not just interfacing, the products (systems) have to be engineered that way Interfacing: Inhibits change Increases costs Interfacing is a short term strategy, not a long term solution

Alignment
Key element in enterprise architecture Means 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 models Next, build row 2 models Next, build row 3 models Next, build row 4 models Next, build row 5 models Ensuring that the intent of each row is successfully represented (transformed) in the succeeding row

Perfectly Aligned Functioning 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 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 first Transform the change through the rest of the framework Net impact of the change will be your gap analysis Nothing 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 management Any time you have duplication, you have discontinuity Reduce discontinuity by reducing redundant systems and redundant data

Discontinuity
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

Nature of Complexity
There is a certain amount of complexity built into any enterprise, product or service Three 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 dont 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 sight The detail and complexity doesnt go away just because you dont 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. Implicit Primitives vs. Composites Integration vs. Interfacing Alignment vs. Discontinuity Nature 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 enterprise Most systems are becoming automated systems IT is responsible for IT 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 werent 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 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 Through Enterprise Architecture

You cant integrate systems (optimally) if you dont 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 position Technology change (row 5) should not interrupt the enterprise (because the models dont 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 somewhere Projects must be architected

Lessons Learned Through Enterprise Architecture

Because government is service oriented, column 4 is most important

Column Column Column Column Column Column

1 2 3 4 5 6

GIS, Banking, Finance Manufacturing Fed Ex Universities, Government Fire Dept., Police - Everyone

Zachmans 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.

Zachmans 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 tool A change management tool The 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