Integrating Zachman and TOGAF-ADM
-
Upload
tetradian-consulting -
Category
Business
-
view
9.749 -
download
3
description
Transcript of Integrating Zachman and TOGAF-ADM
the futures of business
10/04/23 © Tetradian 2007 1
Integrating Zachman and TOGAF-ADM
Tom Graves, Tetradian Consulting26 June 2007http://[email protected]
10/04/23 © Tetradian 2007 2
Zachman and TOGAF - overview
1. Zachman framework layered categories of architectural ‘primitives’
2. TOGAF Architecture Design Method consistent methodology for IT-architecture
3. Initial Zachman/TOGAF integration an inconsistent mix of perspectives
4. Resolving integration issues beyond IT and data – a missing dimension clarify enterprise-meaning of rows and columns
5. Revised Zachman/TOGAF integration consistent enterprise-architecture methodology
10/04/23 © Tetradian 2007 3
1. The Zachman-framework grid
© John A Zachman
Although the examples provided in each cell here are IT-oriented,the framework itself is not intended to be IT-specific
10/04/23 © Tetradian 2007 4
Zachman framework – rows and columns
Six rows (layers): R1: Contextual /scope
planner R2: Conceptual /business
owner R3: Logical /system
designer R4: Physical /technology
builder R5: Out-of-context
/components subcontractor
R6: Product /functioning enterprise
Six columns (categories): What / data
entity / relationship How / function
process / input-output Where / location
node / line Who / people
agent / capability When / time
event / cycle Why / motivation
ends / measures
Framework is a 6x6 grid of layers and categories:
10/04/23 © Tetradian 2007 5
Using Zachman – framework cells No explicit methodology with framework
(Zachman Associates do promise to provide one Real Soon Now)
Identify ‘primitives’ within a single cell examples: data-entity, master-schedule primitives are ‘architectural building blocks’
Identify ‘composites’ across cells examples: process-flow, software application composites are ‘solution building blocks’
Layers are levels of abstraction higher levels are implementation-independent higher levels change rarely, lower-levels often
10/04/23 © Tetradian 2007 6
Using Zachman – cell scope
Horizontal vs vertical scope (may be combined)
horizontal: level of detail
Zachman: ‘slice’
vertical: breadth of coverage across organisational units
Zachman: ‘sliver’
10/04/23 © Tetradian 2007 7
2. TOGAF Architectural Design Method Iterative, recursive cycles
cycle from Phase A to Phase H Requirements at the centre Three distinct emphases:
initial overview and governance expand the architecture:
extend ‘as-is’, develop ‘to-be’ layered views (Phase A to D)
identify and implement solutions choose solutions (Phase E) from ‘as-is’ to ‘to-be’ (Phase F) govern and manage change
(Phase G-H)
10/04/23 © Tetradian 2007 8
Using TOGAF ADM Establish overall principles, governance etc
‘Preliminary framework and principles’ For each iteration:
Set the iteration scope [Phase A] Review and update architecture [Phases B-D]
draw from and update the ‘Enterprise Continuum’: Architectural Building Blocks [ABBs – ‘primitives’] Solution Building Blocks [SBBs – ‘composites’]
Identify opportunities and solutions [Phase E] Drive and manage change [Phases F-H]
Emphasis almost exclusively on IT ‘business architecture’ is ‘anything not-IT’
‘business’ viewed only in terms of its impact on IT
10/04/23 © Tetradian 2007 9
3. Initial Zachman/TOGAF integration TOGAF provides methodology for Zachman
similar layering: Zachman: context » conceptual » logical » physical TOGAF: business » information systems » technology
TOGAF and Zachman cover similar domains business drivers, business process data, information, locations, applications technology implementation, networks, etc
TOGAF is mapped to Zachman see “ADM and the Zachman Framework”
http://www.opengroup.org/architecture/togaf8-doc/arch/chap39.html
10/04/23 © Tetradian 2007 10
Map between TOGAF and Zachman [1]
TOGAF/Zachman seem to map well overall…
10/04/23 © Tetradian 2007 11
Map between TOGAF and Zachman [2]
…but mapping doesn’t work so well in detail
10/04/23 © Tetradian 2007 12
Map between TOGAF and Zachman [3]
…especially for Phase C1, ‘Data Architecture’
10/04/23 © Tetradian 2007 13
4. Resolving the mismatch Both Zachman and TOGAF are IT-centric
need to expand to cover non-IT business-context Zachman has internal inconsistencies
‘What’ column described as ‘Data’, ‘Meaning’ etc cause: additional dimension is required
i.e. ‘segment’ depth vs ‘slice’ height, ‘sliver’ breadth
TOGAF filters everything through an IT lens IT-only view sees Zachman ‘What’ only as ‘Data’ C2: ‘Application’, D: ‘Technology’ are composites
mismatch: mixed primitives, composites, layers Phases B-D are separate views, not true phases
10/04/23 © Tetradian 2007 14
Resolve Zachman issues Expand base-metaphor for framework
enterprise as ‘organism’, not ‘machine’ organisation-change can be guided but not ‘engineered’
Expand the model structure to support this Add an R0 row for core-principles etc
maps to TOGAF initial ‘Preliminary’ phase
Add ‘depth’ dimension to clarify asset-types physical ‘things’: tangible objects, etc conceptual ‘things’: information, data etc relational ‘things’: business relationships etc aspirational ‘things’: identity, purpose, morale etc plus an ‘overall integration’ layer
will relate to specific columns (e.g. ‘What’/physical) but they do not map exactly – is a distinct dimension
10/04/23 © Tetradian 2007 15
Zachman framework: amended rows R0: (implied)
common to all columns: vision, principles, key strategies, etc R1: Contextual / ‘scope’ [planner]
lists of key items relevant to enterprise R2: Conceptual / ‘business’ [owner]
summaries of key items and relations R3: Logical / ‘system’ [designer]
items independent of any implementation R4: Physical / ‘technology’ [builder]
items linked to the specified implementation R5: Out-of-context / ‘components’ [subcontractor]
items as specified in work-instructions, program-code etc R6: Product / ‘functioning enterprise’
instances of each item occurring in the day-to-day or minute-to-minute running of the enterprise
10/04/23 © Tetradian 2007 16
Zachman framework: amended columns What : entity / relationship
assets: physical things, data, relations, values, financials etc How : function / input-output
machine-based, IT-based or manual processes, etc Where : node / line
locations in physical, virtual or social space, etc Who : agent / capability
human, IT or machine ‘actors’ and their skills / capabilities When : event / cycle
any event that starts, ends or intervenes in a business-process, on timescales from microseconds to decades
Why : ends / measures decisions, requirements, business-rules, etc
Also measures across these: inventory, yield, capability, performance, time, state-of-change etc
10/04/23 © Tetradian 2007 17
Resolve TOGAF-ADM issues TOGAF ‘Preliminary’ phase defines initial R0 Identify scope for iteration in Phase A
i.e. ‘slice’ detail, ‘sliver’ org-scope, ‘segment’ etc Remap Phases B-D to architecture phases
Phase B: identify ‘as-is’ architecture Phase C: develop ‘to-be’ architecture Phase D: gap-analysis from ‘as-is’ to ‘to-be’
Amend ADM IT-specific terminology e.g. all possibilities of R4, not just networks etc
Amend steps to be consistent at all layers e.g. remove existing over-emphasis on Phase D
Phases E-H minor changes to broaden scope
10/04/23 © Tetradian 2007 18
5. Revised TOGAF-ADM methodology Do ‘Preliminary’ phase before anything else
may review at any time, but is not an iteration For each iteration
iterations may be for a project, context-change etc see TOGAF guide for input/output documents etc
Phase A: define purpose and scope Phases B-D: review ‘as-is’ and ‘to-be’ views Phase E: identify candidate solutions Phases F-H: identify, govern and guide change update requirements-repository at each step
Views are linked to amended Zachman additional R0 row, ‘depth’ dimension etc
10/04/23 © Tetradian 2007 19
Use TOGAF-ADM cycle for governance
RequirementsManagement
G.Governance
and Compliance
E.Opportunities
andSolutions
C.Develop
‘Future-State’ Architecture
A.Architecture
Iteration Scope and Purpose
Preliminary:Framework,
Principles and Core Content
H.Architecture
Change Management
B.Develop
‘Current-State’ Architecture
D.Conduct
Gap-Analysis
F.Migration Planning
Statement of Architecture Work (for iteration)
Stakeholder review for ‘current state’
Stakeholder review for ‘future state’
Gap-analysis / requirements review
Solution design review
Project plan review
Project architecture compliance
review
Benefits realisation
(‘lessons learned’ etc)
Architecture Charter
Governance-artefactsdefine methodology’sphase-boundaries
10/04/23 © Tetradian 2007 20
‘Preliminary’ phase [1] Identify core-principles etc for R0
business-drivers, business-goals – esp. ‘Vision’ Vision is always greater than the organisation itself
record item-list in repository may be best to record as ‘business-requirements’
Define key standards-documents Architecture Charter, Architecture Principles etc
Include key themes by reference documents for key strategies, business-policies security policy, OH&S policy, privacy policy,
environment policy, quality-system etc
RequirementsManagement
G.Governance
and Compliance
E.Opportunities
andSolutions
C.Develop
‘Future-State’ Architecture
A.Architecture
Iteration Scope and Purpose
Preliminary:Framework,
Principles and Core Content
H.Architecture
Change Management
B.Develop
‘Current-State’ Architecture
D.Conduct
Gap-Analysis
F.Migration Planning
10/04/23 © Tetradian 2007 21
‘Preliminary’ phase [2] For each Zachman column (cell) in R1:
use core-principles to suggest candidate items what: key ‘things’, physical and otherwise how: key processes, functions etc where: key locations, physical, virtual etc who: key actors/agents, organisations etc when: key events, cycles etc why: key continuing aims, strategies etc
record/amend cell’s item-list in repository repository may store in list- or graphic-form, but
must be possible to link to here from other layers
Note: content may be minimal at first pass content will also be developed in architecture
cycles
RequirementsManagement
G.Governance
and Compliance
E.Opportunities
andSolutions
C.Develop
‘Future-State’ Architecture
A.Architecture
Iteration Scope and Purpose
Preliminary:Framework,
Principles and Core Content
H.Architecture
Change Management
B.Develop
‘Current-State’ Architecture
D.Conduct
Gap-Analysis
F.Migration Planning
10/04/23 © Tetradian 2007 22
Phase A: Iteration Scope / Purpose [1] Identify business-purpose of iteration
e.g. support project, broader work-program etc
Identify Zachman vertical scope of iteration typically R2 to R3, sometimes also R4 for detail
For each Zachman row in iteration-scope identify ‘slice’ (level of detail) identify ‘sliver’ (coverage across organisation) identify ‘segment’ (categories of assets covered)
Document ‘Statement of Architecture Work’ (see TOGAF guide for details of document content)
sign-off document to begin architecture iteration
RequirementsManagement
G.Governance
and Compliance
E.Opportunities
andSolutions
C.Develop
‘Future-State’ Architecture
A.Architecture
Iteration Scope and Purpose
Preliminary:Framework,
Principles and Core Content
H.Architecture
Change Management
B.Develop
‘Current-State’ Architecture
D.Conduct
Gap-Analysis
F.Migration Planning
10/04/23 © Tetradian 2007 23
Phase A: Iteration Scope / Purpose [2] TOGAF ‘architectures’ are predefined
scopes i.e. prepackaged sets of Zachman ‘slices’
see “ADM and the Zachman Framework” http://www.opengroup.org/architecture/togaf8-doc/arch/chap39.html
‘Architectures’ emphasise different areas ‘Business Architecture’ (TOGAF Phase B)
emphasis on Zachman R2 ‘conceptual’ layer ‘Data Architecture’ (TOGAF Phase C1) and
‘Application Architecture’ (TOGAF Phase C2) emphasis on Zachman R3 ‘logical’ layer
‘Technology Architecture’ (TOGAF Phase D) emphasis on Zachman R4 ‘physical’ layer
RequirementsManagement
G.Governance
and Compliance
E.Opportunities
andSolutions
C.Develop
‘Future-State’ Architecture
A.Architecture
Iteration Scope and Purpose
Preliminary:Framework,
Principles and Core Content
H.Architecture
Change Management
B.Develop
‘Current-State’ Architecture
D.Conduct
Gap-Analysis
F.Migration Planning
10/04/23 © Tetradian 2007 24
Phase A: Iteration Scope / Purpose [3] Example: Data Architecture
for this iteration-focus, we’d set ‘slices’ as follows:
Explore ‘What » virtual’ (data) column in depth
Confirm validity of ‘Contextual’ layer
Limited interest in ‘Conceptual’ layer
outside of Data scope
Detailed focus across all of ‘Logical’ layer
Little to no interestin ‘Physical’ layer
outside of Data scope
RequirementsManagement
G.Governance
and Compliance
E.Opportunities
andSolutions
C.Develop
‘Future-State’ Architecture
A.Architecture
Iteration Scope and Purpose
Preliminary:Framework,
Principles and Core Content
H.Architecture
Change Management
B.Develop
‘Current-State’ Architecture
D.Conduct
Gap-Analysis
F.Migration Planning
10/04/23 © Tetradian 2007 25
Phase A: Iteration Scope / Purpose [4] Example: Information Architecture
for this iteration-focus, we’d set ‘slices’ as follows:Explore ‘What’ column in depth –
both ‘virtual’ (data) and ‘relational’ (non-IT-based knowledge)
Confirm validity of ‘Contextual’ layer
Limited interest in ‘Conceptual’ layer
outside of Info scope
Detailed focus across all of ‘Logical’ layer
Little to no interest in ‘Physical’ layer
outside of Info scope
Explore ‘Why’ column (as business-rules) to derive business meaning
RequirementsManagement
G.Governance
and Compliance
E.Opportunities
andSolutions
C.Develop
‘Future-State’ Architecture
A.Architecture
Iteration Scope and Purpose
Preliminary:Framework,
Principles and Core Content
H.Architecture
Change Management
B.Develop
‘Current-State’ Architecture
D.Conduct
Gap-Analysis
F.Migration Planning
10/04/23 © Tetradian 2007 26
Phases B-D: Develop the architecture
…review links to primitives above
For each item in main emphasis…
…look below for implied primitives /
composites
Scan down columns to identify primitives
Scan across rows to identify composites
RequirementsManagement
G.Governance
and Compliance
E.Opportunities
andSolutions
C.Develop
‘Future-State’ Architecture
A.Architecture
Iteration Scope and Purpose
Preliminary:Framework,
Principles and Core Content
H.Architecture
Change Management
B.Develop
‘Current-State’ Architecture
D.Conduct
Gap-Analysis
F.Migration Planning
10/04/23 © Tetradian 2007 27
Phase B: Current-state architecture [1]
Preliminary: For each cell in R2 (‘Conceptual’ layer)
for each item-type in scope identify the ‘owner’ (person responsible for items)
TOGAF-ADM steps:(see also TOGAF guide, ‘Business architecture’, for more detail)
Step 1: develop baseline architecture note: this is Step 1 in TOGAF Phases B-D
if artefacts already exist for iteration-scope (e.g. repository content, requirements documents, process models etc), develop a summary ‘architecture’ as implied by these artefacts
RequirementsManagement
G.Governance
and Compliance
E.Opportunities
andSolutions
C.Develop
‘Future-State’ Architecture
A.Architecture
Iteration Scope and Purpose
Preliminary:Framework,
Principles and Core Content
H.Architecture
Change Management
B.Develop
‘Current-State’ Architecture
D.Conduct
Gap-Analysis
F.Migration Planning
10/04/23 © Tetradian 2007 28
Phase B: Current-state architecture [2] Step 2: select reference-models, views etc
note: this is Step 2 in TOGAF Phases B-D
identify any reference-models applying to scope e.g. select from repository any existing R2 / R3 / R4
reference-models matching the iteration-scope identify appropriate viewpoints
e.g. Operations, Finance, specific client-groups identify tools, techniques and model-types
matching the iteration-scope use mappings between model-types and Zachman
rows / columns etc to assist in this
RequirementsManagement
G.Governance
and Compliance
E.Opportunities
andSolutions
C.Develop
‘Future-State’ Architecture
A.Architecture
Iteration Scope and Purpose
Preliminary:Framework,
Principles and Core Content
H.Architecture
Change Management
B.Develop
‘Current-State’ Architecture
D.Conduct
Gap-Analysis
F.Migration Planning
10/04/23 © Tetradian 2007 29
Phase B: Current-state architecture [2] Step 3: create/update architecture models
note: this is Step 3 in TOGAF Phases B-D
for each viewpoint and cell, in iteration-scope identify additional ‘as-is’ primitives and their owners verify derivations from cell above (principles etc) summarise implied entities in cells below
e.g. logical data-entities implied by business-data objects to required detail, check relations with all R1 cells
i.e. TOGAF 3(v) validation tests e.g. requirements, motivation audit-trail etc
identify multi-cell composites e.g. business-patterns, business-unit maps etc
note that primitive might appear as lower-row composite
RequirementsManagement
G.Governance
and Compliance
E.Opportunities
andSolutions
C.Develop
‘Future-State’ Architecture
A.Architecture
Iteration Scope and Purpose
Preliminary:Framework,
Principles and Core Content
H.Architecture
Change Management
B.Develop
‘Current-State’ Architecture
D.Conduct
Gap-Analysis
F.Migration Planning
10/04/23 © Tetradian 2007 30
Phase B: Current-state architecture [4] Step 4: update architecture repository
note: this is Step 4 in TOGAF Phases B-D
merge any new or amended primitives into the Architecture Building Blocks (ABBs)
merge any new or amended composites into the Solution Building Blocks (SBBs)
RequirementsManagement
G.Governance
and Compliance
E.Opportunities
andSolutions
C.Develop
‘Future-State’ Architecture
A.Architecture
Iteration Scope and Purpose
Preliminary:Framework,
Principles and Core Content
H.Architecture
Change Management
B.Develop
‘Current-State’ Architecture
D.Conduct
Gap-Analysis
F.Migration Planning
10/04/23 © Tetradian 2007 31
Phase B: Current-state architecture [5] Step 5: review qualitative criteria
note: this is Step 6 in TOGAF Phases B-D note: not covered directly in Zachman
identify required qualitative criteria such as performance, costs, volumes
e.g. KPI/KSC sets for a ‘balanced scorecard’ cross-check with all R0 standards, policies etc
e.g. security, environment, OH&S
RequirementsManagement
G.Governance
and Compliance
E.Opportunities
andSolutions
C.Develop
‘Future-State’ Architecture
A.Architecture
Iteration Scope and Purpose
Preliminary:Framework,
Principles and Core Content
H.Architecture
Change Management
B.Develop
‘Current-State’ Architecture
D.Conduct
Gap-Analysis
F.Migration Planning
10/04/23 © Tetradian 2007 32
Phase B: Current-state architecture [6] Step 6: conduct checkpoint review
note: this is Step 5 in TOGAF Phases B-D
conduct formal stakeholder review of architecture
identify stakeholders from: iteration-scope as specified in Phase A item-owners as identified at start of this Phase additional item-owners identified in this Phase, step 3
RequirementsManagement
G.Governance
and Compliance
E.Opportunities
andSolutions
C.Develop
‘Future-State’ Architecture
A.Architecture
Iteration Scope and Purpose
Preliminary:Framework,
Principles and Core Content
H.Architecture
Change Management
B.Develop
‘Current-State’ Architecture
D.Conduct
Gap-Analysis
F.Migration Planning
10/04/23 © Tetradian 2007 33
Phase C: Future-state architecture Repeat steps 1-6 for ‘to-be’ architecture
note: this is Step 7 in TOGAF Phases B-D note: scope is same as identified / specified in Phase A
1. create ‘to-be’ baseline from artefacts in scope ‘to-be’ time-point is specified in Phase A
2. use same viewpoints etc as in Phase B3. from iteration-scope documents etc
for each viewpoint and cell in iteration-scope identify new or amended primitives and composites
4. merge into repository as ‘to-be’5. review amended criteria6. conduct formal checkpoint review
RequirementsManagement
G.Governance
and Compliance
E.Opportunities
andSolutions
C.Develop
‘Future-State’ Architecture
A.Architecture
Iteration Scope and Purpose
Preliminary:Framework,
Principles and Core Content
H.Architecture
Change Management
B.Develop
‘Current-State’ Architecture
D.Conduct
Gap-Analysis
F.Migration Planning
10/04/23 © Tetradian 2007 34
Phase D: Architecture gap-analysis Perform gap-analysis
note: this is Step 8 in TOGAF Phases B-D
compare ‘as-is’ to ‘to-be’ for gap-analysis matrix see TOGAF specification for matrix-structure details
compare primitives, composites etc identify, extract and document requirements
store gap-analysis requirements in repository document for Phase E opportunities/solutions
see TOGAF specification for documents / deliverables for this Phase
RequirementsManagement
G.Governance
and Compliance
E.Opportunities
andSolutions
C.Develop
‘Future-State’ Architecture
A.Architecture
Iteration Scope and Purpose
Preliminary:Framework,
Principles and Core Content
H.Architecture
Change Management
B.Develop
‘Current-State’ Architecture
D.Conduct
Gap-Analysis
F.Migration Planning
10/04/23 © Tetradian 2007 35
Phases E to H: architecture to practice
As per TOGAF-ADM, but less IT-specific Phase E: opportunities and solutions
use architecture to guide solution design see http://www.opengroup.org/architecture/togaf8-doc/arch/chap11.html
Phase F: migration-planning create ‘roadmap’ for iteration’s change
see http://www.opengroup.org/architecture/togaf8-doc/arch/chap12.html
Phase G: governance verify project’s architecture-compliance
see http://www.opengroup.org/architecture/togaf8-doc/arch/chap13.html
Phase H: change-management manage changes to architecture content etc
see http://www.opengroup.org/architecture/togaf8-doc/arch/chap14.html
RequirementsManagement
G.Governance
and Compliance
E.Opportunities
andSolutions
C.Develop
‘Future-State’ Architecture
A.Architecture
Iteration Scope and Purpose
Preliminary:Framework,
Principles and Core Content
H.Architecture
Change Management
B.Develop
‘Current-State’ Architecture
D.Conduct
Gap-Analysis
F.Migration Planning
10/04/23 © Tetradian 2007 36
Summary Zachman/TOGAF integration-issues
routine IT-centric use masks inconsistencies Revise Zachman for consistent categories
expand scope to architecture of full enterprise additional dimension for asset-types etc
Revise TOGAF for consistent methodology revised Phases B, C, D apply to any architecture some changes to other Phases to broaden scope
Methodology for enterprise architecture supports full enterprise scope – IT and beyond
the futures of business
10/04/23 © Tetradian 2007 37
More detail on amended Zachman
Rows, Columns and Segments
10/04/23 © Tetradian 2007 38
Notes: new R0 ‘Universal’ (enterprise) row Shared across all Zachman columns Represents the core drivers for enterprise
core Vision (as ultimate anchor for architecture) key architecture / governance principles
list of enterprise Values etc architectural principles e.g. ‘single source of truth’ core standards, strategies, policies etc
Provides upward anchor for all derivations e.g. requirements ultimately anchor to Vision also acts as ultimate anchor for quality-system
Small numbers of items usually described in text-form
10/04/23 © Tetradian 2007 39
Notes: revised R1 ‘Contextual’ row Split into respective Zachman columns
what, how, where, who, when, why also depth-layers (‘segments’): physical,
conceptual, relational, aspirational, integration etc usually primitives only – no composites
Lists of key items relevant to enterprise described in text-form or as objects on diagram
Provides anchor for conceptual level core functions as frames on Function Model,
key business-information as anchor for relational model, geographical regions, etc
No more than 10-20 items per list
10/04/23 © Tetradian 2007 40
Notes: revised R2 ‘Conceptual’ row Split into respective Zachman columns
may have composites across columns/segments e.g. org-chart is a composite: who, what, where
Summaries of key items and relations usually as objects and relationships on diagram
Links upward to R1 contextual level if there’s no R1 object to link to, it may need to
be added to the respective list Provides anchor for R3 logical level
top-level of standard model-types e.g. BPMN Around 30-100 items per Zachman cell
10/04/23 © Tetradian 2007 41
Notes: revised R3 ‘Logical’ row Split into respective Zachman columns
R2 items often expand to composites at R3 level Items independent of implementation
usually as objects and relationships on diagram composites modelled as links between diagrams
Links upward to R1 / R2 levels if there’s no R2 object to link to, it may need to
be added; likewise upward to R1 lists Provides anchor for R4 physical level
standard model-types e.g. BPMN, ER diagram From 60-100 items up per Zachman cell
10/04/23 © Tetradian 2007 42
Notes: revised R4 ‘Physical’ row Split into respective Zachman columns
R3 items usually as composites at R4 level Items are linked to implementation
model as objects and relationships on diagram composites modelled as links between diagrams
Links upward to R1 / R2 / R3 levels if there’s no R3 object to link to, it may need to
be added; likewise upward to R2 and R1 lists Provides anchor for R5 design » build
implementation-specific – e.g. database schema Any number of items per Zachman cell
10/04/23 © Tetradian 2007 43
Notes: unchanged R5 and R6 rows R5: Zachman ‘Detailed Representation’ row
detailed ‘master-instructions’ to implement architecture-items (e.g. software source-code, process work-instruction, etc)
derived from R4-level models but rarely represented direct in architecture
R6: Zachman ‘Functioning Enterprise’ row placeholder for all item-instances (e.g. every
data-item of a data-class, every occurrence of a business-activity, etc)
implied but rarely used in architecture-models
10/04/23 © Tetradian 2007 44
Example: organisation-chart R0: ‘the enterprise’ R1: major business units, roles, locations R2: main sub-units, roles, regions etc
links between units / sub-units as primitives highest-level org-chart as composite
R3: include cross-reports, dependencies head-quarters, regional units, infrastructure
R4: detail as implemented, roles only R5: names linked to nominal roles
‘the org-chart’ as shown at induction etc R6: names linked to all run-time roles
real-time changes e.g. day-shift roster
10/04/23 © Tetradian 2007 45
Example: software development life-cycle R0 » R1: (implied) R2: Conceptual Design Document
high-level requirements for system R3: System Requirements
high-level: may be implementation-independent R4: System Design Document
detail-level: fully implementation-dependent R5: Software source-code
rewrite for each change of technology etc R6: Executable code
includes instances generated at run-time
10/04/23 © Tetradian 2007 46
Example: ISO-9000:2000 quality-system R0: Vision (as ultimate anchor for quality-system)
R1 » R2: Policy high-level (values) to detail-level (linked to strategy)
R3 » R4: Procedure high-level: implementation-independent detail-level: more implementation-dependent
R5 » R6: Work-instruction rewrite for each change of technology etc
Same upward/downward dependencies work-instruction depends on / implies procedure,
which in turn implies policy, etc
10/04/23 © Tetradian 2007 47
Notes: new ‘depth’ dimension [1] Aim is to remove Zachman-cell ambiguity
e.g. is ‘What’-column objects, data or meaning? Zachman variously describes column as any of these...
Number of segments may vary per column usually ‘physical’, ‘conceptual’, ‘relational’,
‘aspirational’ – but may have more or less implied extra segment for integration between
other segments – e.g. financials Composites may occur between segments
e.g. R2/R3 abstract-function (‘service’) could be any mix of machine, IT and manual functions
resolved at R4 level as explicit implementation mix
10/04/23 © Tetradian 2007 48
Notes: new ‘depth’ dimension [2] ‘What’ column
physical things; data; links to people; meaning ‘How’ column
machine function; IT interface; business-meeting ‘Where’ column
geographic; virtual; social-network; value-web ‘Who’ column
machine; IT-system; person ‘When’ column
timescales – sub-seconds to days to decades ‘Why’ column
rule; best-practice; heuristic/guideline; principle
10/04/23 © Tetradian 2007 49
Notes: amended ‘What’ column Primitive: object / dependent relationships
Zachman definition: entity / relationship
Example model-types: physical assets:
parts-breakdown; bill of materials conceptual assets:
data-model; metadata-schema; model-definitions relational assets:
note: people are not ‘assets’ – the relationship with the person is the asset
business-relationships and relationship-types aspirational assets:
meaning-types (e.g. financials); morale etc types
10/04/23 © Tetradian 2007 50
Notes: amended ‘How’ column Primitive: function / inputs and outputs
Zachman definition: process / input-output (process is function sequence, hence process-flow may be a composite)
Example model-types: function model:
Functional Business Model; Business Systems Model cause-effect model:
‘fishbone’ diagram Six Sigma SIPOC model:
supplier, input, process, output, customer
10/04/23 © Tetradian 2007 51
Notes: amended ‘Where’ column Primitive: nodes of same type / link and
properties Zachman definition: node / line
(node-type is location; item at location is usually a ‘What’ entity)
Example model-types: geographic map:
literal map (guide-book), schematic (railway grid) etc IT network map:
network nodes and IP addresses social-network map:
nodes are people, lines are connections between people
10/04/23 © Tetradian 2007 52
Notes: amended ‘Who’ column Primitive: agent / capabilities
Zachman definition: agent / work (‘Who’ is misleading: agent may be a person, IT-unit or machine –
or a collective of any combination of these, such as a business unit) (many of Zachman’s examples here – e.g. workflow, org-chart etc –
are not primitives, but composites, usually with ‘How’)
Example model-types: skills-architecture:
capability-type and skills-level category (none: rule-based; low: causal context; medium: heuristic; high: principles/experience)
agent / skills / capabilities: machine: no-skill; IT: up to contextual / low-‘skill’;
human agent required for higher skill-levels
10/04/23 © Tetradian 2007 53
Notes: amended ‘When’ column Primitive: time-point / time-relationship
Zachman definition: event / cycle (an event occurs at a specific point in time; a ‘cycle’ is one of many
possible types of relationship within time) (timescales could vary anywhere from nanoseconds or less to
millennia or more)
Example model-types: project:
Gantt chart – events plus inter-dependencies business-cycle:
calendar – repeated and non-repeated business events
10/04/23 © Tetradian 2007 54
Notes: amended ‘Why’ column Primitive: ends / measures, dependencies
Zachman definition: ends / means (but: ‘means’ is more properly ‘How’ than ‘Why’) (‘measure’ identifies/confirms that the ‘end’ has been achieved)
Example model-types: requirements:
includes dependencies, conflicts, traceability audit-trail, test-conditions, priorities etc
decision: business-rules and relationships
decision-type: rule, best-practice, heuristic, principle
motivation: Business Motivation Model, Enterprise Direction etc
10/04/23 © Tetradian 2007 55
Notes: primitives and composites “Building implementations (composite models) and saying
you are doing ‘enterprise architecture’ (primitive models) is the worst possible architecture strategy” [John A Zachman]
Primitives are discrete architectural building-blocks are of only one type and one set of relations cannot be used on their own for implementation
Composites are structures to guide implementation
(‘solution building blocks’) are defined relationships between different
types of primitives at the same Zachman level
10/04/23 © Tetradian 2007 56
Notes: example composites R1: contextual
high-level tactics: ends (‘Why’) + means (‘How’)
R2: conceptual high-level service: business-function (‘How’) + agent
(‘Who’ » machine | IT | manual) + performance-indicators (data: ‘What’ » conceptual [¤ « ‘Why’])
R3: logical software pattern: function (‘How’ » virtual) + data (‘What’
» conceptual) + sequence (‘When’ » ‹timescale›)
R4: physical deployment map: IT unit (‘What’ » physical) + function
(‘How’ » virtual) + location (‘Where’ » physical) + IP address (‘Where’ » virtual)
Further reading (June 2009)Note: this presentation summarises earlier work (June 2007)
on a restructure of IT-oriented frameworks and methods for better alignment with whole-of-enterprise architecture
For updated versions, see: framework: http://tetradianbooks.com/ebook/silos_real-ea-frame-ref.pdf method: http://tetradianbooks.com/ebook/silos_real-ea-adm-ref.pdf
See also books: “Bridging the Silos: enterprise architecture for IT-architects”
info and sample chapters at http://tetradianbooks.com/2008/04/silos/ “Doing Enterprise Architecture: process and practice in the
real enterprise” info and sample chapters at http://tetradianbooks.com/2009/03/doing-ea/
For other enterprise architecture books by Tom Graves, see http://tetradianbooks.com/category/entarch/
10/04/23 © Tetradian 2007 57