Managing Complexity and Change

Transcription

1 Enterprise Physis 101 Enterprise Arhiteture Managing Complexity and Change My quote to a General Management audiene several years ago: "This seminar is NOT about inreasing the stok prie by the lose of market, Friday afternoon. "It IS about the laws of nature that determine the suess of an Enterprise... partiularly, ontinuing suess in the turbulent times of the Information Age. "It is a presentation on Physis... "Enterprise Physis" John A. Zahman Zahman International 2222 Foothill Blvd. Suite 337 La Canada, Ca John A. Zahman, Zahman International 1998 John A. Zahman, Zahman International

2 Introdution Origins of Ent. Arh. Frederik Taylor "Priniples of Sientifi Management" 1911 Enterprise Arhiteture presently appears to be a grossly misunderstood onept among management. It is NOT an Information Tehnology issue. It is an ENTERPRISE issue. It is likely pereived to be an Information Tehnology issue as opposed to a Management issue for two likely reasons: A. Awareness of it tends to surfae in the Enterprise through the Information Systems ommunity. B. Information Tehnology people seem to have the skills to do Enterprise Arhiteture if any Enterprise Arhiteture is being or is to be done. Walter A. Shewhart "The Eonomi Control of Quality of Manufatured Produt" 1931 Peter Druker "The Pratie of Management" 1954 Jay Forrester "Industrial Dynamis" 1961 Peter Senge "The Fifth Disipline" 1990 Eri Helfert "Tehniques of Finanial Analysis" 1962 Robert Anthony "Planning and Control Systems: A Framework for Analysis" 1965 Sherman Blumenthal "Management Information Systems: A Framework for Planning and Development" 1969 Alvin Toffler "Future Shok" John A. Zahman, Zahman International George Steiner "Comprehensive Managerial Planning" 1972 Et., et., et John A. Zahman, Zahman International

3 "Enterprise" The Information Age There are two impliations to the word "Enterprise": I. Sope The broadest possible boundary of the Enterprise. The Enterprise in its entirety. Enterprise-wide in sope. The whole thing. II. Content ENTERPRISE Arhiteture is for ENTERPRISES. Enterprise Arhiteture has nothing to do with the Enterprise's systems or its information tehnology (exept as they may onstitute Row 4 onstraints). The end objet is to engineer and manufature the ENTERPRISE, NOT simply to build and run systems. "ENTERPRISE" ACTUALLY MEANS "ENTERPRISE" "The next information revolution is well underway. But it is not happening where information sientists, information exeutives, and the information industry in general are looking for it. It is not a revolution in tehnology, mahinery, tehniques, software, or speed. It is a revolution in CONCEPTS." Peter Druker. Forbes ASAP, August 24, 1998 "Future Shok" (1970) - The rate of hange. "The Third Wave" (1980) - The struture of hange. "Powershift" (1990) - The ulture of hange. Alvin Toffler "We are living in an extraordinary moment in history. Historians will look bak on our times, the 40-year time span between 1980 and 2020, and lassify it among the handful of histori moments when humans reorganized their entire ivilization around a new tool, a new idea." Peter Leyden. Minneapolis Star Tribune. June 4, 1995 "On the Edge of the Digital Age: The Histori Moment" 2005 John A. Zahman, Zahman International 1995 John A. Zahman, Zahman International

4 The Challenge What is your strategy for addressing: Orders of magnitude inreases in omplexity, and Orders of magnitude inreases in the rate of hange? Seven thousand years of history would suggest the only known strategy for addressing omplexity and hange is ARCHITECTURE. If it gets so omplex you an't remember how it works, you have to write it down... Arhiteture. If you want to hange how it works, you start with what you have written down... Arhiteture. I. Introdution Agenda II. Bakground - Enterprise Arhiteture: Why Is It Important III. Definitions - What does It Look Like? IV. The Framework and Management Issues V. The Framework and Arhitets VI. Conlusions The key to omplexity and hange: Arhiteture. The question is: What is "Arhiteture," Enterprise Arhiteture? 1995 John A. Zahman, Zahman International 2006 John A. Zahman, Zahman International

