Introduction

                                                                                Enterprise Architecture pres...
Origins of Ent. Arch.                                                                      "Enterprise"
Frederick Taylor "...
"Architecture"                                                          "Architecture"
                   Architecture ......
"Architecture"                                                                    "Architecture"

If the object you are tr...
"Architecture"




                                                                                                       ...
"Architecture"




                                                                                                       ...
"Architecture" In General


                                                                                              ...
"Enterprise Architecture"                                                         "Enterprise Architecture"
Therefore "Ent...
"Enterprise Architecture"


                                                                                              ...
Go to www.ZachmanInternational.com,

                                         Standards, print out a free color copy of
  ...
Architecture Is Architecture                                                     Architecture Is Architecture
I learned ab...
Ontology                                                                     Process
The Zachman Framework schema technica...
Ontology                                                                              Process
A Structure DEFINES somethin...
Chemistry - A Science                                                                             Process

A Process TRANS...
Ontology vs Process




                                                                                                  ...
Enterprise Design Objectives: Complexity and Change
Enterprise Design Objectives: Complexity and Change
Enterprise Design Objectives: Complexity and Change
Enterprise Design Objectives: Complexity and Change
Enterprise Design Objectives: Complexity and Change
Enterprise Design Objectives: Complexity and Change
Upcoming SlideShare
Loading in...5
×

Enterprise Design Objectives: Complexity and Change

