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


…but mapping doesn’t work so well in detail

10/04/23 © Tetradian 2007 12


…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


G.Governance

and Compliance

E.Opportunities

andSolutions

C.Develop


A.Architecture




H.Architecture

Change Management

B.Develop


D.Conduct

Gap-Analysis


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


G.Governance

and Compliance

E.Opportunities

andSolutions

C.Develop


A.Architecture




H.Architecture

Change Management

B.Develop


D.Conduct

Gap-Analysis


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


G.Governance

and Compliance

E.Opportunities

andSolutions

C.Develop


A.Architecture




H.Architecture

Change Management

B.Develop


D.Conduct

Gap-Analysis


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


G.Governance

and Compliance

E.Opportunities

andSolutions

C.Develop


A.Architecture




H.Architecture

Change Management

B.Develop


D.Conduct

Gap-Analysis


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


G.Governance

and Compliance

E.Opportunities

andSolutions

C.Develop


A.Architecture




H.Architecture

Change Management

B.Develop


D.Conduct

Gap-Analysis


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


G.Governance

and Compliance

E.Opportunities

andSolutions

C.Develop


A.Architecture




H.Architecture

Change Management

B.Develop


D.Conduct

Gap-Analysis


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


G.Governance

and Compliance

E.Opportunities

andSolutions

C.Develop


A.Architecture




H.Architecture

Change Management

B.Develop


D.Conduct

Gap-Analysis


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


G.Governance

and Compliance

E.Opportunities

andSolutions

C.Develop


A.Architecture




H.Architecture

Change Management

B.Develop


D.Conduct

Gap-Analysis


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


G.Governance

and Compliance

E.Opportunities

andSolutions

C.Develop


A.Architecture




H.Architecture

Change Management

B.Develop


D.Conduct

Gap-Analysis


10/04/23 © Tetradian 2007 29

Phase B: Current-state architecture [2] Step 3: create/update architecture models


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


G.Governance

and Compliance

E.Opportunities

andSolutions

C.Develop


A.Architecture




H.Architecture

Change Management

B.Develop


D.Conduct

Gap-Analysis


10/04/23 © Tetradian 2007 30

Phase B: Current-state architecture [4] Step 4: update architecture repository


merge any new or amended primitives into the Architecture Building Blocks (ABBs)

merge any new or amended composites into the Solution Building Blocks (SBBs)


G.Governance

and Compliance

E.Opportunities

andSolutions

C.Develop


A.Architecture




H.Architecture

Change Management

B.Develop


D.Conduct

Gap-Analysis


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


G.Governance

and Compliance

E.Opportunities

andSolutions

C.Develop


A.Architecture




H.Architecture

Change Management

B.Develop


D.Conduct

Gap-Analysis


10/04/23 © Tetradian 2007 32

Phase B: Current-state architecture [6] Step 6: conduct checkpoint review


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


G.Governance

and Compliance

E.Opportunities

andSolutions

C.Develop


A.Architecture




H.Architecture

Change Management

B.Develop


D.Conduct

Gap-Analysis


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


G.Governance

and Compliance

E.Opportunities

andSolutions

C.Develop


A.Architecture




H.Architecture

Change Management

B.Develop


D.Conduct

Gap-Analysis


10/04/23 © Tetradian 2007 34

Phase D: Architecture gap-analysis Perform gap-analysis


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


G.Governance

and Compliance

E.Opportunities

andSolutions

C.Develop


A.Architecture




H.Architecture

Change Management

B.Develop


D.Conduct

Gap-Analysis


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


Phase H: change-management manage changes to architecture content etc



G.Governance

and Compliance

E.Opportunities

andSolutions

C.Develop


A.Architecture




H.Architecture

Change Management

B.Develop


D.Conduct

Gap-Analysis


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

Integrating Zachman and TOGAF-ADM

Business

zachman framework rows

zachman issues

zachman framework cells

zachmanframework grid

zachman framework http

framework zachman associates

businesscontext zachman

togaf adm