Integrating Zachman and TOGAF-ADM

1. Integrating Zachman and TOGAF-ADM Tom Graves, Tetradian Consulting 26 June 2007 http://www.tetradian.com [email_address] 23/06/09 © Tetradian 2007

2. Zachman and TOGAF - overview <ul><li>Zachman framework </li></ul><ul><ul><li>layered categories of architectural ‘primitives’ </li></ul></ul><ul><li>TOGAF Architecture Design Method </li></ul><ul><ul><li>consistent methodology for IT-architecture </li></ul></ul><ul><li>Initial Zachman/TOGAF integration </li></ul><ul><ul><li>an inconsistent mix of perspectives </li></ul></ul><ul><li>Resolving integration issues </li></ul><ul><ul><li>beyond IT and data – a missing dimension </li></ul></ul><ul><ul><li>clarify enterprise-meaning of rows and columns </li></ul></ul><ul><li>Revised Zachman/TOGAF integration </li></ul><ul><ul><li>consistent enterprise -architecture methodology </li></ul></ul>23/06/09 © Tetradian 2007

3. 1. The Zachman-framework grid 23/06/09 © Tetradian 2007 © John A Zachman Although the examples provided in each cell here are IT-oriented, the framework itself is not intended to be IT-specific

4. Zachman framework – rows and columns <ul><li>Six rows (layers): </li></ul><ul><li>R1: Contextual /scope </li></ul><ul><ul><li>planner </li></ul></ul><ul><li>R2: Conceptual /business </li></ul><ul><ul><li>owner </li></ul></ul><ul><li>R3: Logical /system </li></ul><ul><ul><li>designer </li></ul></ul><ul><li>R4: Physical /technology </li></ul><ul><ul><li>builder </li></ul></ul><ul><li>R5: Out-of-context /components </li></ul><ul><ul><li>subcontractor </li></ul></ul><ul><li>R6: Product /functioning enterprise </li></ul>23/06/09 © Tetradian 2007 <ul><li>Six columns (categories): </li></ul><ul><li>What / data </li></ul><ul><ul><li>entity / relationship </li></ul></ul><ul><li>How / function </li></ul><ul><ul><li>process / input-output </li></ul></ul><ul><li>Where / location </li></ul><ul><ul><li>node / line </li></ul></ul><ul><li>Who / people </li></ul><ul><ul><li>agent / capability </li></ul></ul><ul><li>When / time </li></ul><ul><ul><li>event / cycle </li></ul></ul><ul><li>Why / motivation </li></ul><ul><ul><li>ends / measures </li></ul></ul>Framework is a 6x6 grid of layers and categories:

5. Using Zachman – framework cells <ul><li>No explicit methodology with framework </li></ul><ul><ul><li>(Zachman Associates do promise to provide one Real Soon Now) </li></ul></ul><ul><li>Identify ‘primitives’ within a single cell </li></ul><ul><ul><li>examples : data-entity, master-schedule </li></ul></ul><ul><ul><li>primitives are ‘architectural building blocks’ </li></ul></ul><ul><li>Identify ‘composites’ across cells </li></ul><ul><ul><li>examples : process-flow, software application </li></ul></ul><ul><ul><li>composites are ‘solution building blocks’ </li></ul></ul><ul><li>Layers are levels of abstraction </li></ul><ul><ul><li>higher levels are implementation-independent </li></ul></ul><ul><ul><li>higher levels change rarely, lower-levels often </li></ul></ul>23/06/09 © Tetradian 2007

6. Using Zachman – cell scope <ul><li>Horizontal vs vertical scope (may be combined) </li></ul>23/06/09 © Tetradian 2007 <ul><ul><li>horizontal : level of detail </li></ul></ul><ul><ul><ul><li>Zachman : ‘slice’ </li></ul></ul></ul><ul><ul><li>vertical : breadth of coverage across organisational units </li></ul></ul><ul><ul><ul><li>Zachman : ‘sliver’ </li></ul></ul></ul>

7. 2. TOGAF Architectural Design Method <ul><li>Iterative, recursive cycles </li></ul><ul><ul><li>cycle from Phase A to Phase H </li></ul></ul><ul><li>Requirements at the centre </li></ul><ul><li>Three distinct emphases: </li></ul>23/06/09 © Tetradian 2007 <ul><ul><li>initial overview and governance </li></ul></ul><ul><ul><li>expand the architecture: </li></ul></ul><ul><ul><ul><li>extend ‘as-is’, develop ‘to-be’ </li></ul></ul></ul><ul><ul><ul><li>layered views (Phase A to D) </li></ul></ul></ul><ul><ul><li>identify and implement solutions </li></ul></ul><ul><ul><ul><li>choose solutions (Phase E) </li></ul></ul></ul><ul><ul><ul><li>from ‘as-is’ to ‘to-be’ (Phase F) </li></ul></ul></ul><ul><ul><ul><li>govern and manage change (Phase G-H) </li></ul></ul></ul>

8. Using TOGAF ADM <ul><li>Establish overall principles, governance etc </li></ul><ul><ul><li>‘ Preliminary framework and principles’ </li></ul></ul><ul><li>For each iteration: </li></ul><ul><ul><li>Set the iteration scope [Phase A] </li></ul></ul><ul><ul><li>Review and update architecture [Phases B-D] </li></ul></ul><ul><ul><ul><li>draw from and update the ‘Enterprise Continuum’: </li></ul></ul></ul><ul><ul><ul><ul><li>Architectural Building Blocks [ABBs – ‘primitives’] </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Solution Building Blocks [SBBs – ‘composites’] </li></ul></ul></ul></ul><ul><ul><li>Identify opportunities and solutions [Phase E] </li></ul></ul><ul><ul><li>Drive and manage change [Phases F-H] </li></ul></ul><ul><li>Emphasis almost exclusively on IT </li></ul><ul><ul><li>‘ business architecture’ is ‘anything not-IT’ </li></ul></ul><ul><ul><ul><li>‘ business’ viewed only in terms of its impact on IT </li></ul></ul></ul>23/06/09 © Tetradian 2007