1,088
-1

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,088
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
67
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Enterprise Design Objectives: Complexity and Change

  1. 1. Introduction Enterprise Architecture presently appears to be a grossly Enterprise Architecture misunderstood concept among management. It is NOT an Information Technology issue. It is an ENTERPRISE issue. Enterprise Design Objectives: Complexity and Change It is likely perceived to be an Information Technology issue as opposed to a Management issue for two reasons: A. Awareness of it tends to surface in the Enterprise through the Information Systems community. B. Information Technology people seem to have the skills to do Enterprise Architecture if any Enterprise Architecture is being or is to be done. John A. Zachman Zachman International 2222 Foothill Blvd. Suite 337 La Canada, Ca. 91011 818-244-3763 © 2008 John A. Zachman, Zachman International c 2005 John A. Zachman, Zachman International
  2. 2. Origins of Ent. Arch. "Enterprise" Frederick Taylor "Principles of Scientific Management" 1911 There are two implications to the word "Enterprise": Walter A. Shewhart "The Economic Control of Quality I. Scope of Manufactured Product" 1931 (Dr. Edward Demming's Mgr.) Peter Drucker "The Practice of Management" 1954 The broadest possible boundary of the Enterprise. The Enterprise in its entirety. Jay Forrester "Industrial Dynamics" 1961 Enterprise-wide in scope. The whole thing. Peter Senge "The Fifth Discipline" 1990 II. Content Eric Helfert "Techniques of Financial Analysis" 1962 ENTERPRISE Architecture is for ENTERPRISES. Robert Anthony "Planning and Control Systems: A Enterprise Architecture has nothing to do with the Framework for Analysis" 1965 Enterprise's systems or its information technology Sherman Blumenthal "Management Information Systems: (except as they may constitute Row 4 constraints). A Framework for Planning and Development" 1969 The end object is to engineer and manufacture the ENTERPRISE, NOT simply to build and run Alvin Toffler "Future Shock" 1970 systems. George Steiner "Comprehensive Managerial Planning" 1972 "ENTERPRISE" ACTUALLY MEANS "ENTERPRISE" Etc., etc., etc. c 2005 John A. Zachman, Zachman International c 2005 John A. Zachman, Zachman International
  3. 3. "Architecture" "Architecture" Architecture ... what is it? This is the RESULT of architecture. In the RESULT you can see the Architect's "architecture". Some people think this is Architecture: The RESULT is an implementation, an instance. That is a common "Architecture" IS the set of descriptive representations MISCONCEPTION relevant for describing a complex object (actually, any (Note: This same misconception about Enterprises is what object) such that an instance of the object can be created leads people to misconstrue Enterprise Architecture as and such that the descriptive representations serve as the baseline for changing an object instance (assuming that the being big, monolithic, static, inflexible and unachievable descriptive representations are maintained consistent with and ... it takes too long and costs too much.) Zachman International the instantiation). © 2007 John A. Zachman, © 2007 John A. Zachman, Zachman International
  4. 4. "Architecture" "Architecture" If the object you are trying to create is simple, you can see COMPLEXITY the whole thing all at one time, and it is not likely to change, (e.g. a log cabin, a program, etc.), then you don't need If you can't describe it, you can't create it Architecture. All you need is a tool (e.g. an ax, a compiler, (whatever "it" is). etc.), some raw material (e.g. a forest, some data, etc.) and some time (then, build log cabins, write programs, etc.). On the other hand, if the object is complex, you can't see it CHANGE in its entirety at one time and it is likely to change consid- erably over time (e.g. a hundred story building, an If you don't retain the descriptive representations after Enterprise, etc.), now you need Architecture. you create them (or if you never created them in the first place) and you need to change the resultant implementa- In short, the reasons you need Architecture: tion, you have only three options: COMPLEXITY AND CHANGE A. Change the instance and see what happens. (High risk!) B. Recreate ("reverse engineer") the architectural representations from the existing ("as is") implementation. (Takes time and costs money!) C. Scrap the whole thing and start over again. © 2007 John A. Zachman, Zachman International © 2007 John A. Zachman, Zachman International
  5. 5. "Architecture" TECH- OPERATIONS COMPONENT SYSTEM BUSINESS SCOPE PERSPECTIVES AUDIENCE PERSPECTIVE INTERROGATIVE NOLOGY There is not a single descriptive representation for a com- plex object ... there is a SET of descriptive representations. INVENTORY WHAT Descriptive representations (of anything) Bills of Material typically include "Abstractions": PROCESS HOW Functional Specs Abstractions A. Bills of Material (What) B. Functional Specs (How) NETWORK WHERE C. Drawings (Where) Drawings D. Operating Instructions (Who) ORGANIZATION E. Timing Diagrams (When) F. Design Objectives (Why) Operating Instructions © 2007 WHO TIMING John A. Zachman, Zachman International as well as Perspectives: Timing Diagrams WHEN MOTIVATION 1. Scoping Boundaries (Strategists) 2. Requirement Concepts (Owners) Design Objectives WHY 3. Design Logic (Designers) STRATEGISTS TECHNICIANS 4. Plan Physics (Builders) CONTRIBUTORS ARCHITECTS ENGINEERS EXECUTIVE WORKERS LEADERS DOMAINS TARGET TARGET 5. Part Configurations (Implementers) and the 6. Product Instances (Operators) © 2007 John A. Zachman, Zachman International
  6. 6. "Architecture" PERSPECTIVE INTERROGATIVE TECH- OPERATIONS COMPONENT SYSTEM BUSINESS SCOPE PERSPECTIVES AUDIENCE NOLOGY There is not a single descriptive representation for a com- INVENTORY plex object ... there is a SET of descriptive representations. WHAT Descriptive representations (of anything) PROCESS Requirements (Concepts) Requirements (Concepts) typically include "Abstractions": HOW Part (Configurations) Part (Configurations) Perspectives Scope (Boundaries) Scope (Boundaries) Product (Instances) Design (Logic) Design (Logic) Plan (Physics) Plan (Physics) NETWORK A. Bills of Material (What) WHERE B. Functional Specs (How) ORGANIZATION C. Drawings (Where) D. Operating Instructions (Who) WHO E. Timing Diagrams (When) © 2007 F. Design Objectives (Why) TIMING WHEN John A. Zachman, Zachman International as well as Perspectives: MOTIVATION 1. Scope Boundaries (Strategists) WHY 2. Requirement Concepts (Owners) STRATEGISTS TECHNICIANS CONTRIBUTORS ARCHITECTS ENGINEERS EXECUTIVE WORKERS 3. Design Logic (Designers) LEADERS DOMAINS TARGET TARGET 4. Plan Physics (Builders) 5. Part Configurations (Implementers) and the 6. Product Instances (Operators) © 2007 John A. Zachman, Zachman International
  7. 7. "Architecture" In General TECH- OPERATIONS COMPONENT SYSTEM BUSINESS SCOPE PERSPECTIVES AUDIENCE PERSPECTIVE INTERROGATIVE "Architecture" (for anything) would be the total set of NOLOGY descriptive representations (models) relevant for describing a complex object such that it can be created and that INVENTORY WHAT constitute a baseline for changing the object after it has been instantiated. The relevant descriptive representations would necessarily have to include all the intersections PROCESS HOW between: the "Abstractions": Representation Representation Reification Identification Configuration Configuration Specification Specification Instantiation NETWORK A. Bills of Material (What) Definition Definition Where B. Functional Specs (How) C. Drawings (Where) ORGANIZATION WHO D. Operating Instructions (Who) E. Timing Diagrams (When) c 2007 John A. Zachman, Zachman International F. Design Objectives (Why) TIMING WHEN and the Perspectives: 1. Scoping Boundaries (Strategists) MOTIVATION 2. Requirement Concepts (Owners) WHY 3. Design Logic (Designers) 4. Plan Physics (Builders) TECHNICIANS STRATEGISTS CONTRIBUTORS ARCHITECTS ENGINEERS EXECUTIVE WORKERS LEADERS 5. Part Configurations (Implementers) DOMAINS TARGET TARGET resulting in the 6. Product Instances (Operators) © 2007 John A. Zachman, Zachman International
  8. 8. "Enterprise Architecture" "Enterprise Architecture" Therefore "Enterprise Architecture" would be the total The total set would necessarily have to include set of descriptive representations (models) relevant for Abstractions: WHAT describing an Enterprise, that is, the descriptive Inventory Models equal Bills of Materials representations required to create (a coherent, optimal) (Entity Models Enterprise and required to serve as a baseline for changing and Data Models ARE Bills of Material) the Enterprise once it is created. The total set of relevant HOW descriptive representations would necessarily have to include all the intersections between the Process Models equal Functional Specs Abstractions: (Transformation Models) A. Inventory Models (Bills of Material) WHERE Network Models equal Drawings B. Process Models (Functional Specs) (Geographic Models) (Geometry) C. Geographic Models (Drawings) (Distribution Models) D. Work Flow Models (Operating Instructions) WHO E. Cyclical Models (Timing Diagrams) Organization Models equal Operating Instructions F. Objective Models (Design Objectives) (Work Flow Models) and the Perspectives: (Presentation Architecture) 1. Scope Boundaries (Scoping Boundaries) WHEN 2. Business Models (Requirement Concepts) Timing Models equal Timing Diagrams 3. System Models (Design Logic) (Control Structures) 4. Technology Models (Plan Physics) (Cyclical Models) 5. Tooling Configurations (Part Configurations) (Dynamics Models) resulting in the WHY 6. The Enterprise Implementation (Product Instance) Motivation Models equal Design Objectives © 2007 John A. Zachman, Zachman International © 2007 John A. Zachman, Zachman International
  9. 9. "Enterprise Architecture" TECH- OPERATIONS COMPONENT SYSTEM BUSINESS SCOPE PERSPECTIVES AUDIENCE PERSPECTIVE INTERROGATIVE NOLOGY The total set would necessarily have to include Perspectives: STRATEGISTS INVENTORY Scope Boundaries equal Scope Boundaries WHAT Inventory Models equal Bills of Material ("CONOPS" or Concepts Package) PROCESS HOW EXECUTIVE LEADERS Process Models equal Functional Specs Abstractions Business Models equal Requirement Concepts (Concepts Models) (Customer's Usage) NETWORK WHERE Network Models equals Drawings ("Computation Independent") ARCHITECTS ORGANIZATION System Models equal Design Logic Organization Models equal Operating Instructions WHO (Logic Models) (Engineering Descriptions) © 2007 ("Platform Independent") ENGINEERS TIMING John A. Zachman, Zachman International Timing Models equal Timing Diagrams Technology Models equal Plan Physics WHEN (Physics Models) (Mfg. Eng. Descriptions) MOTIVATION ("Platform Specific") Motivation Models equal Design Objectives TECHNICIANS WHY Tooling Configurations equal Part Configurations STRATEGISTS TECHNICIANS (Vendor Product Specific) (Machine Tool Specific) CONTRIBUTORS ARCHITECTS ENGINEERS EXECUTIVE WORKERS LEADERS DOMAINS TARGET WORKERS TARGET Enterprise Implementation equals Product Instance (Operations Instances) © 2007 John A. Zachman, Zachman International
  10. 10. Go to www.ZachmanInternational.com, Standards, print out a free color copy of register for the Zachman Framework the Zachman Framework graphic. Perspectives INTERROGATIVE TARGET PERSPECTIVE WHAT HOW WHERE WHO WHEN WHY CONTRIBUTORS SCOPE Scope Boundaries equals Scope Boundaries Scope Boundaries equals Scope Boundaries STRATEGISTS EXECUTIVE BUSINESS Business Models equal Requirement Concepts LEADERS SYSTEM Systems Models equal Design Logic Systems Models equal Design Logic ARCHITECTS TECH- ENGINEERS NOLOGY Technology Models equal Plan Physics Technology Models equal Plan Physics COMPONENT TECHNICIANS Tooling Configurations equal Part Configurations Tooling Configurations equal Part Configurations Enterprise Implementation equals Product Instances OPERATIONS Enterprise Implementation equals Product InstancesWORKERS TARGET AUDIENCE INVENTORY PROCESS NETWORK ORGANIZATION TIMING MOTIVATION DOMAINS PERSPECTIVES c 2005 John A. Zachman, Zachman International
  11. 11. Architecture Is Architecture Architecture Is Architecture I learned about architecture for Enterprises by looking at I simply put Enterprise names on the same descriptive architecture for: representations relevant for describing anything. Airplanes, Buildings, Locomotives, Computers, ... Complex Industrial Products Why would anyone think that the descriptions of an Enterprise It is all the same ... Bills of Material, Functional Specs, Drawings, ... etc. are going to be any different Requirements, Schematics, Blueprints, ... etc. from the descriptions of anything else humanity has ever described? ENTERPRISES have: Bills of Material, Functional Specs, Drawings, ... etc. ARCHITECTURE ENTERPRISES have: IS ARCHITECTURE Requirements, Schematics, Blueprints, ... etc. IS ARCHITECTURE The Engineering Design Artifacts (the descriptive I don't think Enterprise Architecture is arbitrary ... representations of anything) fall into a two dimensional and it is not negotiable. classification system: My opinion is, we ought to accept the definitions of A. The focus of the description (Abstraction) Architecture that the older disciplines of Architecture (What, How, Where, Who, When, Why) and Construction, Engineering and Manufacturing have B. The usage of the description (Perspective) established and focus our energy on learning how to use (Owner, Designer, Builder) them to actually engineer Enterprises. © 2007 John A. Zachman, Zachman International © 2007 John A. Zachman, Zachman International
  12. 12. Ontology Process The Zachman Framework schema technically is an ontology - a theory of the existence of a structured set A Process TRANSFORMS something. of essential components of an object for which explicit expression is necessary (is mandatory?) for designing, This is a Process: operating and changing the object (the object being an Enterprise, a department, a value chain, a "sliver," a solution, a project, an airplane, a building, a bathtub or Add Bleach to an Alkali and whatever or whatever). it is transformed into Saltwater. The Zachman Framework is NOT a methodology for creating the implementation (an instantiation) of the object (i.e. the Framework is an ontology, not a methodology). A Framework is a STRUCTURE. (A Structure DEFINES something.) An Ontology is a theory of existance - what IS An Ontology IS a Structure. A Methodology is a PROCESS. (A Process TRANSFORMS something.) A Structure IS NOT A Process A Process IS NOT©a2008 John A. Zachman, Zachman International Structure. © 2009 John A. Zachman, Zachman International
  13. 13. Ontology Process A Structure DEFINES something. A Process TRANSFORMS something. This is a Structure: This is a PROCESS: Standard periodic table G roup ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 Hydrochloric Sodium Sodium Water ? P eriod 1 2 Acid Hydroxide Chloride 1 H He (salt) 2 3 4 L i Be 11 12 5 B 13 6 C 14 7 N 15 8 O 16 9 F 17 10 Ne 18 HCl + NaOH --> NaCl + H2O 3 Na Mg Al Si P S Cl Ar Hydrogen Sodium Sodium 2 Hydrogens 4 19 20 21 2 2 23 24 25 26 27 28 29 30 31 3 2 33 34 35 36 Chlorine Oxygen Chlorine Oxygen K Ca Sc Ti V C r Mn Fe Co Ni Cu Zn Ga Ge As Se Br Kr Hydrogen 37 38 39 4 0 41 42 43 44 45 46 47 48 49 50 51 52 53 54 5 Rb S r Y Zr Nb Mo Tc Ru Rh P d A g Cd In Sn Sb Te I Xe 55 56 * 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 6 Cs Ba Hf Ta W Re O s Ir Pt Au Hg Tl Pb Bi Po At Rn 87 88 * * 10 4 10 5 106 107 108 109 110 111 112 1 13 1 14 11 5 116 117 118 7 Fr Ra Rf Db Sg Bh Hs Mt Ds Rg Uub Uut U uq Uu p Uuh Uu s Uuo 5 7 58 59 60 61 62 63 64 65 66 67 68 69 70 71 * Lanthanide s L a Ce Pr Nd Pm Sm E u Gd Tb Dy Ho Er Tm Y b Lu 89 90 91 92 93 94 95 96 97 98 9 9 10 0 101 102 103 * * Actinide s Ac Th Pa U Np P u Am Cm B k Cf E s Fm Md No Lr This is a Structure, an ontological structure ... a fixed, structured set of elemental components that exist of which any and every compound must be composed. The Periodic Table provides precise DEFINITION. © 2009 John A. Zachman, Zachman International © 2009 John A. Zachman, Zachman International
  14. 14. Chemistry - A Science Process A Process TRANSFORMS something. (Compounds are A Process TRANSFORMS something. virtually infinite) This is a PROCESS: These are This is a Process: Sodium compounds Hydrochloric Sodium Chloride Acid Hydroxide (salt) Water Add Bleach to an Alkali and HCl + NaOH --> NaCl + H2O it is transformed into Saltwater. Hydrogen Sodium Sodium 2 Hydrogens Chlorine Oxygen Chlorine Oxygen Hydrogen These are elements (Elements come from the Ontology - finite) A Process with no ontological structure is ad hoc, fixed and dependent on practitioner skills. This is NOT a science. It is ALCHEMY. A Process based on an ONTOLOGICAL structure will be repeatable and predictable - A SCIENCE. © 2009 John A. Zachman, Zachman International © 2009 John A. Zachman, Zachman International
  15. 15. Ontology vs Process Certification Chemistry Certified Chemist Standard periodic table The Science Group ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 ? Period 1 2 1 H He 3 4 5 6 7 8 9 10 2 Standard periodic table Li Be B C N O F Ne 11 12 13 14 15 16 17 18 G ro up ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 3 Na Mg Al Si P S Cl Ar ? P erio d 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 4 1 2 K Ca Sc Ti V Cr Mn Fe Co Ni Cu Zn Ga Ge As Se Br Kr 1 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 H He 5 Rb Sr Y Zr Nb Mo Tc Ru Rh Pd Ag Cd In Sn Sb Te I Xe 3 4 5 6 7 8 9 10 55 56 * 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 2 6 L i Be B C N O F Ne Cs Ba Hf Ta W Re Os Ir Pt Au Hg Tl Pb Bi Po At Rn 11 12 13 14 15 16 17 18 87 88 ** 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 3 7 Fr Ra Rf Db Sg Bh Hs Mt Ds Rg Uub Uut U uq Uup Uuh Uus Uuo Na Mg Al Si P S Cl Ar 19 20 21 2 2 23 24 25 26 27 28 29 30 31 3 2 33 34 35 36 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 4 * Lanthanides K Ca Sc Ti V C r Mn Fe Co Ni Cu Zn Ga Ge As Se Br Kr La Ce Pr Nd Pm Sm Eu Gd Tb Dy Ho Er Tm Yb Lu 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 37 38 39 4 0 41 42 43 44 45 46 47 48 49 50 51 52 53 54 ** Actinides 5 Ac Th Pa U Np Pu Am Cm Bk Cf Es Fm Md No Lr Note: The question is, Rb S r Y Zr Nb Mo T c Ru Rh P d A g Cd In Sn Sb Te I Xe scientifically defined? An Ontology 6 55 56 * 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 was the Practice Cs Ba Hf Ta W Re O s Ir Pt Au Hg Tl Pb Bi Po At Rn 87 88 * * 10 4 10 5 106 107 108 109 110 111 112 1 13 1 14 11 5 116 117 118 7 Fr Ra Rf Db Sg Bh Hs Mt Ds Rg Uub Uut U uq Uu p Uuh Uu s Uuo 5 7 58 59 60 61 62 63 64 65 66 67 68 69 70 71 * L an than id e s L a Ce Pr Nd Pm Sm E u Gd Tb Dy Ho Er Tm Y b Lu 89 90 91 92 93 94 95 96 97 98 9 9 10 0 101 102 103 * * Actin id e s Ac Th Pa U Np P u Am Cm B k Cf E s Fm Md No Lr Chemical Manufacturing IS NOT LiOH + H2SO4 --> 3Cu(OH)2 + 2H3PO4 --> HCl + NaOH --> NaCl + H2O 3Ca(OH)2 + 2H3PO4 --> Certified Copper Phosphate Certified Lithium Sulfate Certified Salt Manufacturer Certified Calcium Phosphate Certification Etc., etc., etc. The Practice c 2009 John A. Zachman, Zachman International 6H2O + Cu2(PO4)2 Ca3(PO4)2 + 6H2O Hydrochloric Sodium Sodium Water Li2SO4 + 2H2O Acid Hydroxide Chloride (salt) HCl + NaOH --> NaCl + H2O A Process Manufacturer Manufacturer Hydrogen Sodium Sodium 2 Hydrogens Manufacturer Chlorine Oxygen Chlorine Oxygen Hydrogen and a Process IS NOT an Ontology. © 2009 John A. Zachman, Zachman International © 2009 John A. Zachman, Zachman International
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×