Togaf Version 9.1 Introduction Overview

Editor's Notes

• #2: Slide deck for use by Open Group members only. Redistribution and commercial use prohibited without prior permission from The Open Group. If you use this deck please acknowledge the source – thank you. This is a technical overview of TOGAF, and specifically TOGAF Version 9.1
• #4: This is the agenda for this deck
• #5: TOGAF(r), an Open Group Standard, is a proven enterprise architecture methodology and framework used by the world's leading organizations to improve business efficiency. It is the most prominent and reliable enterprise architecture standard, ensuring consistent standards, methods, and communication among enterprise architecture professionals. Enterprise architecture professionals fluent in TOGAF standards enjoy greater industry credibility, job effectiveness, and career opportunities. TOGAF helps practitioners avoid being locked into proprietary methods, utilize resources more efficiently and effectively, and realize a greater return on investment.
• #6: TOGAF is developed and maintained by The Open Group Architecture Forum. The first version of TOGAF, developed in 1995, was based on the US Department of Defense Technical Architecture Framework for Information Management (TAFIM). Starting from this sound foundation, The Open Group Architecture Forum has developed successive versions of TOGAF at regular intervals and published each one on The Open Group public web site. TAFIM, Technical Architecture Framework for Information Management
• #7: This is a view of the timeline , this illustrates the long maturation cycle. As TOGAF has become more mature the time period between publications has also increased
• #8: This slide gives many of the reasons why TOGAF is suitable and widely chosen as an architecture framework The graphic shown is the conceptual overview diagram for the TOGAF ADM illustrating the iterative cyclical nature of the process. (This process model is sometimes referred as a ‘the crop circle’.)
• #9: Some stats
• #10: Some more stats
• #11: These were the market drivers behind the major revision that was TOGAF 9
• #13: TOGAF 9.1 includes a set of maintenance updates based on feedback received on the 2009 publication of TOGAF 9. As such, the changes are upwards-compatible adding clarification, consistency, and additional details where needed. A separate document describing the changes including rationale is available as TOGAF 9 Technical Corrigendum 1 (Document U112).[1] [1] TOGAF 9 Technical Corrigendum 1 can be obtained from www.opengroup.org/bookstore/catalog/u112.htm.
• #14: This slide shows the TOGAF 9.1 Specification table of contents, which remains the same as TOGAF 9
• #15: The structure of the TOGAF standard reflects the structure and content of an architecture capability within an enterprise The architecture capability operates a method (click) The method is supported by a number of guidelines and techniques (click) And produces content to be store in the repository (click) the content is classified according to the Enterprise continuum (click) which is populated initially with the TOGAF reference models. This ties to the business as follows
• #16: This shows the structure in a graphical overview format calling out the main components These are discussed briefly in the next few slides: Architecture Development Method (ADM) An iterative sequence of steps to develop an enterprise-wide architecture ADM Guidelines and Techniques Architecture Content Framework TOGAF Reference Models Technical Reference Model I3RM: Integrated Information Infrastructure Reference Model, Supporting “Boundaryless Information Flow” The Enterprise Continuum A virtual repository of architecture assets. During application of the ADM, assets are created or drawn from existing assets, used, modified and returned to the virtual repository The Architecture Capability Framework
• #17: The ADM is the core of TOGAF
• #18: The ADM is iterative and circular.
• #19: ADM Phase overview
• #20: The phases of the ADM cycle are further divided into steps; this example shows Phase B: Business Architecture phase. A similar set of steps applies to phases C and D
• #21: (TOGAF 9 Part III: ADM Guidelines and Techniques is a set of resources – guidelines, templates, checklists, and other detailed materials – that directly support application of the TOGAF ADM. The individual guidelines and techniques are described in a separate part of TOGAF so that they can be referenced from the relevant points in the ADM as necessary, rather than having the detailed text clutter the description of the ADM itself. Guidelines versus Technique The guidelines provided with TOGAF describe how the ADM process can be adapted to deal with a number of different usage scenarios, including different process styles (e.g., the use of iteration) and also specific specialty architectures (such as security). The techniques described within TOGAF 9 Part III support specific tasks within the ADM (e.g., the gap analysis technique, principles, etc.). Some examples follow
• #22: An example from ADM Guidelines and Techniques is how to apply iteration. This is a Guideline
• #23: Similarly it provides guidance on applying the ADM at different levels across the Architecture Landscape. This is another Guideline
• #24: Part III contains the Stakeholder Management Technique to support application of the ADM
• #25: Part IV of the TOGAF 9 document is the Architecture content framework. (During application of the ADM process, a number of outputs are produced; for example, process flows, architectural requirements, project plans, project compliance assessments, etc. In order to collate and present these major work products in a consistent and structured manner, TOGAF defines a structural model – the TOGAF Architecture Content Framework – in which to place them. We look at Deliverables, Artifacts and Architecture Building Blocks next
• #26: The Architecture Content Framework provides three categories to describe architectural work products The Architecture Content Framework uses the following three categories to describe the type of architectural work product within the context of use: Deliverables Formal products Contractually specified Outputs from a project A deliverable can contain many artifacts Building blocks components that can be combined with other building blocks to deliver architectures and solutions Artifacts fine grained products that describe an architecture from a specific viewpoint For example: use-case specifications, architectural requirements, network diagrams, etc. Classified as: Catalogs (lists of things), matrices (showing relationships between things) or diagrams (pictures of things). Artifacts make up the content of the Architecture Repository (longer explanations) A deliverable is a work product that is contractually specified and in turn formally reviewed, agreed, and signed off by the stakeholders. Deliverables represent the output of projects and those deliverables that are in documentation form will typically be archived at completion of a project, or transitioned into an Architecture Repository as a reference model, standard, or snapshot of the Architecture Landscape at a point in time. An artifact is an architectural work product that describes an aspect of the architecture. Artifacts are generally classified as catalogs (lists of things), matrices (showing relationships between things), and diagrams (pictures of things). Examples include a requirements catalog, business interaction matrix, and a use-case diagram.. An architectural deliverable may contain many artifacts and artifacts will form the content of the Architecture Repository. A building block represents a (potentially re-usable) component of business, IT, or architectural capability that can be combined with other building blocks to deliver architectures and solutions.
• #27: This is the full content metamodel with relationships. We won’t be going into this level of detail in this overview talk
• #28: Part V of TOGAF: The Enterprise Continuum is a “virtual repository” of all the architecture assets – models, patterns, architecture descriptions, etc. – The Enterprise Continuum, sets the broader context for an architect and explains how generic solutions can be leveraged and specialized in order to support the requirements of an individual organization. The Enterprise Continuum is a view of the Architecture Repository that provides methods for classifying architecture and solution artifacts as they evolve from generic Foundation Architectures to Organization-Specific Architectures. The Enterprise Continuum comprises two complementary concepts: the Architecture Continuum and the Solutions Continuum. This diagram shows an overview of the context and constituents of the Enterprise Continuum. The Enterprise Continuum is partitioned into three distinct continua: The Enterprise Continuum is the outermost continuum and classifies assets related to the context of the overall enterprise architecture. The Enterprise Continuum classes of assets may influence architectures, but are not directly used during the ADM architecture development. The Enterprise Continuum classifies contextual assets used to develop architectures, such as policies, standards, strategic initiatives, organizational structures, and enterprise-level capabilities. The Enterprise Continuum can also classify solutions (as opposed to descriptions or specifications of solutions). Finally, the Enterprise Continuum contains two specializations, namely the Architecture and Solutions continuum
• #29: Supporting the Enterprise Continuum is the concept of an Architecture Repository which can be used to store different classes of architectural output at different levels of abstraction, created by the ADM. In this way, TOGAF facilitates understanding and co-operation between stakeholders and practitioners at different levels. (In 9.1 we have added the Enterprise Repository explicitly to the diagram)
• #30: Part VI: The TOGAF Technical Reference Model (TRM), provides a model and taxonomy of generic platform services It is a Foundation Architecture: “An architecture of generic services and functions that provides a foundation on which more specific architectures and architectural components can be built”. III-RM The Open Group has documented the business scenario that led to the creation of the Integrated Information Infrastructure Reference Model (III-RM) in the Interoperable Enterprise Business Scenario (K022). This is freely available for download from the Business Scenarios section of The Open Group online bookstore at www.opengroup.org/bookstore.
• #31: The coarsest breakdown of the TRM is shown in Technical Reference Model - High-Level View , which shows three major entities (Application Software, Application Platform, and Communications Infrastructure) connected by two interfaces (Application Platform Interface and Communications Infrastructure Interface). The diagram says nothing about the detailed relationships between the entities; only that they exist. Each of the elements in this diagram will be discussed in detail later.
• #32: The detailed TRM is only a depiction of the TRM entities: it neither implies nor inhibits inter-relationships among them. IT architectures derived from TOGAF may differ greatly depending on the requirements of the information system. In practice, many architectures will not include all of the services discussed here, and many will include additional services to support Application Software that is specific to the organization or to its vertical industry. In building an architecture, users of TOGAF should assess their own requirements and select the services, interfaces, and standards that satisfy their own business needs. (Ch 43 of TOGAF)
• #33: This is pronounced I3-RM. Closer to the solution space than the TRM. An example of a Common Systems Architecture So a lower level abstraction than the TRM Based on the TRM Aimed at the helping the design of architectures to enable and support the vision of Boundaryless Information Flow III-RM The Open Group has documented the business scenario that led to the creation of the Integrated Information Infrastructure Reference Model (III-RM) in the Interoperable Enterprise Business Scenario (K022). This is freely available for download from the Business Scenarios section of The Open Group online bookstore at www.opengroup.org/bookstore.
• #34: TOGAF 9 provides an Architecture Capability Framework that is a set of reference materials and guidelines for establishing an architecture function or capability within an organization. A structured definition of the organizations, skills, roles and responsibilities to establish and operate an Enterprise Architecture, including: Terms of Reference for an Architecture Board Guidance on measuring levels of Architecture Compliance against Architecture contracts Processes and organization structures required to operate Architecture Governance Techniques for assessing Architecture Maturity An overview of the Skills required by practicing architects
• #38: The TOGAF For People Certification program for TOGAF 9 has two levels of certification, an entry level known as TOGAF 9 Foundation and a higher level known as TOGAF 9 Certified These are described in further detail on the next few slides
• #40: This is a brief summary of TOGAF 9.1.
• #42: The TOGAF Specification
• #43: The TOGAF Pocket Guide
• #44: The TOGAF Certification Self Study Pack 2nd edition covers TOGAF 9.1