5 Different Faets Introdution to Enterprise Arhiteture The Framework for Enterprise Arhiteture Column 1 is desriptive of WHAT Inventories the Enterprise ares enough about to manage, that is, the ountable things over whih they maintain inventory ontrol. Column 2 is desriptive of HOW the Enterprise funtions in Transforming (proessing) raw materials and energy into finished goods and servies. Column 3 is desriptive of WHERE the Enterprise operates, the Loations from and to whih various things are stored and transported, the Networks of the Enterprise. Column 4 is desriptive of WHO, the Organizations of the Enterprise, the Roles to whom various work produt responsibilities are alloated. Column 5 is desriptive of WHEN things happen, the Timing yles of the Enterprise 1990 John A. Zahman, Zahman International Column 6 is desriptive of WHY, the Motivation, the intent, the Ends of the Enterprise John A. Zahman, Zahman International

6 AUDIENCE PERSPECTIVES INVENTORY FUNCTION NETWORKS ORGANIZATION TIMING MOTIVATION TARGET DOMAINS OPERATIONS WORKERS COMPONENT TECH- NOLOGY IMPLE- MENTERS WHAT - Inventory - Things HOW - Proess - Transforms WHERE - Network - Loations WHO - Organization - Roles WHEN - Timing - Cyles WHY - Motivation - Ends ENGINEERS SYSTEM ARCHITECTS EXECUTIVE LEADERS SCOPE VISIONARIES INTERROGATIVE AUDIENCE PERSPECTIVE WHAT HOW WHERE WHO WHY WHEN INTERROGATIVE TARGET CONTRIBUTORS PERSPECTIVE Different Perspetives Row 1 is omprised of the Visionaries' Lists that identify Enterprise SCOPE boundaries. Row 2 is omprised of the Exeutive Leaders' semanti models that define Enterprise Business onepts. Row 3 is omprised of the Arhitets' shemati models that represent the Enterprise System logi. Row 4 is omprised of the Engineers' blueprint models that speify Enterprise Tehnology Construts. Row 5 is omprised of the Implementers' listings that onfigure Enterprise Component instrutions. Row 6 is the Workers' instanes that instantiate Enterprise Operations reality John A. Zahman, Zahman International 2006 John A. Zahman, Zahman International

7 E1 E1 E1 E1.1 E1.1 E1.1 E1.2 E1.2 E1.2 E1.3 E1.3 E1.3 A1 A1 A1 E2 E2 E2 SCOPE (CONTEXTUAL) Planner MODEL (CONCEPTUAL) Owner SYSTEM MODEL (LOGICAL) A FRAMEWORK FOR ENTERPRISE ARCHITECTURE DATA What FUNCTION How NETWORK Where PEOPLE Who When MOTIVATION Why List of Things Important to the Business Entity = Class of Business Thing e.g. Semanti Model Ent. = Business Entity Reln. = Business Relationship e.g. Logial Data Model List of Proesses the Business Performs Proess = Class of Business Proess e.g. Business Proess Model Pro. = Business Proess I/O = Business Resoures e.g. Appliation Arhiteture List of Loations in Whih the Business Operates Node = Major Business Loation e.g. Business Logistis System Node = Business Loation Link = Business Linkage e.g. Distributed System Arhiteture List of Organizations Important to the Business People = Major Organization Unit e.g. Work Flow Model People = Organization Unit Work = Work Produt e.g. Human Interfae Arhiteture TIME List of Events/Cyles SignifiantList of Business Goals/ to the Business Strategies Time = Major Business Event/Cyle e.g. Master Shedule Time = Business Event Cyle = Business Cyle e.g. Proessing Struture TM Ends/Means = Major Business Goal/Strategy e.g. Business Plan End = Business Objetive Means = Business Strategy e.g. Business Rule Model SCOPE (CONTEXTUAL) Planner MODEL (CONCEPTUAL) Owner SYSTEM MODEL (LOGICAL) 2006 John A. Zahman, Zahman International Designer Ent. = Data Entity Reln. = Data Relationship Pro. = Appliation Funtion I/O = User Views Node = I/S Funtion (Proessor, Storage, et.) Link = Line Charateristis People = Role Work = Deliverable Time = System Event Cyle = Proessing Cyle End = Strutural Assertion Means = Ation Assertion Designer TECHNOLOGY MODEL (PHYSICAL) e.g. Physial Data Model e.g. System Design e.g. Tehnology Arhiteture e.g. Presentation Arhiteture e.g. Control Struture e.g. Rule Design TECHNOLOGY MODEL (PHYSICAL) Builder DETAILED REPRESEN- TATIONS (OUT-OF- CONTEXT) Sub- Contrator FUNCTIONING ENTERPRISE Ent. = Table/Segment, et. Reln. = Key/Pointer, et. e.g. Data Definition Ent. = Field Reln. = Address e.g. DATA Pro. = Computer Funtion I/O = Data Elements/Sets e.g. Program Pro. = Language Statement I/O = Control Blok e.g. FUNCTION Node = Hardware/Systems Software Link = Line Speifiations e.g. Network Arhiteture Node = Address Link = Protool e.g. NETWORK People = User Work = Sreen Format e.g. Seurity Arhiteture People = Identity Work = Job e.g. ORGANIZATION Time = Exeute Cyle = Component Cyle e.g. Timing Definition Time = Interrupt Cyle = Mahine Cyle e.g. SCHEDULE End = Condition Means = Ation e.g. Rule Speifiation End = Sub-ondition Means = Step e.g. STRATEGY 1987 John A. Zahman, Zahman International For downloadable, olor version of 2005, standard Enterprise Framework graphi see Framework Standards at Builder DETAILED REPRESEN- TATIONS (OUT-OF CONTEXT) Sub- Contrator FUNCTIONING ENTERPRISE Audienes INTERROGATIVE AUDIENCE PERSPECTIVE Artifat Types WHEN WHAT HOW WHERE WHO WHY INTERROGATIVE TARGET CONTRIBUTORS PERSPECTIVE SCOPE Visionaries' Lists Identify Sope Boundaries Exeutive Semanti Leaders' Models Shemati Arhitets' SYSTEM Models Proess COMPONENT IMPLE- Implementers' Listings Configure Component Instrutions MENTERS Perspetives Intent VISIONARIES Define Business Conepts Represent System Logi EXECUTIVE LEADERS ARCHITECTS 2006 John A. Zahman, Zahman International Engineers' TECH- NOLOGY Blueprint Models Speify Tehnology Construts ENGINEERS Implementers' Listings Configure Component Instrutions Workers' OPERATIONS Instanes Instantiate Operations Reality WORKERS AUDIENCE PERSPECTIVES INVENTORY PROCESS NETWORK ORGANIZATION TIMING MOTIVATION TARGET DOMAINS

