A apresentação fala de Arquitetura Empresarial.

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. Zachman
Zachman International
2222 Foothill Blvd. Suite 337
La Canada, Ca. 91011
www.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" 1911
Enterprise Architecture presently appears to be a grossly
misunderstood concept among management. Walter A. Shewhart "The Economic Control of Quality
of Manufactured Product" 1931 (Dr. Edward Demming's Mgr.)
It is NOT an Information Technology issue.
It is an ENTERPRISE issue. Peter Drucker "The Practice of Management" 1954
Jay Forrester "Industrial Dynamics" 1961
It is likely perceived to be an Information Technology
Peter Senge "The Fifth Discipline" 1990
issue as opposed to a Management issue for two reasons:
Eric Helfert "Techniques of Financial Analysis" 1962
A. Awareness of it tends to surface in the Enterprise
through the Information Systems community. Robert Anthony "Planning and Control Systems: A
Framework for Analysis" 1965
B. 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 Age
There 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
Enterprise's 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 Environment
1. If IT is in the business of building and running systems II. Introduction to Enterprise Architecture
and the objective is to build systems faster and cheaper, then III. Ontology versus Methodology
break them down into smaller pieces and start writing the IV. Enterprise Knowledgebase
code. Result is more of the same ... legacy. (NOT Day 2
integrated, 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 Objectives
2. 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 Migration
Build and maintain "interfaces" with any replicated X. Building Row 1 Matrices
concepts 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. Conclusions
3. If IT is in the business of engineering and manufactur-
ing Enterprises, then start building an inventory of Enter-
Appendix
prise Architecture assets, engineering them to be reused in XV. 12 Step Program
any implementation ... the "asset paradigm" ... that is, XVI. Intro to Sample Models
"Mass-Customization" of the Enterprise ... ("custom XVII. Meta Frameworks
Enterprises, mass-produced in quantities of one for XVIII. Zachman Propositions
immediate 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 see
In the RESULT you can see the Architect's "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 don't
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 can't 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 representations
relevant for describing a complex object (actually, any
object) such that an instance of the object can be created
and such that the descriptive representations serve as the
baseline for changing an object instance (assuming that the
descriptive representations are maintained consistent with
the 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 can't describe it, you can't 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 don't 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
Perspectives
INTERROGATIVE TARGET
PERSPECTIVE 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 DOMAINS
PERSPECTIVES
© 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 total
descriptive representations (models) relevant for describing set of descriptive representations (models) relevant for
a complex object such that it can be created and that describing an Enterprise, that is, the descriptive
constitute 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 changing
would necessarily have to include all the intersections the Enterprise once it is created. The total set of relevant
between: 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
INTERROGATIVE
The total set would necessarily have to include
NOLOGY
Abstractions: 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"
(Customer's 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 dimensional
Architecture 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 Ontology
I 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 an
that 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 IS
I don't 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 have
established and focus our energy on learning how to use A Structure IS NOT A Process
them 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 18
Add 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 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 "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 doesn't 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 and
Hydrochloric
Acid
Sodium
Hydroxide
Sodium
Chloride
Water
experience (heuristics). The process (methodology) will
HCl + NaOH --> NaCl + H2O
(salt)
be fixed (not changeable) and the alchemist will forever
Hydrogen 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 Schema
Before Mendeleev figured out the Periodic table, The Fmwrk is a two-dimensional classification system
Alchemists (practitioners) could create compounds for ENTERPRISE descriptive representations NOT I/S.
based on their experience ... whatever worked. After
Mendeleev figured out the Periodic Table, Chemistry The classification scheme for each axis grew up quite
became 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. Comprehensive
splitting atoms. b. Non-redundant
If I am right that Architecture is Architecture is Therefore, each cell of the Framework is:
Architecture, and if my work understanding the a. Unique
underlying primitives (elements) of Architecture b. "Primitive" (one single Abstraction
correctly 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 don't know. I hope so. The Framework is a "normalized" schema ...
We'll probably know in 50 years. ... NOT a matrix.
That's 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. Didn't 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. Couldn't change the system. (Inflexible)
4. Couldn't change the technology. (Not adaptable)
5. Couldn't change the business. (Couldn't change the
system or the technology so couldn't 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 - can't understand it, can't 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 It's Funny ...
1. Don't meet Requirements. (not "aligned") COBOL didn't fix those problems!
2. The data is no good: MVS didn't fix those problems!
Not consistent from system to system. Virtual Memory didn't fix those problems!
Not accurate. IMS, DB2, Oracle, Sybase, Access, Fortran, PL/1, ADA,
Not accessible. C++, Visual Basic, JAVA 2, 360's, 390's, MPP's, DEC
Too late. VAX's, H200's, Crays, PC's, MAC's, Distributed Processing,
3. Can't change the system. (Inflexible) didn't fix those problems!
4. Can't change the technology. (Not adaptable) Word, Excel, Powerpoint, Outlook Express, eMAIL, DOS,
5. Can't change the business. (Can't change the Windows 95, 98, 2000, NT, ME, XP, Unix, Linux, Object
Oriented, COM, DCOM, CORBA, EDI, HTML, XML,
system or the technology so can't change business.)
UML, the Internet, B2B, B2C, Portals, Browsers
6. Little new development (80% $ for maintenance)
didn't 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, EAI
10. Always missed schedules.
didn't fix those problems!
11. IT budget out of control.
And, I doubt that Web Services, .Net, Websphere, Agile
12. Too complicated - can't understand it, can't manage it. Programming, Service Oriented Architecture or Component
13. 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