Enterprise Architecture A General Overview

1
Enterprise ArchitectureA General Overview

• Presented to
• Enterprise Solutions Council (ESC)
• August 19, 2004

2
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

3
Enterprise architecture is not
focused on Information Technology (IT is only a
part or subset of enterprise architecture)
4
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?

5
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

6
Thousands of years of history would suggest the
only known strategy for addressing complexity and
change is architecture.
7
If it gets so complex you cant remember how it
works, you have to write it down
Architecture
Complexity
Change
If you want to change how it works, you start
with what you have written down
8
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)
9
The Zachman Framework for Enterprise Architecture
10
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

11
Different Perspectives (Rows)

• Owner
• Designer
• Builder

12
Different Abstractions (Columns)

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

13
Other Rows Defined

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

14
Functioning Enterprise Row
The systems are the enterprise!

• System down no work

• Out of pencils no work

15
Using the Zachman Framework
16
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

17
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.
18
Implementation of the Framework
Enterprise Blueprints (Knowledgebase of
enterprise, implementations)
State of Montana Architecture Standards
Framework (our business rules, policies, best
practices, templates)
Zachman Framework (Case Tool)
19
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)

20
Enterprise Architecture Terms
21
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

22
Primitives vs. Composites

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

23
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

24
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

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

26
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

27
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?
28
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

29
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

30
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

31
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
32
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

33
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

34
Key enterprise architecture terms

• Explicit vs. Implicit
• Primitives vs. Composites
• Integration vs. Interfacing
• Alignment vs. Discontinuity
• Nature of Complexity

35
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)

36
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

37
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)

38
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

39
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

40
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)

41
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

42
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

43
Zachmans Architectural Principles

• Make sure you have alignment through the entire
  framework.
• Make sure all models are developed based on the
  same standards managed from an enterprise-wide
  perspective.
• Make sure all hardware and software is compatible
  based on standards for effective communication.

44
Zachmans Architectural Principles

• Make sure business rules are enforced
  consistently across the enterprise.
• Make sure systems are defined logically (row 3
  and 4 models), independent of technology (row 5)
  so technology can be easily changed.
• Make sure change is incorporated as a management
  criteria so any aspect of the enterprise can be
  maintained in a dynamic environment.

45
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