9. 3. Initial Zachman/TOGAF integration <ul><li>TOGAF provides methodology for Zachman </li></ul><ul><ul><li>similar layering: </li></ul></ul><ul><ul><ul><li>Zachman : context » conceptual » logical » physical </li></ul></ul></ul><ul><ul><ul><li>TOGAF : business » information systems » technology </li></ul></ul></ul><ul><li>TOGAF and Zachman cover similar domains </li></ul><ul><ul><li>business drivers, business process </li></ul></ul><ul><ul><li>data, information, locations, applications </li></ul></ul><ul><ul><li>technology implementation, networks, etc </li></ul></ul><ul><li>TOGAF is mapped to Zachman </li></ul><ul><ul><li>see “ADM and the Zachman Framework” </li></ul></ul><ul><ul><ul><li>http://www.opengroup.org/architecture/togaf8-doc/arch/chap39.html </li></ul></ul></ul>23/06/09 © Tetradian 2007

10. Map between TOGAF and Zachman [1] <ul><li>TOGAF/Zachman seem to map well overall… </li></ul>23/06/09 © Tetradian 2007

11. Map between TOGAF and Zachman [2] <ul><li>… but mapping doesn’t work so well in detail </li></ul>23/06/09 © Tetradian 2007

12. Map between TOGAF and Zachman [3] <ul><li>… especially for Phase C1, ‘Data Architecture’ </li></ul>23/06/09 © Tetradian 2007

13. 4. Resolving the mismatch <ul><li>Both Zachman and TOGAF are IT-centric </li></ul><ul><ul><li>need to expand to cover non-IT business-context </li></ul></ul><ul><li>Zachman has internal inconsistencies </li></ul><ul><ul><li>‘ What’ column described as ‘Data’, ‘Meaning’ etc </li></ul></ul><ul><ul><li>cause : additional dimension is required </li></ul></ul><ul><ul><ul><li>i.e. ‘segment’ depth vs ‘slice’ height, ‘sliver’ breadth </li></ul></ul></ul><ul><li>TOGAF filters everything through an IT lens </li></ul><ul><ul><li>IT-only view sees Zachman ‘What’ only as ‘Data’ </li></ul></ul><ul><ul><li>C2: ‘Application’, D: ‘Technology’ are composites </li></ul></ul><ul><ul><ul><li>mismatch : mixed primitives, composites, layers </li></ul></ul></ul><ul><ul><li>Phases B-D are separate views , not true phases </li></ul></ul>23/06/09 © Tetradian 2007

14. Resolve Zachman issues <ul><li>Expand base-metaphor for framework </li></ul><ul><ul><li>enterprise as ‘organism’, not ‘machine’ </li></ul></ul><ul><ul><ul><ul><li>organisation-change can be guided but not ‘engineered’ </li></ul></ul></ul></ul><ul><li>Expand the model structure to support this </li></ul><ul><ul><li>Add an R0 row for core-principles etc </li></ul></ul><ul><ul><ul><ul><li>maps to TOGAF initial ‘Preliminary’ phase </li></ul></ul></ul></ul><ul><ul><li>Add ‘depth’ dimension to clarify asset-types </li></ul></ul><ul><ul><ul><ul><li>physical ‘things’: tangible objects, etc </li></ul></ul></ul></ul><ul><ul><ul><ul><li>conceptual ‘things’: information, data etc </li></ul></ul></ul></ul><ul><ul><ul><ul><li>relational ‘things’: business relationships etc </li></ul></ul></ul></ul><ul><ul><ul><ul><li>aspirational ‘things’: identity, purpose, morale etc </li></ul></ul></ul></ul><ul><ul><ul><ul><li>plus an ‘overall integration’ layer </li></ul></ul></ul></ul><ul><ul><ul><li>will relate to specific columns (e.g. ‘What’/physical) </li></ul></ul></ul><ul><ul><ul><ul><li>but they do not map exactly – is a distinct dimension </li></ul></ul></ul></ul>23/06/09 © Tetradian 2007

15. Zachman framework: amended rows <ul><li>R0: (implied) </li></ul><ul><ul><li>common to all columns: vision, principles, key strategies, etc </li></ul></ul><ul><li>R1 : Contextual / ‘scope’ [planner] </li></ul><ul><ul><li>lists of key items relevant to enterprise </li></ul></ul><ul><li>R2 : Conceptual / ‘business’ [owner] </li></ul><ul><ul><li>summaries of key items and relations </li></ul></ul><ul><li>R3 : Logical / ‘system’ [designer] </li></ul><ul><ul><li>items independent of any implementation </li></ul></ul><ul><li>R4 : Physical / ‘technology’ [builder] </li></ul><ul><ul><li>items linked to the specified implementation </li></ul></ul><ul><li>R5: Out-of-context / ‘components’ [subcontractor] </li></ul><ul><ul><li>items as specified in work-instructions, program-code etc </li></ul></ul><ul><li>R6: Product / ‘functioning enterprise’ </li></ul><ul><ul><li>instances of each item occurring in the day-to-day or minute-to-minute running of the enterprise </li></ul></ul>23/06/09 © Tetradian 2007

