Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

TOGAF Vs E-Tom

10,866 views

Published on

TOGAF Vs E-Tom

Published in: Software

TOGAF Vs E-Tom

  1. 1. Exploring synergies between TOGAF and Frameworx Industry Group Liaison - The Open Group Architecture Framework and TeleManagement Forum Frameworx Collaboration Project Technical Report Document 1 – Mapping of TOGAF and Frameworx - Business Process Framework (eTOM), Information Framework (SID) and Application Framework (TAM) Version 1.0 August, 2010 ãTM Forum 2008-2010
  2. 2. Exploring synergies between TOGAF and Frameworx Notice TMF and The Open Group No recipient of this document shall in any way interpret this document as representing a position or agreement of the TeleManagement Forum (TM Forum) or its members. This document is a draft working document of TM Forum and is provided solely for comments and evaluation. It is not a Forum Approved Document and is solely circulated for the purposes of assisting TM Forum in the preparation of a final document in furtherance of the aims and mission of TM Forum. Although it is a copyrighted document of TM Forum: · Members of TM Forum are only granted the limited copyright waiver to distribute this document within their companies and may not make paper or electronic copies for distribution outside of their companies. · Non-members of the TM Forum are not permitted to make copies (paper or electronic) of this draft document other than for their internal use for the sole purpose of making comments thereon directly to TM Forum. · If this document forms part of a supply of information in support of an Industry Group Liaison relationship, the document may only be used as part of the work identified in the Liaison and may not be used or further distributed for any other purposes Any use of this document by the recipient, other than as set forth specifically herein, is at its own risk, and under no circumstances will TM Forum be liable for direct or indirect damages or any costs or losses resulting from the use of this document by the recipient. This document is governed by all of the terms and conditions of the Agreement on Intellectual Property Rights between TM Forum and its members, and may involve a claim of patent rights by one or more TM Forum members or by non-members of TM Forum. Direct inquiries to the TM Forum office: 240 Headquarters Plaza, East Tower – 10th Floor, Morristown, NJ 07960 USA Tel No. +1 973 944 5100 Fax No. +1 973 944 5110 TM Forum Web Page: www.tmforum.org Document #, Version 0.1 © TM Forum 2008 -2010 Page 2 of 127
  3. 3. Exploring synergies between TOGAF and Frameworx The Open Group Notice All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the copyright owners. FOR ARCH FORUM ONLY: This White Paper is an informational document and does not form part of the TOGAF documentation set. Readers should note that this document has not been approved through the formal Open Group Standards Process and does not represent the formal consensus of The Open Group Architecture Forum. Boundaryless Information Flow™ and TOGAF™ are trademarks and Making Standards Work®, The Open Group®, UNIX®, and the “X” device are registered trademarks of The Open Group in the United States and other countries. All other trademarks are the property of their respective owners. All other brand, company, and product names are used for identification purposes only and may be trademarks that are the sole property of their respective owners. Using TOGAF 9 ………ISBN ………. Doc No Published by The Open Group, month, year Any comments relating to the material contained in this document may be submitted to: The Open Group, 44 Montgomery St. #960, San Francisco, CA 94104 or by email to: ogpubs@opengroup.org Document #, Version 0.1 © TM Forum 2008 -2010 Page 3 of 127
  4. 4. Exploring synergies between TOGAF and Frameworx Table of Contents Notice TMF and The Open Group......................................................................................................2 The Open Group, 44 Montgomery St. #960, San Francisco, CA 94104............................................3 or by email to:.................................................................................................................................... 3 List of Figures.................................................................................................................................... 6 Executive Summary...........................................................................................................................8 1. General information and introduction...........................................................................................10 1.1. Benefits of the mapping exercise...........................................................................................10 1.2. About TMF and Frameworx..................................................................................................13 1.2.1. Introduction...................................................................................................................13 1.2.2. The four components of the Frameworx family................................................................14 1.3. About The Open Group and TOGAF.....................................................................................18 1.3.1. Introduction...................................................................................................................18 1.3.2. Short overview of TOGAF..............................................................................................20 1.4. Positioning of TOGAF and TMF Frameworx at a glance.........................................................26 1.4.1. TOGAF and TMF Frameworx........................................................................................28 1.5. Sources used for the mapping...............................................................................................32 2. Frameworx & the Architecture Development Method (ADM)........................................................34 1.6. Preliminary Phase................................................................................................................34 1.7. Phase A – Architecture Vision...............................................................................................36 1.8. Phase B – Business Architecture...........................................................................................38 1.9. Phase C – Information Systems Architecture.........................................................................40 1.9.1. Data Architecture...........................................................................................................41 1.9.2. Application Architecture.................................................................................................41 1.10. Phase D – Technology Architecture.....................................................................................43 1.11. Summary of Phase E to H...................................................................................................44 1.12. Requirements Management................................................................................................48 3. ADM Guidelines & Techniques as applied to Frameworx.............................................................51 1.13. Introduction and Scope.......................................................................................................51 1.13.1. Guidelines for adapting the ADM process.....................................................................51 1.13.2. Techniques for architecture development......................................................................51 1.13.3. Scope.........................................................................................................................51 1.14. Applying Iteration to the ADM in different enterprise levels....................................................51 1.15. Security Architecture and the ADM......................................................................................55 1.16. Leveraging both TOGAF and Frameworx in the context of SOA............................................55 1.17. Architecture Principles........................................................................................................55 1.18. Stakeholder Management...................................................................................................57 1.19. Architecture Patterns..........................................................................................................60 1.20. Business Scenarios............................................................................................................61 1.21. Gap Analysis......................................................................................................................63 1.22. Migration Planning Techniques...........................................................................................65 Document #, Version 0.1 © TM Forum 2008 -2010 Page 4 of 127
  5. 5. Exploring synergies between TOGAF and Frameworx 1.23. Business Transformation Readiness Assessment................................................................70 1.24. Risk Management..............................................................................................................71 1.25. Capability Based Planning..................................................................................................73 4. Architecture Content Framework and synergies with Frameworx...............................................75 1.26. Introduction and Scope.......................................................................................................75 1.27. Content Metamodel............................................................................................................75 1.28. Architectural Artifacts..........................................................................................................80 1.29. Architectural Deliverables....................................................................................................82 1.30. Building Blocks...................................................................................................................86 5. Enterprise Continuum and Tools and synergies with Frameworx................................................87 1.31. Introduction and Scope.......................................................................................................87 1.32. Enterprise Continuum.........................................................................................................87 1.32.1. Architecture Continuum...............................................................................................87 1.32.2. Solutions Continuum...................................................................................................87 1.33. Architecture Partitioning......................................................................................................88 1.34. Architecture Repository.......................................................................................................93 1.35. Tools for Architecture Development.....................................................................................95 6. TOGAF Reference Models and their relevance to Frameworx......................................................97 1.36. Introduction and Scope.......................................................................................................97 1.37. Foundation Architecture: Technical Reference Model...........................................................97 1.38. Integrated Information Infrastructure Reference Model..........................................................97 7. Applying Architecture Capability Framework to Frameworx........................................................98 1.39. Introduction and Scope.......................................................................................................98 1.40. Establishing an Architecture Capability................................................................................98 1.41. Architecture Board..............................................................................................................98 1.42. Architecture Compliance.....................................................................................................99 1.43. Architecture Contracts.......................................................................................................102 1.44. Architecture Governance...................................................................................................105 1.45. Architecture Maturity Models.............................................................................................108 1.46. Architecture Skills Framework...........................................................................................111 8. Summary of synergies and complementarities...........................................................................114 Appendix A: Quick Reference Guide TOGAF – Frameworx..........................................................118 Appendix B Process description metamodel................................................................................119 Appendix C Glossary, Terms and abbreviations...........................................................................120 9. Administration of the document..................................................................................................122 1.47. Document History.............................................................................................................122 1.47.1. Version History..........................................................................................................122 1.47.2. Release History.........................................................................................................123 1.48. Company Contact Details.................................................................................................123 1.49. IPR releases and patent disclosures..................................................................................124 1.50. Acknowledgements..........................................................................................................124 10. References.................................................................................................................................125 Annex Clarification of Information and Data..................................................................................126 Document #, Version 0.1 © TM Forum 2008 -2010 Page 5 of 127
  6. 6. Exploring synergies between TOGAF and Frameworx List of Figures Figure 1 – Frameworx blueprint......................................................................................................14 Figure 2 – Frameworx eTOM Level 1 View.......................................................................................15 Figure 3 – Frameworx SID...............................................................................................................16 Figure 4 – Frameworx TAM...............................................................................................................17 Figure 5– Frameworx – Integration Framework relationships........................................................18 Figure 6 – TOGAF development........................................................................................................19 Figure 7 – TOGAF Core Components...............................................................................................21 Figure 8 – TOGAF ADM.....................................................................................................................22 Figure 9 – TOGAF Deliverables.........................................................................................................23 Figure 10 – TOGAF Metamodel....................................................................................................23 Figure 11 – TOGAF Continuum.........................................................................................................24 Figure 12 – TOGAF Repository.........................................................................................................25 Figure 13 – TOGAF Capability Framework........................................................................................26 Figure 14 – TOGAF – Frameworx mapping overview.......................................................................27 Figure 15 – TOGAF ADM – Frameworx mapping overview..............................................................28 Figure 16 – TOGAF – Frameworx phase 1 mapping eTOM, SID, TAM overview..............................30 Figure 17 – TOGAF – Frameworx phase 1 mapping complete overview..........................................31 Figure 18 – TOGAF Preliminary Phase.............................................................................................34 Figure 19 – TOGAF Architecture Vision............................................................................................36 Figure 20 – TOGAF Business Architecture...................................................................................38 Figure 21 – TOGAF Information Systems Architecture.................................................................41 Figure 22 – TOGAF Technology Architecture...................................................................................43 Figure 23 – TOGAF Phase Requirements Management...................................................................48 Figure 24 – TOGAF Phase Requirements Management - Steps.....................................................49 Figure 25 – TOGAF Iteration Cycles and Frameworx solutions.......................................................52 Figure 26 – TOGAF different enterprise levels................................................................................53 Figure 27 – TOGAF ADM and different enterprise levels.................................................................54 Figure 28 – Stakeholder Analysis...................................................................................................58 Figure 29 – Stakeholder Power Grid.................................................................................................58 Figure 30 – Business Scenarios and Frameworx............................................................................62 Document #, Version 0.1 © TM Forum 2008 -2010 Page 6 of 127
  7. 7. Exploring synergies between TOGAF and Frameworx Figure 31 – Business Scenario in TOGAF and Assessment Methodology in Frameworx...............62 Figure 32 – Gap analysis................................................................................................................64 Figure 33 – Gap Implementation Factor Assessment and Deduction Matrix...................................66 Figure 34 – TOGAF Consolidated Gaps, Solution & Dependencies Matrix......................................66 Figure 35 – TOGAF Gaps, Solution & Dependencies Matrix with Frameworx services...................67 Figure 36 – TOGAF Architecture Definition Increments Table with Frameworx services................67 Figure 37 – TOGAF State Evolution Table........................................................................................68 Figure 38 – TOGAF State Evolution Table - Frameworx Services....................................................68 Figure 39 – TOGAF Business Information Interoperability Matrix....................................................69 Figure 40 – TOGAF Summary table of Business Transformation Readiness Assessment.............71 Figure 41 – Risk Classification Scheme.........................................................................................72 Figure 42 – Risk Identification Worksheet......................................................................................72 Figure 43 – Capability Based Planning and Frameworx..................................................................74 Figure 44 – TOGAF – Content Metamodel with extensions and mapping to Frameworx.................77 Figure 45 – TOGAF – Artifacts and Frameworx solutions...............................................................81 Figure 46 – Architecture Partitioning with Frameworx - Examples..................................................91 Figure 47 – Architecture Partitioning with Frameworx - Examples..................................................92 Figure 48 – TOGAF – Partitioning and Frameworx solutions..........................................................93 Figure 49 – TOGAF – Repository and Frameworx solutions...........................................................94 Figure 50 – TOGAF Architecture Governance Process.................................................................107 Figure 51 – DEN-ng Mapping.....................................................................................................127 Document #, Version 0.1 © TM Forum 2008 -2010 Page 7 of 127
  8. 8. Exploring synergies between TOGAF and Frameworx Executive Summary Members of both The Open Group (referred to onwards as TOG) and the TeleManagement Forum (referred to onwards as TMF) have the view that there is benefit in combining the assets of both organizations. Over the past decade TOG has focused on the methodology for producing and exploiting the architecture approach. On the other hand TMF has focused on developing industry reference frameworks aiming at accelerating the work of business and IT professionals in the telecom industry. Applying TOGAF methodology to TMF industry assets is expected to generate benefits because its users will understand how to apply specific assets of TOGAF or through a better understanding of how to use these assets in their own initiatives. It is the ambition of the TOG-TMF liaison to identify these benefits and have them exploited in both membership sides. More specifically this collaboration team has been chartered to explore synergies, identify integration points between the TM Forum Frameworx and TOGAF version 9 and then map and document such synergies. The results of this work so far have been documented in this Technical Report and summarized in a Quick Reference Guide included as an appendix to this document. Based on the actual situation regarding the ongoing development of the Integration Framework (previously known as Technology Neutral Architecture TNA) of the TMF, the result of the mapping activity is reported into two different documents: · Document 1: (this current document). Focus on the mapping of TOGAF to Frameworx: Business Process Framework (eTOM), Information Framework (SID) and Application Framework (TAM). The purpose of this mapping is to assess differences in their contents, complementarities and the areas for application– having the Enterprise Continuum in mind. · Document 2: (next target document for this liaison project). Focus on mapping TOGAF to Frameworx Integration Framework (previously known as TNA). The purpose of this mapping is to generate a common vocabulary between the two organizations for integration of information system assets i.e. includes both applications and their interfaces. The present Technical Report provides the mapping between TOGAF and Frameworx previously referred to as NGOSS (eTOM, SID and TAM). Insight into identified synergies During the exercise insights were gained into the synergies between the TOGAF and TMF assets. In summary the following were identified: Document #, Version 0.1 © TM Forum 2008 -2010 Page 8 of 127
  9. 9. Exploring synergies between TOGAF and Frameworx 1. Immediate synergies have been identified between the TOGAF ADM Phases Preliminary, A, B, C and Common Systems Architecture of the Enterprise Continuum. This document includes phases from Preliminary to Phase C of the TOGAF ADM. The synergies between business services formerly known as NGOSS contracts) and the Systems Architecture will be dealt with in a separate document. 2. TOGAF provides an Architecture Repository structure that can smoothly accommodate the mapping of TMF assets; this feature can be leveraged to identify and derive the added value of the content. 3. TMF assets can be classified as either industry frameworks or Common Systems Framework in (TOGAF) Enterprise Continuum language. TOGAF provides a widely accepted methodology to leverage these frameworks into the development of Enterprise Architecture. 4. Professionals that use TMF assets will find templates and guidelines in TOGAF that facilitates the transformation of such TMF asset into deliverables for a specific project/program. 5. TOGAF concepts as defined in the TOG Architecture Content Framework provide clear definitions as to what artifacts from TMF assets have to be developed in order to be consistent and comprehensive with an architecture construct. Recommendations: TMF workgroups can benefit from TOGAF by adopting the concepts and definitions from TOGAF. Once the charter of a workgroup is agreed, it is suggested to have a preliminary phase for identification of re-usable elements from TOGAF 9 before starting to produce the deliverables. The workgroup potentially gains in consistency, comprehensiveness and sustainability. The Open Group can benefit from TMF by considering the TMF assets as an exemplar and generalize it into a re-usable asset by other industries. The Open Group may consider adopting the TMF Forum Maturity model for tagging workgroup results. The authority level of artefacts or deliverables would gain transparency. Clients that consider adoption of TMF standards, can leverage their investment by adopting TOGAF 9 and exploit their complementarities at the same time. This enhances architecture governance, its comprehensiveness and sustainability. Document #, Version 0.1 © TM Forum 2008 -2010 Page 9 of 127
  10. 10. Exploring synergies between TOGAF and Frameworx 1. General information and introduction 1.1. Benefits of the mapping exercise Approaches for business and IT systems (data, applications and their interfaces) alignment vary greatly. The need for integration of domains within as well as crossing the borders of the enterprise also forces both executives and professionals to communicate about approaches for their business. A common vocabulary and terminology facilitates their challenging integration initiatives. TMF and TOG assets provide two different but complementary approaches for developing enterprise architectures. Therefore comparing both can be highly beneficial for different types of companies. A very broad audience can benefit from applying a combination of both models by leveraging the mapping concepts described throughout this document; such audiences embrace Project and Program Managers, Application Developers, Enterprise Architects, Domain Architects (Business, Application, Data, Infrastructure, Integration, Security, etc), Business Analysts, Product Development Managers, Marketing and Sales Leads and more senior staff, such as C-Level executives. TM Forum defined processes primarily deal with the definition and structure of common processes, rather than company-specific activity flow. However, in these industry frameworks the enterprise specific parts are missing. The TMF industry frameworks (eTOM, SID, TAM) coupled with the company specific strategic direction provide the foundation for a company’s enterprise architecture. In order to get a good understanding of the composition of a business, it is necessary to understand what value each activity contributes to the overall business goals, what the expected quality of the goals is, and what dependencies exist. eTOM provides a decomposition of each Service Provider’s business processes. However, it is non-specific about the goals of each process. By non-specific is meant that the goal is described in terms that could apply for each and all Service Provider (SP). This is sufficient for understanding the standard industry model, but not sufficient to understand the architecture of a specific SP. In fact eTOM describes and decomposes the working model of service providers regardless of the technology i.e. it is technology and environment neutral. This model differs slightly for telephony-only services, as compared to voice, data and video integrated services. The mapping exercise enables to understand very well and easy what the description covers. Document #, Version 0.1 © TM Forum 2008 -2010 Page 10 of 127
  11. 11. Exploring synergies between TOGAF and Frameworx In order to understand the architecture of a specific SP during a specific time frame, one has to take into account the objects that are transformed and the means (models, tools, expertise) supporting the transformation, as well as the actor(s) responsible for the transformation. Frameworx does not provide this information. The detailed information has to come from the business strategy (expressed in terms of business requirements). Leveraging the Business Process Framework (eTOM) can be instrumental in describing such enterprise architecture. Furthermore, TOGAF provides specific methodologies for analyzing this information, and developing a good understanding of the structure of the working model of such enterprise. eTOM provides the key ingredients needed to develop this understanding for a specific enterprise. It is comprehensive and the standard model covers most of the service provider’s scope. Therefore it can help initiatives effectively through the use of a common reference readily available. If working teams in such initiatives not only adopt the common descriptions, but also share the TOGAF methodology they will have even better and more effective communications and will reduce the overall effort of the transformation journey. Frameworx also includes a methodology. However, it has a different perspective than TOGAF. TMF provides the business lifecycle for developing Frameworx compliant solutions. TOGAF on the other hand, provides the full description of an Enterprise Architecture methodology, the detailed approach as well as comprehensive documentation; but at the end, both models complement very well each other. Some core benefits are: · Optimal development of new enterprise architecture by using both frameworks · ADM development process · Guidelines and techniques support the architectural development · Predefined templates provide a structure for an Architecture Repository · Criteria for tool evaluation and selection help to figure out the right tool · Deploying an optimal Architecture Capability to establish and consolidate the architecture function Optimal development of new enterprise architecture by using both frameworks: TOGAF describes both a method and a set of supporting tools & techniques for developing and maintaining enterprise architecture. Frameworx solutions describe Document #, Version 0.1 © TM Forum 2008 -2010 Page 11 of 127
  12. 12. Exploring synergies between TOGAF and Frameworx the working model of communications service providers in a generic way, without getting specific to individual service providers. By combining these capabilities, flaws and gaps will be reduced to a minimum. ADM development process: The TOGAF ADM provides a step by step approach for developing enterprise architecture: 1. separation of concerns: business, information, and application structures. 2. effective use of abstraction: separating the definition of what value has to be generated from how it will be generated 3. devising appropriate concepts: using the right concepts to build a conceptual model of the architecture. Furthermore, the components of the enterprise architecture capability include a detailed process for architecture implementation, migration, change and requirements management. This can be of high value to the Frameworx’ approach when the results are applied to the architecture development. Guidelines and techniques support the architectural development TOGAF provides guidelines & techniques, which provide varied methodologies and templates necessary to develop successful enterprise architecture. The thinking behind Frameworx solutions aligns with such guidelines and techniques, but do not describe detailed steps and methods to do the implementation in a particular way. Therefore, a combination of both models is highly useful for successful enterprise architecture. Predefined templates provide a structure for an Architecture Repository TOGAF provides an architecture repository template which can be used to structure all the architecture artifacts in enterprise architecture. Criteria for tool evaluation and selection help to figure out the right tool Most of the well known enterprise architecture tools (e.g.: PlanningIT, ARIS, Sparx, Metastorm, Casewise, Mega, etc.) are already TOGAF certified software solutions and therefore are mostly used by many enterprises for managing their enterprise architecture, including companies within the Telecommunications industry. TOGAF provides criteria for the evaluation and selection of these tools. Furthermore, this feature can also be used for the evaluation of architecture tools suggested by the TMF. Deploying an optimal Architecture Capability to establish and consolidate the architecture function Document #, Version 0.1 © TM Forum 2008 -2010 Page 12 of 127
  13. 13. Exploring synergies between TOGAF and Frameworx How to establish an architecture capability is one of the critical points during an architectural effort. TOGAF provides a chapter to support such purpose and it can be combined with several sections of the Frameworx solutions to a successful Architecture Capability. Especially, the Architecture Skills Framework and Architecture Governance comprehensively provide a detailed description of enterprise architecture methods for the telecommunication industry. This is of great additional value for the Frameworx assets of TMF 1.2. About TMF and Frameworx 1.2.1. Introduction About the TeleManagement Forum The TeleManagement Forum is the world’s leading industry association focused on enabling best-in-class IT for Service Providers in the communications, media, entertainment and cloud service markets. The TM Forum provides business-critical industry standards and expertise to enable the creation, delivery and monetization of digital services. TM Forum Frameworx Frameworx is a Telecoms industry specific framework developed by the TeleManagement Forum (TMF) to organize, specify, design and develop new generation management systems. It provides a standard method, common terminology and harmonized framework for the entire Telecom Industry value chain. Frameworx captures best practices and common definitions to meet the needs of a variety of stakeholders including service providers, equipment vendors, independent software vendors, and system integrators. By focusing on the cornerstones of the so called “lean operator” (smart operator who is able to reduce overall costs and optimize overall performance by leveraging Frameworx to automate its business processes and reducing the integration tax), Frameworx embraces intelligent problem solving and holistic solution design. Frameworx prones solution flexibility, enabling an enterprise to transform and improve the way it operates. Frameworx is undergoing further development; particularly with the so called TM Forum Integration Program or “TIP” and the “Integration Framework” previously known as TNA (Technology Neutral Architecture). Frameworx consists of four frameworks or content models which represent the cornerstones of a Service Provider (SP) Enterprise Architecture. These are: Document #, Version 0.1 © TM Forum 2008 -2010 Page 13 of 127
  14. 14. Exploring synergies between TOGAF and Frameworx - Process Framework (aka eTOM), - Information Framework (also known as (aka) SID), - Application Framework (aka TAM), and - Integration Framework (aka TNA) which describes Business Services (similar to contracts) and their lifecycle. The following description of the Frameworx lifecycle views and the Integration Framework are based on the existing draft documents, which are available on the TMF webpage. They are under development at this moment and therefore cannot be seen as final description of these sections. 1.2.2. The four components of the Frameworx family Figure 1 – Frameworx blueprint The Business Process Framework (aka eTOM – enhanced Telecom Operations Map) The eTOM defines most of the common business processes of a Service Provider environment based on the current state of technology, it provides a standard framework and Document #, Version 0.1 © TM Forum 2008 -2010 Page 14 of 127
  15. 15. Exploring synergies between TOGAF and Frameworx a common language for the definition and classification of most business processes within an SPs environment. It is useful as a standard catalog and classification scheme for business processes for an SP. However, it will always need alignment for specific business strategies in order to accommodate specific business requirements Figure 2 – Frameworx eTOM Level 1 View The Enterprise-wide Information Framework (aka SID – Shared Information and Data Model) The Information Framework provides a comprehensive common information and data model covering a wide set (though not all) of business concepts relevant within a SP’s environment. It provides a common language for software developers and integrators to use in describing information and data, which in turn allows easier and more effective integration across OSS/BSS (Operations Support Systems/Business Support Systems) software applications provided by multiple vendors. It provides the concepts and principles needed to define a shared information and data model (hence the name SID), the elements or entities of the model, the business oriented UML class models, as well as design oriented UML class models and sequence diagrams to provide a system view of the information and data. The model contains - similar to the process framework - generic information and data model, which needs adaptation to each specific enterprise. In both frameworks inter-change of level of detail might occur due to the service provider’s strategy. Document #, Version 0.1 © TM Forum 2008 -2010 Page 15 of 127
  16. 16. Exploring synergies between TOGAF and Frameworx Figure 3 – Frameworx SID The Application Framework (aka TAM – Telecom Application Map) The Application Framework has been developed as a working guide to help operators and their suppliers use a common reference map and language to navigate the complex application landscape that is typically found in fixed, mobile and convergent operators. Where the Process Framework provides a framework of processes, the Application Framework provides a framework of telecom applications. One should be aware that software vendors might have very specific combinations of application domains, due to focus on a specific challenge that has to be resolved. The TMF definition of application domains is inspired by what vendors choose as logical combinations of processes in their application, but attempts to remain as generic as possible. Again as is the case for eTOM and SID, a SP’s application landscape might look somewhat different depending on the specific business strategy or business model. Document #, Version 0.1 © TM Forum 2008 -2010 Page 16 of 127
  17. 17. Exploring synergies between TOGAF and Frameworx Figure 4 – Frameworx TAM The Integration Framework (aka TNA – Technology Neutral Architecture) The Integration Framework supersedes the TNA (Technology Neutral Architecture). It identifies the dependencies and unifies the TM Forum’s eTOM, SID, TAM, and TM Forum Interface program (TIP) in a service oriented architecture (SOA) context ensuring a seamless migration to a more advanced architecture supporting the service oriented enterprise (SOE). The key to the Integration Framework is a growing set of reusable building blocks, known as “business services”. These business services (also known previously as NGOSS contracts) are based on standard service oriented architecture (SOA) and work like Lego bricks – each relating to a standard business function and designed to support the enterprise’s portfolio of products. To build business services, the Integration Framework assembles elements from the eTOM and the SID, and adds capabilities from the TAM to form groups of business services (aka service platform). A platform service is created by taking specific information entities from the Information Framework and taking into account their interactions with business processes as defined in the Process framework and analyzing entities with common characteristics and supporting Document #, Version 0.1 © TM Forum 2008 -2010 Page 17 of 127
  18. 18. Exploring synergies between TOGAF and Frameworx these with application framework (TAM) capabilities. The relationship between a business service, a business process as defined in the eTOM and an information entity as defined in the SID is shown below. Figure 5– Frameworx – Integration Framework relationships 1.3. About The Open Group and TOGAF 1.3.1. Introduction About The Open Group The Open Group is a vendor-neutral and technology-neutral consortium, whose vision of Boundaryless Information Flow strives for enabling access to integrated information within and between enterprises based on open standards and global interoperability. The Open Group works with customers, suppliers, consortia, and other standards bodies. Its role is to capture, understand, and address current and emerging requirements, establish policies, and share best practices; to facilitate interoperability, develop consensus, and evolve and integrate specifications and Open Source technologies; to offer a comprehensive set of services to enhance the operational efficiency of consortia; and to operate the industry's premier certification service, including UNIX(R) system certification. Further information on The Open Group can be found at www.opengroup.org. Document #, Version 0.1 © TM Forum 2008 -2010 Page 18 of 127
  19. 19. Exploring synergies between TOGAF and Frameworx The Open Group of Architecture Framework (TOGAF) The Open Group Architecture Framework (TOGAF) is a framework — a detailed method a common vocabulary and a set of, supporting tools and templates — for developing enterprise architecture. It may be used freely by any organization wishing to develop enterprise architecture for use within that organization. The method is particularly useful when during initiatives the industry standards of TMF are transformed into enterprise specific frameworks. TOGAF is developed and maintained by members of The Open Group, working within the Architecture Forum. The original development of TOGAF Version 1 in 1995 was based on the Technical Architecture Framework for Information Management (TAFIM), developed by the US Department of Defense (DoD). The DoD gave The Open Group explicit permission and encouragement to create TOGAF by building on the TAFIM, which itself was the result of many years of development effort and many millions of dollars of US Government investment. Starting from this sound foundation, the members of The Open Group Architecture Forum have developed successive versions of TOGAF and published each one on The Open Group public web site. Figure 6 – TOGAF development The Open Group Architecture Framework (TOGAF) allows architectures to be developed that are consistent, reflect the needs of stakeholders, employ best practices, de-risk the architecture development process and finally provides a platform for adding value to the enterprise which uses TOGAF. Design Objectives of TOGAF 9: In comparison to TOGAF 8, TOGAF 9 is an evolution and not a revolution. TOGAF 9 has no changes to the top level processes but individual features from TOGAF 9 can be adopted into a TOGAF 8 environment. TOGAF 9 provides a stronger link to the business, than TOGAF 8. It provides a strategic planning and further deployment decisions steps. Document #, Version 0.1 © TM Forum 2008 -2010 Page 19 of 127
  20. 20. Exploring synergies between TOGAF and Frameworx Because of the new metamodel, further developed guideline and techniques and an improved structure, TOGAF 9 is much easier to use. What is new in TOGAF 9 The following sections are new in TOGAF 9: - Architecture Partitioning - Content Framework and Meta-Model - Capability Based Planning - Business Transformation Readiness - Architecture Repository - Stakeholder Management - Using TOGAF to develop Security Architectures - Using TOGAF to develop Service Oriented Architectures 1.3.2. Short overview of TOGAF TOGAF Core Concepts The core of TOGAF is represented by the ADM which provides a step by step approach to develop and apply enterprise architecture methodology. TOGAF 9 basically consists of different components, which interact closely with each other. The following picture shows the structure of such components. Document #, Version 0.1 © TM Forum 2008 -2010 Page 20 of 127
  21. 21. Exploring synergies between TOGAF and Frameworx Figure 7 – TOGAF Core Components Part II - TOGAF Architecture Development Method The ADM features a series of linked phases which enable a full life-cycle management of an Enterprise Architecture and which furthermore enable a path going from planning to operational development and changes. For each iteration of the ADM, a fresh decision must be taken as to: - The challenge to resolve with the architecture - The breadth of coverage of the enterprise to be defined - The level of detail to be defined - The extent of the time period aimed at, including the number and extent of any intermediate time periods - The architectural assets to be leveraged, including:  Assets created in previous iterations of the ADM cycle within the enterprise  Assets available elsewhere in the industry (other frameworks, systems models, vertical industry models, etc.) These decisions should be based on a practical assessment of resource and competence availability, and the value that can realistically be expected to accrue to the enterprise from the chosen scope of the architecture work. As a generic method, the ADM is intended to be used by enterprises in a wide variety of different geographies and applied in different vertical sectors/industry types. As such, it may be, but does not necessarily have to be, tailored to specific needs. The different phases of the ADM life-cycle management are shown in the following picture. Document #, Version 0.1 © TM Forum 2008 -2010 Page 21 of 127
  22. 22. Exploring synergies between TOGAF and Frameworx Figure 8 – TOGAF ADM Part IV - TOGAF Architecture Content Framework and Meta Model Deliverables, Artifacts and Building Blocks The Architecture Content Framework uses three categories to describe the type of architectural work product within the context of use: deliverables, artifacts and building blocks. Document #, Version 0.1 © TM Forum 2008 -2010 Page 22 of 127
  23. 23. Exploring synergies between TOGAF and Frameworx Figure 9 – TOGAF Deliverables The Content Metamodel The content metamodel provides a definition of all the types of building blocks that may exist within an architecture, showing how these building blocks can be described and related to one another. For example, when creating an architecture, an architect will identify applications, ‘‘data entities’’ held within applications, and technologies that implement those applications. These applications will in turn support particular groups of business user or actor, and will be used to fulfill ‘‘business services’’. The content metamodel identifies all of these concerns (i.e., application, data entity, technology, actor, and business service), shows the relationships that are possible between them (e.g., actors consume business services), and finally identifies artifacts that can be used to represent them. The following picture shows an overview about the content metamodel. Figure 10 – TOGAF Metamodel Part V - TOGAF Architecture Continuum and Tools Document #, Version 0.1 © TM Forum 2008 -2010 Page 23 of 127
  24. 24. Exploring synergies between TOGAF and Frameworx Architecture Continuum TOGAF includes the concept of the Enterprise Continuum, which 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. An overview of the structure and context for the Enterprise Continuum is shown in the following picture. Figure 11 – TOGAF Continuum Architecture Repository Document #, Version 0.1 © TM Forum 2008 -2010 Page 24 of 127
  25. 25. Exploring synergies between TOGAF and Frameworx 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. By means of the Enterprise Continuum and Architecture Repository, architects are encouraged to leverage all other relevant architectural resources and assets in developing an Organization-Specific Architecture. In this context, the TOGAF ADM can be regarded as describing a process lifecycle that operates at multiple levels within the organization, operating within a holistic governance framework and producing aligned outputs that reside in an Architecture Repository. The Enterprise Continuum provides a valuable context for understanding architectural models: it shows building blocks and their relationships to each other, and the constraints and requirements on a cycle of architecture development. The structure of the TOGAF Architecture Repository is shown in the following picture. Figure 12 – TOGAF Repository Document #, Version 0.1 © TM Forum 2008 -2010 Page 25 of 127
  26. 26. Exploring synergies between TOGAF and Frameworx Part VII - TOGAF Enterprise Architecture Capability Framework In order to carry out architectural activity effectively within an enterprise, it is necessary to put in place an appropriate business capability for architecture, through organization structures, roles, responsibilities, skills, and processes. An overview of the TOGAF architecture capability is shown in the following picture. Figure 13 – TOGAF Capability Framework 1.4. Positioning of TOGAF and TMF Frameworx at a glance TOGAF is a detailed method and a set of supporting tools for developing an enterprise architecture. Frameworx is a telecommunications industry specific framework to organize, design and develop distributed management systems. It provides a set of methods, best practices and industry agreed specifications. Document #, Version 0.1 © TM Forum 2008 -2010 Page 26 of 127
  27. 27. Exploring synergies between TOGAF and Frameworx The mapping starts with the TOGAF ADM and Frameworx. The other parts of TOGAF, which are Architecture Content Framework, Reference models, Guidelines & Techniques, Enterprise Continuum and Architecture Capability Framework will be covered in different chapters of this document. When appropriate, definitions are included in order to facilitate the reading and to describe the relationship. Furthermore, a Quick Reference Guide is provided as an annex at the end of this document; this guide compares the chapters and paragraphs to the various parts of Frameworx in detail. Figure 14 – TOGAF – Frameworx mapping overview Document #, Version 0.1 © TM Forum 2008 -2010 Page 27 of 127
  28. 28. Exploring synergies between TOGAF and Frameworx Figure 15 – TOGAF ADM – Frameworx mapping overview 1.4.1. TOGAF and TMF Frameworx In this chapter the difference between TOGAF and Frameworx is further discussed. In general it will help to reckon that TOGAF as a methodology framework and Frameworx is the content to which it can be applied. The Preliminary Phase as well as Phase A - Architecture vision of TOGAF provides the handles to start applying Frameworx in a specific situation. The Preliminary phase applies to the architecture capability. One has to agree beforehand which standards to use in the organization. The Architecture vision applies to all projects. It provides the link between the business vision, the architectural challenge and the specific initiative. TOGAF ADM and Frameworx The Preliminary Phase does not explicitly exist in Frameworx and is consequently to be considered as an add-on to Frameworx when an Enterprise Architecture approach is to be applied. At the Preliminary Phase, Frameworx and TOGAF can be identified and tailored as architecture reference frameworks for the enterprise architecture development approach. See section 1.6 for more detail on this. Concerning Phase A - Architecture Vision, it also represents a new part for Frameworx, as this is only covered partially by the latter in the form of definitions related to the formulation of the strategy of the enterprise. In this phase, TOGAF describes the baseline and scope of target architectures for all architecture Document #, Version 0.1 © TM Forum 2008 -2010 Page 28 of 127
  29. 29. Exploring synergies between TOGAF and Frameworx dimensions in line with Frameworx. Therefore, Frameworx needs to be considered within this phase for defining and describing the target architecture for the enterprise. As shown in figure 16, the three Frameworx solutions map mainly into Phases A, B, and C of the TOGAF ADM. The business process framework “enhanced Telecom Operations Map” (eTOM) describes the foundational business processes of a Telecommunication Service Provider (SP) and therefore maps to Phase B of TOGAF ADM. The “Shared Information and Data Model” (SID) provides a comprehensive common information and data model for a Telecom SP and it maps to phase C Data Architecture of TOGAF ADM. Additionally, the SID framework is linked to eTOM business processes across its various domains, which are composed of different sets of layered Aggregate Business Entities (ABEs). For this reason the iteration cycle “Architecture Definition iterations” of TOGAF part 19 “Applying Iteration to the ADM” also has an important role considering the creation of the overall architecture content by cycling through phases A, B, C of the TOGAF ADM. The “Telecom Application Map” (TAM) provides a framework of applications relevant to a Telecoms industry SP, which the latter can implement and leverage for the classification of its complex application landscape. SPs normally talk about BSS/O Systems (Business/Operations Support Systems), therefore, the TAM maps to Phase C Application Architecture of TOGAF ADM. The Integration Framework will be part of the mapping in document two. This mapping will be dealt with in the next phase of this liaison project. In the preliminary analysis it was recognized that the Phase D of TOGAF ADM does not map directly to the Integration Framework. Phase D refers to the technology architecture of IT. TOGAF does not include a specific integration phase in the ADM. Phases E to H of the TOGAF ADM refer to the architecture capability. Phase E and F prepare the implementation of the To-be architecture as defined in the ADM phases B, C and D of TOGAF. Frameworx solutions do not explicitly map to these ADM phases, but to be able to plan the activities and the roadmap for the implementation of the To-be architecture, each Frameworx solution has to be considered in regards to a consolidated gap analysis from phases B, C and D of the TOGAF ADM. Therefore, it could be necessary to review the different architectures and the corresponding Frameworx as part of a new iteration. Phase G - Implementation Governance reflects the active implementation and execution of the organization-specific development process. Frameworx solutions do not specifically map to Phase G of TOGAF ADM. Phase H - Architecture Change Management ensures the architecture achieves its original target business value. Frameworx do not explicitly map to this phase, but can Document #, Version 0.1 © TM Forum 2008 -2010 Page 29 of 127
  30. 30. Exploring synergies between TOGAF and Frameworx be seen as architectural input (deliverables and artifacts) to the change activities in this phase. The requirements management of the TOGAF ADM does not exist as a stand-alone component in Frameworx, this is partly why it does not map to it. eTOM does not specify measurable goals for processes. When the business strategy is applied and imposes specific business requirements it results in measurable goals for each process. These measurable goals can be considered as reflecting requirements that have to be captured and implemented in order to comply with the architecture vision. The Business Process framework (eTOM) provides a sound starting point to capture requirements in the form of Use Cases (high level use cases typically use level 2 processes, while detailed use cases use level 3 and 4 processes). Therefore the eTOM framework can be seen as an effective tool to address the challenge of effectively capturing business requirements and ensuring the accurate linkage of these requirements to the business processes. In summary the Frameworx Solutions eTOM, SID and TAM contribute to the execution of Phases A, B and C. Figure 16 – TOGAF – Frameworx phase 1 mapping eTOM, SID, TAM overview Document #, Version 0.1 © TM Forum 2008 -2010 Page 30 of 127
  31. 31. Exploring synergies between TOGAF and Frameworx Figure 17 – TOGAF – Frameworx phase 1 mapping complete overview TOGAF Enterprise Continuum and Frameworx Frameworx solutions eTOM, SID and TAM can be positioned as industry architectures in the Architecture Continuum. They have the potential to leverage the creation of an industry solution for targeted customer problems – e.g. Telecommunications industry. The Integration Framework is part of the Common Systems Architecture in the Enterprise Architecture Continuum. It will be discussed in document 2 – mapping of TOGAF to Frameworx solution Integration Framework. TOGAF Solutions and Frameworx Solutions Document #, Version 0.1 © TM Forum 2008 -2010 Page 31 of 127
  32. 32. Exploring synergies between TOGAF and Frameworx TOGAF Enterprise Continuum distinguishes two abstraction levels: architecture and solution. TOGAF refers to solutions as an instance or description of a solution that can be implemented. It is implementation specific and dependent. It refers to architecture when the description is solution neutral. The meaning of Solution in Frameworx is different. Frameworx refers to the Process, Information and Application frameworks as Solutions. However, these are Architectures in the terminology of TOGAF, since they are solution neutral. TOGAF ADM Guidelines and Techniques and Frameworx This chapter in TOGAF provides guidelines and techniques, which can be used to develop enterprise architecture. The Frameworx solutions provide a different perspective to map to various chapters of the TOGAF ADM TOGAF Architecture Content Framework and Frameworx In consideration of the Content Framework by ADM, the business architecture maps to the eTOM, the information systems architecture maps to the SID and TAM. Furthermore, the three Frameworx solutions can also be related to the scope which is defined in the TOGAF ADM - Architecture Vision Phase. TOGAF Architecture Capability Framework and Frameworx Implementing and establishing an architecture capability requires the design of the four domain architectures: Business, Information, Application and Technology. Therefore all three solutions in Frameworx (eTOM, SID, TAM) need to be considered in this part of TOGAF as supporting tools. TOGAF provides further information on the structure and processes required for an architecture capability. TOGAF TRM & III-RM and Frameworx This mapping is part of the document 2 mapping between TOGAF and Frameworx solution Integration Framework. 1.5. Sources used for the mapping This document is based on the following documents: Document #, Version 0.1 © TM Forum 2008 -2010 Page 32 of 127
  33. 33. Exploring synergies between TOGAF and Frameworx The Open Group: TOGAF 9 Version 2009 TeleManagement Forum: Frameworx solution Release V1.0; eTOM Version 8.0; SID Version 8.0; TAM Version 3.2; Book “NGOSS distilled 2005” (for eTOM, SID and TAM information) The documents for the Frameworx solution Integration Framework are not considered for this document. Document #, Version 0.1 © TM Forum 2008 -2010 Page 33 of 127
  34. 34. Exploring synergies between TOGAF and Frameworx 2. Frameworx & the Architecture Development Method (ADM) 1.6. Preliminary Phase The Preliminary Phase is the most important phase at the beginning of the enterprise architecture initiative. It mainly prepares the organization for a successful enterprise architecture by defining “where”, “what”, “why”, “who” and “how” enterprise architecture will be done. The main objectives of this phase are to identify the sponsor, stakeholders and other major stakeholders impacted by the business, to identify and scope the elements of the enterprise organizations, the definition or rather selection of an architecture footprint, frameworks, principles and tools and the confirmation of the governance. The enterprise's approach to re-use of architecture assets is a key part of both the framework definition and architecture principles. (Typically the principles will state the policy on re-use; and the framework will explain how re-use is affected.) Figure 18 – TOGAF Preliminary Phase Using TOGAF and Frameworx: The Preliminary Phase does not explicitly exist in Frameworx at present. Currently most SPs use their own existing procedures and processes to start a new enterprise architecture project. Some parts of this phase are not project specific, but have value for the complete initiative portfolio. The preliminary phase can also be seen as an entry point to a new TOGAF/ Frameworx based enterprise architecture initiative, as Document #, Version 0.1 © TM Forum 2008 -2010 Page 34 of 127
  35. 35. Exploring synergies between TOGAF and Frameworx such, it can be very beneficial to SPs to apply the method provided by this phase in the TOGAF ADM. After scoping the enterprise organizations impacted, the governance and the support frameworks need to be confirmed. The SID conformance & compliance criteria and conformance levels can be used together with the chapters 50 Architecture Governance and chapter 48 Architecture compliance of TOGAF to evaluate potential application acquisitions and to confirm the architecture governance process. Further details can be found in sections 7.4 Architecture Compliance and 7.6 Architecture Governance of this document. When defining and establishing the architecture team and organization, both TOGAF and Frameworx should be known by all involved architects and other team members of the EA project. Regarding Frameworx the respective eTOM, SID and TAM experts should be members of the architecture team as other stakeholders, like vendors, suppliers and Integrators too. Use the chapter 52 Architecture Skills Framework of TOGAF, see section 7.8 of this document, to basically identify the necessary knowledge and experience of each involved architect or rather team member. The architecture principles are an important anchor when establishing the architecture governance. Firstly use the information framework TAM to establish the 10 Telecom specific principles provided by Frameworx, see section 3.5 of this document. Furthermore, use the chapter 23 Architecture Principles of TOGAF to define and establish further principles which may be necessary to the EA project. The three solutions of Frameworx are identified as a deliverable framework for telecom-specific artifacts in regards to business, data, and application architecture. Contextually, identify the Architecture Content Framework of TOGAF (chapter 34 of TOGAF and section 4.2 of this document), compare it with Frameworx and finally identify re-usable components out of both for the enterprise architecture. The Architecture Continuum classifies Frameworx solutions eTOM, SID and TAM as industry-specific architecture as shown in section 5.2 of this document. After a specific time, every enterprise architecture team needs to evaluate the EA tools which can be used to develop the enterprise architecture. The chapter 42 of TOGAF and section 5.5 of this document provide detailed information how to identify and implement an EA tool. This section can also be used to identify and evaluate the telecom-specific tools suggested by Frameworx. Document #, Version 0.1 © TM Forum 2008 -2010 Page 35 of 127
  36. 36. Exploring synergies between TOGAF and Frameworx 1.7. Phase A – Architecture Vision Phase A - Architecture Vision, is essential to the architect’s “elevator pitch” in order to sell the benefits of the proposed enterprise architecture to the decision makers within the enterprise. The goal is to articulate the architecture vision that enables the business goals, responds to the strategic drivers, confirm the principles and addresses the stakeholders concerns and objectives. Clarifying and agreeing the purpose of the architecture effort is one of the key parts of this activity and the purpose needs to be clearly reflected in the vision that is created. Architecture projects are often undertaken with a specific purpose in mind, a specific set of business drivers that represent the return on investment for the stakeholders in the architecture development. Clarifying the purpose and demonstrating how it will be achieved by the proposed architecture development is the whole point of the architecture vision phase. Figure 19 – TOGAF Architecture Vision Using TOGAF and Frameworx The Architecture Vision Phase is a critical complement to all Frameworx components eTOM, SID, and TAM. It describes which challenges have to be resolved in the architecture that is to be developed. When establishing the architecture project, the objective of the architecture, the scope, the stakeholder’s concerns and business requirements need to be identified. TOGAF provides guidance on how to approach this. eTOM, SID and TAM support the architecture scoping and partitioning. For example, one has to define which architecture domains are considered and which breadth in eTOM and SID – i.e. levels – are in scope for the architecture approach. The defined scope will have implications for instance for the architecture effort that has to be estimated. Document #, Version 0.1 © TM Forum 2008 -2010 Page 36 of 127
  37. 37. Exploring synergies between TOGAF and Frameworx Considering the architecture capability, especially eTOM and SID can be used to support the identification of capabilities for the architecture project. Use the chapter 46 of TOGAF – Establishing Architecture Capability –, chapter 36.2.10 capability assessment and chapter 32 Capability based planning to identify the capabilities. Before scoping the architecture, quantify the enterprise’s readiness to undergo changes by the architecture project. Use the chapter 30 / section 3.12 of this document Business Transformation Readiness Assessment to quantify this situation. eTOM, SID and TAM also strongly support the definition of the architecture scope and partitioning. For example, you have to define which architecture domains you are going to consider and which breadth of eTOM and SID – means levels – you are going to use for the architecture approach. That clearly influences the architecture effort the architecture team has to estimate. Use the Frameworx solutions in connection with the chapter 40 of TOGAF Architecture Partitioning to define the architecture scope. The Frameworx solution TAM also supports the confirmation of architecture principles and should be used together with the chapter 23 of TOGAF / section 3.5 of this document Architecture Principles. The Frameworx solutions eTOM and SID should be considered when confirming the principles for business and data architecture. Finally, all solutions of Frameworx heavily support the development of the architecture vision for all architecture domains, especially for the target architecture. Use the chapter 26 of TOGAF / section 3.8 of this document Business Scenario in connection with the assessment methodology of Frameworx to develop the architecture vision. After developing the architecture vision, the business transformation risks should be identified using the chapter 31 of TOGAF / section 3.13 of this document Risk Management in connection with the Frameworx solutions. These solutions support the identification of risks in regards to relationships of processes, applications and infrastructure. At the end, produce the statement of architecture work using the chapter 37 of TOGAF / section 4.4 of this document Architecture Deliverables in connection with Frameworx to define the work products for the architecture project. Detailed mapping: Please refer to “Quick Reference Guide”. The eTOM, SID and TAM can be used during this phase to delineate the scope and boundaries of the considered domain. Document #, Version 0.1 © TM Forum 2008 -2010 Page 37 of 127
  38. 38. Exploring synergies between TOGAF and Frameworx 1.8. Phase B – Business Architecture The business architecture is the first architecture activity that needs to be undertaken. It is necessary for demonstrating the business value and requirements of subsequent technical architecture work to key stakeholders and its return on investment. Figure 20 – TOGAF Business Architecture Using TOGAF and Frameworx The business architecture describes the working model related to the defined architecture scope and architecture challenges that need to be addressed. The Document #, Version 0.1 © TM Forum 2008 -2010 Page 38 of 127
  39. 39. Exploring synergies between TOGAF and Frameworx business architecture reflects the business strategy/model and related challenges and shapes the detailed process decomposition of each process in the eTOM. Some processes might have to be added in order to complete the working model for a specific business strategy/model. eTOM describes the process, and identifies the relevant Aggregate Business Entity from the SID. These processes become enterprise specific by elaborating the goals into measurable output and by attributing the accountability for the outcome of a process to an actor or organizational function. SID most relevance is along Phase C. However, at the Information model level it makes also sense to include it in Phase B. At the highest level it defines the objects that are transformed along with the business processes. For example: the sales process transforms an OPPORTUNITY into a CUSTOMER. The lower level information objects on the other hand have to be elaborated according to the business strategy/business model. Use the eTOM Frameworx solution and the existing business models in the enterprise to define the baseline, target architecture and gaps describing building blocks, functions, processes, activities, services and roles and responsibilities of actors (RACI/CRUD). Consider the existing environment in the enterprise, identify the gaps and develop the different types of artifacts for the business architecture, which are catalogs, matrices and diagrams. The chapters 35.9 of TOGAF / 4.3 of this document Architecture Artifacts, chapter 41 of TOGAF / section 5.4 of this document Architecture Repository and chapter 27 of TOGAF / section 3.9 of this document Gap Analysis support the development of the business architecture in connection with eTOM and SID. Furthermore, use the chapter 51 of TOGAF / section 7.7 of this document Architecture Maturity Model in connection with the eTOM levels of maturity to develop the actual baseline architecture. After developing the business architecture, resolve the impacts across the enterprise and architecture landscape to identify the potential impact of the new business architecture to the existing landscape or rather baseline architecture. The focus of this impact assessment should mainly concentrate on the roles and responsibilities of the relevant stakeholders and the impact of the new business architecture to their power and concerns from their perspective. Use eTOM and chapter 36.2.18 of TOGAF / section 4.4 Architecture Deliverables. Additionally, check the original motivation for the architecture project with the stakeholders and the Stakeholder Management Technique of chapter 24 of TOGAF / section 3.6 of this document. Finally, develop the final business architecture including building blocks, functions, processes, roles and responsibilities and create the architecture definition document. Use eTOM and the chapter 36 of TOGAF / section 4.4 of this document Architecture Deliverables. Looking to the above-mentioned architecture development, the chapter 19 of TOGAF / section 3.2 of this document Applying iteration to the ADM can be seen as a very useful method to develop the business architecture by using eTOM and SID at the same time. The architecture definition iteration cycle clearly focuses on this matter and it also covers the application architecture of Frameworx solution TAM. Document #, Version 0.1 © TM Forum 2008 -2010 Page 39 of 127
  40. 40. Exploring synergies between TOGAF and Frameworx Detailed mapping: Please refer to “Quick Reference Guide”. 1.9. Phase C – Information Systems Architecture The objective of phase C Information Systems Architecture is to define the baseline and target architectures covering either or both (depending on the scope) the data and application domains. Document #, Version 0.1 © TM Forum 2008 -2010 Page 40 of 127
  41. 41. Exploring synergies between TOGAF and Frameworx Figure 21 – TOGAF Information Systems Architecture Phase C Information Systems Architecture in TOGAF is divided into data, and application architectures. Therefore, the mapping between TOGAF and Frameworx considers the architectures separately, as shown below. The TMF SID framework deals with both information and data as one framework. 1.9.1. Data Architecture The Information framework (SID) can be used to represent the data architecture in phase C of the TOGAFADM. The objective of the data architecture of TOGAF is to define the major types of (automated) data necessary to support the business in a way that is:  Understandable by stakeholders,  Complete and consistent,  Stable. It is important to note that this effort is not concerned with database design. The goal is to define the data entities, attributes and relationships relevant to the enterprise, not the design of logical or physical storage systems. However, linkages to existing files and databases may be included for reference. 1.9.2. Application Architecture The objective is to define the major types of applications necessary to process the data and support the business. It is important to note that this effort is not concerned with applications systems design. The goal is to define what kinds of application systems are relevant to the enterprise, and what those applications need to do in order to manage data and to present information to the human and computer systems across the enterprise. The applications are not described as computer systems, but as logical groups of capabilities that manage data objects in the Data Architecture and support the business functions. The applications and their capabilities are technology neutral. The applications are stable and relatively unchanging over time, whereas the technology used to implement them will change over time, based on the technologies currently available and changing business needs. Document #, Version 0.1 © TM Forum 2008 -2010 Page 41 of 127
  42. 42. Exploring synergies between TOGAF and Frameworx The mapping of the Frameworx TAM with the TOGAF Information Systems (Application Architecture) appears to be a rich area in terms of synergies between the two models. TOGAF defines the various steps to define and describe the baseline and target Application Architecture. Frameworx provides the TAM as a well defined classification scheme and structured application framework, which provides direct alignment with both the eTOM and the SID. Using TOGAF and Frameworx solutions SID and TAM: Select the reference models and the relevant viewpoints and tools to develop the Information Systems Architecture using the chapter 34 of TOGAF / section 4.2 of this document Content Metamodel and chapter 35.10/11 of TOGAF / section 4.3 of this document Viewpoints of phase C in connection with the Frameworx solutions SID and TAM. Use SID and the existing data models in the enterprise to define the baseline, target architecture and gaps describing building blocks, data models, logical data models of the actual data of interest from the applications point of view, data management processes, lifecycle, security and data entities. Use TAM and the existing application models in the enterprise to define the baseline, target application architecture and gaps describing building blocks, the business functions and organizations supported by the application and the hardware/software on which the IT function runs. Identify the critical relationships (that might affect application design) between the applications, the business processes and the technology architecture. For SID and TAM, consider the current architecture, identify gaps and develop the different types of artifacts for the information systems architecture, which are catalogs, matrices and diagrams. The chapters 35.10/11 of TOGAF / 4.3 of this document Architecture Artifacts, chapter 41 of TOGAF / section 5.4 of this document Architecture Repository and chapter 27 of TOGAF / section 3.9 of this document Gap Analysis support the development of the information systems architecture in connection with SID and TAM. Furthermore, use the chapter 51 of TOGAF / section 7.7 of this document Architecture Maturity Model to identify the actual baseline architecture. After developing the information systems architecture, resolve the impacts across the enterprise and architecture landscape to identify the potential impact of the new information systems architecture to the existing landscape or rather baseline architecture. The focus of this impact assessment should mainly concentrate on the relationships to other applications, to business architecture, to their relevant stakeholders. Use SID and TAM and chapter 36.2.18 of TOGAF / section 4.4 Architecture Deliverables. Document #, Version 0.1 © TM Forum 2008 -2010 Page 42 of 127
  43. 43. Exploring synergies between TOGAF and Frameworx Additionally, check the original motivation for the architecture project with the stakeholders and the Stakeholder Management Technique of chapter 24 of TOGAF / section 3.6 of this document. Finally, develop the final information systems architecture including building blocks, components, capabilities, services and relationships to the application and business processes and create the architecture definition document. Use SID and TAM and the chapter 36 of TOGAF / section 4.4 of this document Architecture Deliverables. Looking to the above-mentioned architecture development, the chapter 19 of TOGAF / section 3.2 of this document Applying iteration to the ADM can be seen as a very useful method to develop the business architecture by using eTOM and SID at the same time. The architecture definition iteration cycle clearly focuses on this matter and it also covers the application architecture of Frameworx solution TAM. Detailed mapping: Please refer to “Quick Reference Guide”. 1.10. Phase D – Technology Architecture The technology architecture phase seeks to map application components defined in the application architecture phase into a set of technology software and hardware components, available from the market or existing within the organization as technology platforms. As technology architecture defines the physical realization of an architectural solution, it has strong links to implementation and migration planning. Figure 22 – TOGAF Technology Architecture Using TOGAF and Frameworx: Document #, Version 0.1 © TM Forum 2008 -2010 Page 43 of 127
  44. 44. Exploring synergies between TOGAF and Frameworx When considering TOGAF and Frameworx synergies, it seems quite intuitive that the technology architecture Phase D of TOGAF would map straightforward to the Integration Framework in Frameworx especially when considering the former name “Technology Neutral Architecture”. Unfortunately, this is not so; this is due to the fact that the Integration Framework in Frameworx is an integration (interfaces between applications) methodology rather than a technology method or framework. Therefore the Phase D does not need any further analysis within the scope of this document. The mapping of the Integration Framework with TOGAF will be part of another document to be produced by this team in the near future. 1.11. Summary of Phase E to H TOGAF ADM Phase E: The Phase E is the first phase, which, is directly concerned with the method describing how the Target Architecture will be implemented. This phase concentrates on how to deliver the architecture and takes both, business and technical perspective to rationalize the IT activities and logically group them into project work packages with the IT portfolio and also within any other portfolios that are dependent upon IT. TOGAF ADM Phase F: The main focus of Phase F is the creation of a viable implementation and migration plan in co-operation with the portfolio and project managers. It includes assessing the dependencies, costs, and benefits of the various migration projects. The prioritized list of projects will form the basis of the detailed implementation and migration plan that will supplement the architectures with portfolio and project-level detail assigning tasks to specific resources. TOGAF ADM Phase G: Phase G establishes the connection between architecture and implementation organization, through the Architecture Contract. This phase ensures the compliance with the defined architecture, not only by the implementation projects, but also by other ongoing projects within the enterprise. The implementation governance is closely related to architecture governance, discussed at chapter 50 of TOGAF / section 7.6 of this document. TOGAF ADM Phase H: Document #, Version 0.1 © TM Forum 2008 -2010 Page 44 of 127
  45. 45. Exploring synergies between TOGAF and Frameworx The goal of the architecture change management process is to ensure that the architecture achieves its original target business value. This includes managing changes to the architecture in a cohesive and architected way. Additionally, the architecture change management process aims to establish and support the implemented enterprise architecture as a dynamic architecture, that is, one having the flexibility to evolve rapidly in response to changes in the technology and business environment. Using TOGAF and Frameworx: The Frameworx solutions eTOM, SID, and TAM do not directly map to the phases E to H, as this is shown in the figure below. Document #, Version 0.1 © TM Forum 2008 -2010 Page 45 of 127
  46. 46. Exploring synergies between TOGAF and Frameworx TOGAF phases E, F, and G and Frameworx: In spite of this situation, all three Frameworx solutions support these phases by representing the content and the result of the architecture development which should be implemented and realized at the TOGAF ADM phases E, F, and G. As already mentioned, the TOGAF ADM phases E, F, and G mainly concentrate on the planning and implementation of the developed enterprise architecture. Therefore, the focus of the comparison or rather mapping has rested with the joint usage of the Frameworx solutions in connection with these TOGAF ADM phases whilst the planning and implementation of the developed enterprise architecture. The synergies or rather complementarities of the Frameworx solutions and these phases of TOGAF ADM are significant and Frameworx can highly benefit from TOGAF. The phases E, F, and G provides a description of detailed steps and a step by step approach including various migration planning and implementation techniques to plan and implement the developed enterprise architecture. Furthermore, lot of techniques such as for assessing the readiness of the enterprise to undergo changes and identify the risks for business transformation or how to consolidate and reconcile interoperability requirements are comprehensively described. These very useful techniques strongly help to build up and to implement an enterprise architecture based on TOGAF and Frameworx solutions. TOGAF ADM phase H and Frameworx: The three Frameworx solutions eTOM, SID, and TAM do not map to the phase H. Furthermore, this phase does not exist in Frameworx solutions but it is the most important part of the architecture development method in regards to handling and managing business and technology changes, as shown in the figure below. Document #, Version 0.1 © TM Forum 2008 -2010 Page 46 of 127
  47. 47. Exploring synergies between TOGAF and Frameworx This phase of TOGAF describes the different drivers for changes, categories of changes and suggests guidelines for changes and finally describes the different steps of a change management process. Depending on the nature of the change, the respective Frameworx solutions need to be considered when managing and implementing this change. The Frameworx does not have a specific change management process and therefore, the phase H strongly supports any change activities also in a Frameworx solution. Because of this situation, using this phase is highly beneficial to every enterprise in telecommunication industry. What has been investigated How the comparison has been done Summary of findings on synergies or complementarities Document #, Version 0.1 © TM Forum 2008 -2010 Page 47 of 127
  48. 48. Exploring synergies between TOGAF and Frameworx 1.12. Requirements Management Requirements Management defines a process whereby requirements for enterprise architecture are identified, stored, and fed into and out of the relevant ADM phases of TOGAF. Figure 23 – TOGAF Phase Requirements Management Using TOGAF and Frameworx: Frameworx uses eTOM, the SID and the TAM to define business requirements in terms of use cases. Use cases will first be created in the Business View, then they will evolve into more detail across the System View, the Implementation View onto the final stage which is the Deployment View; such use cases represent the expression of requirements according to Frameworx. Different types of requirements (including business requirements) are identified in eTOM, examples of these are:  Interaction requirements in the B2B process interaction with Supplier, Partners and other external parties. Document #, Version 0.1 © TM Forum 2008 -2010 Page 48 of 127
  49. 49. Exploring synergies between TOGAF and Frameworx  Customer requirements in the product lifecycle management process to develop and manage products in accordance with customer demand.  Financial requirements in the strategic and enterprise planning in order to improve the overall capital and investment capacity of the enterprise.  Operational requirements for the operation of service delivery platforms. All these different types of requirements need to be identified and documented before moving on to next steps. Generally speaking, the Frameworx solutions eTOM, SID and TAM as well as changes originated by new business trends and technologies provide the new requirements to the enterprise architecture and need to be considered at the first step of the requirements management of TOGAF, as shown below. Figure 24 – TOGAF Phase Requirements Management - Steps After identifying the new requirements, collect and monitor them and check the motivation with the stakeholders. Identify the changed requirements (remove, add or modify) at the different architecture domains (business, information systems and technology architecture) from the phases B to G. Use the Framworx solutions eTOM, SID and TAM to prioritize the requirements and identify the dependencies of each requirement to the different Frameworx solutions and generate an requirements impact statement, chapter 36.2.18 of TOGAF. Assess the impact to the previous phases, implement the requirements and update the repository. Document #, Version 0.1 © TM Forum 2008 -2010 Page 49 of 127
  50. 50. Exploring synergies between TOGAF and Frameworx The requirements management of TOGAF defines a process of handling the requirements during a development of an enterprise architecture. The Frameworx solution eTOM shortly describes business requirements – as mentioned above – but does not describe a requirements management process as the TOGAF does. Therefore, this phase of TOGAF ADM provides a huge benefit of managing requirements during the development of a new enterprise architecture using Frameworx and TOGAF. Detailed mapping: Please refer to “Quick Reference Guide”. Document #, Version 0.1 © TM Forum 2008 -2010 Page 50 of 127
  51. 51. Exploring synergies between TOGAF and Frameworx 3. ADM Guidelines & Techniques as applied to Frameworx 1.13. Introduction and Scope This section describes supporting guidelines and techniques for the enterprise architecture development by using the TOGAF ADM (Architecture Development Method) in connection with Frameworx. 1.13.1.Guidelines for adapting the ADM process The ADM process can be adapted to accommodate a number of different scenarios, including different process styles (e.g. iteration cycle) and also specific architectures (e.g. security). 1.13.2. Techniques for architecture development The techniques support specific tasks within the ADM, such as definition of principles. They can be used in different phases of the ADM. 1.13.3. Scope This section shows which of these TOGAF ADM guidelines and techniques can be used in combination with Frameworx and how they can be applied. 1.14. Applying Iteration to the ADM in different enterprise levels The ADM is a flexible process that can be used to support the development of architecture as a stand-alone process or as an extension to other solution development or project management method. Using TOGAF and Frameworx: The different iteration cycles of TOGAF span a number of ADM phases and allow a formal review upon completion of each multi-phase iteration cycle. Using the iteration cycles “Architecture Definition Iteration” and “Architecture Context Iteration” as shown in the following figure, imply the usage of the associated frameworks of the Frameworx solution (eTOM, SID, TAM). Document #, Version 0.1 © TM Forum 2008 -2010 Page 51 of 127
  52. 52. Exploring synergies between TOGAF and Frameworx As already mentioned at the phases B and C, the Frameworx solution SID also supports eTOM and consequently the development of the business architecture. Considering the different process levels and business functions of eTOM, the data entities and attributes of SID and their relationships strongly need to be considered with eTOM when defining business and data architecture. Applying iteration to the ADM phases B, C and D is a very useful technique to ensure a joint development of different architecture dimensions, which are dependent from each other. Figure 25 – TOGAF Iteration Cycles and Frameworx solutions During the development and implementation of an enterprise architecture, it is mostly not possible to develop a single architecture that addresses all the needs of all stakeholders. Furthermore, the Frameworx solutions eTOM, SID and TAM also have a strong relationship to each other and consequently have dependencies when developing an enterprise architecture. Because of this reason, the enterprise must be partitioned into different areas, each of which can be supported by the respective architecture. Typically it is partitioned into subject matter, time period and level of detail, as shown in the figure below. Document #, Version 0.1 © TM Forum 2008 -2010 Page 52 of 127
  53. 53. Exploring synergies between TOGAF and Frameworx Figure 26 – TOGAF different enterprise levels Using the ADM of TOGAF, the different enterprise architectures and the Frameworx solutions eTOM, SID and TAM, the strategic architecture can be described at the architecture vision phase (Phase A) by developing the strategic view of the different architecture dimensions of B, C and D. For example, the strategic view of business architecture can be the level 0 and level 1 processes of eTOM business process framework. A more detailed and formal architecture description can be provided in the phase B (business architecture) by describing the level 2, level 3 and following levels of eTOM business process framework, which finally illustrates the segment architecture as shown in the figure below. Document #, Version 0.1 © TM Forum 2008 -2010 Page 53 of 127
  54. 54. Exploring synergies between TOGAF and Frameworx Figure 27 – TOGAF ADM and different enterprise levels Document #, Version 0.1 © TM Forum 2008 -2010 Page 54 of 127
  55. 55. Exploring synergies between TOGAF and Frameworx This section is not in scope of the mapping exercise 1.15. Security Architecture and the ADM This section is not in scope of this document. 1.16. Leveraging both TOGAF and Frameworx in the context of SOA Not inscope of this document 1.17. Architecture Principles Architecture principles define the underlying general rules and guidelines for the use and deployment of all IT resources and assets across the enterprise. They reflect a level of consensus among the various elements of the enterpr ise, and form the basis for making future IT decisions. Each architecture principle should be clearly related back to the business objectives and key architecture drivers. Principles shape the organization and IT of an enterprise. In TOGAF architecture principles are defined as a subset of IT principles. They are considered as part of hierarchy of principles: enterprise – IT – architecture. Using TOGAF and Frameworx: Considering TOGAF and Frameworx, especially the application framework TAM maps to the principles of TOGAF (enterprise principles, information technology principles and architecture principles). The section “Core NGOSS principles” now “Core Frameworx principles” describes ten key business and technology principles from the perspective of Frameworx. These ten principles can be mapped into the architecture principles as shown below: TOGAF Principles Frameworx Principles Respective Frameworx Principle covered in Document #, Version 0.1 © TM Forum 2008 -2010 Page 55 of 127
  56. 56. Exploring synergies between TOGAF and Frameworx TOGAF? Architecture Principles - Provide comprehensive, enterprise-wide operational solutions for fixed, mobile, cable and converged industry segments. - No. This Frameworx Principle would an additional principle in the example set of TOGAF. Business Principles - Enable an operator’s business transformation. - Allow business processes to be easily changed without software change by separating control of business process flow from application operation. - No. This Frameworx Principle would an additional principle in the example set of TOGAF. - Partially yes. It can be considered with the principle 4 of TOGAF: Business Continuity Data Principles - Allow corporate data to be widely shared across the enterprise and where appropriate with trading partners. - Yes. The principle 11 of TOGAF “Data is Shared” directly maps to this principle of Frameworx. Application Principles - Reduce software development costs and risks by building on industry best practices and existing standards work. - Allow operators organization to evolve without systems lock in by using loosely coupled distributed systems. - No. This Frameworx Principle would an additional principle in the example set of TOGAF. - Yes. The principle 16 of TOGAF “Technology Independence” maps to this principle of Frameworx. Technology Principles - Reduce IT costs and timescales by utilizing widely available, commercial-off-the-shelf (COTS) software components. - Partially yes. The principle 5 and 16 of TOGAF “Common Use Applications” and “Technology Independence” can Document #, Version 0.1 © TM Forum 2008 -2010 Page 56 of 127
  57. 57. Exploring synergies between TOGAF and Frameworx - Allow a clear migration path by integrating with and evolving from legacy systems. - Allow simplified systems integration (Plug & Play) through clearly defined contract interfaces between applications. - Allow simplified systems integration by utilizing a common communications bus between applications. lead to reduced IT costs. - No. This Frameworx Principle would an additional principle in the example set of TOGAF. - Yes. The principle 21 of TOGAF “Interoperability” maps to this principle of Frameworx. - Partly yes. The principle 6 of TOGAF “Service Orientation” would imply the usage of a communications/ service bus. As shown above in that table, the Frameworx principles mentioned in the Frameworx solution TAM map into the different architecture principles of TOGAF. For sure, these principles are strongly related to Frameworx solutions and to the needs of the telecommunication operator. TOGAF provides an additional benefit to this section of Frameworx by providing methods, templates, set of criteria and qualities for developing further good principles in the TOGAF Phase A Architecture Vision. These materials intensively help to define new principles when starting a new architecture approach and can be found at the TOGAF chapter 23 Architecture Principles. 1.18. Stakeholder Management Stakeholder management is one of the most important techniques for a successful enterprise architecture project. It is essential in any initiative to identify the individuals and groups within the organization who will contribute to the development of the architecture, just as important it is to identify those that will gain and those that will lose its introduction and then develop for dealing with them. Document #, Version 0.1 © TM Forum 2008 -2010 Page 57 of 127

×