8 Caution After three DAYS of intense instrution on the Framework, a reently retired Manufaturing Engineer from Ford observed, regarding the Framework and its impliations relative to engineering and manufaturing Enterprises... : "Well, it's simple... deeptively simple! Three days is merely 'srathing the surfae'." Another Caution I hesitate to show you the next foil... for two reasons: 1. Some labels I put on some of the Cells may not suggest "primitive" models to some people. 2. I do not want to enourage anyone to hange any of the words on the Framework graphi. I put some different labels on the Cells but I did not alter the lassifiation shema nor did I modify the metamodels of any of the Cells. The labels are meant to "elaborate" the idea of the Framework for a partiular audiene as a ommuniations devie. The labels are NOT the Framework. The Framework is atually the lassifiation shema as expressed by the metamodel of the set of Framework Cells John A. Zahman, Zahman International 2005 John A. Zahman, Zahman International

9 VISIONARIES CLASSES OF ENTERPRISE PERSPECTIVES Enterprise Arhiteture The Framework and Management 2005 John A. Zahman, Zahman International The Framework for Enterprise Arhiteture - General Management Elaboration EXECUTIVE LEADERS ANALYSTS TECH- NOLOGISTS IMPLE- MENTERS WORKERS WHAT HOW WHERE IMPORTANT RESOURCES LIST INVENTORY POLICY MODEL INVENTORY MANAGEMENT FILING SYSTEM FILING CONTAINER STORAGE PLACEMENT FILE IDENTIFICATION LISTINGS FOR PEOPLE OR MACHINES CLASSES OF DESCRIPTIVE REPRESENTATIONS IMPORTANT TRANSFORMA- TIONS LIST PROCESS YIELD MODEL FUNCTIONALITY SCHEMATIC SYSTEMS DESIGN (MANUAL OR AUTOMATED) SPECIFIC INSTRUCTIONS FOR PEOPLE OR MACHINES IMPORTANT NETWORKS LIST LOGISTICS CAPACITY MODEL LOGISTICS SYSTEM SCHEMATIC LOCATION CAPACITY BLUEPRINT LOCATION ADDRESSES FOR PEOPLE OR MACHINES WHO IMPORTANT ORGANIZATIONS LIST WORK ALLOCATION MODEL ROLES AND RESPONSI- BILITIES WORK PRODUCT FORMAT DESIGN INDIVIDUAL WORK ASSIGNMENTS FOR PEOPLE OR MACHINES WHEN IMPORTANT TIMINGS LIST CYCLES TIMING MODEL SYSTEM PROCESSING CYCLES SYSTEM TIMING DESIGN TIMING SPECIFICATIONS FOR PEOPLE OR MACHINES RESOURCES TRANSFORMATIONS NETWORKS ORGANIZATIONS TIMINGS MOTIVATIONS WHY IMPORTANT MOTIVATIONS LIST OBJECTIVES MODEL RULE SYSTEM LOGIC RULE SYSTEM DESIGN RULE SPECIFICATIONS FOR PEOPLE OR MACHINES T H E E N T E R P R I S E SCOPE SYSTEM TECH- NOLOGY COMPONENT OPERATIONS The domain of MANAGEMENT (in general) 2005 John A. Zahman, Zahman International The domain of Systems (Information Systems or Manual Systems) (in general) The domain of various Staff Organizations (in general) Figure 1. The Framework for Enterprise Arhiteture (Business Vernaular Elaboration) See CAUTION on previous foil. CLASSES OF ENTERPRISE ENGINEERING DESIGN ARTIFACTS 2005 John A. Zahman, Zahman International

