Exploring Synergies between TOGAF and Frameworx

Transcription

1 Exploring Synergies between TOGAF and Frameworx White Paper Industry Group Liaison TOGAF and TM Forum Frameworx Collaboration Project Document 1: Mapping of TOGAF and Frameworx Solutions Business Process Framework (etom), Information Framework (SID) and Application Framework (TAM) Version 1.0 April 2011

2 Notice TM Forum and The Open Group This document has been jointly developed by the TeleManagement (TM Forum) and The Open Group. This document has been through review cycles; however, due to the inherent complexity in the design and implementation of software and systems, no liability is accepted for any errors or omissions or for consequences of any use made of this document. Under no circumstances will the TM Forum or The Open Group be liable for direct or indirect damages or any costs or losses resulting from the use of this document. The risk of designing and implementing products in accordance with this document is borne solely by the user of this document. This document is a copyrighted document of the TM Forum and The Open Group. Its use by members and non-members of the TM Forum is governed by all of the terms and conditions of the Intellectual Property Rights Policy of the TM Forum ( and may involve a claim of patent rights by one or more TM Forum members or by non-members of the TM Forum. Its use by members of The Open Group is governed by the terms and conditions of The Open Group membership agreement at Direct inquiries to the TM Forum office: 240 Headquarters Plaza East Tower 10th Floor Morristown NJ USA Tel No Fax No TM Forum web page: Direct inquiries to The Open Group should be directed to The Open Group office: 44 Montgomery St., Suite 960 San Francisco CA , USA Tel: Fax: The Open Group web page: Boundaryless Information Flow is a trademark and ArchiMate, Jericho Forum, Making Standards Work, Motif, OSF/1, The Open Group, TOGAF, UNIX, and the X device are registered trademarks of The Open Group in the United States and other countries. Open Group Document Number W114 The Open Group and TM Forum Page 2 of 110

3 Table of Contents Notice TM Forum and The Open Group... 2 Table of Contents... 3 List of Figures... 5 Executive Summary General Information and Introduction Benefits of the Mapping Exercise About TM Forum and Frameworx Introduction Four Components of the Frameworx Family About The Open Group and TOGAF Introduction Short Overview of TOGAF Positioning of TOGAF and TM Forum Frameworx At-a-Glance TOGAF and TM Forum Frameworx Sources Used for the Mapping Frameworx and the Architecture Development Method (ADM) Preliminary Phase Phase A Architecture Vision Phase B Business Architecture Phase C Information Systems Architecture Data Architecture Application Architecture Phase D Technology Architecture Summary of Phase E to H Requirements Management ADM Guidelines & Techniques as Applied to Frameworx Introduction and Scope Guidelines for Adapting the ADM Process Techniques for Architecture Development Scope Applying Iteration to the ADM in Different Enterprise Levels Security Architecture and the ADM Leveraging both TOGAF and Frameworx in the Context of SOA Architecture Principles Stakeholder Management Architecture Patterns Business Scenarios Gap Analysis Migration Planning Techniques Interoperability Requirements Business Transformation Readiness Assessment Risk Management Capability-Based Planning Architecture Content Framework and Synergies with Frameworx The Open Group and TM Forum Page 3 of 110

4 4.1 Introduction and Scope Content Metamodel Architectural Artifacts Architectural Deliverables Building Blocks Enterprise Continuum and Tools and Synergies with Frameworx Introduction and Scope Enterprise Continuum Architecture Continuum Solutions Continuum Architecture Partitioning Architecture Repository Tools for Architecture Development TOGAF Reference Models and their Relevance to Frameworx Introduction and Scope Foundation Architecture: Technical Reference Model Integrated Information Infrastructure Reference Model Applying the Architecture Capability Framework to Frameworx Introduction and Scope Establishing an Architecture Capability Architecture Board Architecture Compliance Architecture Contracts Architecture Governance Architecture Maturity Models Architecture Skills Framework Summary of Synergies and Complementary Elements Appendix A: Quick Reference Guide TOGAF Frameworx Appendix B: Process Description Metamodel Appendix C: Glossary, Terms and Abbreviations Annex: Clarification of Information and Data Acknowledgements The Open Group and TM Forum Page 4 of 110

5 List of Figures Figure 1 Frameworx Blueprint Figure 2 Frameworx etom Level 1 View Figure 3 Frameworx SID Figure 4 Frameworx TAM Figure 5 Frameworx Integration Framework Relationships Figure 6 TOGAF Core Components Figure 7 TOGAF ADM Figure 8 TOGAF Deliverables Figure 9 TOGAF Metamodel Figure 10 TOGAF Enterprise Continuum Figure 11 TOGAF Repository Figure 12 TOGAF Capability Framework Figure 13 TOGAF Frameworx Phase 1 Mapping etom, SID, TAM Overview Figure 14 TOGAF Frameworx Phase 1 Mapping Complete Overview Figure 15 TOGAF Preliminary Phase Figure 16 TOGAF Architecture Vision Figure 17 TOGAF Business Architecture Figure 18 TOGAF Information Systems Architecture Figure 19 TOGAF Technology Architecture Figure 20 Architecture Changes Figure 21 TOGAF Phase Requirements Management Figure 22 TOGAF Phase Requirements Management Steps Figure 23 TOGAF Iteration Cycles and Frameworx Solutions Figure 24 TOGAF Enterprise Levels Figure 25 TOGAF ADM and Different Enterprise Levels Figure 26 Stakeholder Analysis Figure 27 Stakeholder Power Grid...54 Figure 28 Business Scenarios and Frameworx Figure 29 Business Scenario in TOGAF and Assessment Methodology in Frameworx Figure 30 Gap Analysis Figure 31 TOGAF Implementation Factor Assessment and Deduction Matrix Figure 32 TOGAF Consolidated Gaps, Solution and Dependencies Matrix Figure 33 TOGAF Gaps, Solution and Dependencies Matrix with Frameworx Services Figure 34 TOGAF Architecture Definition Increments Table with Frameworx Services Figure 35 TOGAF State Evolution Table Figure 36 TOGAF State Evolution Table with Frameworx Services The Open Group and TM Forum Page 5 of 110

6 Figure 37 TOGAF Business Information Interoperability Matrix Figure 38 TOGAF Summary Table of Business Transformation Readiness Assessment Figure 39 Risk Classification Scheme Figure 40 Risk Identification Worksheet Figure 41 Capability-Based Planning and Frameworx Figure 42 TOGAF Content Metamodel with Extensions and Mapping to Frameworx Figure 43 TOGAF Artifacts and Frameworx Solutions Figure 44 Architecture Partitioning with Frameworx Examples Figure 45 Architecture Partitioning with Frameworx Examples Figure 46 TOGAF Partitioning and Frameworx Solutions Figure 47 TOGAF Repository and Frameworx Solutions Figure 48 Architecture Contracts Figure 49 TOGAF Architecture Governance Framework Figure 50 DEN-ng Mapping The Open Group and TM Forum Page 6 of 110

7 Executive Summary Members of both The Open Group and the TM Forum have the view that there is benefit in harnessing the assets of both organizations. Over the past decade The Open Group has focused on the methodology for producing and exploiting the architecture approach. On the other hand, the TM Forum has focused on developing industry reference frameworks aimed at accelerating the work of business and IT professionals in the telecommunications industry. Applying TOGAF methodology to the TM Forum industry assets is expected to generate benefits because its users will understand how to apply specific assets of TOGAF or have a better understanding of how to use these assets in their own initiatives. It is the ambition of The Open Group-TM Forum 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 TM Forum the result of the mapping activity is reported into two different documents: Document 1 (this document): Focuses on mapping 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, complementary areas and the areas for application with the TOGAF Enterprise Continuum in mind. Document 2: Focuses 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. This 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 TM Forum assets. In summary, the following were identified: 1. Immediate synergies have been identified between the TOGAF Architecture Development Method (ADM) phases Preliminary, A, B, C and the Common Systems Architecture of the Enterprise Continuum. This document addresses The Open Group and TM Forum Page 7 of 110

8 the TOGAF ADM phases from Preliminary to Phase C. The synergies between business services (formerly known as NGOSS contracts) and the Common Systems Architecture will be dealt with in a separate document. 2. TOGAF provides an Architecture Repository structure that can smoothly accommodate the mapping of TM Forum assets; this feature can be leveraged to identify and derive the added value of the content. 3. TM Forum assets can be classified as either Industry Architectures or Common Systems Architecture in (TOGAF) Enterprise Continuum language. TOGAF provides a widely accepted methodology to leverage these architectures into the development of enterprise architecture. 4. Professionals that use TM Forum assets will find templates and guidelines in TOGAF that facilitate the transformation of such TM Forum assets into deliverables for a specific project/program. 5. TOGAF concepts as defined in the TOGAF Architecture Content Framework provide clear definitions as to what artifacts from TM Forum assets have to be developed in order to be consistent and comprehensive with an architecture construct. Recommendations TM Forum 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 the TM Forum by considering the TM Forum assets as an exemplar and generalize it into a re-usable asset by other industries. The Open Group may consider adopting the TM Forum Maturity Model for tagging workgroup results. The authority level of artifacts or deliverables would gain transparency. Clients considering adoption of TM Forum standards can leverage their investment by adopting TOGAF 9 and exploiting the complementary features at the same time. This enhances architecture governance, its comprehensiveness and sustainability. The Open Group and TM Forum Page 8 of 110

9 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 across 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. The Open Group and TM Forum 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 TM Forum 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 (SP) business processes. However, it is nonspecific 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 SPs. 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 SPs 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 us to understand very well and easily what the description covers. In order to understand the architecture of a specific SP during a specific time frame, one has to take into account of 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). The Open Group and TM Forum Page 9 of 110

10 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 SP s scope. Therefore, it can help initiatives effectively through the use of a common reference which is 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. The TM Forum provides the business lifecycle for developing Frameworxcompliant 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 each other very well. 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 and techniques for developing and maintaining enterprise architecture. Frameworx solutions describe the working model of communications SPs in a generic way, without getting specific to individual SPs. 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 The Open Group and TM Forum Page 10 of 110

11 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 and 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 does not describe detailed steps and methods to perform 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 a template for an Architecture Repository which can be used to manage and structure all the architecture artifacts in the enterprise architecture. Criteria for Tool Evaluation and Selection help to Figure out the Right Tool Most of the well-known enterprise architecture tools 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 TM Forum. Deploying an Optimal Architecture Capability to Establish and Consolidate the Architecture Function 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. The TOGAF Architecture Skills Framework and Architecture Governance chapters provide a comprehensive and detailed description of enterprise architecture methods suitable for the telecommunications industry. This is of great additional value for the Frameworx assets of the TM Forum. The Open Group and TM Forum Page 11 of 110

