AE Rio 2011 - Apresentação de John Zachman
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

AE Rio 2011 - Apresentação de John Zachman

on

  • 1,515 views

A apresentação fala de Arquitetura Empresarial.

A apresentação fala de Arquitetura Empresarial.

Statistics

Views

Total Views
1,515
Views on SlideShare
1,080
Embed Views
435

Actions

Likes
0
Downloads
74
Comments
0

2 Embeds 435

http://www.congresso-ae.com.br 431
http://congresso-ae.com.br 4

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

AE Rio 2011 - Apresentação de John Zachman Presentation Transcript

  • 1. Preface This seminar is NOT about increasing the stock Enterprise Architecture price by the close of market, Friday afternoon. It IS about the laws of nature that determine the Managing Enterprise success of an Enterprise ... particularly, continuing success in the turbulent times of the Information Age. Complexity and Change It is a presentation on Physics ... Enterprise Physics.John A. ZachmanZachman International2222 Foothill Blvd. Suite 337La Canada, Ca. 91011www.Zachman.com © 1990-2006 John A. Zachman, Zachman International © 2010 John A. Zachman, Zachman International
  • 2. Introduction Origins of Ent. Arch. Frederick Taylor "Principles of Scientific Management" 1911Enterprise Architecture presently appears to be a grosslymisunderstood concept among management. Walter A. Shewhart "The Economic Control of Quality of Manufactured Product" 1931 (Dr. Edward Demmings Mgr.) It is NOT an Information Technology issue. It is an ENTERPRISE issue. Peter Drucker "The Practice of Management" 1954 Jay Forrester "Industrial Dynamics" 1961It is likely perceived to be an Information Technology Peter Senge "The Fifth Discipline" 1990issue as opposed to a Management issue for two reasons: Eric Helfert "Techniques of Financial Analysis" 1962A. Awareness of it tends to surface in the Enterprise through the Information Systems community. Robert Anthony "Planning and Control Systems: A Framework for Analysis" 1965B. Information Technology people seem to have the skills to do Enterprise Architecture if any Enterprise Sherman Blumenthal "Management Information Systems: Architecture is being or is to be done. A Framework for Planning and Development" 1969 Alvin Toffler "Future Shock" 1970 George Steiner "Comprehensive Managerial Planning" 1972 Etc., etc., etc. c 2005 John A. Zachman, Zachman International c 2005 John A. Zachman, Zachman International
  • 3. "Enterprise" The Information AgeThere are two implications to the word "Enterprise": "The next information revolution is well underway. But it is not happening where information scientists, informa- I. Scope tion executives, and the information industry in general are looking for it. It is not a revolution in technology, The broadest possible boundary of the Enterprise. machinery, techniques, software, or speed. It is a The Enterprise in its entirety. revolution in CONCEPTS." Enterprise-wide in scope. Peter Drucker. Forbes ASAP, August 24, 1998 The whole thing. "Future Shock" (1970) - The rate of change. II. Content "The Third Wave" (1980) - The structure of change. "Powershift" (1990) - The culture of change. ENTERPRISE Architecture is for ENTERPRISES. Alvin Toffler Enterprise Architecture has nothing to do with the Enterprises systems or its information technology "We are living in an extraordinary moment in history. (except as they may constitute Row 4 constraints). Historians will look back on our times, the 40-year time The end object is to engineer and manufacture span between 1980 and 2020, and classify it among the the ENTERPRISE, NOT simply to build and run handful of historic moments when humans reorganized systems. their entire civilization around a new tool, a new idea." Peter Leyden. Minneapolis Star Tribune. June 4, 1995"ENTERPRISE" ACTUALLY MEANS "ENTERPRISE" "On the Edge of the Digital Age: The Historic Moment" c 2005 John A. Zachman, Zachman International © 1990-2006 John A. Zachman, Zachman International
  • 4. Strategy Pattern Agenda (2 Day) Short term, Expense-based Strategy Day 1 Custom Products (Make-to-Order) I. Global Environment1. If IT is in the business of building and running systems II. Introduction to Enterprise Architectureand the objective is to build systems faster and cheaper, then III. Ontology versus Methodologybreak them down into smaller pieces and start writing the IV. Enterprise Knowledgebasecode. Result is more of the same ... legacy. (NOT Day 2integrated, NOT flexible, NOT aligned, NOT reusable,NOT interoperable, etc., etc. ... BUT, running.) V. Architecture Work/End State Vision Modified Short Term Strategy VI. Why Primitive Models Standard Products (Provide-from-Stock) VII. Enterprise Eng. Design Objectives2. If the IT strategy is to buy rather than build ... then VIII. "Federated Architecture"implement "as is"... change the Enterprise to fit the package. IX. Legacy MigrationBuild and maintain "interfaces" with any replicated X. Building Row 1 Matricesconcepts in the existing legacy or in future system XI. Value Propositions (Old and New)implementations. XII. Cheaper and Faster Long Term, Asset-based Strategy XIII. Methodology Considerations Custom, Standard Products (Assemble-to-Order) XIV. Conclusions3. If IT is in the business of engineering and manufactur-ing Enterprises, then start building an inventory of Enter- Appendixprise Architecture assets, engineering them to be reused in XV. 12 Step Programany implementation ... the "asset paradigm" ... that is, XVI. Intro to Sample Models"Mass-Customization" of the Enterprise ... ("custom XVII. Meta FrameworksEnterprises, mass-produced in quantities of one for XVIII. Zachman Propositionsimmediate delivery" ... at the click of a mouse.) © 2011 John A. Zachman, Zachman International © 2010 John A. Zachman, Zachman International
  • 5. "Architecture" Architecture ... what is it?Introduction to Enterprise Architecture Some people think this is Architecture: The Framework for Enterprise Architecture That is a common MISCONCEPTION (Note: This same misconception about Enterprises is what leads people to misconstrue Enterprise Architecture as being big, monolithic, static, inflexible and unachievable © 1990-2006 John A. Zachman, Zachman International and ... it takes too long and costs too much.) © 2007 John A. Zachman, Zachman International
  • 6. "Architecture" "Architecture" This is the RESULT of architecture. If the object you are trying to create is simple, you can seeIn the RESULT you can see the Architects "architecture". the whole thing all at one time, and it is not likely to The RESULT is an implementation, an instance. change, (e.g. a log cabin, a program, etc.), then you dont need Architecture. All you need is a tool (e.g. an ax, a compiler, 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 cant see it in its entirety at one time and it is likely to change consid- erably over time (e.g. a hundred story building, an Enterprise, etc.), now you need Architecture. In short, the reasons you need Architecture: COMPLEXITY AND CHANGE"Architecture" IS the set of descriptive representationsrelevant for describing a complex object (actually, anyobject) such that an instance of the object can be createdand such that the descriptive representations serve as thebaseline for changing an object instance (assuming that thedescriptive representations are maintained consistent withthe instantiation). © 2007 John A. Zachman, Zachman International © 2007 John A. Zachman, Zachman International
  • 7. "Architecture" "Architecture" There is not a single descriptive representation for a com- COMPLEXITY plex object ... there is a SET of descriptive representations. If you cant describe it, you cant create it Descriptive representations (of anything) (whatever "it" is). typically include "Abstractions": A. Bills of Material (What) CHANGE B. Functional Specs (How) C. Drawings (Where)If you dont retain the descriptive representations after D. Operating Instructions (Who)you create them (or if you never created them in the first E. Timing Diagrams (When)place) and you need to change the resultant implementa- F. Design Objectives (Why)tion, you have only three options: as well as Perspectives: A. Change the instance and see what happens. (High risk!) 1. Scoping Boundaries (Strategists) B. Recreate ("reverse engineer") the architectural 2. Requirement Concepts (Owners) representations from the existing ("as is") 3. Design Logic (Designers) implementation. (Takes time and costs money!) 4. Plan Physics (Builders) C. Scrap the whole thing and start over again. 5. Part Configurations (Implementers) and the 6. Product Instances (Operators) © 2007 John A. Zachman, Zachman International © 2007 John A. Zachman, Zachman International
  • 8. "Architecture" There is not a single descriptive representation for a com- TECH- PERSPECTIVE INTERROGATIVE OPERATIONS COMPONENT SYSTEM BUSINESS SCOPE PERSPECTIVES AUDIENCE NOLOGY plex object ... there is a SET of descriptive representations. WHAT INVENTORY Bills of Material Descriptive representations (of anything) typically include "Abstractions": PROCESS HOW Functional Specs A. Bills of Material (What) B. Functional Specs (How) Abstractions WHERE NETWORK C. Drawings (Where) Drawings D. Operating Instructions (Who) E. Timing Diagrams (When) ORGANIZATION© 1990-2007 John A. Zachman, Zachman International F. Design Objectives (Why) WHO Operating Instructions as well as Perspectives: TIMING WHEN Timing Diagrams 1. Scope Boundaries (Strategists) MOTIVATION Design Objectives 2. Requirement Concepts (Owners) WHY 3. Design Logic (Designers) 4. Plan Physics (Builders) CONTRIBUTORS STRATEGISTS TECHNICIANS ARCHITECTS ENGINEERS WORKERS EXECUTIVE DOMAINS TARGET LEADERS TARGET 5. Part Configurations (Implementers) and the 6. Product Instances (Operators) © 2007 John A. Zachman, Zachman International
  • 9. Reification INTERROGATIVE WHEN TARGET PERSPECTIVE WHAT HOW WHERE WHO WHY CONTRIBUTORS SCOPE Identification Identification STRATEGISTS BUSINESS Definition Definition EXECUTIVE LEADERS SYSTEM Representation ARCHITECTS TECH- NOLOGY Specification Specification ENGINEERS COMPONENT Configuration Configuration TECHNICIANS OPERATIONS Instantiation Instantiation WORKERS MOTIVATION TARGET AUDIENCE INVENTORY PROCESS NETWORK ORGANIZATION TIMING DOMAINS PERSPECTIVES © 1990-2007 John A. Zachman, Zachman International PerspectivesINTERROGATIVE TARGETPERSPECTIVE WHAT HOW WHERE WHO WHEN WHY CONTRIBUTORS STRATEGISTS SCOPE Scope (Boundaries) Scope (Boundaries) EXECUTIVE BUSINESS Requirements (Concepts) Requirements (Concepts) LEADERS ARCHITECTS SYSTEM Design (Logic) Design (Logic) ENGINEERS TECH- NOLOGY Plan (Physics) COMPONENT TECHNICIANS Part (Configurations) WORKERS OPERATIONS Product (Instances) Product (Instances)AUDIENCE TARGET INVENTORY PROCESS NETWORK ORGANIZATION TIMING MOTIVATION DOMAINSPERSPECTIVES © 1990-2007 John A. Zachman, Zachman International
  • 10. "Architecture" In General "Enterprise Architecture""Architecture" (for anything) would be the total set of Therefore "Enterprise Architecture" would be the totaldescriptive representations (models) relevant for describing set of descriptive representations (models) relevant fora complex object such that it can be created and that describing an Enterprise, that is, the descriptiveconstitute a baseline for changing the object after it has representations required to create (a coherent, optimal)been instantiated. The relevant descriptive representations Enterprise and required to serve as a baseline for changingwould necessarily have to include all the intersections the Enterprise once it is created. The total set of relevantbetween: descriptive representations would necessarily have to the "Abstractions": include all the intersections between the A. Bills of Material (What) Abstractions: B. Functional Specs (How) A. Inventory Models (Bills of Material) C. Drawings (Where) B. Process Models (Functional Specs) D. Operating Instructions (Who) C. Geographic Models (Drawings) E. Timing Diagrams (When) D. Work Flow Models (Operating Instructions) F. Design Objectives (Why) E. Cyclical Models (Timing Diagrams) and the Perspectives: F. Objective Models (Design Objectives) 1. Scoping Boundaries (Identification) and the Perspectives: 2. Requirement Concepts (Definition) 1. Scope Boundaries (Scoping Boundaries) 3. Design Logic (Representation) 2. Business Models (Requirement Concepts) 4. Plan Physics (Specification) 3. System Models (Design Logic) 5. Part Configurations (Configuration) 4. Technology Models (Plan Physics) resulting in the 5. Tooling Configurations (Part Configurations) 6. Product Instances (Instantiation) resulting in the 6. The Enterprise Implementation (Product Instance) © 2007 John A. Zachman, Zachman International © 2007 John A. Zachman, Zachman International
  • 11. "Enterprise Architecture" TECH- OPERATIONS COMPONENT SYSTEM BUSINESS SCOPE PERSPECTIVES AUDIENCE PERSPECTIVE INTERROGATIVEThe total set would necessarily have to include NOLOGYAbstractions: WHAT Inventory Models equal Bills of Materials INVENTORY WHAT (Entity Models Inventory Models equal Bills of Material and Data Models ARE Bills of Material) HOW PROCESS Process Models equal Functional Specs HOW Process Models equal Functional Specs Abstractions (Transformation Models) NETWORK WHERE WHERE Network Models equals Drawings Network Models equal Drawings (Geographic Models) (Geometry) ORGANIZATION © 1990-2007 John A. Zachman, Zachman International (Distribution Models) Organization Models equal Operating Instructions WHO WHO Organization Models equal Operating Instructions TIMING (Work Flow Models) Timing Models equal Timing Diagrams WHEN (Presentation Architecture) WHEN MOTIVATION Timing Models equal Timing Diagrams Motivation Models equal Design Objectives WHY (Control Structures) (Cyclical Models) STRATEGISTS CONTRIBUTORS TECHNICIANS ARCHITECTS ENGINEERS WORKERS EXECUTIVE (Dynamics Models) LEADERS DOMAINS TARGET TARGET WHY Motivation Models equal Design Objectives © 2007 John A. Zachman, Zachman International
  • 12. Perspectives INTERROGATIVE TARGET PERSPECTIVE WHAT HOW WHERE WHO WHEN WHY CONTRIBUTORS SCOPE Scope Boundaries equals Scope Boundaries Scope Boundaries equals Scope Boundaries STRATEGISTS BUSINESS Business Models equal Requirement Concepts Business Models equal Requirement Concepts EXECUTIVE LEADERS SYSTEM Systems Models equal Design Logic Systems Models equal Design Logic ARCHITECTS TECH- NOLOGY Technology Models equal Plan Physics ENGINEERS COMPONENT Tooling Configurations equal Part Configurations TECHNICIANS OPERATIONS Enterprise Implementation equals Product Instances Enterprise Implementation equals Product Instances WORKERS AUDIENCE TARGET PERSPECTIVES INVENTORY PROCESS NETWORK ORGANIZATION TIMING MOTIVATION DOMAINS © 1990-2007 John A. Zachman, Zachman International © 2007 John A. Zachman, Zachman International (Machine Tool Specific) Enterprise Implementation equals Product Instance Tooling Configurations equal Part Configurations (Mfg. Eng. Descriptions)"Enterprise Architecture" (Customers Usage) Business Models equal Requirement Concepts (Logic Models) (Engineering Descriptions) Scope Boundaries equal Scope Boundaries Technology Models equal Plan Physics Concepts Package) The total set would necessarily have to include System Models equal Design Logic ("CONOPS" or EXECUTIVE LEADERS STRATEGISTS ARCHITECTS TECHNICIANS ENGINEERS WORKERS ("Computation Independent") (Vendor Product Specific) ("Platform Independent") (Operations Instances) ("Platform Specific") (Concepts Models) (Physics Models) Perspectives:
  • 13. © 2007 John A. Zachman, Zachman International Bills of Material, Functional Specs, Drawings, ... etc. Bills of Material, Functional Specs, Drawings, ... etc. I learned about architecture for Enterprises by looking at representations of anything) fall into a two dimensionalArchitecture Is Architecture Airplanes, Buildings, Locomotives, Computers, The Engineering Design Artifacts (the descriptive (What, How, Where, Who, When, Why) Requirements, Schematics, Blueprints, ... etc. Requirements, Schematics, Blueprints, ... etc. B. The usage of the description (Perspective) A. The focus of the description (Abstraction) ... Complex Industrial Products (Owner, Designer, Builder) ENTERPRISES have: ENTERPRISES have: classification system: It is all the same ... architecture for: © 2010 John A. Zachman, Zachman International ENTERPRISE ARCHITECTURE INTERROGATIVE PERSPECTIVES TARGET CONTRIBUTORS ZACHMAN ENTERPRISE FRAMEWORK WHY WHO WHEN TM STRATEGISTS WHAT HOW WHERE INVENTORY IDENTIFICATION PROCESS IDENTIFICATION NETWORK IDENTIFICATION ORGANIZATION IDENTIFICATION TIMING IDENTIFICATION MOTIVATION IDENTIFICATION LIST LIST LIST LIST LIST LIST SCOPE EXECUTIVE INVENTORY TYPES PROCESS TYPES NETWORK TYPES ORGANIZATION TYPES TIMING TYPES LEADERS MOTIVATION TYPES INVENTORY DEFINITION PROCESS DEFINITION NETWORK DEFINITION ORGANIZATION DEFINITION TIMING DEFINITION MOTIVATION DEFINITION e.g.. e.g.. e.g.. e.g.. e.g.. BUSINESS e.g.. ARCHITECTS BUSINESS ENTITY BUSINESS TRANSFORM BUSINESS LOCATION BUSINESS ROLE BUSINESS CYCLE BUSINESS END BUSINESS RELATIONSHIP BUSINESS INPUT BUSINESS CONNECTION BUSINESS WORK BUSINESS MOMENT BUSINESS MEANS INVENTORY REPRESENTATION PROCESS REPRESENTATION NETWORK REPRESENTATION ORGANIZATION TIMING REPRESENTATION MOTIVATION REPRESENTATION REPRESENTATION e.g.. e.g.. e.g.. e.g.. e.g.. SYSTEM e.g.. ENGINEERS SYSTEM ENTITY SYSTEM TRANSFORM SYSTEM LOCATION SYSTEM ROLE SYSTEM END SYSTEM CYCLE SYSTEM RELATIONSHIP SYSTEM INPUT SYSTEM CONNECTION SYSTEMS WORK SYSTEM MOMENT SYSTEM MEANS INVENTORY SPECIFICATION PROCESS SPECIFICATION NETWORK SPECIFICATION ORGANIZATION TIMING SPECIFICATION MOTIVATION SPECIFICATION SPECIFICATION TECH- e.g.. e.g.. e.g.. e.g.. e.g.. TECHNICIANS NOLOGIES e.g.. TECHNOLOGY ENTITY TECHNOLOGY TRANSFORM TECHNOLOGY LOCATION TECHNOLOGY ROLE TECHNOLOGY CYCLE TECHNOLOGY END TECHNOLOGY RELATIONSHIP TECHNOLOGY INPUT TECHNOLOGY CONNECTION TECHNOLOGY WORK TECHNOLOGY MOMENT TECHNOLOGY MEANS INVENTORY CONFIGURATION PROCESS CONFIGURATION NETWORK CONFIGURATION ORGANIZATION TIMING CONFIGURATION MOTIVATION CONFIGURATION CONFIGURATION COMPONENTS WORKERS COMPONENT ENTITY COMPONENT TRANSFORM COMPONENT LOCATION COMPONENT ROLE COMPONENT CYCLE COMPONENT END COMPONENT RELATIONSHIP COMPONENT INPUT COMPONENT CONNECTION COMPONENT WORK COMPONENT MOMENT COMPONENT MEANS INVENTORY INSTANTIATION PROCESS INSTANTIATION NETWORK INSTANTIATION ORGANIZATION INSTANTIATION TIMING INSTANTIATION MOTIVATION INSTANTIATION OPERATIONS OPERATIONS ENTITY THE ENTERPRISE OPERATIONS TRANSFORM OPERATIONS LOCATION OPERATIONS ROLE OPERATIONS CYCLE OPERATIONS END OPERATIONS RELATIONSHIP OPERATIONS INPUT OPERATIONS CONNECTION OPERATIONS WORK OPERATIONS MOMENT OPERATIONS MEANS AUDIENCE TARGET PERSPECTIVES INVENTORY PROCESS NETWORK ORGANIZATION TIMING MOTIVATION DOMAINS c 2010 John A. Zachman, Zachman International
  • 14. Architecture Is Architecture OntologyI simply put Enterprise names on the same descriptive The Zachman Framework schema technically is an representations relevant for describing anything. ontology - a theory of the existence of a structured set of essential components of an object for which explicit expression is necessary (is mandatory?) for designing, Why would anyone think operating and changing the object (the object being anthat the descriptions of an Enterprise Enterprise, a department, a value chain, a "sliver," a solution, a project, an airplane, a building, a bathtub or are going to be any different whatever or whatever).from the descriptions of anything else humanity has ever described? 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).ARCHITECTURE IS ARCHITECTURE A Framework is a STRUCTURE. IS ARCHITECTURE (A Structure DEFINES something.) An Ontology is a theory of existence - what ISI dont think Enterprise Architecture is arbitrary ... An Ontology IS a Structure. and it is not negotiable.My opinion is, we ought to accept the definitions of A Methodology is a PROCESS.Architecture that the older disciplines of Architecture (A Process TRANSFORMS something.)and Construction, Engineering and Manufacturing haveestablished and focus our energy on learning how to use A Structure IS NOT A Processthem to actually engineer Enterprises. A Process IS NOT a Structure. © 2007 John A. Zachman, Zachman International © 2008 John A. Zachman, Zachman International
  • 15. Process Ontology 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 18Add Bleach to an Alkali and ? P eriod 1 1 H 2 He it is transformed into Saltwater. 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 3 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 4 K Ca Sc Ti V C r Mn Fe Co Ni Cu Zn Ga Ge As Se Br Kr 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
  • 16. Chemistry - A Science ProcessA 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 "practice". 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
  • 17. Ontology vs Process The Periodic Table Metaphor Standard periodic table A reasonable metaphor for the Framework is the G ro up ? 1 ? P erio d 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 2 Periodic Table. The Periodic Table is an ontology ... a 2 1 H 3 4 L i Be 5 B 6 C 7 N 8 O 9 F He 10 Ne schema ... a normalized schema ... one element goes in 3 11 12 Na Mg 13 Al 14 Si 15 P 16 S 17 Cl 18 Ar one and only one cell. The Periodic Table doesnt do 19 20 21 2 2 23 24 25 26 27 28 29 30 31 3 2 33 34 35 36 4 5 K Ca Sc Ti V C r Mn Fe Co 37 38 39 4 0 41 42 43 44 45 46 47 Ni Cu Zn 48 Ga Ge 49 50 As 51 Se 52 Br 53 Kr 54 anything. It reflects nature. The Periodic Table (an Rb S r Y Zr Nb Mo T c Ru Rh P d A g Cd In Sn Sb Te I Xe An Ontology 6 55 56 Cs Ba * 72 Hf 73 Ta 74 W 75 76 Re O s 77 Ir 78 Pt 79 Au 80 Hg 81 Tl 82 Pb 83 Bi 84 Po 85 At 86 Rn ontology) is used by Chemists (practitioners) to define a 7 87 88 * * 10 4 10 5 106 107 108 109 110 111 112 1 13 1 14 11 5 116 117 118 Fr Ra Rf Db Sg Bh Hs Mt Ds Rg Uub Uut U uq Uu p Uuh Uu s Uuo Process (a methodology) for producing compounds * L an than id e s 89 5 7 58 L a Ce 90 59 Pr 91 60 61 62 63 64 Nd Pm Sm E u Gd 92 93 94 95 96 97 65 Tb 66 Dy 98 67 Ho 68 Er 69 70 Tm Y b 9 9 10 0 101 102 103 71 Lu (results, implementations, composites). If an alchemist * * Actin id e s Ac Th Pa U Np P u Am Cm B k Cf E s Fm Md No Lr uses the Periodic Table to define the process, the process can be dynamically defined (or redefined) and will be repeatable and produce predictable results ... and the IS NOT alchemist will become a Chemist. On the other hand, if the alchemist ignores the Periodic Table, they can define a process (a methodology) that will produce results, point-in-time solutions, based on their own skills andHydrochloric Acid Sodium Hydroxide Sodium Chloride Water experience (heuristics). The process (methodology) willHCl + NaOH --> NaCl + H2O (salt) be fixed (not changeable) and the alchemist will foreverHydrogen Sodium Sodium 2 Hydrogens A Process remain an alchemist. Chlorine Oxygen Chlorine Oxygen Hydrogen Practitioners (methodologists) are constrained by time and results. and a Process IS NOT an Ontology. Theoreticians (scientists) are constrained by natural laws and integrity. © 2009 John A. Zachman, Zachman International c 2008 John A. Zachman, Zachman International
  • 18. The Periodic Table Metaphor The Framework Is a SchemaBefore Mendeleev figured out the Periodic table, The Fmwrk is a two-dimensional classification systemAlchemists (practitioners) could create compounds for ENTERPRISE descriptive representations NOT I/S.based on their experience ... whatever worked. AfterMendeleev figured out the Periodic Table, Chemistry The classification scheme for each axis grew up quitebecame a science. Creating compounds became independently from the Framework application.predictable and repeatable based on the natural laws(Physics) expressed in the Periodic Table. Within 50 The classification for each axis is:years, the Chemists and Physicists (practitioners) were a. Comprehensivesplitting atoms. b. Non-redundantIf I am right that Architecture is Architecture is Therefore, each cell of the Framework is:Architecture, and if my work understanding the a. Uniqueunderlying primitives (elements) of Architecture b. "Primitive" (one single Abstractioncorrectly reflects the natural laws of classification and by one single Perspective)has integrity, maybe my Framework will form the and the total set of cells is complete.basis for making Enterprise Architecture a science ...and maybe in 50 years, the methodologists The Framework logic is universal, independent of its(practitioners) will be able to engineer Enterprises to application - totally neutral relative to methods/tools.be assembled to order from reusable "primitive"components dynamically. I dont know. I hope so. The Framework is a "normalized" schema ...Well probably know in 50 years. ... NOT a matrix. Thats what makes it a good analytical tool. c 2007 John A. Zachman, Zachman International © 2001-2006 John A. Zachman, Zachman International
  • 19. 1965 Systems Problems 1. Didnt meet Requirements. (not "aligned") 2. The data was no good:Enterprise Architecture Not consistent from system to system. Not accurate. Not accessible. Too late. Conclusions 3. Couldnt change the system. (Inflexible) 4. Couldnt change the technology. (Not adaptable) 5. Couldnt change the business. (Couldnt change the system or the technology so couldnt change business.) 6. Little new development (80% $ for maintenance) 7. Took too long. 8. Cost too much. 9. Always over budget. 10. Always missed schedules. 11. DP budget out of control. 12. Too complicated - cant understand it, cant manage it. 13. Just frustrating. (Adapted from Doug Erickson) © 2010 John A. Zachman, Zachman International © 2004-2006 John A. Zachman, Zachman International
  • 20. 2011 Systems Problems Its Funny ...1. Dont meet Requirements. (not "aligned") COBOL didnt fix those problems!2. The data is no good: MVS didnt fix those problems! Not consistent from system to system. Virtual Memory didnt fix those problems! Not accurate. IMS, DB2, Oracle, Sybase, Access, Fortran, PL/1, ADA, Not accessible. C++, Visual Basic, JAVA 2, 360s, 390s, MPPs, DEC Too late. VAXs, H200s, Crays, PCs, MACs, Distributed Processing,3. Cant change the system. (Inflexible) didnt fix those problems!4. Cant change the technology. (Not adaptable) Word, Excel, Powerpoint, Outlook Express, eMAIL, DOS,5. Cant change the business. (Cant change the Windows 95, 98, 2000, NT, ME, XP, Unix, Linux, Object Oriented, COM, DCOM, CORBA, EDI, HTML, XML, system or the technology so cant change business.) UML, the Internet, B2B, B2C, Portals, Browsers6. Little new development (80% $ for maintenance) didnt fix those problems!7. Takes too long. IEF, IEW, ADW, ERWIN, POPKIN, Rational, PTECH,8. Costs too much. Rochade, Platinum, Design Bank, Data Warehouse, SAP,9. Always over budget. Baan, Peoplesoft, Oracle Financials, BSP, ISP, EAP, EAI10. Always missed schedules. didnt fix those problems!11. IT budget out of control. And, I doubt that Web Services, .Net, Websphere, Agile12. Too complicated - cant understand it, cant manage it. Programming, Service Oriented Architecture or Component13. Just frustrating. Development (whatever that is) is going to fix the problems. (Adapted from Doug Erickson) IT MAKES ONE WONDER IF THERE ACTUALLY IS A TECHNICAL SOLUTION TO THE PROBLEM!!! © 2004-2006 John A. Zachman, Zachman International © 2004-2006 John A. Zachman, Zachman International
  • 21. Engineering ProblemIm not saying that there is anything wrong with any ofthese technologies.In fact, any or all of them may well be very good ...In fact, you may not be able to solve the Enterpriseproblem without employing some of these technologies. However,The Enterprise problem is an ENGINEERING problem, NOT a technical problem.My perception is that it is going to take actual work,ENGINEERING work, to solve the problem. My planwould be to start building out models, PRIMITIVEmodels, engineering them for alignment, integration,flexibility, reduced time-to-market, etc., etc., etc.What would be YOUR plan for solving the problems??? © 2004-2006 John A. Zachman, Zachman International