10 The Framework and Management Management reasons for the Columns: Column 1 has to do with inventory management. Column 2 has to do with yield on transformations. Column 3 has to do with apaity management. Column 4 has to do with performane management. Column 5 has to do with response times. Column 6 has to do with plans and ontrols. The Framework and Management Management reasons for the Rows: Row 1 has to do with setting Enterprise boundaries. Row 2 has to do with defining Business Poliies. Row 3 has to do with institutionalizing the Business Poliies (systematization). Row 4 has to do with implementations (manual and/or automated). Row 5 has to do with speifi instrutions (for people and/or mahines). Row 6 has to do with Enterprise operations John A. Zahman, Zahman International 2005 John A. Zahman, Zahman International

11 The Framework and Management Oversimplifiations and generalizations, however... Some reasons why the reord keeping system does not: aurately reflet the atual inventories of resoures or aurately reflet the finanial harateristis of the Enterprise or provide onsistent or aurate regulatory ompliane (Sarbanes-Oxley type) information are likely beause: 1. The business poliies that govern inventory management are not defined or not defined and managed onsistently aross the sope of the Enterprise. (Col.1, R 2) 2. The reord-keeping system(s) (Col.1, Row 3) do not aurately and onsistently reflet the business inventory poliies. (Col. 1, Row 2) 3. The transation data about resoure aquisition and onsumption is not aurately and "primitively" reorded. (Col. 2, Row 6; Col. 1, Row 6) The Framework and Management Oversimplifiations and generalizations, however... One reason why G & A and indiret expenses inrease is likely beause: 1. Compensation for inonsistenies in business poliies regarding inventory management (Col. 1, Row 2) or in the filing system that reords atual inventories. (Col. 1, Row 3.) (This is entropy... ompensation for disorder in the system.) One reason why the yield on the business transformation of raw materials and energy to finished goods deteriorates over time is likely beause: 1. The Business Proesses (Col. 2, Row 2) and their supporting systems (Col. 2, Row 3) evolve (like the Winhester House evolved)... they are not being engineered and have never been optimized John A. Zahman, Zahman International 2005 John A. Zahman, Zahman International

12 The Framework and Management Oversimplifiations and generalizations, however... Some reasons why the distribution osts inrease and network reliability dereases are likely beause of: 1. Suboptimal positioning of storage and transmission apaities (Col. 3, Row 2) 2. Lak of standardization of loations and onnetions requiring "interfaing" or "translations." (Column 3, Rows 2-5) Some reasons personnel osts inrease are likely beause: 1. Work produt assignments are omplex and overlapping and not learly speified (Col. 4, Row 2) 2. Skills are not well-mathed with the work assignments. (Col. 4, Row 2) One reason why yle times are exessive and diffiult to predit is likely beause: 1. Multiple yles are interdependent and are interating apriiously. (The law of unintended onsequenes.) (Col. 5, Rows 2-5) 2005 John A. Zahman, Zahman International The Framework and Management Oversimplifiations and generalizations, however... One reason why business objetives are diffiult to realize is likely beause: 1. Objetives are not defined suh they hange the state of some speifi (single) thing that is within the Enterprise's ontrol to hange (Col. 6 and some Entity in Row 2). (Plans not attainable and/or not measurable.) Some reasons why the Enterprise is not flexible are likely beause: 1. No engineering has been done to separate the things that hange independently from one another. (No Framework primitives.) 2. It's hard to figure out what to hange... or what hanges will atually work. (No expliit Arhiteture.) One reason why it is so diffiult to take out osts is likely beause: 1. There is no way to find reurring onepts that should or must be reused (i.e. no reusable primitive omponents.) (No Classifiation, i.e. no Framework.) 2005 John A. Zahman, Zahman International