16. Zachman framework: amended columns 23/06/09 © Tetradian 2007 <ul><li>What : entity / relationship </li></ul><ul><ul><li>assets: physical things, data, relations, values, financials etc </li></ul></ul><ul><li>How : function / input-output </li></ul><ul><ul><li>machine-based, IT-based or manual processes, etc </li></ul></ul><ul><li>Where : node / line </li></ul><ul><ul><li>locations in physical, virtual or social space, etc </li></ul></ul><ul><li>Who : agent / capability </li></ul><ul><ul><li>human, IT or machine ‘actors’ and their skills / capabilities </li></ul></ul><ul><li>When : event / cycle </li></ul><ul><ul><li>any event that starts, ends or intervenes in a business-process, on timescales from microseconds to decades </li></ul></ul><ul><li>Why : ends / measures </li></ul><ul><ul><li>decisions, requirements, business-rules, etc </li></ul></ul><ul><li>Also measures across these: inventory, yield, capability, performance, time, state-of-change etc </li></ul>

17. Resolve TOGAF-ADM issues <ul><li>TOGAF ‘Preliminary’ phase defines initial R0 </li></ul><ul><li>Identify scope for iteration in Phase A </li></ul><ul><ul><li>i.e. ‘slice’ detail, ‘sliver’ org-scope, ‘segment’ etc </li></ul></ul><ul><li>Remap Phases B-D to architecture phases </li></ul><ul><ul><li>Phase B: identify ‘as-is’ architecture </li></ul></ul><ul><ul><li>Phase C: develop ‘to-be’ architecture </li></ul></ul><ul><ul><li>Phase D: gap-analysis from ‘as-is’ to ‘to-be’ </li></ul></ul><ul><li>Amend ADM IT-specific terminology </li></ul><ul><ul><li>e.g. all possibilities of R4, not just networks etc </li></ul></ul><ul><li>Amend steps to be consistent at all layers </li></ul><ul><ul><li>e.g. remove existing over-emphasis on Phase D </li></ul></ul><ul><li>Phases E-H minor changes to broaden scope </li></ul>23/06/09 © Tetradian 2007

18. 5. Revised TOGAF-ADM methodology <ul><li>Do ‘Preliminary’ phase before anything else </li></ul><ul><ul><li>may review at any time, but is not an iteration </li></ul></ul><ul><li>For each iteration </li></ul><ul><ul><ul><li>iterations may be for a project, context-change etc </li></ul></ul></ul><ul><ul><ul><li>see TOGAF guide for input/output documents etc </li></ul></ul></ul><ul><ul><li>Phase A: define purpose and scope </li></ul></ul><ul><ul><li>Phases B-D: review ‘as-is’ and ‘to-be’ views </li></ul></ul><ul><ul><li>Phase E: identify candidate solutions </li></ul></ul><ul><ul><li>Phases F-H: identify, govern and guide change </li></ul></ul><ul><ul><li>update requirements-repository at each step </li></ul></ul><ul><li>Views are linked to amended Zachman </li></ul><ul><ul><li>additional R0 row, ‘depth’ dimension etc </li></ul></ul>23/06/09 © Tetradian 2007

19. Use TOGAF-ADM cycle for governance 23/06/09 © Tetradian 2007 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-artefacts define methodology’s phase-boundaries

20. ‘ Preliminary’ phase [1] <ul><li>Identify core-principles etc for R0 </li></ul><ul><ul><li>business-drivers, business-goals – esp. ‘Vision’ </li></ul></ul><ul><ul><ul><ul><li>Vision is always greater than the organisation itself </li></ul></ul></ul></ul><ul><ul><li>record item-list in repository </li></ul></ul><ul><ul><ul><li>may be best to record as ‘business-requirements’ </li></ul></ul></ul><ul><li>Define key standards-documents </li></ul><ul><ul><li>Architecture Charter, Architecture Principles etc </li></ul></ul><ul><li>Include key themes by reference </li></ul><ul><ul><li>documents for key strategies, business-policies </li></ul></ul><ul><ul><li>security policy, OH&S policy, privacy policy, environment policy, quality-system etc </li></ul></ul>23/06/09 © Tetradian 2007

21. ‘ Preliminary’ phase [2] <ul><li>For each Zachman column (cell) in R1 : </li></ul><ul><ul><li>use core-principles to suggest candidate items </li></ul></ul><ul><ul><ul><li>what : key ‘things’, physical and otherwise </li></ul></ul></ul><ul><ul><ul><li>how : key processes, functions etc </li></ul></ul></ul><ul><ul><ul><li>where : key locations, physical, virtual etc </li></ul></ul></ul><ul><ul><ul><li>who : key actors/agents, organisations etc </li></ul></ul></ul><ul><ul><ul><li>when : key events, cycles etc </li></ul></ul></ul><ul><ul><ul><li>why : key continuing aims, strategies etc </li></ul></ul></ul><ul><ul><li>record/amend cell’s item-list in repository </li></ul></ul><ul><ul><ul><li>repository may store in list- or graphic-form, but must be possible to link to here from other layers </li></ul></ul></ul><ul><li>Note: content may be minimal at first pass </li></ul><ul><ul><ul><li>content will also be developed in architecture cycles </li></ul></ul></ul>23/06/09 © Tetradian 2007

22. Phase A: Iteration Scope / Purpose [1] <ul><li>Identify business-purpose of iteration </li></ul><ul><ul><ul><li>e.g. support project, broader work-program etc </li></ul></ul></ul><ul><li>Identify Zachman vertical scope of iteration </li></ul><ul><ul><ul><li>typically R2 to R3, sometimes also R4 for detail </li></ul></ul></ul><ul><li>For each Zachman row in iteration-scope </li></ul><ul><ul><li>identify ‘slice’ (level of detail) </li></ul></ul><ul><ul><li>identify ‘sliver’ (coverage across organisation) </li></ul></ul><ul><ul><li>identify ‘segment’ (categories of assets covered) </li></ul></ul><ul><li>Document ‘Statement of Architecture Work’ </li></ul><ul><ul><ul><ul><li>(see TOGAF guide for details of document content) </li></ul></ul></ul></ul><ul><ul><li>sign-off document to begin architecture iteration </li></ul></ul>23/06/09 © Tetradian 2007

