Upload
fernando-botafogo
View
1.207
Download
5
Tags:
Embed Size (px)
DESCRIPTION
A apresentação fala de Arquitetura Empresarial.
Citation preview
John A. ZachmanZachman International2222 Foothill Blvd. Suite 337La Canada, Ca. 91011www.Zachman.com
Enterprise Architecture
Managing EnterpriseComplexity and Change
© 2010 John A. Zachman, Zachman International
Preface
This seminar is NOT about increasing the stock price by the close of market, Friday afternoon.
It IS about the laws of nature that determine the success of an Enterprise ... particularly, continuing success in the turbulent times of the Information Age.
It is a presentation on Physics ...
Enterprise Physics.
© 1990-2006 John A. Zachman, Zachman International
Introduction
Enterprise Architecture presently appears to be a grossly misunderstood concept among management.
It is NOT an Information Technology issue. It is an ENTERPRISE issue.
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.
2005 John A. Zachman, Zachman Internationalc
Frederick Taylor "Principles of Scientific Management" 1911
Walter A. Shewhart "The Economic Control of Quality of Manufactured Product" 1931 (Dr. Edward Demming's Mgr.)
Peter Drucker "The Practice of Management" 1954
Jay Forrester "Industrial Dynamics" 1961
Peter Senge "The Fifth Discipline" 1990
Eric Helfert "Techniques of Financial 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 Shock" 1970
George Steiner "Comprehensive Managerial Planning" 1972 Etc., etc., etc.
Origins of Ent. Arch.
2005 John A. Zachman, Zachman Internationalc
"Enterprise"
There are two implications to the word "Enterprise":
I. Scope
The broadest possible boundary of the Enterprise. The Enterprise in its entirety. Enterprise-wide in scope. The whole thing.
II. Content
ENTERPRISE Architecture is for ENTERPRISES. Enterprise Architecture has nothing to do with the Enterprise's systems or its information technology (except as they may constitute Row 4 constraints). The end object is to engineer and manufacture the ENTERPRISE, NOT simply to build and run systems.
"ENTERPRISE" ACTUALLY MEANS "ENTERPRISE"
2005 John A. Zachman, Zachman Internationalc
The Information Age
"The next information revolution is well underway. But it is not happening where information scientists, informa-tion executives, and the information industry in general are looking for it. It is not a revolution in technology, machinery, techniques, software, or speed. It is a
revolution in CONCEPTS." Peter Drucker. Forbes ASAP, August 24, 1998
"Future Shock" (1970) - The rate of change."The Third Wave" (1980) - The structure of change."Powershift" (1990) - The culture of change. Alvin Toffler
"We are living in an extraordinary moment in history. Historians will look back on our times, the 40-year time span between 1980 and 2020, and classify it among the handful of historic moments when humans reorganized their entire civilization around a new tool, a new idea." Peter Leyden. Minneapolis Star Tribune. June 4, 1995 "On the Edge of the Digital Age: The Historic Moment"
© 1990-2006 John A. Zachman, Zachman International
Short term, Expense-based Strategy Custom Products (Make-to-Order)1. If IT is in the business of building and running systems and the objective is to build systems faster and cheaper, then break them down into smaller pieces and start writing the code. Result is more of the same ... legacy. (NOT integrated, NOT flexible, NOT aligned, NOT reusable, NOT interoperable, etc., etc. ... BUT, running.) Modified Short Term Strategy Standard Products (Provide-from-Stock)2. If the IT strategy is to buy rather than build ... then implement "as is"... change the Enterprise to fit the package. Build and maintain "interfaces" with any replicated concepts in the existing legacy or in future system implementations. Long Term, Asset-based Strategy Custom, Standard Products (Assemble-to-Order)3. If IT is in the business of engineering and manufactur-ing Enterprises, then start building an inventory of Enter- prise Architecture assets, engineering them to be reused in any implementation ... the "asset paradigm" ... that is, "Mass-Customization" of the Enterprise ... ("custom Enterprises, mass-produced in quantities of one for immediate delivery" ... at the click of a mouse.)
Strategy Pattern
© 2011 John A. Zachman, Zachman International
Agenda (2 Day) Day 1I. Global EnvironmentII. Introduction to Enterprise ArchitectureIII. Ontology versus MethodologyIV. Enterprise Knowledgebase Day 2V. Architecture Work/End State VisionVI. Why Primitive ModelsVII. Enterprise Eng. Design ObjectivesVIII. "Federated Architecture"IX. Legacy MigrationX. Building Row 1 MatricesXI. Value Propositions (Old and New)XII. Cheaper and FasterXIII. Methodology ConsiderationsXIV. Conclusions AppendixXV. 12 Step ProgramXVI. Intro to Sample ModelsXVII. Meta FrameworksXVIII. Zachman Propositions
© 2010 John A. Zachman, Zachman International
Introduction to Enterprise Architecture
The Framework forEnterprise Architecture
© 1990-2006 John A. Zachman, Zachman International
"Architecture"
Architecture ... what is it?
Some people think this is Architecture:
That is a common MISCONCEPTION
© 2007 John A. Zachman, Zachman International
(Note: This same misconception about Enterprises is what leads people to misconstrue Enterprise Architecture as being big, monolithic, static, inflexible and unachievableand ... it takes too long and costs too much.)
"Architecture"
This is the RESULT of architecture.In the RESULT you can see the Architect's "architecture". The RESULT is an implementation, an instance.
"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
"Architecture"
If the object you are trying to create is simple, you can see 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 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
© 2007 John A. Zachman, Zachman International
"Architecture"
COMPLEXITY
If you can't describe it, you can't create it (whatever "it" is).
CHANGE
If you don't retain the descriptive representations after you create them (or if you never created them in the first place) and you need to change the resultant implementa-tion, you have only three options:
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
"Architecture"There is not a single descriptive representation for a com- plex object ... there is a SET of descriptive representations.
Descriptive representations (of anything) typically include "Abstractions":
A. Bills of Material (What) B. Functional Specs (How) C. Drawings (Where) D. Operating Instructions (Who) E. Timing Diagrams (When) F. Design Objectives (Why)
as well as Perspectives:
1. Scoping Boundaries (Strategists) 2. Requirement Concepts (Owners) 3. Design Logic (Designers) 4. Plan Physics (Builders) 5. Part Configurations (Implementers) and the 6. Product Instances (Operators)
© 2007 John A. Zachman, Zachman International
EN
GIN
EE
RS
SC
OP
E
BU
SIN
ES
S
SYS
TEM
TEC
H-
NO
LOG
Y
CO
MP
ON
ENT
OP
ER
ATIO
NS
WH
AT
HO
WW
HE
RE
EX
EC
UTIV
ELE
AD
ER
S
TEC
HN
ICIAN
S
WO
RK
ER
S
WH
YW
HE
NW
HO
INTE
RR
OG
ATIVE
PER
SPEC
TIVE
AUD
IEN
CE
PER
SPE
CTIVE
S
TARG
ET
CO
NTR
IBUTO
RS
TARG
ETD
OM
AIN
S
AR
CH
ITEC
TS
STR
ATEG
ISTS
Bills of MaterialBills of Material
PR
OC
ES
SN
ETW
OR
KO
RG
AN
IZATIO
NTIM
ING
MO
TIVA
TION
Functional SpecsFunctional Specs
DrawingsDrawings
Operating InstructionsOperating Instructions
Timing DiagramsTiming Diagrams
Design ObjectivesDesign Objectives
Abstractions
INVE
NTO
RY
© 1990-2007 John A
. Zachman, Zachm
an International
"Architecture"
© 2007 John A. Zachman, Zachman International
There is not a single descriptive representation for a com- plex object ... there is a SET of descriptive representations.
Descriptive representations (of anything) typically include "Abstractions":
A. Bills of Material (What) B. Functional Specs (How) C. Drawings (Where) D. Operating Instructions (Who) E. Timing Diagrams (When) F. Design Objectives (Why)
as well as Perspectives:
1. Scope Boundaries (Strategists) 2. Requirement Concepts (Owners) 3. Design Logic (Designers) 4. Plan Physics (Builders) 5. Part Configurations (Implementers) and the 6. Product Instances (Operators)
EN
GIN
EER
S
SC
OPE
BU
SIN
ESS
SYS
TEM
TEC
H-
NO
LOG
Y
CO
MPO
NE
NT
OP
ER
ATIO
NS
WH
AT
EXE
CU
TIVE
LEAD
ER
S
TECH
NIC
IAN
S
WO
RK
ERS
INTE
RR
OG
ATIV
EPE
RS
PE
CTIV
E
AU
DIE
NC
EPE
RS
PE
CTIV
ES
TAR
GE
TC
ON
TRIB
UTO
RS
TAR
GE
TD
OM
AIN
S
ARC
HITE
CTS
STR
ATE
GIS
TS
INVE
NTO
RY
PRO
CE
SS
NETW
OR
KO
RG
AN
IZATIO
NTIM
ING
MO
TIVATIO
N
Product (Instances)Product (Instances)
Requirem
ents (Concepts)
Requirem
ents (Concepts)
Scope (Boundaries)
Scope (Boundaries)
Part (Configurations)
Part (Configurations)
Design (Logic)
Design (Logic)
Plan (Physics)Plan (Physics)
PerspectivesH
OW
WH
ER
EW
HY
WH
EN
WH
O
© 1990-2007 John A
. Zachman, Zachm
an International
SCO
PE
BUS
INES
S
SYSTEM
TECH
- N
OLO
GY
CO
MP
ON
ENT
OPE
RATIO
NS
WH
AT
HO
W
EXEC
UTIVE
LEAD
ER
S
ENG
INEER
S
WO
RK
ER
S
WH
YW
HEN
WH
OIN
TERR
OG
ATIVE
PERSPEC
TIVE
AUD
IENC
EPER
SPECTIVES
TARG
ETC
ON
TRIBU
TOR
S
TARG
ETD
OM
AINS
ARC
HITE
CTS
STRA
TEG
ISTS
Definition
Definition
Representation
Representation
SpecificationSpecification
InstantiationInstantiation
Identification Identification
Configuration
Configuration
PR
OC
ESS
NE
TWO
RK
OR
GA
NIZA
TION
TIMIN
GM
OTIVATIO
NIN
VEN
TOR
Y
Reification
TECH
NIC
IANS
WH
ER
E
© 1990-2007 John A
. Zachman, Zachm
an International
"Architecture" In General
"Architecture" (for anything) would be the total set of descriptive representations (models) relevant for describing a complex object such that it can be created and that constitute a baseline for changing the object after it has been instantiated. The relevant descriptive representations would necessarily have to include all the intersections between: the "Abstractions": A. Bills of Material (What) B. Functional Specs (How) C. Drawings (Where) D. Operating Instructions (Who) E. Timing Diagrams (When) F. Design Objectives (Why) and the Perspectives: 1. Scoping Boundaries (Identification) 2. Requirement Concepts (Definition) 3. Design Logic (Representation) 4. Plan Physics (Specification) 5. Part Configurations (Configuration) resulting in the 6. Product Instances (Instantiation)
© 2007 John A. Zachman, Zachman International
"Enterprise Architecture"Therefore "Enterprise Architecture" would be the total set of descriptive representations (models) relevant for describing an Enterprise, that is, the descriptive representations required to create (a coherent, optimal) Enterprise and required to serve as a baseline for changing the Enterprise once it is created. The total set of relevant descriptive representations would necessarily have to include all the intersections between the Abstractions: A. Inventory Models (Bills of Material) B. Process Models (Functional Specs) C. Geographic Models (Drawings) D. Work Flow Models (Operating Instructions) E. Cyclical Models (Timing Diagrams) F. Objective Models (Design Objectives) and the Perspectives: 1. Scope Boundaries (Scoping Boundaries) 2. Business Models (Requirement Concepts) 3. System Models (Design Logic) 4. Technology Models (Plan Physics) 5. Tooling Configurations (Part Configurations) resulting in the 6. The Enterprise Implementation (Product Instance)
© 2007 John A. Zachman, Zachman International
"Enterprise Architecture"The total set would necessarily have to include Abstractions: WHAT Inventory Models equal Bills of Materials (Entity Models and Data Models ARE Bills of Material) HOW Process Models equal Functional Specs (Transformation Models) WHERE Network Models equal Drawings (Geographic Models) (Geometry) (Distribution Models) WHO Organization Models equal Operating Instructions (Work Flow Models) (Presentation Architecture) WHEN Timing Models equal Timing Diagrams (Control Structures) (Cyclical Models) (Dynamics Models) WHY Motivation Models equal Design Objectives
© 2007 John A. Zachman, Zachman International
EN
GIN
EER
S
SCO
PE
BUS
INESS
SYSTEM
TECH
- N
OLO
GY
CO
MPO
NEN
T
OP
ERATIO
NS
WH
AT
HO
WW
HER
E
EXEC
UTIV
ELEAD
ERS
WH
YW
HEN
WH
OIN
TERR
OG
ATIVE
PE
RS
PE
CTIV
E
AU
DIE
NC
EP
ER
SP
EC
TIVE
S
TAR
GE
TC
ON
TRIB
UTO
RS
TAR
GE
TD
OM
AIN
S
ARC
HITE
CTS
TECH
NIC
IAN
S
WO
RKER
S
STR
ATEG
ISTS
Inventory Models equal Bills of MaterialInventory Models equal Bills of Material
INVEN
TOR
YP
RO
CES
SN
ETWO
RK
OR
GAN
IZATION
TIMIN
GM
OTIVATIO
N
Process Models equal Functional SpecsProcess Models equal Functional Specs
Network Models equals DrawingsNetwork Models equals Drawings
Organization Models equal Operating InstructionsOrganization Models equal Operating Instructions
Timing Models equal Timing DiagramsTiming Models equal Timing Diagrams
Motivation Models equal Design Objectives Motivation Models equal Design Objectives
Abstractions
© 1990-2007 John A
. Zachman, Zachm
an International
"Enterprise Architecture"The total set would necessarily have to include Perspectives: STRATEGISTS Scope Boundaries equal Scope Boundaries ("CONOPS" or Concepts Package) EXECUTIVE LEADERS Business Models equal Requirement Concepts (Concepts Models) (Customer's Usage) ("Computation Independent") ARCHITECTS System Models equal Design Logic (Logic Models) (Engineering Descriptions) ("Platform Independent") ENGINEERS Technology Models equal Plan Physics (Physics Models) (Mfg. Eng. Descriptions) ("Platform Specific") TECHNICIANS Tooling Configurations equal Part Configurations (Vendor Product Specific) (Machine Tool Specific) WORKERS Enterprise Implementation equals Product Instance (Operations Instances)
© 2007 John A. Zachman, Zachman International
ENG
INEER
S
SC
OPE
BU
SINESS
SYS
TEM
TECH
- N
OLO
GY
CO
MP
ON
ENT
OPER
ATIO
NS
WH
AT
EXEC
UTIVE
LEAD
ERS
TEC
HN
ICIAN
S
WO
RKE
RS
INTER
RO
GATIVE
PERSPEC
TIVE
AUD
IENC
EPER
SPEC
TIVES
TARG
ETC
ON
TRIBU
TOR
S
TAR
GET
DO
MAIN
S
AR
CH
ITEC
TS
STRATEG
ISTS
INVE
NTO
RY
PRO
CES
SN
ETWO
RK
OR
GA
NIZATIO
NTIM
ING
MO
TIVATIO
N
Enterprise Implem
entation equals Product InstancesEnterprise Im
plementation equals Product Instances
Business M
odels equal Requirem
ent Concepts
Business M
odels equal Requirem
ent Concepts
Scope Boundaries equals Scope B
oundariesScope B
oundaries equals Scope Boundaries
Tooling Configurations equal Part C
onfigurationsTooling C
onfigurations equal Part Configurations
Systems M
odels equal Design Logic
Systems M
odels equal Design Logic
Technology Models equal Plan Physics
Technology Models equal Plan Physics
PerspectivesH
OW
WH
ER
EW
HY
WH
ENW
HO
© 1990-2007 John A
. Zachman, Zachm
an International
WH
ATH
OW
WH
ER
E
EXE
CU
TIVELEA
DER
S
AR
CH
ITECTS
EN
GIN
EER
S
TEC
HN
ICIA
NS
WO
RK
ERS
WH
YW
HEN
WH
OSTR
ATE
GIS
TS
TARG
ET D
OM
AINS
TARG
ET
CO
NTR
IBU
TOR
S
AUD
IEN
CE
PER
SP
ECTIV
ES
INTE
RR
OG
ATIVE
PER
SPE
CTIV
ES
ZAC
HM
AN
ENTER
PRISE FR
AM
EWO
RK
SC
OPE
BUSIN
ESS
SYSTEM
TEC
H-
NO
LOG
IES
CO
MP
ON
ENTS
OPER
ATION
S
TIMIN
G ID
EN
TIFICATIO
N LIS
T
TIMIN
G TYP
ES
NE
TWO
RK
IDEN
TIFICA
TION
LIST
MO
TIVATIO
N ID
EN
TIFICA
TION
LIST
OR
GAN
IZATION
IDEN
TIFICATIO
N LIS
T
NE
TWO
RK
TYPES
OR
GA
NIZA
TION
TYPES
MO
TIVATIO
N TYP
ES
TIMIN
G R
EP
RE
SEN
TATIO
N
SYS
TEM
CYC
LES
YSTE
M M
OM
ENT
TIMIN
G S
PEC
IFICA
TION
TIMIN
G C
ON
FIGU
RA
TION
TEC
HN
OLO
GY C
YCLE
TEC
HN
OLO
GY M
OM
EN
T
CO
MP
ON
EN
T CYC
LEC
OM
PON
ENT M
OM
EN
T
TIMIN
G IN
STAN
TIATIO
N
OP
ER
ATIO
NS
CYC
LEO
PER
ATION
S M
OM
EN
T
BU
SIN
ESS
CYC
LEB
US
INE
SS M
OM
EN
T
TIMIN
G D
EFINITIO
N
BU
SIN
ESS
EN
DB
US
INE
SS R
OLE
BU
SIN
ESS
LOC
ATIO
NB
US
INES
S W
OR
KB
USIN
ES
S CO
NN
ECTIO
NB
US
INE
SS M
EAN
S
SYSTEM
EN
DSYS
TEM
RO
LES
YSTE
M LO
CA
TION
SYS
TEM
S W
OR
KS
YSTEM C
ON
NE
CTIO
NS
YSTE
M M
EA
NS
TECH
NO
LOG
Y EN
DTE
CH
NO
LOG
Y RO
LETE
CH
NO
LOG
Y LOC
ATIO
NTEC
HN
OLO
GY W
OR
KTE
CH
NO
LOG
Y CO
NN
ECTIO
NTE
CH
NO
LOG
Y ME
AN
S
CO
MP
ON
EN
T END
CO
MPO
NEN
T RO
LEC
OM
PO
NE
NT LO
CA
TION
CO
MP
ON
EN
T WO
RK
CO
MP
ON
EN
T CO
NN
EC
TION
CO
MP
ON
EN
T MEA
NS
OP
ER
ATION
S EN
DO
PE
RA
TION
S R
OLE
OP
ER
ATIO
NS LO
CATIO
NO
PE
RA
TION
S W
OR
KO
PE
RA
TION
S C
ON
NE
CTIO
NO
PE
RA
TION
S M
EA
NS
OR
GA
NIZA
TION
DEFIN
ITION
NE
TWO
RK
DEFIN
ITION
MO
TIVA
TION
DEFIN
ITION
OR
GA
NIZA
TION
RE
PRE
SE
NTA
TION
NE
TWO
RK
RE
PR
ES
ENTATIO
N M
OTIV
ATION
R
EPR
ES
EN
TATIO
N
OR
GA
NIZA
TION
S
PEC
IFICA
TION
NE
TWO
RK
SPE
CIFIC
ATIO
NM
OTIV
ATION
SPE
CIFIC
ATIO
N
OR
GA
NIZA
TION
CO
NFIG
UR
ATIO
NN
ETW
OR
K C
ON
FIGU
RA
TION
MO
TIVATIO
N C
ON
FIGU
RA
TION
OR
GA
NIZA
TION
INSTA
NTIATIO
NN
ETW
OR
K IN
STANTIATIO
NM
OTIVA
TION
INS
TAN
TIATIO
N
e.g..e.g..
e.g..e.g..
e.g..e.g..
e.g..
e.g..e.g..
e.g..e.g..
e.g..e.g..
e.g..
e.g..e.g..
e.g..e.g..
e.g..e.g..
e.g..
2010 John A. Zachm
an, Zachman International
c
INV
EN
TOR
YP
RO
CE
SS
NE
TWO
RK
OR
GA
NIZA
TION
TIMIN
GM
OTIV
ATIO
N
PR
OC
ES
S IDE
NTIFIC
ATIO
N LIS
T
BU
SIN
ESS
TRAN
SFOR
MB
US
INE
SS E
NTITY
BUSIN
ES
S IN
PU
TB
US
INES
S R
ELA
TION
SHIP
SYSTE
M TR
AN
SFO
RM
SYSTEM
EN
TITYSYS
TEM IN
PU
T SYS
TEM
RELA
TION
SH
IP
TEC
HN
OLO
GY E
NTITY
TEC
HN
OLO
GY R
ELA
TION
SH
IP
CO
MPO
NE
NT TR
AN
SFO
RM
CO
MPO
NE
NT EN
TITYC
OM
PO
NE
NT IN
PU
TC
OM
PON
EN
T RE
LATIO
NSH
IP
OP
ER
ATIO
NS
TRA
NSFO
RM
OP
ER
ATIO
NS
EN
TITYO
PE
RA
TION
S IN
PU
TO
PE
RATIO
NS
RE
LATIO
NSH
IP
PR
OC
ES
S DE
FINITIO
NIN
VEN
TOR
Y DE
FINITIO
N
PR
OC
ESS
RE
PR
ESE
NTA
TION
INV
ENTO
RY R
EP
RE
SEN
TATIO
N
PR
OC
ESS
SP
ECIFIC
ATION
INV
EN
TOR
Y SP
EC
IFICA
TION
PR
OC
ES
S CO
NFIG
UR
ATIO
NIN
VE
NTO
RY C
ON
FIGU
RA
TION
PRO
CE
SS IN
STA
NTIA
TION
INV
EN
TOR
Y INS
TAN
TIATIO
N
INV
ENTO
RY ID
EN
TIFICA
TION
LIST
TEC
HN
OLO
GY TR
ANS
FOR
MTE
CH
NO
LOG
Y INPU
T
INV
EN
TOR
Y TYPE
SP
RO
CE
SS TYP
ES
TM
T H E E N
T E R P R
I S E
E N T E R
P R I S E A
R C
H I T E C
T U R
E
© 2010 John A. Zachman, Zachman International
Architecture Is ArchitectureI learned about architecture for Enterprises by looking atarchitecture for: Airplanes, Buildings, Locomotives, Computers, ... Complex Industrial Products
It is all the same ... Bills of Material, Functional Specs, Drawings, ... etc. Requirements, Schematics, Blueprints, ... etc.
ENTERPRISES have: Bills of Material, Functional Specs, Drawings, ... etc.ENTERPRISES have: Requirements, Schematics, Blueprints, ... etc.
The Engineering Design Artifacts (the descriptive representations of anything) fall into a two dimensional classification system: A. The focus of the description (Abstraction) (What, How, Where, Who, When, Why) B. The usage of the description (Perspective) (Owner, Designer, Builder)
© 2007 John A. Zachman, Zachman International
Architecture Is Architecture
© 2007 John A. Zachman, Zachman International
I simply put Enterprise names on the same descriptive representations relevant for describing anything.
Why would anyone think that the descriptions of an Enterprise are going to be any different from the descriptions of anything else humanity has ever described?
ARCHITECTURE IS ARCHITECTURE IS ARCHITECTURE
I don't think Enterprise Architecture is arbitrary ... and it is not negotiable.My opinion is, we ought to accept the definitions of Architecture that the older disciplines of Architecture and Construction, Engineering and Manufacturing haveestablished and focus our energy on learning how to use them to actually engineer Enterprises.
Ontology
© 2008 John A. Zachman, Zachman International
The Zachman Framework schema technically is an 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, 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 whatever or whatever).
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 existence - 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 a Structure.
Process
© 2009 John A. Zachman, Zachman International
Add Bleach to an Alkali and it is transformed into Saltwater.
A Process TRANSFORMS something.
This is a Process:Standard periodic table
Group ? 1 2 3 4 5 6 7 8 9 10 11 12 13 1 4 1 5 16 17 18? Period
1 1 H 2
He
2 3 L i
4 Be 5
B 6C
7N
8 O
9F
10Ne
3 11 Na
12Mg 13
Al 1 4Si
1 5P
16S
17Cl
18Ar
4 19 K
20Ca
21Sc
2 2Ti
23V
24C r
25Mn
26Fe
27Co
28Ni
29Cu
30Zn
31Ga
3 2Ge
3 3As
34Se
35Br
36Kr
5 37 Rb
38Sr
39Y
4 0Zr
41Nb
42Mo
43Tc
44Ru
45Rh
46Pd
47Ag
48Cd
49In
5 0Sn
5 1Sb
52Te
53I
54Xe
6 55 Cs
56Ba
*
7 2Hf
73Ta
74W
75Re
76Os
77Ir
78Pt
79Au
80Hg
81Tl
8 2Pb
8 3Bi
84Po
85At
86Rn
7 87 Fr
88Ra
**
10 4Rf
10 5Db
106Sg
107Bh
108Hs
109Mt
110Ds
111Rg
112Uub
1 13Uut
1 14U uq
11 5Uu p
116Uuh
117Uu s
118Uuo
* Lanthanide s 5 7L a
58Ce
59Pr
60Nd
61Pm
62Sm
63Eu
64Gd
65Tb
66Dy
6 7Ho
6 8Er
69Tm
70Yb
71Lu
** Actinide s 8 9Ac
90Th
91Pa
92U
93Np
94Pu
95Am
96Cm
97Bk
98Cf
9 9Es
10 0Fm
101Md
102No
103Lr
Ontology
This is a Structure, an ontological structure ... a fixed,structured set of elemental components that exist ofwhich any and every compound must be composed.
The Periodic Table provides precise DEFINITION.© 2009 John A. Zachman, Zachman International
A Structure DEFINES something.
This is a Structure:
HCl + NaOH --> NaCl + H2O
These are elements
These arecompounds
Hydrochloric Acid
SodiumHydroxide Water
SodiumChloride (salt)
Hydrogen Chlorine
Sodium Oxygen Hydrogen
Sodium Chlorine
2 Hydrogens Oxygen
(Elements come from the Ontology - finite)
(Compounds are virtually infinite)
Chemistry - A Science
A Process based on an ONTOLOGICAL structurewill be repeatable and predictable - A SCIENCE.
© 2009 John A. Zachman, Zachman International
This is a PROCESS:
A Process TRANSFORMS something.
© 2009 John A. Zachman, Zachman International
A Process with no ontological structure is ad hoc, fixedand dependent on practitioner skills. This is NOT a science. It is ALCHEMY, a "practice".
Process
Add Bleach to an Alkali and it is transformed into Saltwater.
A Process TRANSFORMS something.
This is a Process:
Standard periodic table Group ? 1 2 3 4 5 6 7 8 9 10 11 12 13 1 4 1 5 16 17 18 ? Period
1 1 H 2
He
2 3 L i
4 Be
5B
6C
7N
8O
9F
10Ne
3 11 Na
12 Mg
13Al
1 4Si
1 5P
16S
17Cl
18A r
4 19 K
20 Ca
21 Sc
2 2 Ti
23 V
24 C r
25 Mn
26Fe
27Co
28Ni
29Cu
30Zn
31Ga
3 2Ge
3 3As
34Se
35Br
36K r
5 37 Rb
38 S r
39 Y
4 0 Zr
41 Nb
42 Mo
43 Tc
44Ru
45Rh
46Pd
47Ag
48Cd
49In
5 0Sn
5 1Sb
52Te
53I
54Xe
6 55 Cs
56 Ba
*
7 2 Hf
73 Ta
74 W
75 Re
76Os
77Ir
78Pt
79Au
80Hg
81Tl
8 2Pb
8 3Bi
84Po
85At
86Rn
7 87 Fr
88 Ra
**
10 4 Rf
10 5 Db
106 Sg
107 Bh
108Hs
109Mt
110Ds
111Rg
112Uub
1 13Uut
1 14U uq
11 5Uu p
116Uuh
117Uu s
118Uuo
* Lanthanide s 5 7 L a
58 Ce
59 Pr
60 Nd
61Pm
62Sm
63Eu
64Gd
65Tb
66Dy
6 7Ho
6 8Er
69Tm
70Yb
71Lu
** Actinide s 8 9 Ac
90 Th
91 Pa
92 U
93Np
94Pu
95Am
96Cm
97Bk
98Cf
9 9Es
10 0Fm
101Md
102No
103Lr
HCl + NaOH --> NaCl + H2O
Hydrochloric Acid
SodiumHydroxide
Water SodiumChloride (salt)
Hydrogen Chlorine
Sodium Oxygen Hydrogen
Sodium Chlorine
2 Hydrogens Oxygen
An Ontology
A Process
IS NOT
and a Process IS NOT an Ontology.
Ontology vs Process
© 2009 John A. Zachman, Zachman International
A reasonable metaphor for the Framework is the Periodic Table. The Periodic Table is an ontology ... a schema ... a normalized schema ... one element goes in one and only one cell. The Periodic Table doesn't do anything. It reflects nature. The Periodic Table (an ontology) is used by Chemists (practitioners) to define a Process (a methodology) for producing compounds (results, implementations, composites). If an alchemist 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 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 experience (heuristics). The process (methodology) will be fixed (not changeable) and the alchemist will forever remain an alchemist.
Practitioners (methodologists) are constrained by time and results.Theoreticians (scientists) are constrained by natural laws and integrity.
The Periodic Table Metaphor
2008 John A. Zachman, Zachman Internationalc
Before Mendeleev figured out the Periodic table, Alchemists (practitioners) could create compounds based on their experience ... whatever worked. After Mendeleev figured out the Periodic Table, Chemistry became a science. Creating compounds became predictable and repeatable based on the natural laws (Physics) expressed in the Periodic Table. Within 50 years, the Chemists and Physicists (practitioners) were splitting atoms.
If I am right that Architecture is Architecture is Architecture, and if my work understanding the underlying primitives (elements) of Architecture correctly reflects the natural laws of classification and has integrity, maybe my Framework will form the basis for making Enterprise Architecture a science ... and maybe in 50 years, the methodologists (practitioners) will be able to engineer Enterprises to be assembled to order from reusable "primitive" components dynamically. I don't know. I hope so. We'll probably know in 50 years.
2007 John A. Zachman, Zachman Internationalc
The Periodic Table Metaphor The Framework Is a SchemaThe Fmwrk is a two-dimensional classification system for ENTERPRISE descriptive representations NOT I/S.
The classification scheme for each axis grew up quite independently from the Framework application.
The classification for each axis is: a. Comprehensive b. Non-redundant
Therefore, each cell of the Framework is: a. Unique
b. "Primitive" (one single Abstraction by one single Perspective)
and the total set of cells is complete.
The Framework logic is universal, independent of its application - totally neutral relative to methods/tools.
The Framework is a "normalized" schema ... ... NOT a matrix. That's what makes it a good analytical tool.
© 2001-2006 John A. Zachman, Zachman International
Enterprise Architecture
Conclusions
© 2010 John A. Zachman, Zachman International
1965 Systems Problems
1. Didn't meet Requirements. (not "aligned")2. The data was no good:
Not consistent from system to system.Not accurate.Not accessible.Too late.
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)
© 2004-2006 John A. Zachman, Zachman International
2011 Systems Problems
1. Don't meet Requirements. (not "aligned")2. The data is no good:
Not consistent from system to system.Not accurate.Not accessible.Too late.
3. Can't change the system. (Inflexible)4. Can't change the technology. (Not adaptable)5. Can't change the business. (Can't change the system or the technology so can't change business.)6. Little new development (80% $ for maintenance)7. Takes too long.8. Costs too much.9. Always over budget.10. Always missed schedules.11. IT budget out of control.12. Too complicated - can't understand it, can't manage it.13. Just frustrating.
(Adapted from Doug Erickson)
© 2004-2006 John A. Zachman, Zachman International
It's Funny ...COBOL didn't fix those problems!MVS didn't fix those problems!Virtual Memory didn't fix those problems!IMS, DB2, Oracle, Sybase, Access, Fortran, PL/1, ADA, C++, Visual Basic, JAVA 2, 360's, 390's, MPP's, DEC VAX's, H200's, Crays, PC's, MAC's, Distributed Processing, didn't fix those problems!Word, Excel, Powerpoint, Outlook Express, eMAIL, DOS, Windows 95, 98, 2000, NT, ME, XP, Unix, Linux, Object 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,Rochade, Platinum, Design Bank, Data Warehouse, SAP, Baan, Peoplesoft, Oracle Financials, BSP, ISP, EAP, EAI didn't fix those problems!And, I doubt that Web Services, .Net, Websphere, Agile Programming, Service Oriented Architecture or Component Development (whatever that is) is going to fix the problems.
IT MAKES ONE WONDER IF THERE ACTUALLYIS A TECHNICAL SOLUTION TO THE PROBLEM!!!
© 2004-2006 John A. Zachman, Zachman International
Engineering Problem
I'm 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 Enterprise problem 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 plan would be to start building out models, PRIMITIVE models, 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