12 1.2 About TM Forum and Frameworx Introduction About the TM Forum The TM Forum (TM Forum) is the world s leading industry association focused on enabling best-in-class IT for SPs 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 telecommunications industry-specific framework developed by the TM Forum to organize, specify, design and develop new generation management systems. It provides a standard method, common terminology and harmonized framework for the entire telecommunications Industry value chain. Frameworx captures best practices and common definitions to meet the needs of a variety of stakeholders including SPs, 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 provides 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 (TIP) and the Integration Framework, previously known as Technology Neutral Architecture (TNA). Frameworx consists of four frameworks or content models which represent the cornerstones of an SP enterprise architecture. These are: Process Framework (etom) Information Framework (SID) Application Framework (TAM) Integration Framework (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 TM Forum web page. They are currently under development and therefore the following text cannot be seen as a final description of these frameworks. The Open Group and TM Forum Page 12 of 110

13 1.2.2 Four Components of the Frameworx Family Figure 1 Frameworx Blueprint Business Process Framework, enhanced Telecom Operations Map (etom) etom defines most of the common business processes of an SP environment based on the current state of technology. It provides a standard framework and 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. The Open Group and TM Forum Page 13 of 110

14 Figure 2 Frameworx etom Level 1 View Enterprise-wide Information Framework, Shared Information and Data (SID) 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 Operations Support Systems/Business Support Systems (OSS/BSS) 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 a data model, which needs adaptation to each specific enterprise. In both frameworks interchange of level of detail might occur due to the SP s strategy. The Open Group and TM Forum Page 14 of 110

15 Figure 3 Frameworx SID Application Framework, Telecom Application Map (TAM) 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 telecommunications 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 TM Forum 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, an SP s application landscape might look somewhat different depending on the specific business strategy or business model. The Open Group and TM Forum Page 15 of 110

16 Figure 4 Frameworx TAM Integration Framework, Technology-Neutral Architecture (TNA) The Integration Framework supersedes the Technology-Neutral Architecture (TAN). It identifies the dependencies and unifies the TM Forum 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 re-usable building blocks, known as business services. These business services (also known previously as NGOSS contracts) are based on standard 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 etom and SID, and adds capabilities from TAM to form groups of business services (also known as a service platform). A platform service is created by taking specific information entities from the Information Framework and taking into account their interactions with The Open Group and TM Forum Page 16 of 110

17 business processes as defined in the process framework and analyzing entities with common characteristics and supporting these with application framework (TAM) capabilities. The relationship between a business service, a business process as defined in etom and an information entity as defined in SID is shown in Figure 5. Figure 5 Frameworx Integration Framework Relationships The Open Group and TM Forum Page 17 of 110

18 1.3 About The Open Group and TOGAF 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 system certification. Further information on The Open Group can be found at TOGAF TOGAF is a framework a detailed method, 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. 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. 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 provide 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 and in general many individual features from TOGAF 9 can be adopted into a TOGAF 8 environment. The Open Group and TM Forum Page 18 of 110

19 TOGAF 9 provides a stronger link to the business than TOGAF 8. It provides strategic planning and further deployment decisions steps. Because of the new metamodel, further developed guidelines 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 Metamodel Capability-Based Planning Business Transformation Readiness Architecture Repository Stakeholder Management Using TOGAF to develop Security Architectures Using TOGAF to develop Service-Oriented Architectures Short Overview of TOGAF TOGAF Core Concepts The core of TOGAF is represented by the Architecture Development Method (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. The Open Group and TM Forum Page 19 of 110

20 Figure 6 TOGAF Core Components Part II TOGAF Architecture Development Method The ADM features a series of linked phases which enable a full lifecycle management of an enterprise architecture and which furthermore enable a path leading 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: o Assets created in previous iterations of the ADM cycle within the enterprise The Open Group and TM Forum Page 20 of 110

21 o 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 lifecycle management are shown in Figure 7. Figure 7 TOGAF ADM Part IV - TOGAF Architecture Content Framework and Metamodel 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. The Open Group and TM Forum Page 21 of 110

22 Figure 8 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. Figure 9 shows an overview of the content metamodel. The Open Group and TM Forum Page 22 of 110

23 Figure 9 TOGAF Metamodel Part V - TOGAF Enterprise Continuum and Tools Enterprise 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 Figure 10. The Open Group and TM Forum Page 23 of 110

24 Figure 10 TOGAF Enterprise Continuum Architecture Repository 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 cooperation 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 Figure 11. The Open Group and TM Forum Page 24 of 110

25 Figure 11 TOGAF Repository 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 Figure 12. The Open Group and TM Forum Page 25 of 110

26 Figure 12 TOGAF Capability Framework 1.4 Positioning of TOGAF and TM Forum 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. The mapping starts with the TOGAF ADM and Frameworx. The other parts of TOGAF which are the 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 reading and to describe the relationship. Furthermore, a Quick Reference Guide is provided as an appendix to this document. This guide compares in detail the chapters and paragraphs to the various parts of Frameworx. The Open Group and TM Forum Page 26 of 110

27 1.4.1 TOGAF and TM Forum Frameworx In this chapter the difference between TOGAF and Frameworx is further discussed. In general it will help to consider TOGAF as a methodology framework and Frameworx as the content to which it can be applied. The Preliminary Phase as well as Phase A (Architecture Vision) of TOGAF provide the starting point to apply Frameworx in a specific situation. The Preliminary Phase applies to the architecture capability. The decision about which standards to use in an organization should be agreed beforehand. 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 2.1 for more detail. 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 dimensions in line with Frameworx. Therefore, Frameworx needs to be considered within this phase for defining and describing the Target Architecture for the enterprise. 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 telecommunications SP and therefore maps to Phase B of the TOGAF ADM. The Shared Information and Data Model (SID) provides a comprehensive common information and data model for a telecommunications SP and it maps to Phase C (Data Architecture) of the 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 Architecture Definition iteration cycle Architecture Definition of TOGAF Chapter 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 and C of the TOGAF ADM. The Telecom Application Map (TAM) provides a framework of applications relevant to a telecommunications 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 the TOGAF ADM. The Open Group and TM Forum Page 27 of 110

28 The Integration Framework will be part of the mapping in Document 2. This mapping will be dealt with in the next phase of this liaison project. In the preliminary analysis it was recognized that Phase D of the TOGAF ADM does not map directly to the Integration Framework. Phase D refers to the Technology Architecture. 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 Target Architecture as defined in Phases B, C and D of the TOGAF ADM. 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 Target 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 the TOGAF ADM. Phase H (Architecture Change Management) ensures that the architecture achieves its original target business value. Frameworx does not explicitly map to this phase, but can be seen as architectural input (deliverables and artifacts) to the change activities in this phase. The Requirements Management phase of the TOGAF ADM does not exist as a standalone 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 of the TOGAF ADM. The Open Group and TM Forum Page 28 of 110

29 Figure 13 TOGAF Frameworx Phase 1 Mapping etom, SID, TAM Overview Figure 14 TOGAF Frameworx Phase 1 Mapping Complete Overview The Open Group and TM Forum Page 29 of 110

30 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., the 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 The 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 & 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 the ADM, the Business Architecture maps to etom, and 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 Phase A (Architecture Vision) of the TOGAF ADM. 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 Document 2 mapping between TOGAF and Frameworx solution Integration Framework. The Open Group and TM Forum Page 30 of 110

31 1.5 Sources Used for the Mapping This document is based on the following documents: The Open Group: o TOGAF, Version 9, 2009 TM Forum: o Frameworx Solution Release V1.0 o etom, Version 8.0 o SID, Version 8.0 o TAM, Version 3.2 o NGOSS Distilled 2005 (for etom, SID and TAM information) The documents for the Frameworx solution Integration Framework are not considered for this document. The Open Group and TM Forum Page 31 of 110

32 2 Frameworx and the Architecture Development Method (ADM) 2.1 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 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 15 TOGAF Preliminary Phase The Open Group and TM Forum Page 32 of 110

33 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 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 and compliance criteria and conformance levels can be used together with Chapter 48 (Architecture Compliance) and Chapter 50 (Architecture Governance) of TOGAF to evaluate potential application acquisitions and to confirm the architecture governance process. Further details can be found in Section 7.4 and Section 7.6 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 enterprise architecture 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 Chapter 52 (Architecture Skills Framework) of TOGAF/Section 7.8 of this document to basically identify the necessary knowledge and experience of each involved architect or team member. The architecture principles are an important anchor when establishing the architecture governance. Firstly, use the information framework TAM to establish the ten telecommunications-specific principles provided by Frameworx; see Section 3.2 of this document. Furthermore, use Chapter 23 (Architecture Principles) of TOGAF to define and establish further principles which may be necessary to the enterprise architecture project. The three solutions of Frameworx are identified as a deliverable framework for telecommunications-specific artifacts in regards to business, data and Application Architecture. Contextually, identify the Architecture Content Framework of TOGAF (Chapter 34 of TOGAF/Section 4.2 of this document), compare it with Frameworx and finally identify re-usable components from 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 enterprise architecture tools which can be used to develop the enterprise architecture. Chapter 42 (Tools for Architecture Development) of TOGAF/Section 5.3 of this document provide detailed information on how to identify and implement an enterprise architecture tool. This section can also be used to identify and evaluate the telecommunications-specific tools suggested by Frameworx. The Open Group and TM Forum Page 33 of 110

34 2.2 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, confirms 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 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 Phase A. Figure 16 TOGAF Architecture Vision The Open Group and TM Forum Page 34 of 110

35 Using TOGAF and Frameworx Phase A (Architecture Vision) 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 stakeholders 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. Considering the architecture capability, especially etom and SID can be used to support the identification of capabilities for the architecture project. Use Chapter 32 (Capability- Based Planning), Section (Capability Assessment), and Chapter 46 (Establishing Architecture Capability) of TOGAF to identify the capabilities. Before scoping the architecture, quantify the enterprise s readiness to undergo changes by the architecture project. Use Chapter 30 (Business Transformation Readiness Assessment) of TOGAF/Section 3.9 of this document 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 i.e., levels you are going to use for the architecture approach. That clearly influences the architecture effort which the architecture team has to estimate. Use the Frameworx solutions in connection with Chapter 40 (Architecture Partitioning) of TOGAF to define the architecture scope. The Frameworx solution TAM also supports the confirmation of architecture principles and should be used together with Chapter 23 (Architecture Principles) of TOGAF/Section 3.5 of this document. 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 Chapter 26 (Business Scenarios) of TOGAF/Section 3.8 of this document 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 Chapter 31 (Risk Management) of TOGAF/Section 3.13 of this document 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 Chapter 36 (Architecture Deliverables) of TOGAF/Section 4.4 of this document in connection with Frameworx to define the work products for the architecture project. The Open Group and TM Forum Page 35 of 110

36 Detailed Mapping Please refer to the Quick Reference Guide. etom, SID and TAM can be used during this phase to delineate the scope and boundaries of the considered domain. 2.3 Phase B Business Architecture The Business Architecture is the next architecture activity that needs to be undertaken. It is necessary for demonstrating the business value and requirements of subsequent Technology Architecture work to key stakeholders and its return on investment. Figure 17 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 Business Architecture reflects the business strategy/model and related challenges and shapes the detailed process decomposition of each process in etom. Some processes might have The Open Group and TM Forum Page 36 of 110

37 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 s most relevance is in Phase C. However, at the Information model level it also makes 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. Chapter 27 (Gap Analysis) of TOGAF/Section 3.9 of this document, Chapter 35 (Architectural Artifacts) of TOGAF/ Section 4.3 of this document, and Chapter 41 (Architecture Repository) of TOGAF/Section 5.4 of this document support the development of the Business Architecture in connection with etom and SID. Furthermore, use Chapter 51 (Architecture Maturity Models) of TOGAF/Section 7.7 of this document 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 Section (Requirements Impact Assessment) of TOGAF/Section 4.4 of this document. Additionally, check the original motivation for the architecture project with the stakeholders and the Stakeholder Management Technique of Chapter 24 (Stakeholder Management) 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 Chapter 36 (Architecture Deliverables) of TOGAF/Section 4.4 of this document. Looking to the above-mentioned architecture development, Chapter 19 (Applying Iteration to the ADM) of TOGAF/Section 3.2 of this document 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. The Open Group and TM Forum Page 37 of 110

38 Detailed Mapping Please refer to the Quick Reference Guide. 2.4 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. Figure 18 TOGAF Information Systems Architecture Phase C (Information Systems Architecture) in TOGAF is divided into Data and Application Architectures, respectively. Therefore, the mapping between TOGAF and Frameworx considers the architectures separately, as shown below. The TM Forum SID framework deals with both information and data as one framework Data Architecture The Information framework (SID) can be used to represent the Data Architecture in Phase C of the TOGAF ADM. The Open Group and TM Forum Page 38 of 110

39 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 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. 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 Chapter 34 (Content Metamodel) of TOGAF/Section 4.2 of this document and Section and (Viewpoints in Phase C) of TOGAF/Section 4.3 of this document 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. The Open Group and TM Forum Page 39 of 110

40 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. Chapter 27 (Gap Analysis) of TOGAF/Section 3.9 of this document, Section 35.10/11 (Viewpoints in Phase C) of TOGAF/Section 4.3 of this document and Chapter 41 (Architecture Repository) of TOGAF/Section 5.4 of this document support the development of the Information Systems Architecture in connection with SID and TAM. Furthermore, use Chapter 51 (Architecture Maturity Models) of TOGAF/Section 7.7 of this document 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 Section (Requirements Impact Assessment) of TOGAF/Section 4.4 of this document. Additionally, check the original motivation for the architecture project with the stakeholders and the Stakeholder Management Technique of Chapter 24 (Stakeholder Management) 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 Chapter 36 (Architecture Deliverables) of TOGAF/Section 4.4 of this document. Looking to the above-mentioned architecture development, Chapter 19 (Applying Iteration to the ADM) of TOGAF/Section 3.2 of this document 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 the Quick Reference Guide. The Open Group and TM Forum Page 40 of 110

41 2.5 Phase D Technology Architecture Phase D (Technology Architecture) seeks to map application components defined in Phase C (Application Architecture) 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 19 TOGAF Technology Architecture Using TOGAF and Frameworx When considering TOGAF and Frameworx synergies, it seems quite intuitive that Phase D of TOGAF would map directly 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, 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. The Open Group and TM Forum Page 41 of 110

42 2.6 Summary of Phase E to H TOGAF ADM Phase E Phase E (Opportunities & Solutions) 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 within the IT portfolio and also within any other portfolios that are dependent upon IT. TOGAF ADM Phase F The main focus of Phase F (Migration Planning) 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 (Implementation Governance) 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. Implementation governance is closely related to architecture governance, discussed in Chapter 50 (Architecture Governance) of TOGAF/Section 7.6 of this document. TOGAF ADM Phase H 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 Phases E to H, as shown in Figure 14. The Open Group and TM Forum Page 42 of 110

43 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 Phases E, F and G of the TOGAF ADM. As already mentioned, Phases E, F and G of the TOGAF ADM 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 during the planning and implementation of the developed enterprise architecture. The synergies or rather complementary aspects of the Frameworx solutions and these phases of the TOGAF ADM are significant and Frameworx can highly benefit from TOGAF. Phases E, F and G provide 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, lots 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 Phase H. Furthermore, this phase does not exist in Frameworx solutions but it is the most important part of the ADM with respect to handling and managing business and technology changes, as shown in Figure 20. The Open Group and TM Forum Page 43 of 110

44 Figure 20 Architecture Changes This phase of TOGAF describes the different drivers for changes, categories of changes, 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. Frameworx does not have a specific change management process and, therefore, 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. The Open Group and TM Forum Page 44 of 110

45 2.7 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 21 TOGAF Phase Requirements Management Using TOGAF and Frameworx Frameworx uses etom, SID and TAM to define business requirements in terms of usecases. 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 suppliers, partners and other external parties The Open Group and TM Forum Page 45 of 110

46 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 the 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 in Figure 22. Figure 22 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 Phases B to G. Use the Frameworx solutions etom, SID and TAM to prioritize the requirements and identify the dependencies of each requirement to the different Frameworx solutions and generate a requirements impact statement; see Section (Requirements Impact Assessment) of TOGAF. Assess the impact to the previous phases, implement the requirements and update the repository. The requirements management of TOGAF defines a process of handling the requirements during a development of an enterprise architecture. The Frameworx The Open Group and TM Forum Page 46 of 110

47 solution etom shortly describes business requirements as mentioned above but does not describe a requirements management process as TOGAF does. Therefore, this phase of the 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 the Quick Reference Guide. The Open Group and TM Forum Page 47 of 110

48 3 ADM Guidelines & Techniques as Applied to Frameworx 3.1 Introduction and Scope This section describes supporting guidelines and techniques for the enterprise architecture development by using the TOGAF ADM in connection with Frameworx 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) Techniques for Architecture Development Scope The techniques support specific tasks within the ADM, such as definition of principles. They can be used in different phases of the ADM. This section shows which of these TOGAF ADM guidelines and techniques can be used in combination with Frameworx and how they can be applied. 3.2 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 methods. 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 Figure 23, imply the usage of the associated frameworks of the Frameworx solution (etom, SID, TAM). As already mentioned at Phases B and C, the Frameworx solution SID also supports etom and consequently the development of the Business Architecture. The Open Group and TM Forum Page 48 of 110

49 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 Phases B, C and D of the TOGAF ADM is a very useful technique to ensure a joint development of different architecture dimensions, which are dependent from each other. Figure 23 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. For 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 Figure 24. The Open Group and TM Forum Page 49 of 110

50 Figure 24 TOGAF Enterprise Levels Using the TOGAF ADM, the different enterprise architectures and the Frameworx solutions etom, SID and TAM, the strategic architecture can be described at Phase A (Architecture Vision) 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 the etom business process framework. A more detailed and formal architecture description can be provided in Phase B (Business Architecture) by describing the level 2, level 3 and following levels of the etom business process framework, which finally illustrates the segment architecture as shown in Figure 25. The Open Group and TM Forum Page 50 of 110

51 Figure 25 TOGAF ADM and Different Enterprise Levels This section is not in scope of the mapping exercise. 3.3 Security Architecture and the ADM This section is not in scope of this document. 3.4 Leveraging both TOGAF and Frameworx in the Context of SOA This section is not in scope of this document. The Open Group and TM Forum Page 51 of 110

52 3.5 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 enterprise, 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 a 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 Architecture Principles Business Principles Data Principles Frameworx Principles Provide comprehensive, enterprise-wide operational solutions for fixed, mobile, cable and converged industry segments. 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. Allow corporate data to be widely shared across the enterprise and where appropriate with trading partners. Respective Frameworx Principle covered in TOGAF? No. This Frameworx principle would be an additional principle in the example set of TOGAF. No. This Frameworx principle would be an additional principle in the example set of TOGAF. Partially yes. It can be considered with principle 4 of TOGAF: Business Continuity. Yes. Principle 11 of TOGAF Data is Shared directly maps to this principle of Frameworx. The Open Group and TM Forum Page 52 of 110

53 TOGAF Principles Application Principles Technology Principles Frameworx 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 looselycoupled distributed systems. Reduce IT costs and timescales by utilizing widely available, commercial-off-theshelf (COTS) software components. 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. Respective Frameworx Principle covered in TOGAF? No. This Frameworx principle would be an additional principle in the example set of TOGAF. Yes. Principle 16 of TOGAF: Technology Independence maps to this principle of Frameworx. Partially yes. Principle 5 and 16 of TOGAF: Common Use Applications and Technology Independence can lead to reduced IT costs. No. This Frameworx principle would be an additional principle in the example set of TOGAF. Yes. Principle 21 of TOGAF: Interoperability maps to this principle of Frameworx. Partly yes. Principle 6 of TOGAF: Service-Orientation would imply the usage of a communications/ service bus. As shown above in the 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 telecommunications operator. TOGAF provides an additional benefit to this section of Frameworx by providing methods, templates, criteria and qualities for developing further good principles in Phase A (Architecture Vision) of TOGAF. These materials intensively help to define new principles when starting a new architecture approach and can be found in Chapter 23 (Architecture Principles) of TOGAF. 3.6 Stakeholder Management Stakeholder management is one of the most important techniques for a successful enterprise architecture project. TOGAF identifies the different stakeholders at different phase of ADM by using the following concepts: The Open Group and TM Forum Page 53 of 110

54 Stakeholders Concerns Views Viewpoints Furthermore, TOGAF provides a template for classifying stakeholders position and a stakeholder power grid. The examples are shown below. Stakeholder Group Stakeholder Ability to Disrupt Change Current Understanding Required Understanding Current Commitment Required Commitment Required Support CIO John Smith H M H L M H CFO Jeff Brown M M M L M M Figure 26 Stakeholder Analysis Figure 27 Stakeholder Power Grid Using TOGAF and Frameworx From a Frameworx perspective, stakeholders wishing to implement Frameworx include SPs, Equipment Manufacturers (EM), Independent Software Vendors (ISV) and Systems Integrators (SI). Generally speaking, stakeholders can be divided into two categories: Stakeholders that deliver products, directly or indirectly, to consumers (product delivery stakeholders) Stakeholders that support those that deliver products (product delivery support stakeholders) Stakeholders in the first category can include SPs, ISVs and EMs. The second category can include EMs and SIs. Both stakeholder categories have the opportunity to implement all or some of Frameworx solutions etom, SID or TAM. The Open Group and TM Forum Page 54 of 110

55 Therefore, four different types of stakeholders can be identified, which are: Service Providers (SP) System Integrators (SI) Independent Software Vendors (ISV) Equipment Manufacturers (EM) etom includes a process Stakeholder & External Relations Management at hierarchy level This process focuses on managing the relationship with stakeholders and outside entities and includes customers, supplier & partners, shareholders, employees, regulators, communities, unions and other external stakeholders. In spite of this description, this process type does not explain how to do stakeholder management as TOGAF does. Comparing both in this context, TOGAF provides a rich methodology to manage stakeholders. This includes the identification and classification of stakeholders by using a stakeholder map and power grid. Additionally, TOGAF also suggests considering all types of stakeholders (external and internal) who could be positively or negatively impacted by the architecture approach. These internal or external stakeholders can be business unit leaders, employees or external partners. etom can be used to identify the relevant stakeholders across the various domains within the enterprise. The stakeholder management method will then help to manage these stakeholders along the enterprise architecture project. Therefore, stakeholder management is a critical technique and must be included as part of any major enterprise architecture journey. 3.7 Architecture Patterns A pattern is defined as an idea that has been useful in one practical context and will probably be useful in others. In TOGAF, patterns are considered to be a way of putting building blocks into context; for example, to describe a re-usable solution to a problem. Building blocks are what you use, patterns can tell you how to use them, and when and what trade-offs you have to make in doing so. Using TOGAF and Frameworx In the context of TOGAF and Frameworx, the Frameworx solution SID maps to a certain extent with the architecture patterns of TOGAF. Modeling patterns are defined and used in the SID, these include: Entity Specification/Entity pattern The Open Group and TM Forum Page 55 of 110

56 Entity/Entity Role pattern Composite/Atomic pattern Business Interaction pattern Entity Characteristic Spec/Entity Characteristic pattern These patterns can be found in SID addendum GB922-U Using SID. The guidelines for patterns as defined in the SID framework are concerned with extending the Information/Data model by adding new ABEs or extending the attributes of existing ones. These guidelines include: Modeling patterns Association, attribute and package naming conventions Guidelines for naming entities Guidelines for defining association classes versus simple association The Frameworx solution SID in contrast with TOGAF includes different types of predefined patterns. TOGAF on the other hand provides additional information about different types of patterns (business, integration, composite, application and runtime patterns) and the content of these patterns, which need to be considered for the development of new patterns. Consequently, TOGAF provides an additional and useful method in terms of patterns and methods to apply patterns, as input to the Frameworx-defined patterns. 3.8 Business Scenarios A critical factor in successful enterprise architecture is the extent to which it is aligned and fulfills business requirements enabling the enterprise to achieve its business goals. Business scenarios are an important technique that may be used at various stages of the enterprise architecture (e.g., Architecture Vision and Business Architecture). They are used to identify and to understand business needs and thereby to derive the business requirements that the architecture development has to address. Using TOGAF and Frameworx Frameworx does not explicitly include the business scenario technique in etom, SID and TAM. A similar method is used to develop use-cases and business flows in the Frameworx methodology. This method is described in the Integration Framework (previously known as TNA) in Frameworx, which will be the object of another mapping document that this team intends to produce in the next stage of this initiative. The Open Group and TM Forum Page 56 of 110

57 Nevertheless, we can conclude at this stage that etom, SID and TAM should be applied in use-cases to describe business scenarios as part of Phase A (Architecture Vision) of the TOGAF ADM. Figure 28 Business Scenarios and Frameworx When developing a business scenario based on TOGAF and Frameworx, the three Frameworx solutions should be used to describe business processes as well as business entities and applications which are in the scope of the new architecture. Furthermore, the existing and the future business and technology environment should be described using the Frameworx solutions (use-cases are the starting point for this purpose). This includes the different actors, their roles and responsibilities and the desired outcome of proper execution. In the book NGOSS Distilled, an assessment methodology is described, which includes the documentation, review and interviews of key enterprise staff before executing a new enterprise architecture. This assessment methodology in Frameworx basically illustrates the phases involved in developing a business scenario but does not mention the steps necessary to create a business scenario as TOGAF does. Figure 29 shows the mapping between both methodologies. The Open Group and TM Forum Page 57 of 110

58 Figure 29 Business Scenario in TOGAF and Assessment Methodology in Frameworx Using the business scenario concepts from TOGAF in combination with the three Frameworx solutions will provide strong support for the development of the high-level baseline and Target Architectures. Additionally, TOGAF also provides sample questions for different areas and purposes and a method to define business scenarios. 3.9 Gap Analysis The basic premise of the Gap Analysis technique is to highlight a shortfall between the Baseline Architecture and a Target Architecture; that is, items that have been deliberately omitted, accidentally left out or not yet defined. Using TOGAF and Frameworx The Frameworx solutions do not explicitly say something about a methodology for a gap analysis. Looking to TAM, a gap analysis is mentioned to identify the gaps between the Frameworx solutions seen as the Target Architecture and the actual operator s landscape as the Baseline Architecture. Figure 30 illustrates a gap matrix for telecommunication services, which can be considered in the product architecture as part of the Business Architecture. The Open Group and TM Forum Page 58 of 110

59 Figure 30 Gap Analysis Because of this situation, the information about a gap analysis in TOGAF is useful with regard to performing a gap analysis. It provides a specific set of steps and a sample template for developing a gap analysis Migration Planning Techniques TOGAF provides several migration planning techniques, which are an important part of the overall migration of a new architecture. These are: Implementation Factor Assessment and Deduction Matrix Consolidated Gaps, Solutions and Dependencies Matrix Architecture Definition Increments Table Enterprise Architecture State Evolution Table Business Value Assessment Technique Using TOGAF and Frameworx: The Frameworx solution TAM defines a clear target application set from which operators can either build a migration plan or create a greenfield structure. It also allows suppliers The Open Group and TM Forum Page 59 of 110

60 to clearly position their products and provides a common language and reference model for the industry worldwide. How to build a migration plan is not described in TAM. The Integration Framework is generally a migration and integration framework. It describes the integration of the Frameworx solutions using services and ABEs. The detailed mapping of the Integration Framework will be part of Document 2 mapping at a later time as soon as the official documents of the Integration Framework are published. The three Frameworx solutions etom, SID and TAM should be considered when gaps at different architecture dimensions are identified and a potential solution or rather Frameworx service can be used to fill this gap. The figures below show usable artifacts of TOGAF, which can be used for identifying the gaps of Frameworx services for the architecture projects. Implementation Factor Assessment and Deduction Matrix This technique can be used to document the factors impacting the architecture Implementation and Migration Plan. So, a change in technology can lead to a new business and Information Systems Architecture based on etom, SID and TAM. Figure 31 TOGAF Implementation Factor Assessment and Deduction Matrix Consolidated Gaps, Solutions and Dependencies Matrix This technique allows the architect to group the gaps identified in the domain architecture gap analysis results and assess the potential solutions and dependencies to one or more gaps. The Open Group and TM Forum Page 60 of 110

61 Figure 32 TOGAF Consolidated Gaps, Solution and Dependencies Matrix The three Frameworx solutions etom, SID and TAM represent the different architectures and the related services developed by the Integration Framework of Frameworx; see Figure 33. Considering the example of integrating a new partner, a new order processing process including the related applications can be necessary to establish before being able to run this new partnership. Consequently, the Frameworx solutions etom, SID and TAM need to be considered when developing this new service or rather architecture. Figure 33 TOGAF Gaps, Solution and Dependencies Matrix with Frameworx Services Architecture Definition Increments Table This technique allows the architect to plan a series of Transition Architectures (building a roadmap) outlining the status of the enterprise architecture at a specified time. The Open Group and TM Forum Page 61 of 110

62 Figure 34 TOGAF Architecture Definition Increments Table with Frameworx Services As shown in this example, the different Frameworx solutions etom, SID and TAM can be considered in the respective Transition Architectures basically being part of the architecture roadmap for the implementation. Consider the different deliverables and building blocks of each Frameworx solution in this case. Enterprise Architecture State Evolution Table Using a State Evolution Table as shown below allows the architect to show the proposed state of the architectures at various levels. Figure 35 TOGAF State Evolution Table This table should be drawn listing the services from the Frameworx telecommunicationsspecific enterprise architecture, The transition Architectures, and proposed transformations, as shown in Figure 36. The Open Group and TM Forum Page 62 of 110

63 Figure 36 TOGAF State Evolution Table with Frameworx Services Consequently, the TOGAF migration planning technique strongly supports the migration phase of ADM by providing different types of artifacts, which can be perfectly combined with the Frameworx solutions or rather services Interoperability Requirements Interoperability is the ability to share information and services. Defining the degree to which the information and services are to be shared is a very useful architectural requirement, especially in a complex organization and/or extended enterprise. Using TOGAF and Frameworx The Integration Framework of Frameworx describes Frameworx services, which represent the fundamental unit of interoperability in a Frameworx solution and is a technology-neutral representation of an interface to a service. Considering the Frameworx services, the other Frameworx solutions etom, SID and TAM do strongly support the interoperability of a Frameworx solution. Comparing TOGAF and Frameworx, interoperability is part of the whole Frameworx concept of services but does not explain how to reach and ensure interoperability and which categories of interoperabilities and methodologies can be defined and used. Figure 37 shows that a stakeholder A requires unstructured data exchange (degree 2) with stakeholders B and D, and seamless sharing of data (degree 3) with stakeholders C, E, F and G. Relating to Frameworx solutions etom, SID and TAM the stakeholders can be from different etom domains (e.g., Supply & Partner Management and Service Management & Operations). These stakeholders need specific information and data from other stakeholders within the enterprise which need to be structured on a matrix, as shown below. The Open Group and TM Forum Page 63 of 110

64 Figure 37 TOGAF Business Information Interoperability Matrix As shown in Figure 37, TOGAF provides different categories of interoperabilities and suggests four degrees of interoperabilities, which are both part of business and information systems interoperability matrices. These matrices enable you to build up a scalable and flexible OSS landscape as suggested by the TM Forum and facilitate the rapid deployment of the new service products. This very useful information is provided by TOGAF and can strongly support the development of operator s architecture considering interoperability Business Transformation Readiness Assessment The Business Transformation Readiness Assessment evaluates and quantifies an organization s readiness to undergo changes. Using TOGAF and Frameworx The Frameworx solutions do not have a specific area about this section, even though this is one of the most important parts of developing an architecture. As shown below, the business transformation is one principle at the TAM Frameworx solution and concentrates mostly on automated processes. Frameworx Principle: Enable an Operator s Business Transformation The core aim behind NGOSS is to allow simplified implementation of business process automation coupled with significantly improved business flexibility and agility. These operational aims directly link to the key objectives of the TM Forum Lean Operator Program. Comparing TOGAF and Frameworx the Business Transformation Readiness Assessment of TOGAF does not map directly to the Frameworx solutions but can be considered together with the assessment methodology of Frameworx or rather assessing the Frameworx implementation chapter of the book NGOSS distilled. The Open Group and TM Forum Page 64 of 110

65 This section describes the assessment, how to implement a Frameworx solution concentrating on objectives and scope of the project, the involved stakeholders and the different Frameworx solutions. This assessment approach of Frameworx mostly concentrates on the functional integration of the Frameworx solutions but not on the factors, which are considered by the architecture team, the organization and their units when implementing this solution. Figure 38 illustrates the different readiness factors used in a summary table, which exactly considers these factors. Figure 38 TOGAF Summary Table of Business Transformation Readiness Assessment For example, the readiness factor Need could describe what a business organization would not be able to do if the architecture project does not proceed and equally clear statements of what the project will enable the business organization to do. Implementing the Frameworx solutions or rather services can be critical for the success of the organization and therefore would have a high Urgency but the Readiness Status can be Fair, which means needs some work before proceeding. Consequently, the Degree of Difficulty to Fix can be moderate or difficult this readiness factor. As it can be seen, the Frameworx solutions etom, SID and TAM do not map to Chapter 30 (Business Transformation Readiness Assessment) of TOGAF but they provide some functional inputs to assess the readiness to undergo changes in the organization. The Open Group and TM Forum Page 65 of 110

66 3.13 Risk Management Risk management is a technique used to identify and mitigate risk when implementing an architecture project. It is important to identify, classify and mitigate these risks before starting so that they can be tracked throughout the transformation effort. Mitigation is an ongoing effort and often the risks trigger may be outside the scope of the transformation planners, so the planners must monitor the transformation context effort. Using TOGAF and Frameworx The actual version of the Frameworx solution does not have a specific part for risk management and the three Frameworx solutions are also not needed specifically for the risk management as such. They may be used for specific implementation risks from the baseline to Target Architecture. The Frameworx solution etom includes a process type Enterprise Risk Management at the hierarchy level talking about business continuity management, fraud management, audit management and others. These are process functions in the meaning of the etom process model and do not include a risk management method as described in TOGAF. As shown in Figure 39, Chapter 31 (Risk Management) of TOGAF provides a very useful technique to identify, classify and mitigate risks within an architecture project and therefore strongly ensures the success of an architecture approach based on Frameworx and TOGAF. Figure 39 Risk Classification Scheme Figure 40 Risk Identification Worksheet The Open Group and TM Forum Page 66 of 110

67 3.14 Capability-Based Planning Capability-based-planning is a business planning technique that focuses on business outcomes. It also copes well with the friction of co-ordinating projects across corporate functional domains that together enable the enterprise to achieve that capability. Using TOGAF and Frameworx TOGAF Capability-based-planning is a very useful technique to concentrate on business outcomes but it does not map to the Frameworx solutions etom, SID and TAM. Nevertheless, combining both capability-based-planning of TOGAF and the Frameworx solutions etom, SID and TAM would perfectly harmonize the development of an enterprise architecture, which is business-driven and combines the requisite efforts of all lines of business to achieve the desired capability. For example, a new product development of an IP voice service can be seen as a desired business outcome for which a new architecture on all architecture dimensions is needed. The Frameworx solution etom is needed to define the Business Architecture including processes, functions and roles and responsibilities for the new IP voice service. Right after that, the necessary applications and the respective Data Architecture which support the Business Architecture need to be identified and implemented by using TAM and SID. This can be considered as a business perspective. When a new data center is needed, then it is really about consolidating corporate data and providing the related services (data and application services) to the business. This can be seen as the related IT perspective. Figure 41 Capability-Based Planning and Frameworx Generally speaking, the Frameworx solution Integration Framework considers Frameworx services and describes a particular capability that is offered by the SPs to a service consumer. Therefore, it focuses on services or rather business outcomes, which are developed by the Frameworx solutions and consequently the whole Frameworx The Open Group and TM Forum Page 67 of 110

68 concept and Frameworx solutions support the development of an architecture, based on the capability-based-planning concept as described in TOGAF. A more detailed description of the mapping between capability-based-planning of TOGAF and Integration Framework of Frameworx is expected to follow, as soon as the Integration Framework is published. The Open Group and TM Forum Page 68 of 110

69 4 Architecture Content Framework and Synergies with Frameworx 4.1 Introduction and Scope This section provides a comparison between the TOGAF Architecture Content Framework and Frameworx. 4.2 Content Metamodel A TOGAF architecture is defined by a number of architecture building blocks within architecture catalogs, specifying the relationships between those building blocks in architecture matrices, and then presenting communication diagrams that present in a precise and concise way such architecture. This section introduces the core concepts that make up the TOGAF content metamodel, through the following subsections: Core and Extension Content provides an introduction to the way in which TOGAF employs a basic core metamodel and then applies a number of extension modules to address specific architectural issues in more detail. Core Metamodel Entities introduce the core TOGAF metamodel entities, showing the purpose of each entity and the key relationships that support architectural traceability. Catalog, Matrix and Diagram Concept describes the concept of catalogs, matrices and diagrams. Using TOGAF and Frameworx The Content Metamodel defines a set of entities that allow architectural concepts to be captured, stored, filtered, queried and represented in a way that supports consistency, completeness and traceability. Figure 42 presents the Content Metamodel with extensions and the respective mapping to the Frameworx solutions. The Open Group and TM Forum Page 69 of 110

70 Figure 42 TOGAF Content Metamodel with Extensions and Mapping to Frameworx Based on the description above, the Content Metamodel represents the content of all three different Frameworx solutions etom, SID and TAM. The content metamodel is valuable as a reference structure to map the TM Forum Frameworx and highlight gaps. This provides an insight into where the assets fit from an enterprise architecture perspective. etom, SID, TAM and the Content Metamodel As already described in the sections above, the SID defines business entities, their attributes, associations and ultimately the conceptual and logical data model, which will serve as a basis to build the physical data model. Such models are linked to relevant business processes and applications across the enterprise. The following table shows the objects in the TOGAF Content Metamodel and their mapping to the Frameworx etom, SID and TAM. The Open Group and TM Forum Page 70 of 110

71 TOGAF Content Metamodel Objects Organizational Unit Actor/Role Business Function Process Data Entity Frameworx Not included in Frameworx. As part of the Business Architecture, it maps to the Frameworx solution etom. Within etom, it can be considered as the conceptual view of etom and represents the horizontal and vertical process groupings. These groupings represent the line management responsibilities, goals, objectives and measures. Not included in Frameworx. As part of the Business Architecture, it maps to the Frameworx solution etom. An actor can be a person, organization or system that has a role that initiates or interacts with activities or functions as part of functional process grouping. This actor can have different roles within a process or rather function; e.g., customer, supplier, subscriber, end user as described in etom. As part of the Business Architecture, it maps to etom. A function or activity delivers a business capability aligned to an organization. Within etom it can be, for example, a level 3 process like Determine Customer Order Feasibility within the the Order Handling core process. Depending on applied terminology, Function goes hand-inhand with process as it (the function) provides the organizational perspective. As part of the Business Architecture, it maps to the etom. A process is a flow/sequence of steps that produce a specified outcome. The flow combines different functions. It can be decomposed into sub-processes. TOGAF process definition refers to the logical perspective representing the HOW, and Frameworx refers to both the WHAT and the HOW depending on which view is taken as perspective; in the etom, the WHAT represents the dynamic view, whereas the HOW represents the dynamic view. As part of the Data Architecture, it maps to the Frameworx SID. Data Entity is an encapsulation of data that is classified within a business domain as a thing of interest to the business. In SID terms, these are business entities which map to Data Entity in TOGAF. These are, for example: Data Entity refers to the physical implementation of the SID logical view. Business Entity represents something of interest to the business. These are characterized by attributes and participate in relationships with other business entities. Aggregate Business Entity (ABE) is a loosely-coupled set of business entities. Sometimes called Business Object. The Open Group and TM Forum Page 71 of 110

72 TOGAF Content Metamodel Objects Logical Data Component Physical Data Component Information System Service Logical Application Component Physical Application Component Business Services Principle Frameworx As part of the Data Architecture, it maps to the Frameworx solution SID as an information model. This is a boundary zone that encapsulates related data entities to form a logical location to be held; e.g., procurement information. Does not map to the SID by definition, because it reflects the implementation of a data entity, and in architecture no implementations exist. This is an automated element of a business service and may support business services. Both, business and information system services are described in the Integration Framework in Frameworx and therefore are not part of this document which focuses on the mapping of etom, SID and TAM only. As part of Application Architecture, it maps to Frameworx TAM. In TAM, applications are not described as computer systems, but as logical groups of capabilities that manage the data objects and support the business functions in the Business Architecture. The applications and their capabilities are defined without reference to particular technologies. Even if this is part of the Application Architecture, it does not map to TAM, because TAM is a conceptual architecture framework, not an implementable solution. A Physical Application Component is an application, application module, service or deployable component of functionality of a COTS product. A business service supports capabilities through an explicitly defined interface and is governed by an organization. The Integration Framework focuses on business services, which represent a specification of system capability to achieve a stated business purpose. Therefore, this object maps to the Integration Framework in Frameworx. This is a qualitative statement of intent that should be met by the architecture. This is not included in Frameworx. TAM in Frameworx mentions ten principles and therefore it can be mapped to this object. The TM Forum Frameworx can benefit from the Content Metamodel object definitions in TOGAF as shown above. The Open Group and TM Forum Page 72 of 110

73 4.3 Architectural Artifacts The artifact represents an individual model of a system or solution, which could potentially be re-used in a variety of contexts. An artifact is distinct from a deliverable, which is a contracted output from a project. In general, deliverables will contain artifacts and each artifact may have many deliverables. Using TOGAF and Frameworx TOGAF defines specific classes of viewpoints or artifacts, which can be considered at different phases of the TOGAF ADM. These are: Catalogs: list of building blocks (e.g., Principle catalog) Matrices: shows the relationships between building blocks of specific types (e.g., actor/role matrix) Diagrams: a graphical viewpoint that presents building blocks (e.g., class diagram) Looking into detail, the TOGAF artifacts describe the structure of outputs of the architectural effort during a development of an enterprise architecture. Considering Frameworx, artifacts are components of the Frameworx solution and not part of the architectural effort during the development of an enterprise architecture as described in TOGAF. Therefore, they do not really map to each other but rather complement each other. How etom, SID and TAM relate to the artifacts of TOGAF is shown in Figure 43. The Open Group and TM Forum Page 73 of 110

74 Figure 43 TOGAF Artifacts and Frameworx Solutions Frameworx makes use of all three artifacts. The metamodel concepts can well be adopted by the TM Forum in order to extend the frameworks to other assets. TOGAF Artifacts Artifacts (catalogs, matrices and diagrams) of the Preliminary Phase Artifacts (catalogs, matrices and diagrams) of Phase A (Architecture Vision) Artifacts (catalogs, matrices and diagrams) of Phase B (Business Architecture) Artifacts (catalogs, matrices and diagrams) of Phase C (Data Architecture) Frameworx Artifacts Frameworx application solution TAM identifies Frameworx-specific principles. Not covered directly. However, Frameworx mentions different type of stakeholders which support the development of the stakeholder map. Frameworx process etom supports the development of the artifacts. For example, an actor/role matrix can be created by defining roles and responsibilities of actors in etom processes. The result will be a RACI matrix equal to the actor/role matrix. Frameworx data SID supports the development of the artifacts. For example, a class diagram will be produced when the Data Architecture based on SID is developed. The Open Group and TM Forum Page 74 of 110

75 TOGAF Artifacts Artifacts (catalogs, matrices and diagrams) of Phase C (Application Architecture) Artifacts (catalogs, matrices and diagrams) of Phase D (Technology Architecture) Artifacts (catalogs, matrices and diagrams) of Phase E (Opportunities and Solutions) Artifacts (catalogs, matrices and diagrams) of Requirements Management Frameworx Artifacts Frameworx application TAM supports the development of the artifacts. For example, an interface catalog will be produced when the Application Architecture based on TAM is developed and the dependencies between the applications are identified. Not covered. Systems architecture (SOA style architecture) contains a set of concepts that are similar or equal to contracts in Frameworx. Not covered. Frameworx etom does not define measurable requirements. It only defines the generic goal for an SP. 4.4 Architectural Deliverables Architecture deliverables as defined in TOGAF are deliverables that are typically produced and consumed across the TOGAF ADM cycle. As deliverables are typically the contractual or formal work products of an architecture project, it is likely that these deliverables will be constrained or altered by any overarching project or process management for the enterprise. Using TOGAF and Frameworx TOGAF describes different architectural deliverables produced at different phases of the ADM cycle. These are shown in the table below. TOGAF Deliverables Frameworx Architecture Building Blocks See Section 4.5. Architecture Contract Partly covered. In Frameworx (etom, SID and TAM) there is also the notion of contract. It was known as NGOSS contract, and has now evolved into the notion of business service as defined within the context of SOA. Business services as defined in Frameworx can be related to Architecture Contracts as defined in TOGAF if done from a technical perspective. The TOGAF Architecture Contract between architecting function and business users concentrates on services delivered by the architecture to the business users. This contract mainly maps to the Integration Framework approach of business services and will be covered within The Open Group and TM Forum Page 75 of 110

76 TOGAF Deliverables Architecture Definition Document Architecture Principles Architecture Repository Architecture Requirements Specification Architecture Roadmap Architecture Vision Business Principles, Business Goals, Business Drivers Capability Assessment Change Request Communications Plan Frameworx the next stage of this project mapping in the near future. See Section 7.5 for further details on Architecture Contracts. Not covered. etom, SID and TAM can be leveraged as part of this document and represent the architecture content. A number of architecture principles are defined as part of Frameworx documentation, particularly within the Application Framework TAM. Not covered. etom, SID and TAM can be easily moved to being part of the content in the Architecture Repository and of the Reference Library therein. This forms the basis for the development of a new enterprise architecture. Architecture requirements are taken into account and described as use-cases. Use-cases are a key artifact for gathering business requirements and confirm how processes and information actually interact. etom processes are a good starting point for modeling and defining use-cases; level 2 (high-level), levels 3 and below (detailed). The aim with Frameworx is to provide an integrated Business Architecture roadmap which helps achieve business process automation coupled with significantly improved business flexibility and agility. Not covered. For the formulation of an Architecture Vision, etom, SID and TAM should be used to develop the high-level view of the Target Architecture in Phase A (Architecture Vision) of TOGAF. A number of architecture principles are defined as part of Frameworx documentation. The Frameworx solution etom provides maturity assessment; the Frameworx assessment team supports the development of this deliverable. Not covered. A further adaptation of etom, SID and TAM can lead to a change request to cover new requirements. Frameworx can benefit from TOGAF. Not covered. The communication plan as suggested by TOGAF helps to structure the communication and type of information delivered to involved stakeholders. Stakeholders can be those involved across the different horizontal domains that constitute the Frameworx structure. The Open Group and TM Forum Page 76 of 110

77 TOGAF Deliverables Compliance Assessment Implementation and Migration Plan Implementation Governance Model Organizational Model for Enterprise Architecture Request for Architecture Work Requirements Impact Assessment Frameworx This assessment is relevant to Frameworx as it relates to the SID and etom conformance and compliance assessment principles and rules. In connection with the TOGAF Architecture Compliance assessment methodology it can be very helpful in the assessment of conformance or compliance. Frameworx can benefit from TOGAF. Not covered. Frameworx can benefit from TOGAF. Not covered. Frameworx can benefit from TOGAF. Not covered. Frameworx can benefit from TOGAF. Not covered. Frameworx can benefit from TOGAF. Not covered. Frameworx can benefit from TOGAF. Solution Building Block See Section 4.5. There is a notion of application components defined in TAM. Frameworx can benefit from TOGAF. Statement of Architecture Work Not covered. Frameworx can benefit from TOGAF. Tailored Architecture Framework Tailored Frameworx solutions etom, SID and TAM. Transition Architecture Not covered. Frameworx can benefit from TOGAF. These architectural deliverables can be seen as architectural outputs in particular projects within enterprise architecture revamping initiatives. As we compare TOGAF and Frameworx, the latter does not explicitly describe deliverables as TOGAF does. As shown in the table above, different parts of Frameworx can be considered or will influence the development of the architecture deliverables across the ADM cycle. Frameworx could apply the deliverables more rigorously by mentioning explicitly the deliverables in dedicated sections of a document, but this is more within the scope of the Integration Framework as it describes and provides a methodology to integrate etom, SID and TAM together in the form of business services; such business services can be considered and are linked to specific deliverables. 4.5 Building Blocks All artifacts described within etom, SID and TAM are in their own right a kind of building block as per the definition of building block in TOGAF; such artifacts can be considered as Architecture Building Blocks (ABBs); they are Business Processes in etom, The Open Group and TM Forum Page 77 of 110

78 Aggregate Business Entities (ABEs) in SID and Modules or Application Components within TAM. SBBs on the other hand are more closely related to packaged products or solutions; they can be, for instance, certified tools, COTS software, personal computers or other types of packaged products or capabilities. The Open Group and TM Forum Page 78 of 110

79 5 Enterprise Continuum and Tools and Synergies with Frameworx 5.1 Introduction and Scope This section provides a comparison between the TOGAF Enterprise Continuum and Frameworx solutions. 5.2 Enterprise Continuum The Enterprise Continuum is a view of the Architecture Repository that provides methods for classifying architecture and solution artifacts, both internal and external to the Architecture Repository as they evolve from generic Foundation Architectures to Organization-Specific Architectures Architecture Continuum The Architecture Continuum illustrates how the architectures are developed and evolved across a continuum ranging from Foundation Architectures, such as the one provided by TOGAF, through Common Systems Architectures and Industry Architectures and to an enterprise s own Organization-Specific Architectures. Using TOGAF and Frameworx Frameworx solutions etom, SID and TAM reflect the industry architecture of the Architecture Continuum. These frameworks define specific building blocks for a vertical industry, namely the Information, Communications, Media and Entertainment industry, and consists of business processes, data, and applications Solutions Continuum The Solutions Continuum represents the detailed specification and construction of the architectures at the corresponding levels of the Architecture Continuum. At each level, the Solutions Continuum is a population of the architecture with reference to building blocks either purchased products or built components that represent a solution to the enterprise s business need expressed at that level. The Open Group and TM Forum Page 79 of 110

80 Using TOGAF and Frameworx Frameworx solutions etom, SID and TAM do map to the Architecture Continuum. They do not map to the Solutions Continuum. The Frameworx Lifecycle provides a framework for developing solutions from architectures. 5.3 Architecture Partitioning In a typical enterprise, multiple architectures will be in existence at any point in time. Some architectures will address very specific needs; others will be more general. Some will address detail; some will provide a bigger picture. Likewise, there will also be many solutions in use, or being considered for use to meet the needs of the enterprise. Each of these solutions and architectures do not exist in a vacuum and the Enterprise Continuum provides a classification model for all related architectures and solutions. Within the Enterprise Continuum, boundaries, relationships and ordering can be established for both solutions and architectures in order to simplify the development and management of the enterprise. Using TOGAF and Frameworx Considering the characteristics of solutions and architecture of TOGAF partitioning, the Frameworx solutions etom, SID and TAM need to be considered in order to partition an architecture as prescribed in TOGAF. They mainly represent the segment architectures and thus provide a definition of the architecture in a specific partition. When partitioning, the relationships between the segment architectures also have to be defined. Further detailed information can be found in the table below. TOGAF Characteristics of Architecture Partitioning Partitioning of Solution Subject Matter Time Maturity/Volatility Frameworx Solutions Depending on the nature of the architecture, the Frameworx solutions of the business domain (etom), information domain (SID) and application domain (TAM) need to be considered. Examples can be developing new products, services, service centers, etc. for which a new architecture based on etom, SID and TAM can be formulated. The evolution of Frameworx solutions over time is an important consideration as they provide modeling for business processes, data and applications, whose dynamic evolution over time can impact legacy as well as current architectures. Use the etom process maturity model for the Business Architecture to identify the actual status in contrast with the solution lifecycle. The Open Group and TM Forum Page 80 of 110

81 TOGAF Characteristics of Architecture Partitioning Partitioning of Architecture Viewpoint Level of Detail Level of Abstraction Accuracy Frameworx Solutions Depending of the nature of the Target Architecture solution, etom, SID and TAM can be used to identify specific viewpoints. Example: The horizontal Supplier/Partner domain within etom, SID and TAM can be the source for developing viewpoints from stakeholders in this domain (Procurement, Partner Management, etc). Identify the relevant process elements within etom starting at level 0, as well as related SID entities/attributes and components within TAM, to define the level of architecture detail for a specific architecture project. See Figure 44. Identify and use etom, SID and TAM to define the architecture. Use the higher levels of Frameworx (0 and 1 mainly) solutions as abstract architectures to communicate future concepts and reference models which can be applied to specific problems in future architectures. Valuable when applying Frameworx solutions. Accuracy can be of significant concern to ensure a higher precision in further architecture development. The following drawings and descriptions represent an example of how TOGAF and Frameworx can be used together for architecture partitioning. When integrating a new partner (supplier, vendor, system integrator or any other type of business partner) some degree of impact will have to be accommodated in the enterprise architecture. Frameworx solutions etom, SID and TAM need to be considered within the Supplier/Partner domain in order to partition the architecture effort, as shown in Figure 44. The Open Group and TM Forum Page 81 of 110

82 Figure 44 Architecture Partitioning with Frameworx Examples Consider the level of detail, scope and timeframe in terms of architecture content for Supplier/Partner Relationship Management to partition the architecture. etom provides the enterprise business (processes), SID the enterprise information concepts and data in scope and TAM the enterprise applications or components. Use the various hierarchy levels in etom, SID and TAM to define the depth and detail granularity for the enterprise architecture, as shown in Figure 45 and Figure 46. Finally, define the building blocks for each architecture domain and consequently the capability and transition architectures for the implementation at Phases E, F and G of the TOGAF ADM and establish the portfolio/project team for these phases. The Open Group and TM Forum Page 82 of 110

83 Exploring Synergies between TOGAF and Frameworx Figure 45 Architecture Partitioning with Frameworx Examples Frameworx also provides in its etom, SID and TAM different levels of detail which facilitate decision-making on what detail to cover. The Open Group and TM Forum Page 83 of 110

84 Figure 46 TOGAF Partitioning and Frameworx Solutions 5.4 Architecture Repository The Architecture Repository allows the enterprise to distinguish between different types of architectural assets that exist at different levels of abstraction in the organization. It provides the capability to link architectural assets to components of the detailed design, deployment and Service Management Repositories. Using TOGAF and Frameworx The Frameworx solution Integration Framework describes a repository of business services (registry in TOGAF terms) as the heart of the distributed architecture, which provides a logical view of all the information regarding deployed distributed systems and the business services in scope. A detailed mapping of the TOGAF repository and Frameworx Integration Framework will be part of a future document as a deliverable for the next phase of this mapping project. The Frameworx solutions etom, SID and TAM can also be considered in the scope of the Architecture Repository in TOGAF. Figure 47 provides an overview of how Frameworx solutions fit with respect to the TOGAF repository. The Open Group and TM Forum Page 84 of 110

85 Figure 47 TOGAF Repository and Frameworx Solutions With the link to the Architecture Continuum, Frameworx is part of the Reference Library, especially as part of the Industry Architecture. They form the basis, templates and guidelines for the revamping of a new enterprise architecture. Mostly etom and SID can be qualified in the Governance Log, especially in the section compliance assessment and particularly the etom and SID conformance criteria. These criteria provide a record of governance activities across the enterprise with respect to conformance and compliance assessment. In addition, the Frameworx solutions also need to be considered from an Architecture Landscape perspective in terms of providing the architectural view on existing building blocks, which can be based on these Frameworx solutions too. etom, SID and TAM can be part of the organizationally tailored architecture framework including a method for architecture development and a metamodel for the architectural content. The TOGAF Architecture Repository consists of six different classes, which provides a base structure for an Architecture Repository, and which also accommodates the Frameworx solutions as shown in the figure. The Open Group and TM Forum Page 85 of 110

86 5.5 Tools for Architecture Development This section discusses considerations for choosing automated tools in order to design and generate architecture models and views and to maintain them over time. TOGAF defines a set of specific criteria which a COTS modeling tool should comply with; this is an added value for enterprises who want to use such tools. These criteria are as follows: Functionality Tool Architecture Full Lifecycle Support Interoperability Factors Financial Considerations Vendor Factors Using TOGAF and Frameworx Frameworx does provide a concept about the use of tools to apply Frameworx. The TM Forum has produced a Technical Report (TR144 from the TM Forum Tooling Environment) which is an output of the Tooling Program (formerly Tooling Task Force). The charter of the Tooling Program was to address outstanding issues with TM Forum tools. This involves streamlining and unifying the process of creation, sharing and maintenance of NGOSS artifacts throughout their lifecycle. A high priority item for the team was to address the various compatibility issues between different tools in the Solution Frameworks (NGOSS) tool chain. The technical teams must be able to produce artifacts that can be easily used by consumers of those artifacts, be they other TM Forum technical teams or TM Forum member organizations. The technical report documents the use-cases for the production of TM Forum artifacts, and defines requirements for effective use of tools across the TM Forum technical teams. It also describes the tools currently in use by technical teams within the TM Forum in the production of TM Forum artifacts. The document makes recommendations for changes and improvements to existing TM Forum Solution Frameworks artifacts development processes. The document suggests that the Solution Frameworks tooling framework should be aimed to be oriented towards the use of Domain-Specific Languages in order to better address the requirement specific to each individual Solution Frameworks modeling activity and simplify the modeling process for end users. TOGAF on the other hand provides a set of tools selection criteria. Furthermore, TOGAF criteria for tool selection can also be used for selecting OSS/BSS supporting tools for SPs and other players within the telecommunications industry. The Open Group and TM Forum Page 86 of 110

87 6 TOGAF Reference Models and their Relevance to Frameworx 6.1 Introduction and Scope This chapter describes the detailed mapping of the Technical Reference Model (TRM) and the Integrated Information Infrastructure Reference Model (III-RM) to Frameworx. Generally speaking, the Integration Framework in Frameworx exhibits strong synergies with regard to these two reference models in TOGAF. 6.2 Foundation Architecture: Technical Reference Model This section is not in scope of this document. It will be part of the next document in this project, which will provide the mapping between TOGAF and the Frameworx solution Integration Framework. 6.3 Integrated Information Infrastructure Reference Model This section is not in scope of this document. It will be part of the next document in this project, which will provide the mapping between TOGAF and the Frameworx solution Integration Framework. The Open Group and TM Forum Page 87 of 110

88 7 Applying the Architecture Capability Framework to Frameworx 7.1 Introduction and Scope This section describes the Architecture Capability Framework in TOGAF and proposes an initial mapping to the four TM Forum Frameworx solutions. 7.2 Establishing an Architecture Capability This section provides guidelines on how to use the ADM to establish an architecture capability. The establishment of an enterprise architecture capability can be supported by the TOGAF Architecture Development Method (ADM). Successful use of the ADM will provide a customer-focused, value-adding, and sustainable architecture practice that helps the business maximize the value of investments, and pro-actively identifies opportunities to gain business benefits and manage risk. Using TOGAF and Frameworx As mentioned previously, this section provides an overview of how to establish the architecture capability by using the ADM cycle. All Frameworx solutions etom, SID and TAM are considered for such purpose (establishing the architecture capability). Frameworx describes architecture capabilities in terms of business services, but we will leave this topic to the next document in this project covering the mapping of the Integration Framework. 7.3 Architecture Board This chapter provides guidelines for establishing and operating an enterprise Architecture Board. It describes the different roles, responsibilities and how to set up an Architecture Board. Using TOGAF and Frameworx Frameworx provides information about stakeholders and project members but not about the Architecture Board as such. The three Frameworx solutions etom, SID and TAM do not map to this chapter of TOGAF. The Open Group and TM Forum Page 88 of 110

89 Nevertheless, when establishing an Architecture Board, the members of this board (can also be called stakeholders) should have specific knowledge about the concept of Frameworx and its solutions etom, SID and TAM to fulfill the respective roles in this board. 7.4 Architecture Compliance When establishing architecture governance, an architecture compliance review based on defined criteria is necessary. The suggested compliance review process of TOGAF helps to identify the compliance levels of the architecture. Using architecture compliance, TOGAF suggests the following six levels of architecture compliance: Irrelevant: no features in common with architectures Consistent: some features in common with architectures Compliant: some features are not implemented Conformant: all features are implemented but some are not in accordance with the specification Fully conformant: full correspondence between architectures Non-conformant: some features are implemented but not in accordance with the specification Using TOGAF and Frameworx Comparing TOGAF with Frameworx, the TM Forum has defined conformance criteria for both the Business Process Framework (etom) and the Information Framework (SID). Information Framework certification is only for software (TM Forum members who are software vendors), while Business Process Framework certification is available for any member of the TM Forum. TM Forum conformance certification enables industry suppliers to test and certify their adherence to individual TM Forum frameworks and standards. Through a combination of prescribed self-testing and external verification, conformance is assessed on a graduated scale to show the level of adoption of the elements of each framework. Products which meet the rigorous standards set by the conformance tests are awarded the TM Forum Conformance Mark for each framework they successfully adopt. The TM Forum has defined seven levels of conformance criteria for the etom and SID; these are as follows. The Open Group and TM Forum Page 89 of 110

90 For the Information Framework (SID): Level 1 Conformance: The content of the model is compatible with a subset of the Information Framework (SID) ABEs that define its domain coverage. This provides two interacting components/solutions with a common vocabulary and model structure. The subset represents the scope of the model, expressed in Information Framework (SID) domains and ABEs. Level 2 Conformance: The model has passed Level 1 conformance and the content of the ABE, part of the domain coverage and defined in the model, contains the ABE s core business entity or entities. A core business entity is an entity upon which other entities within the ABE are dependent. For example, Service in the Service ABE. A model should strive to attain as high a level of Information Framework (SID) conformance as possible. A core entity is also an entity whose absence in the ABE would make the ABE incomplete. Level 3 Conformance: The model has passed Level 2 conformance and the required attributes of the ABE s core entity or entities are defined in the model. Level 4 Conformance: The model has passed Level 3 conformance and dependent entities within the ABEs are defined in the model. A dependent entity is one whose instances are dependent on an instance of a core entity. For example, a ServiceCharacteristic instance within the Service ABE is dependent upon an instance of the Service entity. Level 5 Conformance: The model has passed Level 4 conformance and the required attributes of the ABE s dependent entities are defined in the model. Level 6 Conformance: The model has passed Level 5 conformance and all attributes of the ABE s core entities are defined in the model. Level 7 Conformance: The model has passed Level 6 conformance and all attributes of the ABE s dependent entities are defined in the model. Note: The word model in the conformance levels means the collective set of create and update APIs for an ABE. Models themselves are not assessed as noted earlier in this document. For the Business Process Framework (etom): Level 1: Content of software is compatible with a subset of the framework at level 1 (the scope of the software solution). Level 2: Compatible with level 2 process elements within defined scope with minor deviations. Level 3: Compatible with level 2 process elements within defined scope with no deviations. Level 4: Compatible with level 3 process elements within defined scope with minor deviations. The Open Group and TM Forum Page 90 of 110

91 Level 5: Compatible with level 3 process elements within defined scope with no deviations. Level 6: Compatible with level 4 process elements within defined scope with minor deviations. Level 7: Compatible with level 4 process elements within defined scope with no deviations. Referring to Frameworx, level 3 should be a minimum objective. Comparing both compliance and conformance models, the following differences can be identified: TOGAF provides a description of six levels of compliance areas and a compliance review process for all architecture dimensions at the architecture project, whereas the Frameworx conformance description focuses on the seven levels for etom and SID implementation. Each Frameworx etom/sid compatibility level is based on the previous level as described above. TOGAF architecture compliance does not work in this way. The architecture compliance levels of TOGAF Irrelevant and Non- Conformant do not really exist at the Frameworx conformance levels. TOGAF provides various checklists including different questions, which may be used for compliance reviews. The following table shows the detailed mapping between the TOGAF architecture compliance levels and the Frameworx etom/sid conformance levels. TOGAF Architecture Compliance Levels Irrelevant Consistent Compliant Conformant Fully Conformant Frameworx SID Conformance Levels Not covered. The levels 1 to 7 of the Frameworx conformance levels cannot really be mapped to the TOGAF architecture compliance levels. As described above, the idea and consequently the basis for the conformance and compliance levels are different. Therefore, the three compliance levels of TOGAF (consistent, compliant and conformant) can be additionally considered when developing an enterprise architecture based on both TOGAF and Frameworx. Level 7 (Currently only Level 5 is available/achievable because business processes in the etom are complete and fully defined from Level 0 to Level 3. In order to achieve Level 6 and Level 7 conformance, the Level 4 business processes in the etom have to be completely available and defined; this is currently a target set for the end of 2011). The Open Group and TM Forum Page 91 of 110

92 TOGAF Architecture Compliance Levels Non-Conformant Frameworx SID Conformance Levels Not covered. Based on this table, this section of TOGAF complements the Frameworx approach significantly by providing description for the levels, consistent, compliant, conformant and non-conformant. Additionally, it covers the whole enterprise architecture and not a specific architecture, like Frameworx does it for etom and SID. 7.5 Architecture Contracts In very strict semantic and literary terms, contracts are defined as follows (example from Dictionary.com): 1. An agreement between two or more parties for the doing or not doing of something specified. 2. An agreement enforceable by law. 3. The written form of such an agreement. 4. The division of law dealing with contracts. Generally speaking contracts are elaborated and agreed upon by two or more parties in order to define, frame and agree on the rights and obligations of each party with regard to the others in a given business or interaction context. These are typically known as legal or formal contracts; this is in line with the perspective embedded and developed in the definition of contract within TOGAF (Architecture Contract). On the other hand, we can also transpose the concept of the rights and obligations couple to systems or applications which would play the role of involved parties within a particular system (like an IT system, for instance). In this case we would not refer to rights and obligations, but to requirements and capabilities couple which somehow are an abstraction of rights and obligations as seen from an IT systems perspective. The above distinction is an important concept to understand when comparing contracts from TOGAF and Frameworx perspectives. Frameworx defines contracts (recently redefined as Business Services) in terms of the relationship between the defined requirements and the provided capabilities to support a given (IT or BSS/OSS) solution within an application ecosystem (consumer/provider). The example provided in Figure 48 illustrates both perspectives. If we think of the two parties involved in the figure as being two different companies or legal entities (or parties), for example, we could have two SPs. One SP covers receipt of a customer service complaint and the immediate processing to generate and handle a customer problem report from this. The other SP is responsible for handling the problem analysis and resolution if a service problem report must be created and analyzed. Here we would The Open Group and TM Forum Page 92 of 110

93 have a typical legal contract defining the rights and obligations of both companies within the scope of the delivery of services to the end customer. Taking the same example, if we think about two IT systems or applications integrated together (by means of an automated interface between them) providing a specific business service; i.e., customer problem handling, the scope of the contract would not be a legal contract in the TOGAF sense, but a technical contract (business service as defined in Frameworx); such contract is realized by taking into account the requirements and capabilities of both applications or IT systems. Business services (formerly known as NGOSS contracts) look at key interfaces within the SP s business and consider all of the information that has to pass across that interface to ensure that everything that needs to happen is enabled to happen. The type of information passing across includes not just the basic process information but also some information more appropriate to use-cases, actors involved, conditions, policies, etc. but also such information as context, management methods, benefits and so on. A Business Service (NGOSS contract) represents a specification of system capability to achieve a stated business purpose. A Business Service or NGOSS contract includes a defined interface and may also define pre- and post-conditions, semantics for using the service(s), policies affecting the configuration, use and operation of the service. A Business Service implements one or more use-cases (task-level processes). Figure 48 Architecture Contracts In TOGAF, Architecture Contracts are joint agreements between development partners and sponsors on deliverable, quality and fitness-for-purpose of an architecture. The Architecture Contracts may occur at various stages of the ADM cycle: Phase A, B to D and G. Furthermore, contracts can be between architecting function and business users. The Open Group and TM Forum Page 93 of 110

94 Within architecture governance (Chapter 50 of TOGAF) architecture contracts can drive architecture changes. Using TOGAF and Frameworx When comparing TOGAF and Frameworx, etom, SID and TAM do not map at the same level or on a one-to-one basis to the Architecture Contracts concept as defined in TOGAF. Generally speaking, TOGAF considers different types of contracts, which are: Statement of Architecture Work Contract between architecture design and development partners Contract between architecting function and business users The Statement of Architecture Work contract will be delivered in Phase A of the TOGAF ADM and is the contract between the architecting organization and the sponsor of the architecture. Frameworx solutions etom, SID and TAM should be taken into consideration as the basis for the new enterprise architecture. In TOGAF the contract between architecture design and development partners mainly focuses on suppliers, SPs and system integrators. The Frameworx solutions etom, SID and TAM do not map to this section, but involved stakeholders should leverage them. The contract between architecting function and business users concentrates on services delivered by the architecture to the business users. This contract mainly maps to the Integration Framework approach of business services and will be covered in the next stage of this mapping project (i.e., Document 2 mapping at a later time). Looking to both, the contract concept in TOGAF provides an added value to Frameworx. Especially, the contract types Statement of Architecture Work and Contract between architecture design and development partners are not directly covered in Frameworx, but they represent the basis for the architecture work. 7.6 Architecture Governance This is the practice by which an enterprise architecture is managed and controlled at an enterprise-wide level. It has a hierarchy of governance structures which can include corporate, technology, IT and architecture governance. It focuses on the rights, roles and equitable treatment of shareholders, transparency and responsibilities. The Architecture Governance Framework of TOGAF is a series of processes, a cultural orientation and a set of owned responsibilities that ensure the integrity and effectiveness of the organization's architecture. It includes: Implementing a system of controls over the creation and monitoring of all architecture components and activities The Open Group and TM Forum Page 94 of 110

95 Implementing a system to ensure compliance with internal and external standards and regulatory obligations Establishing a process that supports effective management of the above processes within agreed parameters Developing practices that ensure accountability to a clearly identified stakeholder community Generally speaking this section is mainly used in Chapter 15 (Phase G: Implementation Governance) together with Chapter 48 (Architecture Compliance) of TOGAF. Using TOGAF and Frameworx Frameworx can benefit from TOGAF. Architecture governance does not operate in isolation, but within a hierarchy of governance structures and therefore can include the following: Corporate governance Technology governance IT governance Architecture governance Frameworx does not explicitly have a chapter called architecture governance and the Frameworx solutions etom, SID and TAM also do not directly map to this chapter. Architecture governance describes governance in the context of enterprise-wide governance. It provides an overview of the nature of the governance and in which context architecture governance typically functions within the enterprise. So, this specific hierarchy of governance can be used for the whole development of the architecture approach or rather architecture project using Frameworx and TOGAF frameworks for that architecture approach. IT governance provides a structure that links IT resources and information to enterprise goals and strategies. Furthermore, IT governance considers planning, acquiring, implementing and monitoring IT performance to ensure that the enterprise s IT assets support its business objectives. Technology governance controls how an organization utilizes technology in the research, development and production of its goods and services. It may include IT governance activities, but can also have a broader scope. Because of the described nature of architecture, IT and technology governance, the Frameworx solutions etom, SID and TAM can be continuously considered as an input to the architecture governance framework. The following description represents a potential way of interworking TOGAF and Frameworx solutions at the architecture governance processes. The Open Group and TM Forum Page 95 of 110

96 Figure 49 TOGAF Architecture Governance Framework Process Policy Management, Take-on and Retirement Architecture contracts, services, policies and other supporting information come through a formal process of register, validate, ratify, manage and publish a new content. This covers the policies as described at the Frameworx solutions concentrating on services and solutions developed by the Frameworx solutions plus the contracts and policies in the meaning of TOGAF covering the whole architecture development. Process Compliance As described in Section 7.4, the SID conformance & compliance criteria include a section titled compliance and certification, which explains the usage of Frameworx principles with architecture compliance. Consequently, the Frameworx solution SID should be especially considered at this process to set criteria for accepting or rejecting the working output of the architecture projects at this architecture dimension. Generally, a complete set of compliance criteria covering all four Frameworx solutions should be developed at this process to ensure the stability, conformance and performance monitoring of the whole architecture developed by Frameworx and TOGAF. The Open Group and TM Forum Page 96 of 110