23. Phase A: Iteration Scope / Purpose [2] <ul><li>TOGAF ‘architectures’ are predefined scopes </li></ul><ul><ul><li>i.e. prepackaged sets of Zachman ‘slices’ </li></ul></ul><ul><ul><ul><li>see “ADM and the Zachman Framework” </li></ul></ul></ul><ul><ul><ul><ul><li>http://www.opengroup.org/architecture/togaf8-doc/arch/chap39.html </li></ul></ul></ul></ul><ul><li>‘ Architectures’ emphasise different areas </li></ul><ul><ul><li>‘ Business Architecture’ (TOGAF Phase B) </li></ul></ul><ul><ul><ul><li>emphasis on Zachman R2 ‘conceptual’ layer </li></ul></ul></ul><ul><ul><li>‘ Data Architecture’ (TOGAF Phase C1) and ‘Application Architecture’ (TOGAF Phase C2) </li></ul></ul><ul><ul><ul><li>emphasis on Zachman R3 ‘logical’ layer </li></ul></ul></ul><ul><ul><li>‘ Technology Architecture’ (TOGAF Phase D) </li></ul></ul><ul><ul><ul><li>emphasis on Zachman R4 ‘physical’ layer </li></ul></ul></ul>23/06/09 © Tetradian 2007

24. Phase A: Iteration Scope / Purpose [3] <ul><li>Example : Data Architecture </li></ul><ul><ul><li>for this iteration-focus, we’d set ‘slices’ as follows: </li></ul></ul>23/06/09 © Tetradian 2007 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 interest in ‘Physical’ layer outside of Data scope

25. Phase A: Iteration Scope / Purpose [4] <ul><li>Example : Information Architecture </li></ul><ul><ul><li>for this iteration-focus, we’d set ‘slices’ as follows: </li></ul></ul>23/06/09 © Tetradian 2007 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

26. Phases B-D: Develop the architecture 23/06/09 © Tetradian 2007 Scan down columns to identify primitives Scan across rows to identify composites … review links to primitives above For each item in main emphasis… … look below for implied primitives / composites

27. Phase B: Current-state architecture [1] <ul><li>Preliminary: </li></ul><ul><li>For each cell in R2 (‘Conceptual’ layer) </li></ul><ul><ul><li>for each item-type in scope </li></ul></ul><ul><ul><ul><li>identify the ‘owner’ (person responsible for items) </li></ul></ul></ul><ul><li>TOGAF-ADM steps: </li></ul><ul><ul><ul><ul><li>(see also TOGAF guide, ‘Business architecture’, for more detail) </li></ul></ul></ul></ul><ul><li>Step 1: develop baseline architecture </li></ul><ul><ul><ul><ul><li>note : this is Step 1 in TOGAF Phases B-D </li></ul></ul></ul></ul><ul><ul><li>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 </li></ul></ul>23/06/09 © Tetradian 2007

28. Phase B: Current-state architecture [2] <ul><li>Step 2: select reference-models, views etc </li></ul><ul><ul><ul><ul><li>note : this is Step 2 in TOGAF Phases B-D </li></ul></ul></ul></ul><ul><ul><li>identify any reference-models applying to scope </li></ul></ul><ul><ul><ul><li>e.g. select from repository any existing R2 / R3 / R4 reference-models matching the iteration-scope </li></ul></ul></ul><ul><ul><li>identify appropriate viewpoints </li></ul></ul><ul><ul><ul><li>e.g. Operations, Finance, specific client-groups </li></ul></ul></ul><ul><ul><li>identify tools, techniques and model-types matching the iteration-scope </li></ul></ul><ul><ul><ul><li>use mappings between model-types and Zachman rows / columns etc to assist in this </li></ul></ul></ul>23/06/09 © Tetradian 2007

29. Phase B: Current-state architecture [2] <ul><li>Step 3: create/update architecture models </li></ul><ul><ul><ul><ul><li>note : this is Step 3 in TOGAF Phases B-D </li></ul></ul></ul></ul><ul><ul><li>for each viewpoint and cell, in iteration-scope </li></ul></ul><ul><ul><ul><li>identify additional ‘as-is’ primitives and their owners </li></ul></ul></ul><ul><ul><ul><li>verify derivations from cell above (principles etc) </li></ul></ul></ul><ul><ul><ul><li>summarise implied entities in cells below </li></ul></ul></ul><ul><ul><ul><ul><li>e.g. logical data-entities implied by business-data objects </li></ul></ul></ul></ul><ul><ul><ul><li>to required detail, check relations with all R1 cells </li></ul></ul></ul><ul><ul><ul><ul><li>i.e. TOGAF 3(v) validation tests </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>e.g. requirements, motivation audit-trail etc </li></ul></ul></ul></ul></ul><ul><ul><li>identify multi-cell composites </li></ul></ul><ul><ul><ul><li>e.g. business-patterns, business-unit maps etc </li></ul></ul></ul><ul><ul><ul><ul><li>note that primitive might appear as lower-row composite </li></ul></ul></ul></ul>23/06/09 © Tetradian 2007

30. Phase B: Current-state architecture [4] <ul><li>Step 4: update architecture repository </li></ul><ul><ul><ul><ul><li>note : this is Step 4 in TOGAF Phases B-D </li></ul></ul></ul></ul><ul><ul><li>merge any new or amended primitives into the Architecture Building Blocks (ABBs) </li></ul></ul><ul><ul><li>merge any new or amended composites into the Solution Building Blocks (SBBs) </li></ul></ul>23/06/09 © Tetradian 2007

