Review of
                   The Open Group Architecture Framework
                        (TOGAF) v. 8, ”Enterprise Editi...
TIETOTEKNIIKAN TUTKIMUSINSTITUUTTI                                               TOGAF 8 Review      1
20.10.2004         ...
TIETOTEKNIIKAN TUTKIMUSINSTITUUTTI                          TOGAF 8 Review   2
20.10.2004                                 ...
TIETOTEKNIIKAN TUTKIMUSINSTITUUTTI                                TOGAF 8 Review   3
20.10.2004                           ...
TIETOTEKNIIKAN TUTKIMUSINSTITUUTTI                    TOGAF 8 Review   4
20.10.2004                                       ...
TIETOTEKNIIKAN TUTKIMUSINSTITUUTTI                     TOGAF 8 Review   5
20.10.2004                                      ...
TIETOTEKNIIKAN TUTKIMUSINSTITUUTTI                       TOGAF 8 Review   6
20.10.2004                                    ...
TIETOTEKNIIKAN TUTKIMUSINSTITUUTTI                                                   TOGAF 8 Review        7
20.10.2004   ...
TIETOTEKNIIKAN TUTKIMUSINSTITUUTTI                     TOGAF 8 Review   8
20.10.2004                                      ...
TIETOTEKNIIKAN TUTKIMUSINSTITUUTTI                     TOGAF 8 Review   9
20.10.2004                                      ...
TIETOTEKNIIKAN TUTKIMUSINSTITUUTTI                                                                      TOGAF 8 Review   1...
TIETOTEKNIIKAN TUTKIMUSINSTITUUTTI                    TOGAF 8 Review   11
20.10.2004                                      ...
TIETOTEKNIIKAN TUTKIMUSINSTITUUTTI                    TOGAF 8 Review   12
20.10.2004                                      ...
TIETOTEKNIIKAN TUTKIMUSINSTITUUTTI                   TOGAF 8 Review   13
20.10.2004                                       ...
TIETOTEKNIIKAN TUTKIMUSINSTITUUTTI                       TOGAF 8 Review   14
20.10.2004                                   ...
Upcoming SlideShare
Loading in …5
×

Review of The Open Group Architecture Framework (TOGAF) v. 8 ...

2,545 views

Published on