13 The Framework and Management Oversimplifiations and generalizations, however... The reason why there is: NO Integration - an't find reusable omponents NO Interoperability - no standardization (of ontents or ontainers) NO Alignment - nothing expliit to whih to align NO Seurity - nothing to examine before implementation NO Redued time to market for systems implementations - nothing in inventory before you get the order NO Flexibility - no separation of independent variables NO Preditability - no knowledgebase Et., et., et. The Framework and Management And... life (business) is getting more omplex... And... the rate of hange ontinues to inrease... And... one again, I submit Someday you are going to wish you had all these models (that is, Enterprise Arhiteture) and when that day omes, it's going to be too late to build them! In short: There is NO ARCHITECTURE John A. Zahman, Zahman International 2005 John A. Zahman, Zahman International

14 Sope Business Primitive Models What How Where Who When Why A "Primitive" Model is one that is omprised of elements from a single Framework Cell... one single "abstration" from one single "perspetive." Primitive Models Visionaries Planner Exeutive Leaders System Arhitets Tehnology Engineers Components Resoures Funtions Networks Organizations Timings Motivations Implementers 1999 John A. Zahman, Zahman International Enterprise Arhiteture Framework and Arhitets 2006 John A. Zahman, Zahman International 2006 John A. Zahman, Zahman International

15 Sope Business Composite Models What How Where Who When Why A "Composite" Model is one that is omprised of elements from more than one Framework Cell... multiple "abstrations" or multiple "perspetives." Composite Models Visionaries Planner Exeutive Leaders 2006 John A. Zahman, Zahman International System Arhitets Tehnology Engineers Components Resoures Funtions Networks Organizations Timings Motivations Sub- Implementers 1999 John A. Zahman, Zahman International Planner Owner Designer Builder Sub- Contrator What How Where Who When Why A "Primitive" Model is one that is omprised of elements from a single Framework Cell... one single "abstration" from one single "perspetive." Primitive Models Primitive Models Planner Owner "Primitive" does NOT mean granular. It means the omponents all are the same things. Designer e.g. The Periodi Table: What makes an element an element is not how big the moleules are or how many of them there are. They all al the same element. Builder Contrator Things Proess Loation People Time Motivation John A. Zahman, Zahman International

16 Planner Primitives vs Composites Building What Primitive HowModels: Where Who When Why The objetive is ENGINEERING (Enterprise Arhiteture) Building Composite Models: The objetive is MANUFACTURING (Implementation) Planner Owner Designer Short Term Strategy: Start Manufaturing. Worry about engineering later (legay) Long Term Strategy: Start Engineering. Minimize srap and rework (arhiteture) Owner Designer Builder Note: if you fabriate the Primitives and keep them in inventory, you an hange the IS/IT strategy to "assemble to order" that is, assemble the Enterprise to order (mass ustomization) Builder Contrator Things Proess Loation People Time Motivation John A. Zahman, Zahman International Sub- Sub- Contrator Sub- Planner Owner Primitives vs Composites What How Where Who When Why You need Primitive Models for Arhiteture Planner Owner 2006 John A. Zahman, Zahman International Designer Builder Sub- Contrator You need Composite Models for Implementation (For arhiteted implementations, omposite models must be reated from primitive models and diagonal omposites from horizontally and vertially integrated primitives. ) Designer Builder Contrator Things Proess Loation People Time Motivation John A. Zahman, Zahman International

17 Arhiteture vs Implementation From a fixed set of 36 Arhitetural Primitives, you ould reate a virtually infinite set of Implementation Composites. The Enterprise Hologram If the Composites are not hard bound together the Enterprise is virtual, like a hologram. It ould be viewed from any faet. Arhitetural Primitives Motivation Time Data People Proess Implementation Composites Loation The Enterprise (Total aggregate set of omposites) 1999 John A. Zahman, Zahman International Motivation Time Data The Enterprise People Proess Loation Eye You an view the Enterprise through any faet of the hologram and see all the other faets relative to the viewing faet John A. Zahman, Zahman International