31. Phase B: Current-state architecture [5] <ul><li>Step 5: review qualitative criteria </li></ul><ul><ul><ul><ul><li>note : this is Step 6 in TOGAF Phases B-D </li></ul></ul></ul></ul><ul><ul><ul><ul><li>note : not covered directly in Zachman </li></ul></ul></ul></ul><ul><ul><li>identify required qualitative criteria such as performance, costs, volumes </li></ul></ul><ul><ul><ul><li>e.g. KPI/KSC sets for a ‘balanced scorecard’ </li></ul></ul></ul><ul><ul><li>cross-check with all R0 standards, policies etc </li></ul></ul><ul><ul><ul><li>e.g. security, environment, OH&S </li></ul></ul></ul>23/06/09 © Tetradian 2007

32. Phase B: Current-state architecture [6] <ul><li>Step 6: conduct checkpoint review </li></ul><ul><ul><ul><ul><li>note : this is Step 5 in TOGAF Phases B-D </li></ul></ul></ul></ul><ul><ul><li>conduct formal stakeholder review of architecture </li></ul></ul><ul><ul><ul><li>identify stakeholders from: </li></ul></ul></ul><ul><ul><ul><ul><li>iteration-scope as specified in Phase A </li></ul></ul></ul></ul><ul><ul><ul><ul><li>item-owners as identified at start of this Phase </li></ul></ul></ul></ul><ul><ul><ul><ul><li>additional item-owners identified in this Phase, step 3 </li></ul></ul></ul></ul>23/06/09 © Tetradian 2007

33. Phase C: Future-state architecture <ul><li>Repeat steps 1-6 for ‘to-be’ architecture </li></ul><ul><ul><ul><ul><li>note : this is Step 7 in TOGAF Phases B-D </li></ul></ul></ul></ul><ul><ul><ul><ul><li>note : scope is same as identified / specified in Phase A </li></ul></ul></ul></ul><ul><ul><li>create ‘to-be’ baseline from artefacts in scope </li></ul></ul><ul><ul><ul><li>‘ to-be’ time-point is specified in Phase A </li></ul></ul></ul><ul><ul><li>use same viewpoints etc as in Phase B </li></ul></ul><ul><ul><li>from iteration-scope documents etc </li></ul></ul><ul><ul><ul><li>for each viewpoint and cell in iteration-scope </li></ul></ul></ul><ul><ul><ul><ul><li>identify new or amended primitives and composites </li></ul></ul></ul></ul><ul><ul><li>merge into repository as ‘to-be’ </li></ul></ul><ul><ul><li>review amended criteria </li></ul></ul><ul><ul><li>conduct formal checkpoint review </li></ul></ul>23/06/09 © Tetradian 2007

34. Phase D: Architecture gap-analysis <ul><li>Perform gap-analysis </li></ul><ul><ul><ul><ul><li>note : this is Step 8 in TOGAF Phases B-D </li></ul></ul></ul></ul><ul><ul><li>compare ‘as-is’ to ‘to-be’ for gap-analysis matrix </li></ul></ul><ul><ul><ul><ul><li>see TOGAF specification for matrix-structure details </li></ul></ul></ul></ul><ul><ul><ul><li>compare primitives, composites etc </li></ul></ul></ul><ul><ul><li>identify, extract and document requirements </li></ul></ul><ul><ul><ul><li>store gap-analysis requirements in repository </li></ul></ul></ul><ul><ul><li>document for Phase E opportunities/solutions </li></ul></ul><ul><ul><ul><ul><li>see TOGAF specification for documents / deliverables for this Phase </li></ul></ul></ul></ul>23/06/09 © Tetradian 2007

35. Phases E to H: architecture to practice <ul><li>As per TOGAF-ADM, but less IT-specific </li></ul><ul><li>Phase E: opportunities and solutions </li></ul><ul><ul><li>use architecture to guide solution design </li></ul></ul><ul><ul><ul><ul><li>see http://www.opengroup.org/architecture/togaf8-doc/arch/chap11.html </li></ul></ul></ul></ul><ul><li>Phase F: migration-planning </li></ul><ul><ul><li>create ‘roadmap’ for iteration’s change </li></ul></ul><ul><ul><ul><ul><li>see http://www.opengroup.org/architecture/togaf8-doc/arch/chap12.html </li></ul></ul></ul></ul><ul><li>Phase G: governance </li></ul><ul><ul><li>verify project’s architecture-compliance </li></ul></ul><ul><ul><ul><ul><li>see http://www.opengroup.org/architecture/togaf8-doc/arch/chap13.html </li></ul></ul></ul></ul><ul><li>Phase H: change-management </li></ul><ul><ul><li>manage changes to architecture content etc </li></ul></ul><ul><ul><ul><ul><li>see http://www.opengroup.org/architecture/togaf8-doc/arch/chap14.html </li></ul></ul></ul></ul>23/06/09 © Tetradian 2007

36. Summary <ul><li>Zachman/TOGAF integration-issues </li></ul><ul><ul><li>routine IT-centric use masks inconsistencies </li></ul></ul><ul><li>Revise Zachman for consistent categories </li></ul><ul><ul><li>expand scope to architecture of full enterprise </li></ul></ul><ul><ul><li>additional dimension for asset-types etc </li></ul></ul><ul><li>Revise TOGAF for consistent methodology </li></ul><ul><ul><li>revised Phases B, C, D apply to any architecture </li></ul></ul><ul><ul><li>some changes to other Phases to broaden scope </li></ul></ul><ul><li>Methodology for enterprise architecture </li></ul><ul><ul><li>supports full enterprise scope – IT and beyond </li></ul></ul>23/06/09 © Tetradian 2007

37. More detail on amended Zachman Rows, Columns and Segments 23/06/09 © Tetradian 2007

