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