18 Building Legay If you have no Primitives and you base your implementation Composites on a single Enterprise-wide faet, you are going to optimize that faet and sub-optimize all the others, that is, you will fix one problem and ause at least five others. You are just building more legay. It doesn't make any differene whih faet you pik. If the only tool you have is a hammer, all the world looks like a nail. If the only tool you have is Proess, all the Enterprise looks like Inputs/Outputs to Proess. If the only tool you have is Data, all the Enterprise looks like attributes of an objet. If the only tool you have is Tehnology, all the Enterprise looks like an appliation. If the only tool you have is People, all the Enterprise looks like Servies/Web Pages. If the only tool you have is Time, all the Enterprise looks like Systems Thinking (Dynamis). If the only tool you have is Motivation, all the Enterprise looks like Constraints/Business Rules John A. Zahman, Zahman International Arhiteture vs Implementation If you are not building "primitive models," you are not doing Arhiteture, you are doing implementation. Composite models are implementations. Primitive models are Arhiteture. Composite models should be reated from primitive models. If omposite models are being reated and no primitive models exist, then the omposite model is likely being defined relative to a speifi implementation (one omponent of one faet), not relative to the Enterprise. You are optimizing the implementation and SUB- OPTIMIZING the ENTERPRISE. It is a point-in- time solution. It is good only as long as nothing hanges. The likelihood of it being reusable is low to zero. It is more "legay." The "Silver Bullet" Building implementations (omposite models) and SAYING you are doing Enterprise Arhiteture (primitive models) is the worst possible strategy John A. Zahman, Zahman International

19 The Framework Is a Shema The Framework is a two-dimensional lassifiation system for ENTERPRISE desriptive representations NOT I/S. The lassifiation sheme for eah axis grew up quite independently from the Framework appliation. The lassifiation for eah axis is: a. Comprehensive b. Non-redundant Therefore, eah ell of the Framework is: a. Unique b. Primitive (one single Abstration by one single Perspetive) and the total set of ells is omplete. The Framework logi is universal, independent of its appliation - totally neutral relative to methods/tools. The Framework is a "normalized" shema NOT a matrix. That's what makes it a good analytial tool John A. Zahman, Zahman International Lean and Mean End Objet: Minimum possible osts Minimum possible omplexity How do you do that? Normalize EVERYTHING! Remove ALL redundany - NO reurring onepts Redundany: 1. Unneessary osts of dupliation - waste. 2. Compensatory osts of disontinuity - Entropy (Entropy = energy not available for produtive work) a. Internal osts - operating expenses b. External osts - damage ontrol, litigation Seond law of thermodynamis - the aging proess. Over time, the energy required to support the system (entropy) inreases. At the point in time the energy required to support the system exeeds the energy in the system, the system dies. How do you remove entropy? Re-engineer the system to remove disorder. Take out all disontinuous dupliation. Engineer for simpliity John A. Zahman, Zahman International

