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 can’t 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 don’t 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 – Owner’s Perspective • Detailed Representations (Technology Used) • Bottom Row “Functioning Enterprise” or the Systems • Electronic • Manual

14. System down = no work Out of pencils = no work “Functioning Enterprise” Row The systems are the enterprise!

15. Using the Zachman Framework

16. State Government A Department A Division A Bureau A Section A Unit IT Managers Lawyers HR Staff Web Developers A Union A Project What constitutes the “enterprise”? Any Natural boundary (or sameness)

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 aren’t…)

20. Enterprise Architecture Terms

21. Explicit vs. Implicit • A cell that hasn’t 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: 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

24. 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 Integration vs. Interfacing

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

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

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

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 weren’t 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 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 position • Technology change (row 5) should not interrupt the enterprise (because the models don’t 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. Zachman’s 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. Zachman’s 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