38. Notes : new R0 ‘Universal’ (enterprise) row <ul><li>Shared across all Zachman columns </li></ul><ul><li>Represents the core drivers for enterprise </li></ul><ul><ul><li>core Vision (as ultimate anchor for architecture) </li></ul></ul><ul><ul><li>key architecture / governance principles </li></ul></ul><ul><ul><ul><li>list of enterprise Values etc </li></ul></ul></ul><ul><ul><ul><li>architectural principles e.g. ‘single source of truth’ </li></ul></ul></ul><ul><ul><ul><li>core standards, strategies, policies etc </li></ul></ul></ul><ul><li>Provides upward anchor for all derivations </li></ul><ul><ul><li>e.g. requirements ultimately anchor to Vision </li></ul></ul><ul><ul><li>also acts as ultimate anchor for quality-system </li></ul></ul><ul><li>Small numbers of items </li></ul><ul><ul><li>usually described in text-form </li></ul></ul>23/06/09 © Tetradian 2007

39. Notes : revised R1 ‘Contextual’ row <ul><li>Split into respective Zachman columns </li></ul><ul><ul><li>what, how, where, who, when, why </li></ul></ul><ul><ul><ul><li>also depth-layers (‘segments’): physical, conceptual, relational, aspirational, integration etc </li></ul></ul></ul><ul><ul><li>usually primitives only – no composites </li></ul></ul><ul><li>Lists of key items relevant to enterprise </li></ul><ul><ul><li>described in text-form or as objects on diagram </li></ul></ul><ul><li>Provides anchor for conceptual level </li></ul><ul><ul><li>core functions as frames on Function Model, key business-information as anchor for relational model, geographical regions, etc </li></ul></ul><ul><li>No more than 10-20 items per list </li></ul>23/06/09 © Tetradian 2007

40. Notes : revised R2 ‘Conceptual’ row <ul><li>Split into respective Zachman columns </li></ul><ul><ul><li>may have composites across columns/segments </li></ul></ul><ul><ul><ul><li>e.g. org-chart is a composite: who, what, where </li></ul></ul></ul><ul><li>Summaries of key items and relations </li></ul><ul><ul><li>usually as objects and relationships on diagram </li></ul></ul><ul><li>Links upward to R1 contextual level </li></ul><ul><ul><li>if there’s no R1 object to link to, it may need to be added to the respective list </li></ul></ul><ul><li>Provides anchor for R3 logical level </li></ul><ul><ul><li>top-level of standard model-types e.g. BPMN </li></ul></ul><ul><li>Around 30-100 items per Zachman cell </li></ul>23/06/09 © Tetradian 2007

41. Notes : revised R3 ‘Logical’ row <ul><li>Split into respective Zachman columns </li></ul><ul><ul><li>R2 items often expand to composites at R3 level </li></ul></ul><ul><li>Items independent of implementation </li></ul><ul><ul><li>usually as objects and relationships on diagram </li></ul></ul><ul><ul><li>composites modelled as links between diagrams </li></ul></ul><ul><li>Links upward to R1 / R2 levels </li></ul><ul><ul><li>if there’s no R2 object to link to, it may need to be added; likewise upward to R1 lists </li></ul></ul><ul><li>Provides anchor for R4 physical level </li></ul><ul><ul><li>standard model-types e.g. BPMN, ER diagram </li></ul></ul><ul><li>From 60-100 items up per Zachman cell </li></ul>23/06/09 © Tetradian 2007

42. Notes : revised R4 ‘Physical’ row <ul><li>Split into respective Zachman columns </li></ul><ul><ul><li>R3 items usually as composites at R4 level </li></ul></ul><ul><li>Items are linked to implementation </li></ul><ul><ul><li>model as objects and relationships on diagram </li></ul></ul><ul><ul><li>composites modelled as links between diagrams </li></ul></ul><ul><li>Links upward to R1 / R2 / R3 levels </li></ul><ul><ul><li>if there’s no R3 object to link to, it may need to be added; likewise upward to R2 and R1 lists </li></ul></ul><ul><li>Provides anchor for R5 design » build </li></ul><ul><ul><li>implementation-specific – e.g. database schema </li></ul></ul><ul><li>Any number of items per Zachman cell </li></ul>23/06/09 © Tetradian 2007

43. Notes : unchanged R5 and R6 rows <ul><li>R5: Zachman ‘Detailed Representation’ row </li></ul><ul><ul><li>detailed ‘master-instructions’ to implement architecture-items (e.g. software source-code, process work-instruction, etc) </li></ul></ul><ul><ul><li>derived from R4-level models but rarely represented direct in architecture </li></ul></ul><ul><li>R6: Zachman ‘Functioning Enterprise’ row </li></ul><ul><ul><li>placeholder for all item-instances (e.g. every data-item of a data-class, every occurrence of a business-activity, etc) </li></ul></ul><ul><ul><li>implied but rarely used in architecture-models </li></ul></ul>23/06/09 © Tetradian 2007

44. Example : organisation-chart <ul><li>R0: ‘the enterprise’ </li></ul><ul><li>R1: major business units, roles, locations </li></ul><ul><li>R2: main sub-units, roles, regions etc </li></ul><ul><ul><li>links between units / sub-units as primitives </li></ul></ul><ul><ul><li>highest-level org-chart as composite </li></ul></ul><ul><li>R3: include cross-reports, dependencies </li></ul><ul><ul><li>head-quarters, regional units, infrastructure </li></ul></ul><ul><li>R4: detail as implemented, roles only </li></ul><ul><li>R5: names linked to nominal roles </li></ul><ul><ul><li>‘ the org-chart’ as shown at induction etc </li></ul></ul><ul><li>R6: names linked to all run-time roles </li></ul><ul><ul><li>real-time changes e.g. day-shift roster </li></ul></ul>23/06/09 © Tetradian 2007