20 Finding Redundanies How do you disover reurring onepts? How do you "normalize" anything? CLASSIFY. But - the lassifiation sheme has to be "lean." You an't have mixtures (apples and oranges) in any ategory beause you won't be able to detet redundanies. The shema has to be "normalized" - one fat in one plae. And - the shema has to be omprehensive. You must have a ategory for every onept or you won't find the dupliation of onepts that are not lassified. That is, the shema has to be omprised of single variable, "primitive" ategories. No mixtures (omposites.) The shema has to be omplete, the total possible set of ategories. For example, the Periodi Table. Anything less than the total set would either, by definition, be DE-normalized (ontain omposite ategories) or ould not aommodate the totality of the onepts John A. Zahman, Zahman International The Framework Primitive Models are arhiteture Primitive models defined relative to the Enterprise are ENTERPRISE Arhiteture. Long term investments. Composite Models are implementations Composite models defined relative to one projet are implementations. It is doubtful that you ould define a omposite, Enterprise-wide Model. It would be so omplex, who ould possibly understand it? Composite models are short term implementations. YOU DON'T HAVE TO NORMALIZE ALL 30 PRIMITIVE MODELS TO REALIZE SHORT TERM OPTIMIZATION BENEFITS! (Note: disontinuity in some Columns may diretly, negatively impat management's performane.) POINT NO. 2 If you retain and maintain the primitive models, they are the baseline for managing hange John A. Zahman, Zahman International

21 The Future A. Build Primitive Models B. Store Primitive Models C. Manage (Enfore) Primitive Models D. Change Primitive Models E. Assemble Composite Models from Primitive Models It is not adequate merely to produe running ode. (That was an Industrial Age idea.) The long term Enterprise value lies in Enterprise "Engineering," i.e. in the MODELS THEMSELVES! The "Knowledgebase" of the Enterprise (This is an Information Age idea!) 1990 John A. Zahman, Zahman International Sope Business System Tehnology END STATE VISION What How Where Who When Why Some day You are going to wish you had all these models made expliit, Enterprise-wide, horizontally and vertially integrated, at exruiating level of detail!!! Visionaries Exeutive Leaders Arhitets Engineers 2006 John A. Zahman, Zahman International Components Resoures Funtions Networks Organizations Timings Motivations Implementers 1990 John A. Zahman, Zahman International

22 1965 Systems Problems Enterprise Arhiteture Conlusions 1. Didn't meet Requirements. (not "aligned") 2. The data was no good: Not onsistent from system to system. Not aurate. Not aessible. Too late. 3. Couldn't hange the system. (Inflexible) 4. Couldn't hange the tehnology. (Not adaptable) 5. Couldn't hange the business. (Couldn't hange the system or the tehnology so ouldn't hange business.) 6. Little new development (80% $ for maintenane) 7. Took too long. 8. Cost too muh. 9. Always over budget. 10. Always missed shedules. 11. DP budget out of ontrol. 12. Too ompliated - an't understand it, an't manage it. 13. Just frustrating. (Adapted from Doug Erikson) 2003 John A. Zahman, Zahman International 2003 John A. Zahman, Zahman International

23 2006 Systems Problems 1. Don't meet Requirements. (not "aligned") 2. The data is no good: Not onsistent from system to system. Not aurate. Not aessible. Too late. 3. Can't hange the system. (Inflexible) 4. Can't hange the tehnology. (Not adaptable) 5. Can't hange the business. (Can't hange the system or the tehnology so an't hange business.) 6. Little new development (80% $ for maintenane) 7. Takes too long. 8. Costs too muh. 9. Always over budget. 10. Always missed shedules. 11. IT budget out of ontrol. 12. Too ompliated - an't understand it, an't manage it. 13. Just frustrating. (Adapted from Doug Erikson) It's Funny... COBOL didn't fix those problems! MVS didn't fix those problems! Virtual Memory didn't fix those problems! IMS, DB2, Orale, Sybase, Aess, Fortran, PL/1, ADA, C++, Visual Basi, JAVA 2, 360's, 390's, MPP's, DEC VAX's, H200's, Crays, PC's, MAC's, Distributed Proessing, didn't fix those problems! Word, Exel, Powerpoint, Outlook Express, , DOS, Windows 95, 98, 2000, NT, ME, XP, Unix, Linux, Objet Oriented, COM, DCOM, CORBA, EDI, HTML, XML, UML, the Internet, B2B, B2C, Portals, Browsers didn't fix those problems! IEF, IEW, ADW, ERWIN, POPKIN, Rational, PTECH, Rohade, Platinum, Design Bank, Data Warehouse, SAP, Baan, Peoplesoft, Orale Finanials, BSP, ISP, EAP, EAI didn't fix those problems! And, I doubt that Web Servies,.Net, Websphere, Extreme Programming, Servie Oriented Arhiteture or Component Development (whatever that is) is going to fix the problems. IT MAKES ONE WONDER IF THERE ACTUALLY IS A TECHNICAL SOLUTION TO THE PROBLEM!!! 2003 John A. Zahman, Zahman International 2003 John A. Zahman, Zahman International

24 Engineering Problem I'm not saying that there is anything wrong with any of these tehnologies. In fat, any or all of them may well be very good... In fat, you may not be able to solve the Enterprise problem without employing some of these tehnologies. However, The Enterprise problem is an ENGINEERING problem, NOT a tehnial problem. My pereption is that it is going to take atual work, ENGINEERING work, to solve the problem. My plan would be to start building out models, PRIMITIVE models, engineering them for alignment, integration, flexibility, redued time-to-market, et., et., et. What would be YOUR plan for solving the problems??? 2003 John A. Zahman, Zahman International