Published in: Education, Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,545
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
177
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Review of The Open Group Architecture Framework (TOGAF) v. 8 ...

  1. 1. Review of The Open Group Architecture Framework (TOGAF) v. 8, ”Enterprise Edition” LARKKI Version: 0.3 Classification: Public Author: Mirja Pulkkinen Date: 20.10.2004 State: Draft
  2. 2. TIETOTEKNIIKAN TUTKIMUSINSTITUUTTI TOGAF 8 Review 1 20.10.2004 Larkki 1 About TOGAF.......................................................................................................... 2 1.1 Roots of TOGAF .................................................................................................. 2 1.2 Purpose of TOGAF............................................................................................... 3 2 TOGAF Components................................................................................................ 4 2.1 Architecture Development Method ADM............................................................ 4 2.1.1 What is the ADM good for? ......................................................................... 5 2.1.2 ADM Phases ................................................................................................. 6 2.2 The enterprise continuum ..................................................................................... 6 2.2.1 Technical reference model (TRM) ............................................................... 7 2.2.2 Standards information base (SIB) ................................................................ 9 2.2.3 Integrated Information Infrastructure Reference Model (III-RM) ............... 9 2.3 Resource base ..................................................................................................... 10 2.3.1 Architecture views: general guidelines for developing views.................... 11 2.3.2 Building blocks........................................................................................... 11 2.3.3 Business process domain views and Business scenarios............................ 12 3 TOGAF and other efforts in the field of architectures ........................................... 13 Frameworks and other work related to the US Federal Government Agencies ......... 13 Standards that have influenced the development of TOGAF..................................... 13 Commercial EA methodologies ................................................................................. 13 Other efforts................................................................................................................ 13 References ...................................................................................................................... 14
  3. 3. TIETOTEKNIIKAN TUTKIMUSINSTITUUTTI TOGAF 8 Review 2 20.10.2004 Larkki 1 About TOGAF TOGAF, The Open Group Architecture Framework, is an attempt to create a generic architecture framework for development and management of software intensive systems within an enterprise. The framework is adaptable for use in any type of organisation. Version 8 ”Enterprise Edition” is devoted to enterprise architecture (EA), an organisation wide management tool for information and communication systems. The previous version of the framework, TOGAF 7, was renamed the ”Technical Edition” according to its technical emphasis. However, large parts of the framework remain the same in the new version. This report gives an overview on TOGAF 8. The approach in both versions is pronouncedly practical, the main focus being on the Architecture Development Method (ADM) and the process of EA management in an enterprise. TOGAF takes as a starting point, that several architecture frameworks exist that describe each a set of deliverables (outcomes / work products / outputs). Yet these frameworks or models do not advise in how to proceed in producing an architecture using the outputs. TOGAF sets therefore the main emphasis on the process expressed in ADM, and provides a set of deliverables (outputs) as an example. However, the use of any other set with the process model is encouraged. The Open group standards are industry standards that are developed by proven technical processes and supported by industry consensus. With issues, for which there are existing standards, TOGAF aims at standard conformance. 1.1 Roots of TOGAF TOGAF is developed and maintained by The Open Group, “an international vendor and technology-neutral consortium that is committed to delivering greater business efficiency by bringing together buyers and suppliers of information technology” (The Open Group 2003). The work behind TOGAF bases on a large part on the United States Federal Government offices’ Enterprise Architecture efforts: the FEA (Federal Enterprise Architecture with FEAF framework), TEAF (Treasury EA framework), C4ISR1 (Department of Defence), as well as the CIO council’s Practical Guide to Federal Enterprise Architecture (Figure 1). (FEAPMO 2003) The predecessor of C4ISR, TAFIM (Department of Defence Technical Architecture Framework for Information Management) is a direct ancestor of TOGAF. (FEAPMO 1 Command, Control, Computers, Communications (C4), Intelligence, Surveillance, and Reconnaissance (ISR), the US Department of Defence.
  4. 4. TIETOTEKNIIKAN TUTKIMUSINSTITUUTTI TOGAF 8 Review 3 20.10.2004 Larkki 2003) Also the ISO/IEC 14252 Technical Report, Guide to the POSIX2 Open System Environment, that bases on TAFIM, is part of the roots of TOGAF (see footnote 2 for further references). The Open Group has collated the work and ideas comprised in these frameworks and guidelines to a general framework and method, and is continuing their development independently of these frameworks. Besides these specific frameworks, also the more generic Zachman Framework for Information Systems Architecture (Zachman 1987, Sowa and Zachman 1992), later renamed as Framework for Enterprise Architecture, is appreciated as a de facto standard. It provides a way to classify the design artefacts in EA development. Also other efforts in the field (frameworks, reference models and standards) are actively taken into account in the development of TOGAF. TOGAF Main Ancestors POSIX TAFIM FEAF TEAF The CIO council’s Practical Guide to Federal Enterprise Architecture C4ISR TOGAF Figure 1: Roots of TOGAF 1.2 Purpose of TOGAF TOGAF is a freely available architecture framework and a methodology applicable for any organisation. It has not been created for commercial use in the first place, but it can be licensed for that purpose also. Industry specific architecture frameworks are taken into account in the framework, but the customisation of the method remains a task of the user organisation. Although the focus is on user organisation EA management, IT service providers can make use of TOGAF. However, the framework and the method are not directly applicable for the use in their customer cases. 2 ”Version 3 is also ISO/IEC 9945:2002. ISO/IEC 9945:2002 is the third edition of ISO/IEC 9945 and incorporates the former ISO/IEC 9945-1:1996 (POSIX.1), and ISO/IEC 9945-2:1993 (POSIX.2) plus subsequent IEEE amendments” (http://www.opengroup.org)
  5. 5. TIETOTEKNIIKAN TUTKIMUSINSTITUUTTI TOGAF 8 Review 4 20.10.2004 Larkki 2 TOGAF Components The three main components of TOGAF are: 1. Architecture Development Method (ADM) 2. Foundation Architecture, that consists of • A Technical Reference Model (TRM) • A Standards Information Base (SIB) • Integrated Information Infrastructure Reference Model (III-RM) • Building Blocks Information Base (BBIB, organization specific) 3. Resource Base In TOGAF terms, the task of designing an organisation architecture draws on - foundation architectures - common systems architectures - industry architectures All of these can be further developed by new insights, won in any of them; this is why the so-called Architecture Continuum is represented with two-way relationships (See Figure 3 below). Foundation architecture is a concept that refers to various architecture frameworks and reference architectures. In TOGAF, this reference architecture is the TOGAF Technical Reference model (TRM). Further, TOGAF draws on a Standards Information Base (SIB), which is a collection of standards, related to building of software intensive systems. A subset of the TRM for information integration is the Integrated Information Infrastructure Reference Model III-RM. Core of the TOGAF framework is the Architecture Development Method (ADM), which is a model process with input and output descriptions for the process phases. Further, TOGAF provides a comprehensive selection of architecture resources, management tools and techniques (See 2.3). Also, the documentation contains an account of other frameworks for work with architectures. These frameworks are compared with TOGAF and correspondences with TOGAF concepts are pointed out. 2.1 Architecture Development Method ADM Architecture Development Method consists of cyclic architecture development phases, with the phases concentrating on either the development of a viewpoint, an architecture, or tasks related with architecture management. (See Figure 2) The phases can be expanded to development cycles. Fully defined is the Technology Architecture development cycle.
  6. 6. TIETOTEKNIIKAN TUTKIMUSINSTITUUTTI TOGAF 8 Review 5 20.10.2004 Larkki Besides the cycle, ADM has comprehensive lists of required inputs and the produced outputs for a phase. Figure 2: The TOGAF 8 ADM Cycle (© The Open Group. Published with the kind permission of The Open Group) 2.1.1 What is the ADM good for? The developers of ADM have had on mind the enterprise architecture development and management of a single user organisation or enterprise (a corporation or a company). The architecture continuum concept is the starting point of the method. ADM is seen as a generic method, that needs adaptation for use in specific industry cases. Modification, extensions or other customisation efforts are needed for use in an organisation. ADM can be used as a reference methodology, but is not as such ready to be used in IT companies that are providing architecture consultation and development services.
  7. 7. TIETOTEKNIIKAN TUTKIMUSINSTITUUTTI TOGAF 8 Review 6 20.10.2004 Larkki 2.1.2 ADM Phases The ADM method consists of eight main phases. As preliminary work, the enterprise architecture framework and architecture principles are fixed for the effort. In the following, a short description of the phases. - A. Architecture vision is the analysis phase of EA project. The project is organised; the scope and domain requirements and constraints are stated. Business scenarios can be used for this. - B. In the Business architecture phase, the current baseline architecture is stated, target architecture is designed and a gap analysis between the two takes place. - C. Information systems architecture consists of the parts Data and Applications. For Data architecture, the types and sources of data needed in the enterprise are defined and a data model is created. A gap analysis is conducted and data model is compared with the business architecture. As to the applications, the applications needed to meet the specified business requirements and data model are turned into an applications architecture and are checked back with the business architecture. - D. For Technology architecture, the previous phases deliver inputs. In this phase, a baseline architecture is stated, and the target technology architecture is designed. - The phases E, Opportunities and solutions is the evaluation phase, where the technology and architecture solutions are selected. - Phase F, Migration planning, is the point for checking dependencies in the environment and preparing for implementation of the target architecture. - G. Implementation and Governance is about the administration of implementation and deployment phase of the development project. - H. Architecture change management is the maintenance phase. A new baseline is created and changes in business environment are monitored as well as new technology opportunities. 2.2 The enterprise continuum The enterprise continuum provides (See Figure 3) a map for dealing with architecture issues in the organisation. Parts of it are the architecture continuum and the solutions continuum. The architecture continuum is a generic representation of architectures and shows the relations of them, architecture building blocks and architectural models. The solutions continuum is a tool to manage the concrete implementation of the architectures. It follows the same pattern as the architecture continuum. The TRM, SIB and III-RM, that are briefly presented next in this review, provide comprehensive sets of details about the generic reference architectures.
  8. 8. TIETOTEKNIIKAN TUTKIMUSINSTITUUTTI TOGAF 8 Review 7 20.10.2004 Larkki Enterprise Continuum Architecture Continuum Foundation Common Systems Industry Organization Architectures Architectures Architectures Architectures Business Applications Qualities Guides & Guides & Guides & Guides & Supports Supports Supports Supports Products & Systems Industry Organization Services Solutions Solutions Solutions Solutions Continuum Introduction to TOGAF 4 of 5 Copyright © 1997 - 2001 Figure 3 The Enterprise Continuum (© The Open Group. Published with the kind permission of The Open Group) 2.2.1 Technical reference model (TRM) The technical reference model consists of three entities, and two interfaces joining them together (See Figure 4): - Application software and application platform are joined with application platform interface - Application platform is joined with communications infrastructure with communications infrastructure interface
  9. 9. TIETOTEKNIIKAN TUTKIMUSINSTITUUTTI TOGAF 8 Review 8 20.10.2004 Larkki Figure 4: Technical reference model, a high level view (© The Open Group. Published with the kind permission of The Open Group) The TRM detailed view (Figure 5) provides an overview of the areas of technology architecture and their relations. The categories of applications and application platform services that form the technology base of an enterprise architecture are presented in one context. Application platform service categories are given in a comprehensive listing by category in TOGAF 8 documentation. Qualities, that are also included in the detailed technical model, fall into following four main categories: - availability - assurance (security etc.) - usability - adaptability (interoperability etc.)
  10. 10. TIETOTEKNIIKAN TUTKIMUSINSTITUUTTI TOGAF 8 Review 9 20.10.2004 Larkki Figure 5: Technical reference model, detailed view (© The Open Group. Published with the kind permission of The Open Group) 2.2.2 Standards information base (SIB) The Standards information base is besides the TRM part of the TOGAF foundation architecture. It is a database of facts and guidance about information systems standards, giving information e.g. on all the areas presented in the TRM detailed view. The standards come from standard organisations like ISO and IEEE or other standard creating bodies like WWW Consortium and OMG. 2.2.3 Integrated Information Infrastructure Reference Model (III-RM) The III-RM is a subset of the TRM. It is an application architecture reference model for an integrated information infrastructure. It consists of the components - Business applications - Infrastructure applications - Application platform - Interfaces - Qualities (e.g. security, mobility, performance..) The III-RM enriches the TRM with integration approach and supports enterprise integration efforts (See Figure 6).
  11. 11. TIETOTEKNIIKAN TUTKIMUSINSTITUUTTI TOGAF 8 Review 10 20.10.2004 Larkki Boundaryless Information Flow … Sell Space … needs access to Customer Support information that was not Processes Selling necessarily designed to leave its original domain. Internal Space Manufacturing Legal Finance Assembling Online Systems Buy Space Design Procuring Systems ERP Systems Requirements Systems Procurement Systems Systems 29 April, 2003 6 (C) The Open Group 2003 Figure 6 An example of an IRM model (© The Open Group. Published with the kind permission of The Open Group) 2.3 Resource base The resource base contains good practices for development and management of user organisation enterprise architectures. There are several issues to be established in an organisation wishing to successfully manage its enterprise architecture. TOGAF deals with: - Architecture board - Architecture compliance - Architecture contracts - Architecture patterns - Architecture principles. Architecture board is a body for discussion of EA issues and co-ordination of EA development within an organisation. Architecture contracts and architecture principles are tools to streamline the EA management and development efforts of an organisation. Architecture compliance and architecture patterns are concrete guidelines for EA development and deal with the technological level. In this review, some of these resources included in TOGAF 8 are looked at briefly. Those items were selected that most likely find interest within the scope of LARKKI project.
  12. 12. TIETOTEKNIIKAN TUTKIMUSINSTITUUTTI TOGAF 8 Review 11 20.10.2004 Larkki In addition to the items listed above, also the different architectural viewpoints are discussed, and TOGAF gives a recommended set of viewpoints and views, which are next presented briefly. 2.3.1 Architecture views: general guidelines for developing views The core viewpoints and views are: - User, planner and business manager viewpoint: Business architecture views - Database designers and administrator viewpoint: Data architecture views - Systems and software engineer viewpoint: Application architecture views - Acquirer, operator, communications engineer, and systems administrator and manager viewpoint: Technology architecture views TOGAF 8 thus suggests four dimensions or four architectures to be the main points of view for enterprise architecture management and development: Business, Data, Application and Technology architecture. In addition to these general viewpoints and corresponding views, there are several composite views that cover all the viewpoints: - Enterprise security view - Enterprise manageability view - Enterprise quality of service view - Enterprise mobility view 2.3.2 Building blocks Building blocks are interoperable packages of functionality services with published interfaces, which may have multiple implementations with different building blocks and thus aid reuse of previously built constructs. The architecture building blocks (ABB) relate to the architecture continuum, and the solutions building blocks relate to the solutions continuum (SBB). The use of building blocks can be integrated into the ADM method. BIBB is a database in which architecture constructs are saved for later retrieval and reuse.
  13. 13. TIETOTEKNIIKAN TUTKIMUSINSTITUUTTI TOGAF 8 Review 12 20.10.2004 Larkki 2.3.3 Business process domain views and Business scenarios Business process domain views and business scenarios are techniques for business requirements elicitation, and complement the ADM method. Business process domain is a concept that aids the development of IT support for business processes. These processes often cross organisational boundaries, and are thus difficult to capture with a more conventional domain concept that bases on functional organisation structure. Business scenarios are used the architecture being planned and to refine the business requirements for the architecture being designed. The business scenario technique is aimed at requirements elicitation and collection of evaluation criteria for architecture and technology solutions. “SMART” business scenarios are defined as - Specific (specify the business requirement precisely) - Measurable (gives clear metrics for success or failure) - Actionable (clear segmentation of the problem and a basis for determining elements and plans for the solution) - Realistic (problem can be solved within reality, time and cost constraints) - Time-bound (clear statement of expiration of the opportunity) Following elements are identified and documented in a business scenario process: - The problem and ranking of the problem - The business and technical environment (scenario models) - Desired objectives - Human actors or participants - Computer actors or computing elements - Roles, responsibilities and measures of success per actor; the required scripts per actor and the results of handling the situation. As the last step, the fitness for purpose is checked, and refinement is undertaken when necessary.
  14. 14. TIETOTEKNIIKAN TUTKIMUSINSTITUUTTI TOGAF 8 Review 13 20.10.2004 Larkki 3 TOGAF and other efforts in the field of architectures The approach suggested in TOGAF for architecture development supports abiding to the ANSI and IEEE standard for architecture descriptions (ANSI/IEEE Std 1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems.) TOGAF is in conformance with the Zachman information systems architecture framework. In the TOGAF 8 document, a comparison is provided to the Zachman framework most extensively, and also to several other frameworks and reference models: Frameworks and other work related to the US Federal Government Agencies (FEAPMO 2003) - C4ISR - FEAF - TAFIM - TEAF - Federal Enterprise Architecture – Practical Guide (CIO council) Standards that have influenced the development of TOGAF - ISO/IEC 14252 (IEEE Std. 1003.0) Commercial EA methodologies - EAP (Spewak and Hill1992) - NCR EAF Other efforts - CORBA Middleware architecture for object oriented distributed systems - RM-ODP Object management reference model for distributed object oriented systems - SPIRIT (The Service Provider’s Integrated Requirements for Information Technology) A set of specifications for software components for general purpose computing platforms.
  15. 15. TIETOTEKNIIKAN TUTKIMUSINSTITUUTTI TOGAF 8 Review 14 20.10.2004 Larkki References FEAPMO Federal Enterprise Architecture Program Management Office http://www.feapmo.gov 04.03.2003 Federal Enterprise Architecture (FEA) http://www.feapmo.gov/fea.htm 07.03.2003, http://www.differentialtech.com/federal/enterprise_architecture.htm 21.03.2003 Federal Enterprise Architecture Framework (FEAF). Version 1.1 September 1999. The Chief Information Officers Council. Department of Defence Technical Architecture Framework for Information Management (TAFIM) Volume 1: Overview Version 3.0 30. April 1996. Defence Information Systems Agency Center for Standards. Department of Defence C4ISR (Command, Control, Communications, Computers Intelligence, Surveillance, Reconnaissance) Framework.18. December 1997. C4ISR Architecture Working Group. Treasury Enterprise Architecture Framework (TEAF). Version 1.0 July 2000. Department of the Treasury Chief Information Office Council. Practical Guide to Federal Enterprise Architecture. Version 1.0 February 2001. Chief Information Officer Council TOGAF Version 7, The Open Group Architecture Framework "Technical Edition", 2001. URL: http://www.opengroup.org/architecture/togaf/ TOGAF Version 8, The Open Group Architecture Framework "Enterprise Edition", Published in December 2002. URL: http://www.opengroup.org/architecture/togaf/ Zachman, J.A., A framework for information systems architecture. IBM Systems Journal, Vol. 26, No. 3. 276-292. IBM Corporation 1987. Sowa, J.F. and John A. Zachman: Extending and Formalizing the Framework for Information Systems Architecture. IBM Systems Journal Vol 31, No. 3. 590-616. IBM Corporation 1992. Spewak, J. and S. Hill: Enterprise Architecture Planning. Developing a Blueprint for Data Applications and Technology. John Wiley & Sons Inc. 1992.

×