45. Example : software development life-cycle <ul><li>R0 » R1: (implied) </li></ul><ul><li>R2: Conceptual Design Document </li></ul><ul><ul><li>high-level requirements for system </li></ul></ul><ul><li>R3: System Requirements </li></ul><ul><ul><li>high-level: may be implementation-independent </li></ul></ul><ul><li>R4: System Design Document </li></ul><ul><ul><li>detail-level: fully implementation-dependent </li></ul></ul><ul><li>R5: Software source-code </li></ul><ul><ul><li>rewrite for each change of technology etc </li></ul></ul><ul><li>R6: Executable code </li></ul><ul><ul><li>includes instances generated at run-time </li></ul></ul>23/06/09 © Tetradian 2007

46. Example : ISO-9000:2000 quality-system <ul><li>R0: Vision (as ultimate anchor for quality-system) </li></ul><ul><li>R1 » R2: Policy </li></ul><ul><ul><li>high-level (values) to detail-level (linked to strategy) </li></ul></ul><ul><li>R3 » R4: Procedure </li></ul><ul><ul><li>high-level: implementation-independent </li></ul></ul><ul><ul><li>detail-level: more implementation-dependent </li></ul></ul><ul><li>R5 » R6: Work-instruction </li></ul><ul><ul><li>rewrite for each change of technology etc </li></ul></ul><ul><li>Same upward/downward dependencies </li></ul><ul><ul><li>work-instruction depends on / implies procedure, which in turn implies policy, etc </li></ul></ul>23/06/09 © Tetradian 2007

47. Notes : new ‘depth’ dimension [1] <ul><li>Aim is to remove Zachman-cell ambiguity </li></ul><ul><ul><li>e.g. is ‘What’-column objects, data or meaning? </li></ul></ul><ul><ul><ul><li>Zachman variously describes column as any of these... </li></ul></ul></ul><ul><li>Number of segments may vary per column </li></ul><ul><ul><li>usually ‘physical’, ‘conceptual’, ‘relational’, ‘aspirational’ – but may have more or less </li></ul></ul><ul><ul><li>implied extra segment for integration between other segments – e.g. financials </li></ul></ul><ul><li>Composites may occur between segments </li></ul><ul><ul><li>e.g. R2/R3 abstract-function (‘service’) could be any mix of machine, IT and manual functions </li></ul></ul><ul><ul><ul><li>resolved at R4 level as explicit implementation mix </li></ul></ul></ul>23/06/09 © Tetradian 2007

48. Notes : new ‘depth’ dimension [2] <ul><li>‘ What’ column </li></ul><ul><ul><li>physical things; data; links to people; meaning </li></ul></ul><ul><li>‘ How’ column </li></ul><ul><ul><li>machine function; IT interface; business-meeting </li></ul></ul><ul><li>‘ Where’ column </li></ul><ul><ul><li>geographic; virtual; social-network; value-web </li></ul></ul><ul><li>‘ Who’ column </li></ul><ul><ul><li>machine; IT-system; person </li></ul></ul><ul><li>‘ When’ column </li></ul><ul><ul><li>timescales – sub-seconds to days to decades </li></ul></ul><ul><li>‘ Why’ column </li></ul><ul><ul><li>rule; best-practice; heuristic/guideline; principle </li></ul></ul>23/06/09 © Tetradian 2007

49. Notes : amended ‘What’ column <ul><li>Primitive: object / dependent relationships </li></ul><ul><ul><li>Zachman definition: entity / relationship </li></ul></ul><ul><li>Example model-types: </li></ul><ul><ul><li>physical assets : </li></ul></ul><ul><ul><ul><li>parts-breakdown; bill of materials </li></ul></ul></ul><ul><ul><li>conceptual assets : </li></ul></ul><ul><ul><ul><li>data-model; metadata-schema; model-definitions </li></ul></ul></ul><ul><ul><li>relational assets : </li></ul></ul><ul><ul><ul><ul><li>note: people are not ‘assets’ – the relationship with the person is the asset </li></ul></ul></ul></ul><ul><ul><ul><li>business-relationships and relationship-types </li></ul></ul></ul><ul><ul><li>aspirational assets : </li></ul></ul><ul><ul><ul><li>meaning-types (e.g. financials); morale etc types </li></ul></ul></ul>23/06/09 © Tetradian 2007

50. Notes : amended ‘How’ column <ul><li>Primitive: function / inputs and outputs </li></ul><ul><ul><li>Zachman definition: process / input-output </li></ul></ul><ul><ul><ul><li>( process is function sequence, hence process-flow may be a composite) </li></ul></ul></ul><ul><li>Example model-types: </li></ul><ul><ul><li>function model : </li></ul></ul><ul><ul><ul><li>Functional Business Model; Business Systems Model </li></ul></ul></ul><ul><ul><li>cause-effect model : </li></ul></ul><ul><ul><ul><li>‘ fishbone’ diagram </li></ul></ul></ul><ul><ul><li>Six Sigma SIPOC model : </li></ul></ul><ul><ul><ul><li>supplier, input, process, output, customer </li></ul></ul></ul>23/06/09 © Tetradian 2007

51. Notes : amended ‘Where’ column <ul><li>Primitive: nodes of same type / link and properties </li></ul><ul><ul><li>Zachman definition: node / line </li></ul></ul><ul><ul><ul><li>(node-type is location; item at location is usually a ‘What’ entity) </li></ul></ul></ul><ul><li>Example model-types: </li></ul><ul><ul><li>geographic map : </li></ul></ul><ul><ul><ul><li>literal map (guide-book), schematic (railway grid) etc </li></ul></ul></ul><ul><ul><li>IT network map : </li></ul></ul><ul><ul><ul><li>network nodes and IP addresses </li></ul></ul></ul><ul><ul><li>social-network map : </li></ul></ul><ul><ul><ul><li>nodes are people, lines are connections between people </li></ul></ul></ul>23/06/09 © Tetradian 2007

