Download - ESC Enterprise Architecture Overview
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