52. Notes : amended ‘Who’ column <ul><li>Primitive: agent / capabilities </li></ul><ul><ul><li>Zachman definition: agent / work </li></ul></ul><ul><ul><ul><li>(‘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) </li></ul></ul></ul><ul><ul><ul><li>(many of Zachman’s examples here – e.g. workflow, org-chart etc – are not primitives, but composites, usually with ‘How’) </li></ul></ul></ul><ul><li>Example model-types: </li></ul><ul><ul><li>skills-architecture : </li></ul></ul><ul><ul><ul><li>capability-type and skills-level category ( none : rule-based; low : causal context; medium : heuristic; high : principles/experience) </li></ul></ul></ul><ul><ul><li>agent / skills / capabilities: </li></ul></ul><ul><ul><ul><li>machine : no-skill; IT : up to contextual / low-‘skill’; human agent required for higher skill-levels </li></ul></ul></ul>23/06/09 © Tetradian 2007

53. Notes : amended ‘When’ column <ul><li>Primitive: time-point / time-relationship </li></ul><ul><ul><li>Zachman definition: event / cycle </li></ul></ul><ul><ul><ul><li>(an event occurs at a specific point in time; a ‘cycle’ is one of many possible types of relationship within time) </li></ul></ul></ul><ul><ul><ul><li>(timescales could vary anywhere from nanoseconds or less to millennia or more) </li></ul></ul></ul><ul><li>Example model-types: </li></ul><ul><ul><li>project : </li></ul></ul><ul><ul><ul><li>Gantt chart – events plus inter-dependencies </li></ul></ul></ul><ul><ul><li>business-cycle : </li></ul></ul><ul><ul><ul><li>calendar – repeated and non-repeated business events </li></ul></ul></ul>23/06/09 © Tetradian 2007

54. Notes : amended ‘Why’ column <ul><li>Primitive: ends / measures, dependencies </li></ul><ul><ul><li>Zachman definition: ends / means </li></ul></ul><ul><ul><ul><li>( but : ‘means’ is more properly ‘How’ than ‘Why’) </li></ul></ul></ul><ul><ul><ul><li>(‘measure’ identifies/confirms that the ‘end’ has been achieved) </li></ul></ul></ul><ul><li>Example model-types: </li></ul><ul><ul><li>requirements : </li></ul></ul><ul><ul><ul><li>includes dependencies, conflicts, traceability audit-trail, test-conditions, priorities etc </li></ul></ul></ul><ul><ul><li>decision : </li></ul></ul><ul><ul><ul><li>business-rules and relationships </li></ul></ul></ul><ul><ul><li>decision-type : </li></ul></ul><ul><ul><ul><li>rule, best-practice, heuristic, principle </li></ul></ul></ul><ul><ul><li>motivation : </li></ul></ul><ul><ul><ul><li>Business Motivation Model, Enterprise Direction etc </li></ul></ul></ul>23/06/09 © Tetradian 2007

55. Notes : primitives and composites <ul><li>“ Building implementations (composite models) and saying you are doing ‘enterprise architecture’ (primitive models) is the worst possible architecture strategy” [John A Zachman] </li></ul><ul><li>Primitives </li></ul><ul><ul><li>are discrete architectural building-blocks </li></ul></ul><ul><ul><li>are of only one type and one set of relations </li></ul></ul><ul><ul><li>cannot be used on their own for implementation </li></ul></ul><ul><li>Composites </li></ul><ul><ul><li>are structures to guide implementation (‘solution building blocks’) </li></ul></ul><ul><ul><li>are defined relationships between different types of primitives at the same Zachman level </li></ul></ul>23/06/09 © Tetradian 2007

56. Notes : example composites <ul><li>R1: contextual </li></ul><ul><ul><li>high-level tactics : ends (‘Why’) + means (‘How’) </li></ul></ul><ul><li>R2: conceptual </li></ul><ul><ul><li>high-level service : business-function (‘How’) + agent (‘Who’ » machine | IT | manual) + performance-indicators (data: ‘What’ » conceptual [¤ « ‘Why’]) </li></ul></ul><ul><li>R3: logical </li></ul><ul><ul><li>software pattern : function (‘How’ » virtual) + data (‘What’ » conceptual) + sequence (‘When’ » ‹timescale›) </li></ul></ul><ul><li>R4: physical </li></ul><ul><ul><li>deployment map : IT unit (‘What’ » physical) + function (‘How’ » virtual) + location (‘Where’ » physical) + IP address (‘Where’ » virtual) </li></ul></ul>23/06/09 © Tetradian 2007

57. Further reading (June 2009) <ul><li>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 </li></ul><ul><li>For updated versions, see: </li></ul><ul><li>framework: http://tetradianbooks.com/ebook/silos_real-ea-frame-ref.pdf </li></ul><ul><li>method: http://tetradianbooks.com/ebook/silos_real-ea-adm-ref.pdf </li></ul><ul><li>See also books: </li></ul><ul><li>“ Bridging the Silos: enterprise architecture for IT-architects ” </li></ul><ul><ul><li>info and sample chapters at http://tetradianbooks.com/2008/04/silos/ </li></ul></ul><ul><li>“ Doing Enterprise Architecture: process and practice in the real enterprise ” </li></ul><ul><ul><li>info and sample chapters at http://tetradianbooks.com/2009/03/doing-ea/ </li></ul></ul><ul><li>For other enterprise architecture books by Tom Graves, see </li></ul><ul><ul><li>http://tetradianbooks.com/category/entarch/ </li></ul></ul>23/06/09 © Tetradian 2007