TOGAF Vs E-Tom

Exploring synergies
between TOGAF and
Frameworx
Industry Group Liaison - The Open Group Architecture
Framework and TeleManagement Forum Frameworx
Collaboration Project
Technical Report
Document 1 – Mapping of TOGAF and Frameworx -
Business Process Framework (eTOM), Information
Framework (SID) and Application Framework (TAM)
Version 1.0
August, 2010
ãTM Forum 2008-2010

Exploring synergies between TOGAF and Frameworx
Notice TMF and The Open Group
No recipient of this document shall in any way interpret this document as representing a position or
agreement of the TeleManagement Forum (TM Forum) or its members. This document is a draft
working document of TM Forum and is provided solely for comments and evaluation. It is not a
Forum Approved Document and is solely circulated for the purposes of assisting TM Forum in the
preparation of a final document in furtherance of the aims and mission of TM Forum.
Although it is a copyrighted document of TM Forum:
· Members of TM Forum are only granted the limited copyright waiver to distribute this
document within their companies and may not make paper or electronic copies for
distribution outside of their companies.
· Non-members of the TM Forum are not permitted to make copies (paper or electronic) of this
draft document other than for their internal use for the sole purpose of making comments
thereon directly to TM Forum.
· If this document forms part of a supply of information in support of an Industry Group Liaison
relationship, the document may only be used as part of the work identified in the Liaison and
may not be used or further distributed for any other purposes
Any use of this document by the recipient, other than as set forth specifically herein, is at its own risk,
and under no circumstances will TM Forum be liable for direct or indirect damages or any costs or
losses resulting from the use of this document by the recipient.
This document is governed by all of the terms and conditions of the Agreement on Intellectual
Property Rights between TM Forum and its members, and may involve a claim of patent rights by
one or more TM Forum members or by non-members of TM Forum.
Direct inquiries to the TM Forum office:
240 Headquarters Plaza,
East Tower – 10th Floor,
Morristown, NJ 07960 USA
Tel No. +1 973 944 5100
Fax No. +1 973 944 5110
TM Forum Web Page: www.tmforum.org
Document #, Version 0.1 © TM Forum 2008 -2010 Page 2 of 127

The Open Group Notice
All rights reserved. No part of this publication may be reproduced, stored in a retrieval
system, or transmitted, in any form or by any means, electronic, mechanical, photocopying,
recording, or otherwise, without the prior permission of the copyright owners.
FOR ARCH FORUM ONLY: This White Paper is an informational document and does not
form part of the TOGAF documentation set. Readers should note that this document has not
been approved through the formal Open Group Standards Process and does not represent
the formal consensus of The Open Group Architecture Forum.
Boundaryless Information Flow™ and TOGAF™ are trademarks and Making Standards
Work®, The Open Group®, UNIX®, and the “X” device are registered trademarks of The
Open Group in the United States and other countries. All other trademarks are the property
of their respective owners. All other brand, company, and product names are used for
identification purposes only and may be trademarks that are the sole property of their
respective owners.
Using TOGAF 9 ………ISBN ………. Doc No Published by The Open Group, month, year
Any comments relating to the material contained in this document may be submitted to:
The Open Group, 44 Montgomery St. #960, San Francisco, CA 94104
or by email to:
ogpubs@opengroup.org

Table of Contents
Notice TMF and The Open Group......................................................................................................2
The Open Group, 44 Montgomery St. #960, San Francisco, CA 94104............................................3
or by email to:.................................................................................................................................... 3
List of Figures.................................................................................................................................... 6
Executive Summary...........................................................................................................................8
1. General information and introduction...........................................................................................10
1.1. Benefits of the mapping exercise...........................................................................................10
1.2. About TMF and Frameworx..................................................................................................13
1.2.1. Introduction...................................................................................................................13
1.2.2. The four components of the Frameworx family................................................................14
1.3. About The Open Group and TOGAF.....................................................................................18
1.3.1. Introduction...................................................................................................................18
1.3.2. Short overview of TOGAF..............................................................................................20
1.4. Positioning of TOGAF and TMF Frameworx at a glance.........................................................26
1.4.1. TOGAF and TMF Frameworx........................................................................................28
1.5. Sources used for the mapping...............................................................................................32
2. Frameworx & the Architecture Development Method (ADM)........................................................34
1.6. Preliminary Phase................................................................................................................34
1.7. Phase A – Architecture Vision...............................................................................................36
1.8. Phase B – Business Architecture...........................................................................................38
1.9. Phase C – Information Systems Architecture.........................................................................40
1.9.1. Data Architecture...........................................................................................................41
1.9.2. Application Architecture.................................................................................................41
1.10. Phase D – Technology Architecture.....................................................................................43
1.11. Summary of Phase E to H...................................................................................................44
1.12. Requirements Management................................................................................................48
3. ADM Guidelines & Techniques as applied to Frameworx.............................................................51
1.13. Introduction and Scope.......................................................................................................51
1.13.1. Guidelines for adapting the ADM process.....................................................................51
1.13.2. Techniques for architecture development......................................................................51
1.13.3. Scope.........................................................................................................................51
1.14. Applying Iteration to the ADM in different enterprise levels....................................................51
1.15. Security Architecture and the ADM......................................................................................55
1.16. Leveraging both TOGAF and Frameworx in the context of SOA............................................55
1.17. Architecture Principles........................................................................................................55
1.18. Stakeholder Management...................................................................................................57
1.19. Architecture Patterns..........................................................................................................60
1.20. Business Scenarios............................................................................................................61
1.21. Gap Analysis......................................................................................................................63
1.22. Migration Planning Techniques...........................................................................................65

1.23. Business Transformation Readiness Assessment................................................................70
1.24. Risk Management..............................................................................................................71
1.25. Capability Based Planning..................................................................................................73
4. Architecture Content Framework and synergies with Frameworx...............................................75
1.27. Content Metamodel............................................................................................................75
1.28. Architectural Artifacts..........................................................................................................80
1.29. Architectural Deliverables....................................................................................................82
1.30. Building Blocks...................................................................................................................86
5. Enterprise Continuum and Tools and synergies with Frameworx................................................87
1.32. Enterprise Continuum.........................................................................................................87
1.32.1. Architecture Continuum...............................................................................................87
1.32.2. Solutions Continuum...................................................................................................87
1.33. Architecture Partitioning......................................................................................................88
1.34. Architecture Repository.......................................................................................................93
1.35. Tools for Architecture Development.....................................................................................95
6. TOGAF Reference Models and their relevance to Frameworx......................................................97
1.37. Foundation Architecture: Technical Reference Model...........................................................97
1.38. Integrated Information Infrastructure Reference Model..........................................................97
7. Applying Architecture Capability Framework to Frameworx........................................................98
1.40. Establishing an Architecture Capability................................................................................98
1.41. Architecture Board..............................................................................................................98
1.42. Architecture Compliance.....................................................................................................99
1.43. Architecture Contracts.......................................................................................................102
1.44. Architecture Governance...................................................................................................105
1.45. Architecture Maturity Models.............................................................................................108
1.46. Architecture Skills Framework...........................................................................................111
8. Summary of synergies and complementarities...........................................................................114
Appendix A: Quick Reference Guide TOGAF – Frameworx..........................................................118
Appendix B Process description metamodel................................................................................119
Appendix C Glossary, Terms and abbreviations...........................................................................120
9. Administration of the document..................................................................................................122
1.47. Document History.............................................................................................................122
1.47.1. Version History..........................................................................................................122
1.47.2. Release History.........................................................................................................123
1.48. Company Contact Details.................................................................................................123
1.49. IPR releases and patent disclosures..................................................................................124
1.50. Acknowledgements..........................................................................................................124
10. References.................................................................................................................................125
Annex Clarification of Information and Data..................................................................................126

List of Figures
Figure 1 – Frameworx blueprint......................................................................................................14
Figure 2 – Frameworx eTOM Level 1 View.......................................................................................15
Figure 3 – Frameworx SID...............................................................................................................16
Figure 4 – Frameworx TAM...............................................................................................................17
Figure 5– Frameworx – Integration Framework relationships........................................................18
Figure 6 – TOGAF development........................................................................................................19
Figure 7 – TOGAF Core Components...............................................................................................21
Figure 8 – TOGAF ADM.....................................................................................................................22
Figure 9 – TOGAF Deliverables.........................................................................................................23
Figure 10 – TOGAF Metamodel....................................................................................................23
Figure 11 – TOGAF Continuum.........................................................................................................24
Figure 12 – TOGAF Repository.........................................................................................................25
Figure 13 – TOGAF Capability Framework........................................................................................26
Figure 14 – TOGAF – Frameworx mapping overview.......................................................................27
Figure 15 – TOGAF ADM – Frameworx mapping overview..............................................................28
Figure 16 – TOGAF – Frameworx phase 1 mapping eTOM, SID, TAM overview..............................30
Figure 17 – TOGAF – Frameworx phase 1 mapping complete overview..........................................31
Figure 18 – TOGAF Preliminary Phase.............................................................................................34
Figure 19 – TOGAF Architecture Vision............................................................................................36
Figure 20 – TOGAF Business Architecture...................................................................................38
Figure 21 – TOGAF Information Systems Architecture.................................................................41
Figure 22 – TOGAF Technology Architecture...................................................................................43
Figure 23 – TOGAF Phase Requirements Management...................................................................48
Figure 24 – TOGAF Phase Requirements Management - Steps.....................................................49
Figure 25 – TOGAF Iteration Cycles and Frameworx solutions.......................................................52
Figure 26 – TOGAF different enterprise levels................................................................................53
Figure 27 – TOGAF ADM and different enterprise levels.................................................................54
Figure 28 – Stakeholder Analysis...................................................................................................58
Figure 29 – Stakeholder Power Grid.................................................................................................58
Figure 30 – Business Scenarios and Frameworx............................................................................62

Figure 31 – Business Scenario in TOGAF and Assessment Methodology in Frameworx...............62
Figure 32 – Gap analysis................................................................................................................64
Figure 33 – Gap Implementation Factor Assessment and Deduction Matrix...................................66
Figure 34 – TOGAF Consolidated Gaps, Solution & Dependencies Matrix......................................66
Figure 35 – TOGAF Gaps, Solution & Dependencies Matrix with Frameworx services...................67
Figure 36 – TOGAF Architecture Definition Increments Table with Frameworx services................67
Figure 37 – TOGAF State Evolution Table........................................................................................68
Figure 38 – TOGAF State Evolution Table - Frameworx Services....................................................68
Figure 39 – TOGAF Business Information Interoperability Matrix....................................................69
Figure 40 – TOGAF Summary table of Business Transformation Readiness Assessment.............71
Figure 41 – Risk Classification Scheme.........................................................................................72
Figure 42 – Risk Identification Worksheet......................................................................................72
Figure 43 – Capability Based Planning and Frameworx..................................................................74
Figure 44 – TOGAF – Content Metamodel with extensions and mapping to Frameworx.................77
Figure 45 – TOGAF – Artifacts and Frameworx solutions...............................................................81
Figure 46 – Architecture Partitioning with Frameworx - Examples..................................................91
Figure 47 – Architecture Partitioning with Frameworx - Examples..................................................92
Figure 48 – TOGAF – Partitioning and Frameworx solutions..........................................................93
Figure 49 – TOGAF – Repository and Frameworx solutions...........................................................94
Figure 50 – TOGAF Architecture Governance Process.................................................................107
Figure 51 – DEN-ng Mapping.....................................................................................................127

Executive Summary
Members of both The Open Group (referred to onwards as TOG) and the TeleManagement
Forum (referred to onwards as TMF) have the view that there is benefit in combining the assets
of both organizations. Over the past decade TOG has focused on the methodology for
producing and exploiting the architecture approach. On the other hand TMF has focused on
developing industry reference frameworks aiming at accelerating the work of business and IT
professionals in the telecom industry.
Applying TOGAF methodology to TMF industry assets is expected to generate benefits because
its users will understand how to apply specific assets of TOGAF or through a better
understanding of how to use these assets in their own initiatives. It is the ambition of the TOG-TMF
liaison to identify these benefits and have them exploited in both membership sides.
More specifically this collaboration team has been chartered to explore synergies, identify
integration points between the TM Forum Frameworx and TOGAF version 9 and then map and
document such synergies. The results of this work so far have been documented in this
Technical Report and summarized in a Quick Reference Guide included as an appendix to this
document.
Based on the actual situation regarding the ongoing development of the Integration Framework
(previously known as Technology Neutral Architecture TNA) of the TMF, the result of the mapping
activity is reported into two different documents:
· Document 1: (this current document). Focus on the mapping of TOGAF to Frameworx:
Business Process Framework (eTOM), Information Framework (SID) and Application
Framework (TAM). The purpose of this mapping is to assess differences in their contents,
complementarities and the areas for application– having the Enterprise Continuum in mind.
· Document 2: (next target document for this liaison project). Focus on mapping TOGAF to
Frameworx Integration Framework (previously known as TNA). The purpose of this mapping
is to generate a common vocabulary between the two organizations for integration of
information system assets i.e. includes both applications and their interfaces.
The present Technical Report provides the mapping between TOGAF and Frameworx previously
referred to as NGOSS (eTOM, SID and TAM).
Insight into identified synergies
During the exercise insights were gained into the synergies between the TOGAF and TMF assets. In
summary the following were identified:

1. Immediate synergies have been identified between the TOGAF ADM Phases Preliminary, A, B,
C and Common Systems Architecture of the Enterprise Continuum. This document includes
phases from Preliminary to Phase C of the TOGAF ADM. The synergies between business
services formerly known as NGOSS contracts) and the Systems Architecture will be dealt with in
a separate document.
2. TOGAF provides an Architecture Repository structure that can smoothly accommodate the
mapping of TMF assets; this feature can be leveraged to identify and derive the added value of
the content.
3. TMF assets can be classified as either industry frameworks or Common Systems Framework in
(TOGAF) Enterprise Continuum language. TOGAF provides a widely accepted methodology to
leverage these frameworks into the development of Enterprise Architecture.
4. Professionals that use TMF assets will find templates and guidelines in TOGAF that facilitates the
transformation of such TMF asset into deliverables for a specific project/program.
5. TOGAF concepts as defined in the TOG Architecture Content Framework provide clear
definitions as to what artifacts from TMF assets have to be developed in order to be consistent
and comprehensive with an architecture construct.
Recommendations:
TMF workgroups can benefit from TOGAF by adopting the concepts and definitions
from TOGAF. Once the charter of a workgroup is agreed, it is suggested to have a
preliminary phase for identification of re-usable elements from TOGAF 9 before
starting to produce the deliverables. The workgroup potentially gains in consistency,
comprehensiveness and sustainability.
The Open Group can benefit from TMF by considering the TMF assets as an
exemplar and generalize it into a re-usable asset by other industries.
The Open Group may consider adopting the TMF Forum Maturity model for tagging
workgroup results. The authority level of artefacts or deliverables would gain
transparency.
Clients that consider adoption of TMF standards, can leverage their investment by
adopting TOGAF 9 and exploit their complementarities at the same time. This
enhances architecture governance, its comprehensiveness and sustainability.

1. General information and introduction
1.1. Benefits of the mapping
exercise
Approaches for business and IT systems (data, applications and their interfaces)
alignment vary greatly. The need for integration of domains within as well as crossing
the borders of the enterprise also forces both executives and professionals to
communicate about approaches for their business. A common vocabulary and
terminology facilitates their challenging integration initiatives.
TMF and TOG assets provide two different but complementary approaches for
developing enterprise architectures. Therefore comparing both can be highly
beneficial for different types of companies.
A very broad audience can benefit from applying a combination of both models by
leveraging the mapping concepts described throughout this document; such
audiences embrace Project and Program Managers, Application Developers,
Enterprise Architects, Domain Architects (Business, Application, Data, Infrastructure,
Integration, Security, etc), Business Analysts, Product Development Managers,
Marketing and Sales Leads and more senior staff, such as C-Level executives.
TM Forum defined processes primarily deal with the definition and structure of
common processes, rather than company-specific activity flow. However, in these
industry frameworks the enterprise specific parts are missing. The TMF industry
frameworks (eTOM, SID, TAM) coupled with the company specific strategic direction
provide the foundation for a company’s enterprise architecture.
In order to get a good understanding of the composition of a business, it is necessary
to understand what value each activity contributes to the overall business goals, what
the expected quality of the goals is, and what dependencies exist. eTOM provides a
decomposition of each Service Provider’s business processes. However, it is non-specific
about the goals of each process. By non-specific is meant that the goal is
described in terms that could apply for each and all Service Provider (SP). This is
sufficient for understanding the standard industry model, but not sufficient to
understand the architecture of a specific SP. In fact eTOM describes and
decomposes the working model of service providers regardless of the technology i.e.
it is technology and environment neutral. This model differs slightly for telephony-only
services, as compared to voice, data and video integrated services. The mapping
exercise enables to understand very well and easy what the description covers.

In order to understand the architecture of a specific SP during a specific time frame,
one has to take into account the objects that are transformed and the means
(models, tools, expertise) supporting the transformation, as well as the actor(s)
responsible for the transformation. Frameworx does not provide this information. The
detailed information has to come from the business strategy (expressed in terms of
business requirements). Leveraging the Business Process Framework (eTOM) can
be instrumental in describing such enterprise architecture. Furthermore, TOGAF
provides specific methodologies for analyzing this information, and developing a good
understanding of the structure of the working model of such enterprise.
eTOM provides the key ingredients needed to develop this understanding for a
specific enterprise. It is comprehensive and the standard model covers most of the
service provider’s scope. Therefore it can help initiatives effectively through the use of
a common reference readily available. If working teams in such initiatives not only
adopt the common descriptions, but also share the TOGAF methodology they will
have even better and more effective communications and will reduce the overall effort
of the transformation journey.
Frameworx also includes a methodology. However, it has a different perspective
than TOGAF. TMF provides the business lifecycle for developing Frameworx
compliant solutions. TOGAF on the other hand, provides the full description of an
Enterprise Architecture methodology, the detailed approach as well as
comprehensive documentation; but at the end, both models complement very well
each other.
Some core benefits are:
· Optimal development of new enterprise architecture by using both
frameworks
· ADM development process
· Guidelines and techniques support the architectural development
· Predefined templates provide a structure for an Architecture Repository
· Criteria for tool evaluation and selection help to figure out the right tool
· Deploying an optimal Architecture Capability to establish and consolidate the
architecture function
Optimal development of new enterprise architecture by using both frameworks:
TOGAF describes both a method and a set of supporting tools & techniques for
developing and maintaining enterprise architecture. Frameworx solutions describe

the working model of communications service providers in a generic way, without
getting specific to individual service providers. By combining these capabilities, flaws
and gaps will be reduced to a minimum.
ADM development process:
The TOGAF ADM provides a step by step approach for developing enterprise
architecture:
1. separation of concerns: business, information, and application structures.
2. effective use of abstraction: separating the definition of what value has to be
generated from how it will be generated
3. devising appropriate concepts: using the right concepts to build a conceptual
model of the architecture.
Furthermore, the components of the enterprise architecture capability include a
detailed process for architecture implementation, migration, change and requirements
management. This can be of high value to the Frameworx’ approach when the results
are applied to the architecture development.
Guidelines and techniques support the architectural development
TOGAF provides guidelines & techniques, which provide varied methodologies and
templates necessary to develop successful enterprise architecture. The thinking
behind Frameworx solutions aligns with such guidelines and techniques, but do not
describe detailed steps and methods to do the implementation in a particular way.
Therefore, a combination of both models is highly useful for successful enterprise
architecture.
Predefined templates provide a structure for an Architecture Repository
TOGAF provides an architecture repository template which can be used to structure
all the architecture artifacts in enterprise architecture.
Criteria for tool evaluation and selection help to figure out the right tool
Most of the well known enterprise architecture tools (e.g.: PlanningIT, ARIS, Sparx,
Metastorm, Casewise, Mega, etc.) are already TOGAF certified software solutions
and therefore are mostly used by many enterprises for managing their enterprise
architecture, including companies within the Telecommunications industry. TOGAF
provides criteria for the evaluation and selection of these tools. Furthermore, this
feature can also be used for the evaluation of architecture tools suggested by the
TMF.
Deploying an optimal Architecture Capability to establish and consolidate the
architecture function

How to establish an architecture capability is one of the critical points during an
architectural effort. TOGAF provides a chapter to support such purpose and it can be
combined with several sections of the Frameworx solutions to a successful
Architecture Capability. Especially, the Architecture Skills Framework and
Architecture Governance comprehensively provide a detailed description of
enterprise architecture methods for the telecommunication industry. This is of great
additional value for the Frameworx assets of TMF
1.2. About TMF and Frameworx
1.2.1. Introduction
About the TeleManagement Forum
The TeleManagement Forum is the world’s leading industry association focused on
enabling best-in-class IT for Service Providers in the communications, media,
entertainment and cloud service markets. The TM Forum provides business-critical
industry standards and expertise to enable the creation, delivery and monetization of
digital services.
TM Forum Frameworx
Frameworx is a Telecoms industry specific framework developed by the
TeleManagement Forum (TMF) to organize, specify, design and develop new
generation management systems. It provides a standard method, common
terminology and harmonized framework for the entire Telecom Industry value chain.
Frameworx captures best practices and common definitions to meet the needs of a
variety of stakeholders including service providers, equipment vendors, independent
software vendors, and system integrators. By focusing on the cornerstones of the so
called “lean operator” (smart operator who is able to reduce overall costs and
optimize overall performance by leveraging Frameworx to automate its business
processes and reducing the integration tax), Frameworx embraces intelligent problem
solving and holistic solution design. Frameworx prones solution flexibility, enabling an
enterprise to transform and improve the way it operates.
Frameworx is undergoing further development; particularly with the so called TM
Forum Integration Program or “TIP” and the “Integration Framework” previously
known as TNA (Technology Neutral Architecture). Frameworx consists of four
frameworks or content models which represent the cornerstones of a Service
Provider (SP) Enterprise Architecture. These are:

- Process Framework (aka eTOM),
- Information Framework (also known as (aka) SID),
- Application Framework (aka TAM), and
- Integration Framework (aka TNA) which describes Business Services (similar to
contracts) and their lifecycle.
The following description of the Frameworx lifecycle views and the Integration
Framework are based on the existing draft documents, which are available on the
TMF webpage. They are under development at this moment and therefore cannot be
seen as final description of these sections.
1.2.2. The four components of the Frameworx family
Figure 1 – Frameworx blueprint
The Business Process Framework (aka eTOM – enhanced Telecom
Operations Map)
The eTOM defines most of the common business processes of a Service Provider
environment based on the current state of technology, it provides a standard framework and

a common language for the definition and classification of most business processes within an
SPs environment. It is useful as a standard catalog and classification scheme for business
processes for an SP. However, it will always need alignment for specific business strategies
in order to accommodate specific business requirements
Figure 2 – Frameworx eTOM Level 1 View
The Enterprise-wide Information Framework (aka SID – Shared Information
and Data Model)
The Information Framework provides a comprehensive common information and
data model covering a wide set (though not all) of business concepts relevant
within a SP’s environment. It provides a common language for software
developers and integrators to use in describing information and data, which in
turn allows easier and more effective integration across OSS/BSS (Operations
Support Systems/Business Support Systems) software applications provided by
multiple vendors. It provides the concepts and principles needed to define a
shared information and data model (hence the name SID), the elements or
entities of the model, the business oriented UML class models, as well as design
oriented UML class models and sequence diagrams to provide a system view of
the information and data.
The model contains - similar to the process framework - generic information and
data model, which needs adaptation to each specific enterprise. In both
frameworks inter-change of level of detail might occur due to the service
provider’s strategy.

Figure 3 – Frameworx SID
The Application Framework (aka TAM – Telecom Application Map)
The Application Framework has been developed as a working guide to help
operators and their suppliers use a common reference map and language to
navigate the complex application landscape that is typically found in fixed, mobile
and convergent operators. Where the Process Framework provides a framework
of processes, the Application Framework provides a framework of telecom
applications. One should be aware that software vendors might have very
specific combinations of application domains, due to focus on a specific
challenge that has to be resolved. The TMF definition of application domains is
inspired by what vendors choose as logical combinations of processes in their
application, but attempts to remain as generic as possible. Again as is the case
for eTOM and SID, a SP’s application landscape might look somewhat different
depending on the specific business strategy or business model.

Figure 4 – Frameworx TAM
The Integration Framework (aka TNA – Technology Neutral Architecture)
The Integration Framework supersedes the TNA (Technology Neutral
Architecture). It identifies the dependencies and unifies the TM Forum’s eTOM,
SID, TAM, and TM Forum Interface program (TIP) in a service oriented
architecture (SOA) context ensuring a seamless migration to a more advanced
architecture supporting the service oriented enterprise (SOE).
The key to the Integration Framework is a growing set of reusable building
blocks, known as “business services”. These business services (also known
previously as NGOSS contracts) are based on standard service oriented
architecture (SOA) and work like Lego bricks – each relating to a standard
business function and designed to support the enterprise’s portfolio of products.
To build business services, the Integration Framework assembles elements from
the eTOM and the SID, and adds capabilities from the TAM to form groups of
business services (aka service platform). A platform service is created by taking
specific information entities from the Information Framework and taking into
account their interactions with business processes as defined in the Process
framework and analyzing entities with common characteristics and supporting

these with application framework (TAM) capabilities. The relationship between a
business service, a business process as defined in the eTOM and an information
entity as defined in the SID is shown below.
Figure 5– Frameworx – Integration Framework relationships
1.3. About The Open Group and
TOGAF
1.3.1. Introduction
About The Open Group
The Open Group is a vendor-neutral and technology-neutral consortium, whose
vision of Boundaryless Information Flow strives for enabling access to integrated
information within and between enterprises based on open standards and global
interoperability. The Open Group works with customers, suppliers, consortia, and
other standards bodies. Its role is to capture, understand, and address current and
emerging requirements, establish policies, and share best practices; to facilitate
interoperability, develop consensus, and evolve and integrate specifications and
Open Source technologies; to offer a comprehensive set of services to enhance the
operational efficiency of consortia; and to operate the industry's premier certification
service, including UNIX(R) system certification. Further information on The Open
Group can be found at www.opengroup.org.

The Open Group of Architecture Framework (TOGAF)
The Open Group Architecture Framework (TOGAF) is a framework — a detailed
method a common vocabulary and a set of, supporting tools and templates — for
developing enterprise architecture. It may be used freely by any organization wishing
to develop enterprise architecture for use within that organization. The method is
particularly useful when during initiatives the industry standards of TMF are
transformed into enterprise specific frameworks.
TOGAF is developed and maintained by members of The Open Group, working
within the Architecture Forum. The original development of TOGAF Version 1 in 1995
was based on the Technical Architecture Framework for Information Management
(TAFIM), developed by the US Department of Defense (DoD). The DoD gave The
Open Group explicit permission and encouragement to create TOGAF by building on
the TAFIM, which itself was the result of many years of development effort and many
millions of dollars of US Government investment. Starting from this sound foundation,
the members of The Open Group Architecture Forum have developed successive
versions of TOGAF and published each one on The Open Group public web site.
Figure 6 – TOGAF development
The Open Group Architecture Framework (TOGAF) allows architectures to be
developed that are consistent, reflect the needs of stakeholders, employ best
practices, de-risk the architecture development process and finally provides a
platform for adding value to the enterprise which uses TOGAF.
Design Objectives of TOGAF 9:
In comparison to TOGAF 8, TOGAF 9 is an evolution and not a revolution. TOGAF 9
has no changes to the top level processes but individual features from TOGAF 9 can
be adopted into a TOGAF 8 environment.
TOGAF 9 provides a stronger link to the business, than TOGAF 8. It provides a
strategic planning and further deployment decisions steps.

Because of the new metamodel, further developed guideline and techniques and an
improved structure, TOGAF 9 is much easier to use.
What is new in TOGAF 9
The following sections are new in TOGAF 9:
- Architecture Partitioning
- Content Framework and Meta-Model
- Capability Based Planning
- Business Transformation Readiness
- Architecture Repository
- Stakeholder Management
- Using TOGAF to develop Security Architectures
- Using TOGAF to develop Service Oriented Architectures
1.3.2. Short overview of TOGAF
TOGAF Core Concepts
The core of TOGAF is represented by the ADM which provides a step by step
approach to develop and apply enterprise architecture methodology.
TOGAF 9 basically consists of different components, which interact closely with each
other. The following picture shows the structure of such components.

Figure 7 – TOGAF Core Components
Part II - TOGAF Architecture Development Method
The ADM features a series of linked phases which enable a full life-cycle
management of an Enterprise Architecture and which furthermore enable a path
going from planning to operational development and changes.
For each iteration of the ADM, a fresh decision must be taken as to:
- The challenge to resolve with the architecture
- The breadth of coverage of the enterprise to be defined
- The level of detail to be defined
- The extent of the time period aimed at, including the number and extent of any
intermediate time periods
- The architectural assets to be leveraged, including:
 Assets created in previous iterations of the ADM cycle within the
enterprise
 Assets available elsewhere in the industry (other frameworks, systems
models, vertical industry models, etc.)
These decisions should be based on a practical assessment of resource and
competence availability, and the value that can realistically be expected to accrue to
the enterprise from the chosen scope of the architecture work.
As a generic method, the ADM is intended to be used by enterprises in a wide variety
of different geographies
and applied in different
vertical sectors/industry types.
As such, it may be, but
does not necessarily have
to be, tailored to specific
needs.
The different phases of the
ADM life-cycle
management are
shown in the following
picture.

Figure 8 – TOGAF ADM
Part IV - TOGAF Architecture Content Framework and Meta Model
Deliverables, Artifacts and Building Blocks
The Architecture Content Framework uses three categories to describe the type of
architectural work product within the context of use: deliverables, artifacts and building
blocks.

Figure 9 – TOGAF Deliverables
The Content Metamodel
The content metamodel provides a definition of all the types of building blocks that
may exist within an architecture, showing how these building blocks can be described
and related to one another. For example, when creating an architecture, an architect
will identify applications, ‘‘data entities’’ held within applications, and technologies that
implement those applications. These applications will in turn support particular groups
of business user or actor, and will be used to fulfill ‘‘business services’’.
The content metamodel identifies all of these concerns (i.e., application, data entity,
technology, actor, and business service), shows the relationships that are possible
between them (e.g., actors consume business services), and finally identifies artifacts
that can be used to represent them.
The following picture shows an overview about the content metamodel.
Figure 10 – TOGAF Metamodel
Part V - TOGAF Architecture Continuum and Tools

Architecture Continuum
TOGAF includes the concept of the Enterprise Continuum, which sets the broader
context for an architect and explains how generic solutions can be leveraged and
specialized in order to support the requirements of an individual organization. The
Enterprise Continuum is a view of the Architecture Repository that provides methods
for classifying architecture and solution artifacts as they evolve from generic
Foundation Architectures to Organization-Specific Architectures. The Enterprise
Continuum comprises two complementary concepts: the Architecture Continuum and
the Solutions Continuum.
An overview of the structure and context for the Enterprise Continuum is shown in the
following picture.
Figure 11 – TOGAF Continuum
Architecture Repository

Supporting the Enterprise Continuum is the concept of an Architecture Repository
which can be used to store different classes of architectural output at different levels
of abstraction, created by the ADM. In this way, TOGAF facilitates understanding and
co-operation between stakeholders and practitioners at different levels.
By means of the Enterprise Continuum and Architecture Repository, architects are
encouraged to leverage all other relevant architectural resources and assets in
developing an Organization-Specific Architecture.
In this context, the TOGAF ADM can be regarded as describing a process lifecycle
that operates at multiple levels within the organization, operating within a holistic
governance framework and producing aligned outputs that reside in an Architecture
Repository. The Enterprise Continuum provides a valuable context for understanding
architectural models: it shows building blocks and their relationships to each other,
and the constraints and requirements on a cycle of architecture development.
The structure of the TOGAF Architecture Repository is shown in the following picture.
Figure 12 – TOGAF Repository

Part VII - TOGAF Enterprise Architecture Capability Framework
In order to carry out architectural activity effectively within an enterprise, it is
necessary to put in place an appropriate business capability for architecture, through
organization structures, roles, responsibilities, skills, and processes. An overview of
the TOGAF architecture capability is shown in the following picture.
Figure 13
– TOGAF
Capability
Framework
1.4. Positioning of TOGAF and
TMF Frameworx at a glance
TOGAF is a detailed method and a set of supporting tools for developing an
enterprise architecture. Frameworx is a telecommunications industry specific
framework to organize, design and develop distributed management systems. It
provides a set of methods, best practices and industry agreed specifications.

The mapping starts with the TOGAF ADM and Frameworx. The other parts of
TOGAF, which are Architecture Content Framework, Reference models, Guidelines
& Techniques, Enterprise Continuum and Architecture Capability Framework will be
covered in different chapters of this document. When appropriate, definitions are
included in order to facilitate the reading and to describe the relationship.
Furthermore, a Quick Reference Guide is provided as an annex at the end of this
document; this guide compares the chapters and paragraphs to the various parts of
Frameworx in detail.
Figure 14 – TOGAF – Frameworx mapping overview

Figure 15 – TOGAF ADM – Frameworx mapping overview
1.4.1. TOGAF and TMF Frameworx
In this chapter the difference between TOGAF and Frameworx is further discussed. In
general it will help to reckon that TOGAF as a methodology framework and
Frameworx is the content to which it can be applied. The Preliminary Phase as well
as Phase A - Architecture vision of TOGAF provides the handles to start applying
Frameworx in a specific situation. The Preliminary phase applies to the architecture
capability. One has to agree beforehand which standards to use in the organization.
The Architecture vision applies to all projects. It provides the link between the
business vision, the architectural challenge and the specific initiative.
TOGAF ADM and Frameworx
The Preliminary Phase does not explicitly exist in Frameworx and is consequently to
be considered as an add-on to Frameworx when an Enterprise Architecture approach
is to be applied. At the Preliminary Phase, Frameworx and TOGAF can be identified
and tailored as architecture reference frameworks for the enterprise architecture
development approach. See section 1.6 for more detail on this.
Concerning Phase A - Architecture Vision, it also represents a new part for
Frameworx, as this is only covered partially by the latter in the form of definitions
related to the formulation of the strategy of the enterprise. In this phase, TOGAF
describes the baseline and scope of target architectures for all architecture

dimensions in line with Frameworx. Therefore, Frameworx needs to be considered
within this phase for defining and describing the target architecture for the enterprise.
As shown in figure 16, the three Frameworx solutions map mainly into Phases A, B,
and C of the TOGAF ADM.
The business process framework “enhanced Telecom Operations Map” (eTOM)
describes the foundational business processes of a Telecommunication Service
Provider (SP) and therefore maps to Phase B of TOGAF ADM.
The “Shared Information and Data Model” (SID) provides a comprehensive common
information and data model for a Telecom SP and it maps to phase C Data
Architecture of TOGAF ADM.
Additionally, the SID framework is linked to eTOM business processes across its
various domains, which are composed of different sets of layered Aggregate
Business Entities (ABEs). For this reason the iteration cycle “Architecture Definition
iterations” of TOGAF part 19 “Applying Iteration to the ADM” also has an important
role considering the creation of the overall architecture content by cycling through
phases A, B, C of the TOGAF ADM.
The “Telecom Application Map” (TAM) provides a framework of applications relevant
to a Telecoms industry SP, which the latter can implement and leverage for the
classification of its complex application landscape. SPs normally talk about BSS/O
Systems (Business/Operations Support Systems), therefore, the TAM maps to Phase
C Application Architecture of TOGAF ADM.
The Integration Framework will be part of the mapping in document two. This
mapping will be dealt with in the next phase of this liaison project. In the preliminary
analysis it was recognized that the Phase D of TOGAF ADM does not map directly to
the Integration Framework. Phase D refers to the technology architecture of IT.
TOGAF does not include a specific integration phase in the ADM.
Phases E to H of the TOGAF ADM refer to the architecture capability. Phase E and F
prepare the implementation of the To-be architecture as defined in the ADM phases
B, C and D of TOGAF. Frameworx solutions do not explicitly map to these ADM
phases, but to be able to plan the activities and the roadmap for the implementation
of the To-be architecture, each Frameworx solution has to be considered in regards
to a consolidated gap analysis from phases B, C and D of the TOGAF ADM.
Therefore, it could be necessary to review the different architectures and the
corresponding Frameworx as part of a new iteration.
Phase G - Implementation Governance reflects the active implementation and
execution of the organization-specific development process. Frameworx solutions do
not specifically map to Phase G of TOGAF ADM.
Phase H - Architecture Change Management ensures the architecture achieves its
original target business value. Frameworx do not explicitly map to this phase, but can

be seen as architectural input (deliverables and artifacts) to the change activities in
this phase.
The requirements management of the TOGAF ADM does not exist as a stand-alone
component in Frameworx, this is partly why it does not map to it. eTOM does not
specify measurable goals for processes. When the business strategy is applied and
imposes specific business requirements it results in measurable goals for each
process. These measurable goals can be considered as reflecting requirements that
have to be captured and implemented in order to comply with the architecture vision.
The Business Process framework (eTOM) provides a sound starting point to capture
requirements in the form of Use Cases (high level use cases typically use level 2
processes, while detailed use cases use level 3 and 4 processes). Therefore the
eTOM framework can be seen as an effective tool to address the challenge of
effectively capturing business requirements and ensuring the accurate linkage of
these requirements to the business processes.
In summary the Frameworx Solutions eTOM, SID and TAM contribute to the
execution of Phases A, B and C.
Figure 16 – TOGAF – Frameworx phase 1 mapping eTOM, SID, TAM overview

Figure 17 – TOGAF – Frameworx phase 1 mapping complete overview
TOGAF Enterprise Continuum and Frameworx
Frameworx solutions eTOM, SID and TAM can be positioned as industry
architectures in the Architecture Continuum. They have the potential to leverage the
creation of an industry solution for targeted customer problems – e.g.
Telecommunications industry.
The Integration Framework is part of the Common Systems Architecture in the
Enterprise Architecture Continuum. It will be discussed in document 2 – mapping of
TOGAF to Frameworx solution Integration Framework.
TOGAF Solutions and Frameworx Solutions

TOGAF Enterprise Continuum distinguishes two abstraction levels: architecture and
solution. TOGAF refers to solutions as an instance or description of a solution that
can be implemented. It is implementation specific and dependent. It refers to
architecture when the description is solution neutral.
The meaning of Solution in Frameworx is different. Frameworx refers to the Process,
Information and Application frameworks as Solutions. However, these are
Architectures in the terminology of TOGAF, since they are solution neutral.
TOGAF ADM Guidelines and Techniques and Frameworx
This chapter in TOGAF provides guidelines and techniques, which can be used to
develop enterprise architecture. The Frameworx solutions provide a different
perspective to map to various chapters of the TOGAF ADM
TOGAF Architecture Content Framework and Frameworx
In consideration of the Content Framework by ADM, the business architecture maps
to the eTOM, the information systems architecture maps to the SID and TAM.
Furthermore, the three Frameworx solutions can also be related to the scope which is
defined in the TOGAF ADM - Architecture Vision Phase.
TOGAF Architecture Capability Framework and Frameworx
Implementing and establishing an architecture capability requires the design of the
four domain architectures: Business, Information, Application and Technology.
Therefore all three solutions in Frameworx (eTOM, SID, TAM) need to be considered
in this part of TOGAF as supporting tools.
TOGAF provides further information on the structure and processes required for an
architecture capability.
TOGAF TRM & III-RM and Frameworx
This mapping is part of the document 2 mapping between TOGAF and Frameworx
solution Integration Framework.
1.5. Sources used for the
mapping
This document is based on the following documents:

The Open Group: TOGAF 9 Version 2009
TeleManagement Forum: Frameworx solution Release V1.0; eTOM Version 8.0;
SID Version 8.0; TAM Version 3.2; Book “NGOSS distilled 2005” (for eTOM, SID and
TAM information)
The documents for the Frameworx solution Integration Framework are not
considered for this document.

2. Frameworx & the Architecture Development Method (ADM)
1.6. Preliminary Phase
The Preliminary Phase is the most important phase at the beginning of the enterprise
architecture initiative. It mainly prepares the organization for a successful enterprise
architecture by defining “where”, “what”, “why”, “who” and “how” enterprise
architecture will be done.
The main objectives of this phase are
to identify the sponsor, stakeholders
and other major stakeholders impacted
by the business, to identify and scope
the elements of the enterprise
organizations, the definition or rather
selection of an architecture footprint,
frameworks, principles and tools and
the confirmation of the governance.
The enterprise's approach to re-use of
architecture assets is a key part of both
the framework definition and
architecture principles. (Typically the
principles will state the policy on re-use;
and the framework will explain
how re-use is affected.)
Figure 18 – TOGAF Preliminary Phase
Using TOGAF and Frameworx:
The Preliminary Phase does not explicitly exist in Frameworx at present. Currently
most SPs use their own existing procedures and processes to start a new enterprise
architecture project. Some parts of this phase are not project specific, but have value
for the complete initiative portfolio. The preliminary phase can also be seen as an
entry point to a new TOGAF/ Frameworx based enterprise architecture initiative, as

such, it can be very beneficial to SPs to apply the method provided by this phase in
the TOGAF ADM.
After scoping the enterprise organizations impacted, the governance and the support
frameworks need to be confirmed. The SID conformance & compliance criteria and
conformance levels can be used together with the chapters 50 Architecture
Governance and chapter 48 Architecture compliance of TOGAF to evaluate potential
application acquisitions and to confirm the architecture governance process. Further
details can be found in sections 7.4 Architecture Compliance and 7.6 Architecture
Governance of this document.
When defining and establishing the architecture team and organization, both TOGAF
and Frameworx should be known by all involved architects and other team members
of the EA project. Regarding Frameworx the respective eTOM, SID and TAM experts
should be members of the architecture team as other stakeholders, like vendors,
suppliers and Integrators too. Use the chapter 52 Architecture Skills Framework of
TOGAF, see section 7.8 of this document, to basically identify the necessary
knowledge and experience of each involved architect or rather team member.
The architecture principles are an important anchor when establishing the
architecture governance. Firstly use the information framework TAM to establish the
10 Telecom specific principles provided by Frameworx, see section 3.5 of this
document. Furthermore, use the chapter 23 Architecture Principles of TOGAF to
define and establish further principles which may be necessary to the EA project.
The three solutions of Frameworx are identified as a deliverable framework for
telecom-specific artifacts in regards to business, data, and application architecture.
Contextually, identify the Architecture Content Framework of TOGAF (chapter 34 of
TOGAF and section 4.2 of this document), compare it with Frameworx and finally
identify re-usable components out of both for the enterprise architecture. The
Architecture Continuum classifies Frameworx solutions eTOM, SID and TAM as
industry-specific architecture as shown in section 5.2 of this document.
After a specific time, every enterprise architecture team needs to evaluate the EA
tools which can be used to develop the enterprise architecture. The chapter 42 of
TOGAF and section 5.5 of this document provide detailed information how to identify
and implement an EA tool. This section can also be used to identify and evaluate the
telecom-specific tools suggested by Frameworx.

1.7. Phase A – Architecture Vision
Phase A - Architecture Vision, is essential to the architect’s “elevator pitch” in order to
sell the benefits of the proposed enterprise architecture to the decision makers within
the enterprise. The goal is to articulate the architecture vision that enables the
business goals, responds to the
strategic drivers, confirm the principles
and addresses the stakeholders
concerns and objectives.
Clarifying and agreeing the purpose of
the architecture effort is one of the key
parts of this activity and the purpose
needs to be clearly reflected in the
vision that is created. Architecture
projects are often undertaken with a
specific purpose in mind, a specific set
of business drivers that represent the
return on investment for the
stakeholders in the architecture
development. Clarifying the purpose
and demonstrating how it will be
achieved by the proposed architecture
development is the whole point of the
architecture vision phase.
Figure 19 – TOGAF Architecture Vision
Using TOGAF and Frameworx
The Architecture Vision Phase is a critical complement to all Frameworx components
eTOM, SID, and TAM. It describes which challenges have to be resolved in the
architecture that is to be developed.
When establishing the architecture project, the objective of the architecture, the
scope, the stakeholder’s concerns and business requirements need to be identified.
TOGAF provides guidance on how to approach this. eTOM, SID and TAM support
the architecture scoping and partitioning. For example, one has to define which
architecture domains are considered and which breadth in eTOM and SID – i.e.
levels – are in scope for the architecture approach. The defined scope will have
implications for instance for the architecture effort that has to be estimated.

Considering the architecture capability, especially eTOM and SID can be used to
support the identification of capabilities for the architecture project. Use the chapter
46 of TOGAF – Establishing Architecture Capability –, chapter 36.2.10 capability
assessment and chapter 32 Capability based planning to identify the capabilities.
Before scoping the architecture, quantify the enterprise’s readiness to undergo
changes by the architecture project. Use the chapter 30 / section 3.12 of this
document Business Transformation Readiness Assessment to quantify this situation.
eTOM, SID and TAM also strongly support the definition of the architecture scope
and partitioning. For example, you have to define which architecture domains you are
going to consider and which breadth of eTOM and SID – means levels – you are
going to use for the architecture approach. That clearly influences the architecture
effort the architecture team has to estimate. Use the Frameworx solutions in
connection with the chapter 40 of TOGAF Architecture Partitioning to define the
architecture scope.
The Frameworx solution TAM also supports the confirmation of architecture principles
and should be used together with the chapter 23 of TOGAF / section 3.5 of this
document Architecture Principles. The Frameworx solutions eTOM and SID should
be considered when confirming the principles for business and data architecture.
Finally, all solutions of Frameworx heavily support the development of the
architecture vision for all architecture domains, especially for the target architecture.
Use the chapter 26 of TOGAF / section 3.8 of this document Business Scenario in
connection with the assessment methodology of Frameworx to develop the
architecture vision.
After developing the architecture vision, the business transformation risks should be
identified using the chapter 31 of TOGAF / section 3.13 of this document Risk
Management in connection with the Frameworx solutions. These solutions support
the identification of risks in regards to relationships of processes, applications and
infrastructure.
At the end, produce the statement of architecture work using the chapter 37 of
TOGAF / section 4.4 of this document Architecture Deliverables in connection with
Frameworx to define the work products for the architecture project.
Detailed mapping:
Please refer to “Quick Reference Guide”.
The eTOM, SID and TAM can be used during this phase to delineate the scope and
boundaries of the considered domain.

1.8. Phase B – Business Architecture
The business architecture is the first architecture activity that needs to be undertaken.
It is necessary for demonstrating the business value and requirements of subsequent
technical architecture work to key stakeholders and its return on investment.
Figure 20 – TOGAF Business Architecture
Using TOGAF and Frameworx
The business architecture describes the working model related to the defined
architecture scope and architecture challenges that need to be addressed. The

business architecture reflects the business strategy/model and related challenges
and shapes the detailed process decomposition of each process in the eTOM. Some
processes might have to be added in order to complete the working model for a
specific business strategy/model. eTOM describes the process, and identifies the
relevant Aggregate Business Entity from the SID. These processes become
enterprise specific by elaborating the goals into measurable output and by attributing
the accountability for the outcome of a process to an actor or organizational function.
SID most relevance is along Phase C. However, at the Information model level it
makes also sense to include it in Phase B. At the highest level it defines the objects
that are transformed along with the business processes. For example: the sales
process transforms an OPPORTUNITY into a CUSTOMER. The lower level
information objects on the other hand have to be elaborated according to the
business strategy/business model.
Use the eTOM Frameworx solution and the existing business models in the
enterprise to define the baseline, target architecture and gaps describing building
blocks, functions, processes, activities, services and roles and responsibilities of
actors (RACI/CRUD). Consider the existing environment in the enterprise, identify the
gaps and develop the different types of artifacts for the business architecture, which
are catalogs, matrices and diagrams. The chapters 35.9 of TOGAF / 4.3 of this
document Architecture Artifacts, chapter 41 of TOGAF / section 5.4 of this document
Architecture Repository and chapter 27 of TOGAF / section 3.9 of this document Gap
Analysis support the development of the business architecture in connection with
eTOM and SID. Furthermore, use the chapter 51 of TOGAF / section 7.7 of this
document Architecture Maturity Model in connection with the eTOM levels of maturity
to develop the actual baseline architecture.
After developing the business architecture, resolve the impacts across the enterprise
and architecture landscape to identify the potential impact of the new business
architecture to the existing landscape or rather baseline architecture. The focus of this
impact assessment should mainly concentrate on the roles and responsibilities of the
relevant stakeholders and the impact of the new business architecture to their power
and concerns from their perspective. Use eTOM and chapter 36.2.18 of TOGAF /
section 4.4 Architecture Deliverables. Additionally, check the original motivation for
the architecture project with the stakeholders and the Stakeholder Management
Technique of chapter 24 of TOGAF / section 3.6 of this document.
Finally, develop the final business architecture including building blocks, functions,
processes, roles and responsibilities and create the architecture definition document.
Use eTOM and the chapter 36 of TOGAF / section 4.4 of this document Architecture
Deliverables.
Looking to the above-mentioned architecture development, the chapter 19 of TOGAF
/ section 3.2 of this document Applying iteration to the ADM can be seen as a very
useful method to develop the business architecture by using eTOM and SID at the
same time. The architecture definition iteration cycle clearly focuses on this matter
and it also covers the application architecture of Frameworx solution TAM.

Detailed mapping:
1.9. Phase C – Information Systems Architecture
The objective of phase C Information Systems Architecture is to define the baseline
and target architectures covering either or both (depending on the scope) the data
and application domains.

Figure 21 – TOGAF Information Systems Architecture
Phase C Information Systems Architecture in TOGAF is divided into data, and
application architectures. Therefore, the mapping between TOGAF and Frameworx
considers the architectures separately, as shown below.
The TMF SID framework deals with both information and data as one framework.
1.9.1. Data Architecture
The Information framework (SID) can be used to represent the data architecture in
phase C of the TOGAFADM.
The objective of the data architecture of TOGAF is to define the major types of
(automated) data necessary to support the business in a way that is:
 Understandable by stakeholders,
 Complete and consistent,
 Stable.
It is important to note that this effort is not concerned with database design. The goal
is to define the data entities, attributes and relationships relevant to the enterprise, not
the design of logical or physical storage systems. However, linkages to existing files
and databases may be included for reference.
1.9.2. Application Architecture
The objective is to define the major types of applications necessary to process the
data and support the business.
It is important to note that this effort is not concerned with applications systems
design. The goal is to define what kinds of application systems are relevant to the
enterprise, and what those applications need to do in order to manage data and to
present information to the human and computer systems across the enterprise.
The applications are not described as computer systems, but as logical groups of
capabilities that manage data objects in the Data Architecture and support the
business functions. The applications and their capabilities are technology neutral. The
applications are stable and relatively unchanging over time, whereas the technology
used to implement them will change over time, based on the technologies currently
available and changing business needs.

The mapping of the Frameworx TAM with the TOGAF Information Systems
(Application Architecture) appears to be a rich area in terms of synergies between the
two models. TOGAF defines the various steps to define and describe the baseline
and target Application Architecture. Frameworx provides the TAM as a well defined
classification scheme and structured application framework, which provides direct
alignment with both the eTOM and the SID.
Using TOGAF and Frameworx solutions SID and TAM:
Select the reference models and the relevant viewpoints and tools to develop the
Information Systems Architecture using the chapter 34 of TOGAF / section 4.2 of this
document Content Metamodel and chapter 35.10/11 of TOGAF / section 4.3 of this
document Viewpoints of phase C in connection with the Frameworx solutions SID
and TAM.
Use SID and the existing data models in the enterprise to define the baseline, target
architecture and gaps describing building blocks, data models, logical data models of
the actual data of interest from the applications point of view, data management
processes, lifecycle, security and data entities.
Use TAM and the existing application models in the enterprise to define the baseline,
target application architecture and gaps describing building blocks, the business
functions and organizations supported by the application and the hardware/software
on which the IT function runs. Identify the critical relationships (that might affect
application design) between the applications, the business processes and the
technology architecture.
For SID and TAM, consider the current architecture, identify gaps and develop the
different types of artifacts for the information systems architecture, which are
catalogs, matrices and diagrams.
The chapters 35.10/11 of TOGAF / 4.3 of this document Architecture Artifacts,
chapter 41 of TOGAF / section 5.4 of this document Architecture Repository and
chapter 27 of TOGAF / section 3.9 of this document Gap Analysis support the
development of the information systems architecture in connection with SID and
TAM. Furthermore, use the chapter 51 of TOGAF / section 7.7 of this document
Architecture Maturity Model to identify the actual baseline architecture.
After developing the information systems architecture, resolve the impacts across the
enterprise and architecture landscape to identify the potential impact of the new
information systems architecture to the existing landscape or rather baseline
architecture.
The focus of this impact assessment should mainly concentrate on the relationships
to other applications, to business architecture, to their relevant stakeholders. Use SID
and TAM and chapter 36.2.18 of TOGAF / section 4.4 Architecture Deliverables.

Additionally, check the original motivation for the architecture project with the
stakeholders and the Stakeholder Management Technique of chapter 24 of TOGAF /
section 3.6 of this document.
Finally, develop the final information systems architecture including building blocks,
components, capabilities, services and relationships to the application and business
processes and create the architecture definition document. Use SID and TAM and
the chapter 36 of TOGAF / section 4.4 of this document Architecture Deliverables.
Looking to the above-mentioned architecture development, the chapter 19 of TOGAF
/ section 3.2 of this document Applying iteration to the ADM can be seen as a very
useful method to develop the business architecture by using eTOM and SID at the
same time. The architecture definition iteration cycle clearly focuses on this matter
and it also covers the application architecture of Frameworx solution TAM.
Detailed mapping:
1.10. Phase D – Technology Architecture
The technology architecture phase
seeks to map application components
defined in the application architecture
phase into a set of technology software
and hardware components, available
from the market or existing within the
organization as technology platforms.
As technology architecture defines the
physical realization of an architectural
solution, it has strong links to
implementation and migration
planning.
Figure 22 – TOGAF
Technology Architecture

When considering TOGAF and Frameworx synergies, it seems quite intuitive that the
technology architecture Phase D of TOGAF would map straightforward to the
Integration Framework in Frameworx especially when considering the former name
“Technology Neutral Architecture”. Unfortunately, this is not so; this is due to the fact
that the Integration Framework in Frameworx is an integration (interfaces between
applications) methodology rather than a technology method or framework. Therefore
the Phase D does not need any further analysis within the scope of this document.
The mapping of the Integration Framework with TOGAF will be part of another
document to be produced by this team in the near future.
1.11. Summary of Phase E to H
TOGAF ADM Phase E:
The Phase E is the first phase, which, is directly concerned with the method
describing how the Target Architecture will be implemented.
This phase concentrates on how to deliver the architecture and takes both, business
and technical perspective to rationalize the IT activities and logically group them into
project work packages with the IT portfolio and also within any other portfolios that
are dependent upon IT.
TOGAF ADM Phase F:
The main focus of Phase F is the creation of a viable implementation and migration
plan in co-operation with the portfolio and project managers. It includes assessing the
dependencies, costs, and benefits of the various migration projects. The prioritized list
of projects will form the basis of the detailed implementation and migration plan that
will supplement the architectures with portfolio and project-level detail assigning tasks
to specific resources.
TOGAF ADM Phase G:
Phase G establishes the connection between architecture and implementation
organization, through the Architecture Contract. This phase ensures the compliance
with the defined architecture, not only by the implementation projects, but also by
other ongoing projects within the enterprise.
The implementation governance is closely related to architecture governance,
discussed at chapter 50 of TOGAF / section 7.6 of this document.
TOGAF ADM Phase H:

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.
The Frameworx solutions eTOM, SID, and TAM do not directly map to the phases E
to H, as this is shown in the figure below.

TOGAF phases E, F, and G and Frameworx:
In spite of this situation, all three Frameworx solutions support these phases by
representing the content and the result of the architecture development which should
be implemented and realized at the TOGAF ADM phases E, F, and G.
As already mentioned, the TOGAF ADM phases E, F, and G mainly concentrate on
the planning and implementation of the developed enterprise architecture. Therefore,
the focus of the comparison or rather mapping has rested with the joint usage of the
Frameworx solutions in connection with these TOGAF ADM phases whilst the
planning and implementation of the developed enterprise architecture.
The synergies or rather complementarities of the Frameworx solutions and these
phases of TOGAF ADM are significant and Frameworx can highly benefit from
TOGAF.
The phases E, F, and G provides a description of detailed steps and a step by step
approach including various migration planning and implementation techniques to plan
and implement the developed enterprise architecture. Furthermore, lot of techniques
such as for assessing the readiness of the enterprise to undergo changes and
identify the risks for business transformation or how to consolidate and reconcile
interoperability requirements are comprehensively described. These very useful
techniques strongly help to build up and to implement an enterprise architecture
based on TOGAF and Frameworx solutions.
TOGAF ADM phase H and Frameworx:
The three Frameworx solutions eTOM, SID, and TAM do not map to the phase H.
Furthermore, this phase does not exist in Frameworx solutions but it is the most
important part of the architecture development method in regards to handling and
managing business and technology changes, as shown in the figure below.

This phase of TOGAF describes the different drivers for changes, categories of
changes and suggests guidelines for changes and finally describes the different steps
of a change management process. Depending on the nature of the change, the
respective Frameworx solutions need to be considered when managing and
implementing this change.
The Frameworx does not have a specific change management process and
therefore, the phase H strongly supports any change activities also in a Frameworx
solution. Because of this situation, using this phase is highly beneficial to every
enterprise in telecommunication industry.
What has been investigated
How the comparison has been done
Summary of findings on synergies or complementarities

1.12. Requirements Management
Requirements Management defines a process whereby requirements for enterprise
architecture are identified, stored, and fed into and out of the relevant ADM phases of
TOGAF.
Figure 23 – TOGAF Phase Requirements Management
Frameworx uses eTOM, the SID and the TAM to define business requirements in
terms of use cases. Use cases will first be created in the Business View, then they
will evolve into more detail across the System View, the Implementation View onto
the final stage which is the Deployment View; such use cases represent the
expression of requirements according to Frameworx. Different types of requirements
(including business requirements) are identified in eTOM, examples of these are:
 Interaction requirements in the B2B process interaction with Supplier,
Partners and other external parties.

 Customer requirements in the product lifecycle management process to
develop and manage products in accordance with customer demand.
 Financial requirements in the strategic and enterprise planning in order to
improve the overall capital and investment capacity of the enterprise.
 Operational requirements for the operation of service delivery platforms.
All these different types of requirements need to be identified and documented before
moving on to next steps. Generally speaking, the Frameworx solutions eTOM, SID
and TAM as well as changes originated by new business trends and technologies
provide the new requirements to the enterprise architecture and need to be
considered at the first step of the requirements management of TOGAF, as shown
below.
Figure 24 – TOGAF Phase Requirements Management - Steps
After identifying the new requirements, collect and monitor them and check the
motivation with the stakeholders. Identify the changed requirements (remove, add or
modify) at the different architecture domains (business, information systems and
technology architecture) from the phases B to G. Use the Framworx solutions eTOM,
SID and TAM to prioritize the requirements and identify the dependencies of each
requirement to the different Frameworx solutions and generate an requirements
impact statement, chapter 36.2.18 of TOGAF. Assess the impact to the previous
phases, implement the requirements and update the repository.

The requirements management of TOGAF defines a process of handling the
requirements during a development of an enterprise architecture. The Frameworx
solution eTOM shortly describes business requirements – as mentioned above – but
does not describe a requirements management process as the TOGAF does.
Therefore, this phase of TOGAF ADM provides a huge benefit of managing
requirements during the development of a new enterprise architecture using
Frameworx and TOGAF.
Detailed mapping:

3. ADM Guidelines & Techniques as applied to Frameworx
1.13. Introduction and Scope
This section describes supporting guidelines and techniques for the enterprise
architecture development by using the TOGAF ADM (Architecture Development
Method) in connection with Frameworx.
1.13.1.Guidelines for adapting the ADM process
The ADM process can be adapted to accommodate a number of different scenarios,
including different process styles (e.g. iteration cycle) and also specific architectures
(e.g. security).
1.13.2. Techniques for architecture development
The techniques support specific tasks within the ADM, such as definition of principles.
They can be used in different phases of the ADM.
1.13.3. Scope
This section shows which of these TOGAF ADM guidelines and techniques can be
used in combination with Frameworx and how they can be applied.
1.14. Applying Iteration to the ADM in different enterprise levels
The ADM is a flexible process that can be used to support the development of architecture as a
stand-alone process or as an extension to other solution development or project management
method.
The different iteration cycles of TOGAF span a number of ADM phases and allow a formal review
upon completion of each multi-phase iteration cycle. Using the iteration cycles “Architecture Definition
Iteration” and “Architecture Context Iteration” as shown in the following figure, imply the usage of the
associated frameworks of the Frameworx solution (eTOM, SID, TAM).

As already mentioned at the phases B and C, the Frameworx solution SID also supports eTOM and
consequently the development of the business architecture.
Considering the different process levels and business functions of eTOM, the data entities and
attributes of SID and their relationships strongly need to be considered with eTOM when defining
business and data architecture. Applying iteration to the ADM phases B, C and D is a very useful
technique to ensure a joint development of different architecture dimensions, which are dependent
from each other.
Figure 25 – TOGAF Iteration Cycles and Frameworx solutions
During the development and implementation of an enterprise architecture, it is mostly not possible to
develop a single architecture that addresses all the needs of all stakeholders. Furthermore, the
Frameworx solutions eTOM, SID and TAM also have a strong relationship to each other and
consequently have dependencies when developing an enterprise architecture. Because of this
reason, the enterprise must be partitioned into different areas, each of which can be supported by the
respective architecture. Typically it is partitioned into subject matter, time period and level of detail, as
shown in the figure below.

Figure 26 – TOGAF different enterprise levels
Using the ADM of TOGAF, the different enterprise architectures and the Frameworx solutions eTOM,
SID and TAM, the strategic architecture can be described at the architecture vision phase (Phase A)
by developing the strategic view of the different architecture dimensions of B, C and D. For example,
the strategic view of business architecture can be the level 0 and level 1 processes of eTOM
business process framework. A more detailed and formal architecture description can be provided in
the phase B (business architecture) by describing the level 2, level 3 and following levels of eTOM
business process framework, which finally illustrates the segment architecture as shown in the figure
below.

Figure 27 – TOGAF ADM and different enterprise levels

This section is not in scope of the mapping exercise
1.15. Security Architecture and the ADM
This section is not in scope of this document.
1.16. Leveraging both TOGAF and Frameworx in the context of SOA
Not inscope of this document
1.17. Architecture Principles
Architecture principles define the underlying general rules and guidelines for the use
and deployment of all IT resources and assets across the enterprise. They reflect a
level of consensus among the various elements of the enterpr ise, and form the basis
for making future IT decisions. Each architecture principle should be clearly related
back to the business objectives and key architecture drivers. Principles shape the
organization and IT of an enterprise.
In TOGAF architecture principles are defined as a subset of IT principles. They are
considered as part of hierarchy of principles: enterprise – IT – architecture.
Considering TOGAF and Frameworx, especially the application framework TAM
maps to the principles of TOGAF (enterprise principles, information technology
principles and architecture principles). The section “Core NGOSS principles” now
“Core Frameworx principles” describes ten key business and technology principles
from the perspective of Frameworx.
These ten principles can be mapped into the architecture principles as shown below:
TOGAF Principles Frameworx Principles Respective Frameworx
Principle covered in

TOGAF?
Architecture
Principles
- Provide comprehensive,
enterprise-wide operational
solutions for fixed, mobile,
cable and converged industry
segments.
- No. This Frameworx
Principle would an
additional principle in
the example set of
TOGAF.
Business Principles - Enable an operator’s
business transformation.
- Allow business processes to
be easily changed without
software change by
separating control of
business process flow from
application operation.
Principle would an
the example set of
TOGAF.
- Partially yes. It can be
considered with the
principle 4 of TOGAF:
Business Continuity
Data Principles - Allow corporate data to be
widely shared across the
enterprise and where
appropriate with trading
partners.
- Yes. The principle 11
of TOGAF “Data is
Shared” directly maps
to this principle of
Frameworx.
Application
Principles
- Reduce software
development costs and risks
by building on industry best
practices and existing
standards work.
- Allow operators organization
to evolve without systems
lock in by using loosely
coupled distributed systems.
Principle would an
the example set of
TOGAF.
of TOGAF
“Technology
Independence” maps
Frameworx.
Technology
Principles
- Reduce IT costs and
timescales by utilizing widely
available, commercial-off-the-shelf
(COTS) software
components.
- Partially yes. The
principle 5 and 16 of
TOGAF “Common
Use Applications” and
“Technology
Independence” can

- Allow a clear migration path
by integrating with and
evolving from legacy
systems.
- Allow simplified systems
integration (Plug & Play)
through clearly defined
contract interfaces between
applications.
- Allow simplified systems
integration by utilizing a
common communications
bus between applications.
lead to reduced IT
costs.
Principle would an
the example set of
TOGAF.
of TOGAF
“Interoperability” maps
Frameworx.
- Partly yes. The
principle 6 of TOGAF
“Service Orientation”
would imply the usage
of a communications/
service bus.
As shown above in that table, the Frameworx principles mentioned in the Frameworx
solution TAM map into the different architecture principles of TOGAF. For sure, these
principles are strongly related to Frameworx solutions and to the needs of the
telecommunication operator. TOGAF provides an additional benefit to this section of
Frameworx by providing methods, templates, set of criteria and qualities for
developing further good principles in the TOGAF Phase A Architecture Vision. These
materials intensively help to define new principles when starting a new architecture
approach and can be found at the TOGAF chapter 23 Architecture Principles.
1.18. Stakeholder Management
Stakeholder management is one of the most important techniques for a successful
enterprise architecture project.
It is essential in any initiative to identify the individuals and groups within the
organization who will contribute to the development of the architecture, just as
important it is to identify those that will gain and those that will lose its introduction and
then develop for dealing with them.

TOGAF identifies the different stakeholders at different phase of ADM by using the
following concepts:
 Stakeholders,
 Concerns,
 Views,
 Viewpoints.
Furthermore, TOGAF provides a template for classifying stakeholders’ position and a
stakeholder power grid. The examples are shown below.
Figure 28 – Stakeholder Analysis
Figure 29 – Stakeholder Power Grid

From a Frameworx perspective, stakeholders wishing to implement Frameworx
include Service Providers (SPs), Equipment Manufacturers, Independent Software
Vendors (ISV s), and Systems Integrators (SIs). 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 Service Providers (SPs), Independent
Software Vendors (ISVs) and Equipment Manufacturers (EMs). The second category
can include Equipment Manufacturers (EMs) and Systems Integrators (SIs). Both
stakeholder categories have the opportunity to implement all or some of Frameworx
solutions eTOM, SID, or TAM.
Therefore, four different types of stakeholders can be identified, which are:
 Service Providers (SP)
 System Integrators (SI)
 Independent Software Vendors (ISV)
 Equipment Manufacturers (EM)
The eTOM includes a process “Stakeholder & External Relations Management” at
hierarchy level 2.1.3.6. 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 ones) 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.
The 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.

1.19. 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, when and what trade-offs you have to
make in doing so.
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
 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 vs. 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.
1.20. 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.
When comparing both TOGAF and Frameworx in terms of business scenarios, in
Frameworx, the eTOM, SID and TAM do not explicitly include business scenarios,
but are to be used in Use Cases and business process flows which represent and
describe the business scenarios used in the Frameworx methodology; the 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.
Nevertheless, we can conclude at this stage that the eTOM, SID, and TAM should be
applied in use cases to describe business scenarios as part of the phase A -
Architecture Vision of the TOGAF ADM.

Figure 30 – 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. The figure below shows the mapping between both methodologies.
Figure 31 – 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.

1.21. Gap Analysis
The basic premise 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.
The Frameworx solutions do not explicitly say something about a methodology for a gap analysis.
Looking to the 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.
The following figure shortly illustrates a gap matrix for telecommunication services, which can be
considered in the product architecture as part of the business architecture.

Figure 32 – Gap analysis
Because of this situation, the information about a gap analysis in TOGAF is a useful information in
regards of doing a gap analysis. It provides a specific set of steps and a sample template for
developing a gap analysis.

1.22. Migration Planning Techniques
TOGAF provides various numbers of implementation and migration 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
The Frameworx solution Telecom Applications Map (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 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 the 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 the document two
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 shows
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 33 – Gap Implementation Factor Assessment and Deduction Matrix
Consolidated Gaps, Solutions, and Dependencies Matrix
That 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.
Figure 34 – TOGAF Consolidated Gaps, Solution & 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 the figure below. Considering the example of integrating a new
partner, a new order processing process including the relating 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 35 – TOGAF Gaps, Solution & 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 specified time.
Figure 36 – 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 solutions 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 37 – TOGAF State Evolution Table
This table should be drawn listing the services from the Frameworx Telecom-specific
enterprise architecture, the transition architectures, and proposed transformations, as
shown below.
Figure 38 – TOGAF State Evolution Table - 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.
Out of scope
Interoperability Requirement 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.
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.
The following figure 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 structure on a matrix as shown below.
Figure 39 – TOGAF Business Information Interoperability Matrix
As shown in the figure, 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 to build up a scalable and flexible OSS landscape as suggested by
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.

1.23. Business Transformation Readiness Assessment
Not in scope
The Business Transformation Readiness Assessment evaluates and quantifies an
organisation’s readiness to undergo changes.
The Frameworx solutions do not have a specific area about this section, even this
is one of the most important parts during 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 TM Forum’s Lean
Operator Program.
Comparing TOGAF and Frameworx the Business Transformation Readiness
Assessment of TOGAF maps not 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”.
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. The figure below illustrates the different
readiness factors used in a summary table, which exactly considers these factors.
Figure 40 – 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” to fix this readiness factor.
As it can be seen, the Frameworx solutions eTOM, SID and TAM do not map to this
chapter 30 of TOGAF but they provide some functional inputs to assess the
readiness to undergo changes in the organization.
1.24. 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.
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 2.1.3.2 talking about business continuity
management, fraud management, audit management and others. These are process
functions in the meaning of eTOM process model and do not include a risk
management method as described in TOGAF.
As shown in the figure below, the risk management chapter 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 41 – Risk Classification Scheme
Figure 42 – Risk Identification Worksheet

1.25. 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.
Capability-based-planning of TOGAF is a very useful technique to concentrates 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 43 – 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 service
providers 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 concept and Frameworx solutions support the development of an
architecture, based on capability-based-planning concept as described in this TOGAF
chapter.
A more detailed description of the mapping between Capability-based-planning of
TOGAF and Integration Framework of Frameworx will follow, as soon as the
Integration Framework is published.

4. Architecture Content Framework and synergies with
Frameworx
This section provides a comparison between the TOGAF Architecture Content
Framework and Frameworx.
1.27. Content Metamodel
A TOGAF architecture is defined by a number of architectural 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.
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. The following figure presents the content
metamodel with extensions and the respective mapping to the Frameworx solutions.

Figure 44 – 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 quite valuable as a reference structure to map the TMF
Frameworx and highlight gaps. This provides an insight into where the assets fit from
an enterprise architecture perspective.
eTOM, SID, TAM and Content Metamodel:
As already described in several 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.

TOGAF Content
Metamodel Objects
Frameworx
Organizational Unit 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.
Actor / Role 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.
Business Function As part of the business architecture, it maps to the 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 might be used as a
synonym for process at conceptual level.
Process 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 logical level representing the HOW?, and Frameworx
refers to the conceptual level as the WHAT?
Data Entity 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): a loosely coupled set of
business entities. Sometimes called Business Object.
Logical Data
Component
As part of the data architecture, it maps to the Frameworx
solution SID as an information model.
This is a boundary zone that encapsulate related data entities to
form a logical location to be held, e.g.: procurement information
Physical Data
Component
Does not map to the SID by definition, because it reflects the
implementation of a data entity, and in architecture no
implementations exist.
Information System
Service
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.
Logical Application
Component
As part of application architecture, it maps to the Frameworx
TAM.
In the 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.
Physical Application
Component
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.

Business Services 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.
Principle This is a qualitative statement of intent that should be met by the
architecture.
This is not included in Frameworx.
The TAM in Frameworx mentions 10 principles and therefore it
can be mapped to this object.
TM Forum Frameworx can benefit from the Content Metamodel object definitions in
TOGAF as shown above.
1.28. 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.
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, it does not really map to each other – it rather
complements each other. How eTOM, SID and TAM relates to the artifacts of
TOGAF is shown in the figure below.
Figure 45 – TOGAF – Artifacts and Frameworx solutions
Frameworx makes use of all three artifacts. The metamodel concepts can well be
adopted by TMF in order to extend the frameworks to other assets.
TOGAF Artifacts Frameworx Artifacts
Artifacts (catalogs, matrices
Frameworx application solution TAM identifies
and diagrams) of
Frameworx specific principles.
Preliminary
and diagrams) of
Architecture Vision – Phase
A
Not covered directly. However, Frameworx
mentions different type of stakeholders which
support the development of the stakeholder
map.
Artifacts (catalogs, matrices Frameworx process eTOM supports the

and diagrams) of Business
Architecture – Phase B
development of the artifacts.
For example: an actor / role matrix can be
created by defining roles & responsibilities of
actors in eTOM processes. The result will be a
RACI matrix equal to actor / role matrix.
and diagrams) of Data
Architecture – Phase C
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.
and diagrams) of
Application Architecture –
Phase C
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 the dependencies
between the applications are identified.
and diagrams) of
Technology Architecture –
Phase D
Not covered.
Systems architecture (SOA style architecture)
contains a set of concepts that are similar or
equal to contracts in Frameworx
and diagrams) of
Opportunities and Solutions
– Phase E
Not covered.
and diagrams) of
Requirements Management
The Frameworx eTOM does not define
measurable requirements. It only defines the
generic goal for a service provider.
1.29. 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.
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 chapter 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, it has now evolved into the
notion of business service as defined within the
context of Service Oriented Architecture (SOA).
Business services as defined in Frameworx can
be related to architecture contracts as defined in
TOGAF if done on 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 next stage of this project
mapping in the near future. See section 7.5 for
further details on Architecture contracts.
Architecture Definition
Document
Not covered.
eTOM, SID and TAM can be leveraged as part
of this document and represent the architecture
content
Architecture Principles A number of Architecture principles are defined
as part of Frameworx documentation,
particularly within th Application Framework
“TAM”.
Architecture Repository 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
Specification
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).
Architecture Roadmap 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.
Architecture Vision 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 the TOGAF phase A Architecture
Vision.
Business Principles,
Business Goals, Business
Drivers
A number of Architecture principles are defined
as part of Frameworx documentation.,
Capability Assessment The Frameworx solution eTOM process
maturity assessment, Frameworx assessment
team supports the development of this
deliverable.
Change Request 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
Communications Plan 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..
Compliance Assessment This assessment is relevant to Frameworx as it
relates to the SID and eTOM conformance and
compliance assessment principles and rlues. 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
Implementation and
Migration Plan
Not covered.
Implementation
Governance Model
Not covered.
Organisational Model for
Enterprise Architecture
Not covered.
Request for Architecture
Work
Not covered.
Requirements Impact
Assessment
Not covered.
Solution Building Block See chapter 4.5.
There is notion of application components
defined in the TAM. Frameworx can benefit
from TOGAF
Statement of Architecture
Work
Not covered.

Tailored Architecture
Framework
Tailored Frameworx solutions eTOM, SID,
TAM.
Transition Architecture Not covered.
These architectural deliverables can be seen as architectural output 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
the eTOM, SID and TAM together in the form of Business Services; such business
services can be considered and are linked to specific deliverables.
1.30. Building Blocks
All artifacts described within the TOM, the SID and the 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 the eTOM, Aggregate Business Entities (ABEs) in the SID and Modules
or Application Components within the TAM.
Solution Building Blocks on the other hand are more related to packaged products or
solutions, they can be for instance certified tools, COTS software, personal
computers or other types packaged products or capabilities.

5. Enterprise Continuum and Tools and synergies with
Frameworx
This section provides a comparison between TOGAF Enterprise Continuum and
Frameworx solutions.
1.32. 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.
1.32.1. 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.
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.
1.32.2. 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.

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.
1.33. Architecture Partitioning
In a typical enterprise, much architecture will be in existence at any point in time.
Some Architecture 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.
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
Frameworx solutions
architecture partitioning
Partitioning of Solution
Subject Matter 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.
Time 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.
Maturity/Volatility Use eTOM process maturity model for the
business architecture to identify the actual
status in contrast with the solution lifecycle.
Partitioning of Architecture
Subject Matter Depending on the nature of the architecture
solution, Frameworx solutions eTOM, SID and
TAM need to be considered.
Examples can be developing new products,
services, service centers, or building up a new
partnership with a supplier or partner, for which
a new architecture based on eTOM, SID and
TAM is needed.
Viewpoint 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 the eTOM, SID and TAM can be
the source for developing viewpoints from
stakeholders in this domain (Procurement,
Partner Management, etc).
Level of Detail Identify the relevant process elements within the
eTOM starting at level 0, as well as related SID
entities/attributes and components within the
TAM, to define the level of architecture detail for
a specific architecture project. See figure below.
Level of Abstraction 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.

Accuracy 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 the
figure below.

Figure 46 – 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. The eTOM
provides the enterprise business (processes), the SID the enterprise information
concepts and data in scope and the TAM the enterprise applications or components.
Use the various hierarchy levels in the eTOM, SID and TAM to define the depth and
detail granularity for the enterprise architecture, as shown at the figures below.
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

TOGAF ADM and establish the portfolio/project team for these phases.
Figure 47 – Architecture Partitioning with Frameworx - Examples
Frameworx provides in its eTOM, SID and TAM also different levels of detail which
facilitate the decision-making on what detail to cover.

Figure 48 – TOGAF – Partitioning and Frameworx solutions
1.34. 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.
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 TOGAF repository and
Frameworx Integration Framework will be part of a future document as 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. The figure below provides an overview on
how Frameworx solutions fit with respect to the TOGAF repository.
Figure 49 – TOGAF – Repository and Frameworx solutions
With the link to architecture continuum, Frameworx are 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 the 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.
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.
1.35. 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
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 the 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 Service Providers and other players within the telecommunications industry.

6. TOGAF Reference Models and their relevance to Frameworx
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.
1.37. 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 Frameworx solution
Integration Framework.
1.38. 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 Frameworx solution

7. Applying Architecture Capability Framework to Frameworx
This section describes the Architecture Capability Framework in TOGAF and
proposes an initial mapping to the four TMF Frameworx solutions.
1.40. 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.
As mentioned previously, this section provides an overview on 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
1.41. 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.
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.

Nevertheless, when establishing an architecture board, the members of this board
(can also be called stakeholders) should have a specific knowledge about the
concept of Frameworx and its solutions eTOM, SID and TAM to fulfill the respective
roles in this board.
1.42. Architecture Compliance
When establishing an 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 it
 Fully conformant: full correspondence between architectures
 Non-conformant: some features are implemented but not in accordance with
specification
Comparing TOGAF with Frameworx, the TM Forum has defined conformance criteria
for both the Business Process Framework (eTOM) and the Information Framework
(the SID). Information Framework Certification is only for software, 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 7 levels of Conformance criteria for the eOM and SID;
these are as follows:
For the Information Framework (SID)
 Level 1: The content of the model is compatible with a subset
 Level 2: The component/solution of level 1 is elaborated into more detail and
the of SID ABEs that define its domain coverage. 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 ABE are dependent.
the required attributes of the ABE’s core entities are defined in the model.
dependent entities within the ABE’s are defined in the model. A dependent
entity is one whose instances are dependent on an instance of a core entity.
 Level 5: The component/solution has passed level 4 and the required
attributes of the ABE’s dependent entities are defined in the model.
 Level 6: The component/solution has passed level 5 and all attributes of the
ABE’s core entities are defined in the model.
 Level 7: The component/solution has passed level 6 and all attributes of the
ABE’s dependent entities are defined in the model.
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
minor deviations
no deviations
minor deviations

no deviations
Referring to Frameworx, the 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 the 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
Frameworx SID Conformance levels
levels
Irrelevant Not covered.
Consistent 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.
Compliant
Conformant
Fully Conformant Level 7
Non-Conformant 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.
1.43. 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 the figure below 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 service providers (SPs). One service
provider covers receipt of a customer service complaint and the immediate
processing to generate and handle a customer problem report from this. The other
service provider is responsible for handling the problem analysis and resolution if a
service problem report must be created and analyzed. Here we would 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 service providers 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).
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, Phases B to D and Phase G. Furthermore, contracts can be between
architecting function and business users. Within architecture governance (chapter 50
of TOGAF) architecture contracts can drive architecture changes.
When comparing TOGAF and Frameworx, the 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 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, service providers 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 the next stage of this mapping project (i.e. document two 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.
1.44. 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 organisation's architecture. It includes:
 Implementing a system of controls over the creation and monitoring of all
architecture components and activities.
 Implementing a system to ensure compliance with internal and external
standards and regulatory obligations.
 Establishing process that support 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 of TOGAF
Implementation Governance and together with the chapter 48 Architecture
Compliance of TOGAF.
Frameworx can benefit from TOGAF.
The 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
The 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.
The architecture governance describes the 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.
The 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.
The 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 of TOGAF and Frameworx solutions at the
architecture governance processes.
Figure 50 – TOGAF Architecture Governance Process
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 at the section architecture compliance, the SID identifies the SID
conformance & compliance criteria describes a section “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.
Process “Dispensation”
Where a compliance assessment is rejected or any ad-hoc decisions based on new
requirements an alternative architecture, as an interim solution can be necessary.
Depending on the specific requirements and on the architecture dimensions, which
need to be considered at this level, the different Frameworx solutions can be
considered to identify an ad-hoc solution for an interim architecture.
Process “Monitoring and Reporting”
This process is required to ensure that the observed behavior is what expected and
consequently fulfils the criteria for the architecture. All Frameworx solutions should be
considered at this process, to monitor the whole architecture dimensions.
Process “Business Control”
This process relates to the processes invoked to ensure compliance with the
organization’s business policies. These business policies can be business services in
the meaning of the Integration Framework services. Therefore, this Integration
Framework should be considered at this governance process to ensure the
compliance. But this will be part of the document two mapping at a later time.
Process “Environment Management”
This process identifies all services required to ensure that the repository-based
environment underpinning the governance framework is effective and efficient. It
includes the physical and logical repository management, access, communication,
training and accreditation of all users. Therefore, it mainly relies on the chapter
Architecture Repository of this document and the Frameworx solutions eTOM, SID,
and TNA can be considered at input to it by providing architectural artifacts.
As shown at the above-mentioned architecture governance framework, all
Frameworx solutions can be continuously considered as an input to the architecture
governance framework or rather the governance process.
1.45. Architecture Maturity Models
Architecture Maturity Model addresses the problem by providing an effective and
proven method for an organisation to gradually gain control over and improve its IT
related development process.
The ACMM of TOGAF provides six levels of maturity:

 None: no enterprise architecture program.
 Initial: informal enterprise architecture process underway.
 Under development: enterprise architecture process under development.
 Defined: defined enterprise architecture including detailed written procedures
and TRM.
 Managed: managed and measured enterprise architecture process.
 Optimizing: continuous improvement of enterprise architecture process.
Comparing TOGAF with Frameworx, Frameworx does not have a specific chapter for
architecture maturity like TOGAF has. Looking into detail, the Frameworx solution
eTOM describes levels of process maturity in the organization. It mentions three
different levels of maturity:
 Process immature : an organization has a very loose set of processes that are
used to control and drive their mission critical operations. These processes
vary widely across different business units, using different approaches and
different terminology to describe the same things. Mission critical processes
often depend on heroes who understand the way things get done to ensure
the smooth operation of the organization. There is generally no end-to-end
process owner for any of the key processes and there are typically loose
hand-off points between the various process stages.
 Process aware : the organization has awareness of the need to manage
processes end-to-end. Processes are typically well documented in a standard
template, although use of terminology varies from process to process. There
may be an organization wide process framework but much of the organization
may be unaware of the existence of this framework.
 Process centric : the organization has a well defined set of operational
processes for all mission critical business areas, each mapped to an
organization wide process framework. Process will be documented to a
common template, using a common dictionary of terminology to describe the
process. Each key process will have an end-to-end process owner or else
clearly defined ownership handover points between process stages with
clearly defined escalation procedures to resolve conflicts. Process
performance will be measured end-to-end and responsibility for process
performance will rest with board level activities.
The following table shows the detailed mapping between the TOGAF Architecture
Maturity Levels and the Frameworx Process Maturity Levels.

TOGAF Architecture Maturity
levels (ACMM)
Frameworx Process Maturity levels
for eTOM
None Not covered.
Initial Process Immature
Under Development Process Aware
Defined Process Centric
Managed (and measured) Process Centric
Optimizing Not covered.
Based on this table, the TOGAF ACMM provides an additional view on this topic and
covers the whole enterprise architecture dimensions (business, information systems
and technology architecture) and not the business architecture like the eTOM
maturity model only.
TOGAF can benefit from Frameworx maturity model on acceptance of workgroup
deliverables. http://www.tmforum.org/MaturityModel/7557/home.html
The TM Forum Maturity Model is a comprehensive program that indicates the
maturity of technical contributions to the TM Forum Collaboration Program. The
Maturity Model enables a broad range of resources, at various levels of maturity, to
be shared across the TM Forum member community. New contributions or artifacts
are typically entered at Level 1 Maturity and progress to the highest level of maturity,
Level 5. Clear criteria are defined for migration from early-stage contributions to
higher levels of maturity.
The Open Group does not apply such a maturity model. The members would benefit
from this classification. The authority of documents or deliverables would be more
transparent to its community users who are not directly involved in its development.
The levels that are distinguished by TMF:
Level 1 Contributed: is submitted to the community but is still in its raw submission
state
Level 2 Artifact that is submitted but is still in its “raw” submission state, but has been
reviewed with the TM Forum.
Level 3 Contribution has been team reviewed. They are subject to change due to
dependencies with other artifacts.

Level 4 TM Forum Package Approved and voted. Artefacts have an establisched
baseline which is TM Forum approved.
Level 5 TM Forum Package Approved and voted. Artefacts have an establisched
baseline which is TM Forum approved.
Something similare might contribute to track the level of authority of workgroup results
within the community.
1.46. Architecture Skills Framework
The architecture skills framework provides a view of the competency levels required
for specific roles within the architecture project. It defines the roles within a working
area, the skills required by roles and the depth of knowledge.
TM Forum can benefit from TOGAF.
Comparing both frameworks, the Frameworx solutions do not explicitly describe the
skills an enterprise needs to implement for these Frameworx solutions. Therefore, it
does not really map to this section of TOGAF.
Nevertheless, Frameworx talks about an “assessment team” which should include:
 Project Manager
 SID Expert
 eTOM Expert
 Integration Framework Expert (not covered at this mapping).
When assembling the team, the project manager is typically appointed first. The
project manager identifies other team members, manages client relationships,
manages and monitors the progress of the project and serves as the facilitator during
client engagements and during the delivery of the final report to the enterprise. The
other roles on the team are optional. Their involvement depends on the Frameworx
artifacts being assessed at the project.
The following table shows the detailed mapping between the TOGAF Architecture
Skills Framework and the Frameworx assessment team.
TOGAF Roles at the Architecture Frameworx roles in the assessment

Skills Framework team
Architecture Board Member Not covered.
Architecture Sponsor Not covered.
Enterprise Architecture Manager
Technology
Not covered.
Enterprise Architecture Data SID Expert
SID Expert
Application
Enterprise Architecture Business eTOM Expert
Program/Project Manager Project Manager
IT Designer Not covered.
Referring to this section, specific skills of the different Frameworx solutions are
needed to run an architecture project based on TOGAF and Frameworx.
TOGAF Architecture Skills Framework provides an additional benefit and input in
regards to:
 How to evaluate and classify the skills and knowledge’s of architecture project
team members.
 What types of skills categories need to be considered by every enterprise
architecture roles.
 What type of proficiency levels should be met by which role and which skills
categories.
 Additional roles are described, such as Architecture Sponsor, and others.
These roles are important for the success of an enterprise architecture
approach and development.
 The templates can be used to define and to describe further roles for the
architecture project.

Since 2007 The Open Group has established a certification program for the IT
Architect. The ITAC certification describes explilcitly what competencies, skills and
experience is expected from an IT architect. Currently the Business Forum of The
Open Group is establishing a certification program for Business Architects. The goal
is to start with this program in Q1 2011.

8. Summary of synergies and complementarities
This chapter provides an overview of the complementarities and synergies between
the Frameworxs assets and TOGAF.
1. Immediate synergies have been identified between the TOGAF ADM Phases
Preliminary, A, B, C and Systems Architecture and Frameworx on the other
hand. This document deals with synergies from phases Preliminary to Phase
C of the TOGAF ADM.
2. The synergies between the Integration Framework and the Systems
Architecture will be dealt with in a separate document.
3. TOGAF provides a transparent Architecture Repository structure – the
enterprise Continuum - that can smoothly accommodate the mapping of TMF
assets; this feature can be leveraged to identify and derive the added value of
the content.
4. TMF assets can be classified as either industry frameworks or Systems
Framework in (TOGAF) Enterprise Continuum language. TOGAF provides a
widely accepted methodology and supporting tools and guidelines to leverage
these frameworks into the development of Enterprise Architectures.
5. Professionals that use TMF assets will find templates and guidelines in
TOGAF that facilitates the transformation of such TMF asset into deliverables
for a specific project/program.
6. The TOGAF Architecture Meta Model provides clearly defined concepts
which have to be developed in order to obtain a consistent and
comprehensive architecture description.
The identified synergies are summarized according to each chapter of this document.
2 Architecture Development Lifecycle
TOGAF and Frameworx Solutions eTOM, SID and TAM have complementarities.
TOGAF Phase Preliminary and Phase A and Frameworx have complementarities.
Both are architecture focused.
TOGAF Phase E – H provides guidelines for the Frameworx Lifecycle. Both are
project / initiative focused.
3.2 Partitioning

TOGAF provides a guideline for partitioning of the enterprise architecture.
Frameworx does not provide partitioning guidelines as regards its frameworks.
3.3 Security
Not dealt with in this document. See also the Jericho Forum for a vision on security.
3.4 SOA context
TMF has defined concepts related to SOA like business service and contracts related
to business service.
SOA has elaborated a complete SOA Reference Architecture providing concepts and
definitions and consistency between them.
This domain will be dealt with in another document of the workgroup
3.5 Principles
TMF has principles defined related to distributed systems architecture.
TOGAF provides template and guidelines how to apply principles.
3.6 stakeholders
TMF identifies stakeholders
TOGAF provides templates for structured stakeholder management
3.7 architectural patterns
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.

3.8 business scenarios
TOGAF provides a technique to apply an solution to one problem, and understand its
implications for decision-making. Method.
Frameworx solutions provide the references to which each scenario can be applied.
Reference content.
3.9 Gap analysis
TOGAF provides a guideline for gap analysis.
Frameworx does not include such a process.
3.10 Migration planning techniques
TOGAF provides various techniques for migration planning.
Frameworx does not include such methodologies.
3.11 Business transformation readiness assessment
TOGAF provides guidelines and techniques.
Frameworx does not have a specific section on this.
3.12 Risk management
3.13 Capability-phased planning

4 Architecture content frameworks
TOGAF contains a content metamodel with concepts and definitions.
Frameworx does not include a content framework. This is a potential for much
synergies because the concepts and artifacts defined enable the identification of gaps
or opportunities for further development and consistency.
5 Enterprise continuum
The enterprise continuum is a valuable tool to map the assets of Frameworx. By
mapping these, the added value of the asset is easily shown and can be
communicated more easily.
6 Technical Reference Models
Frameworx does not include technical reference models
7 Architecture capability
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.
TOGAF provides guidelines for the architecture Board, Compliance, Contract,
Governance, Maturity Model, Skills Framework

Appendix A: Quick Reference Guide TOGAF – Frameworx
The “Quick Reference Guide TOGAF – Frameworx” is an Excel based matrix which provides a very
quick overview about the mapping including the necessary activities and steps what has to be done.
This Quick Reference Guide is most suitable for all readers who want to have an overview about the
content of the mapping document. Furthermore, the readers can use this Quick Reference Guide on
top of this mapping document (word document) as both documents complement each other straight
forward.
The TOGAF 9 chapters including the different steps and sub-chapters represent the basis for the
vertical structure of the document, whereby the usage of the various Frameworx solutions and
TOGAF are shown at the horizontal lane.
At the each chapter or rather step of TOGAF 9 the exact usage of the Frameworx solutions are
described. That includes the detailed usage of the Frameworx solutions’ terminologies as well.
Furthermore, two different types of text bodies help to distinguish between:
- Black text body: consider the Frameworx solutions for usage (exact mapping);
- Red text body: consider the Frameworx solutions for support (supporting function)

Appendix B Process description metamodel
Both static and dynamic processes can be distinguished.
Frameworxs eTOM contains static processes. These are described in a solution
neutral manner. Typically static processes reside in architecture descriptions.
Besides static processes, dynamic processes are recognized. These provide the
process flow of a specific company, and refer to specific solutions. Typically dynamic
processes reside in solution descriptions.
Both TOGAF as well as TMF might include more explicit descriptions to distinguish
between the different levels of abstraction of processes.
The SCOR framework for process abstraction levels is recommended.

Appendix C Glossary, Terms and abbreviations
Abbreviation/ Acronym Abbreviation/ Acronym Spelled
Out
Definition
Frameworx (former NGOSS) New Generation Operations
Systems and Software
NGOSS defines for Service Providers and their
suppliers a comprehensive, integrated
framework for developing, procuring and
deploying operational and business support
systems and software.
TOGAF The Open Group Architecture
Framework
TOGAF is a framework - a detailed method and a
set of supporting tools - for developing
enterprise architecture.
TMF Telemanagement Forum The TM Forum (Forum) is an industry
association focused on transforming business
processes, operations and systems for
managing and monetizing on-line Information,
Communications and Entertainment services.
The Forum has over 650 global members from
across the converging industries of telecom,
cable, media and the Internet.
ADM Architecture Development
Method
A step-by-step approach to developing enterprise
architecture.
eTOM enhanced Telecom Operations
Map
It provide a business process framework for use
by service providers and others within the
telecommunications industry.
TAM Telecoms Application Map It considers the role and the functionality of the
various applications that deliver OSS and BSS
capability.
SID Shared information Data Model It provides the NGOSS information model that
is a representation of business concepts, their
characteristics and relationships, described in
an implementation independent manner.
Integration Framework It defines architectural principles to guide OSS
developers to create OSS components that
operate successfully in a distributed
environment.
IETF Internet Engineering Task Force It is a large open international community of
network designers, operators, vendors, and
researchers concerned with the evolution of the
Internet architecture and the smooth operation
of the Internet.
RFC Request for Comments It contains technical and organizational
documents about the Internet, including the
technical specifications and policy documents

produced by the Internet Engineering Task
Force.

9. Administration of the document
1.47. Document History
1.47.1. Version History
<This section records the changes between this and the previous document version as it is edited
by the team concerned. Note: this is an incremental number which does not have to match the
release number and used for change control purposes only>
Version Number Date Modified Modified by: Description of
changes
0.1 2/12/09 Danny Weinberger
(Architecting-the-Enterprise)
First issue of
document covering
TOGAF 9 version
0.4 01/03/2010 Danny Weinberger
Updates on
Frameworx solutions
0.4.2 04/03/2010 Danny Weinberger
Resetting the structure
and definition of work
packages.
Work on content.
Additional input to
content.
Additional input to
Architecture Capability
Framework, Content
Framework, ADM, etc.
0.6.4 16.04.2010 Danny Weinberger
Additional input to
phase D and
repository, and
changes in xls file.
0.7 03.05.2010 Danny Weinberger
Change to phase 1
document excluding
former TNA mapping.
0.8 17.06.2010 Danny Weinberger
Finalization for internal
review
0.8.2 28.06.2010 Danny Weinberger
First final draft version
as basis for feedback.
0.8.2 Consolidated 2 21.07.2010 Danny Weinberger
Consolidated version
of the comments from
Harry and Alfred

1.47.2. Release History
< This section records the changes between this and the previous Official document release. The
release number is the ‘Marketing’ number which this version of the document is first being
assigned to >
Release Number Date
Modified
Modified by: Description of changes
0.9 27/07/2009 Harry Hendrickx Changes to provide more focus
on synergies than guidance for
usage; several finetuings;
0.9 R. 2 11/08/2010 Alfred Anaya-Dubernard,
Architelco
Proof reading and editorial
corrections across the whole
document
0.9 R. 3 12.08.2010 Harry Hendrickx, HP
Enterprise Services
Proof reading and corrections and
acceptance of agreed changes
1.0 30. 08. 2010 Core team A.o. added: recommendations,
summary of synergies, maturity
model TMF, appendix on process
framework.
Proof reading by participants of
TMF-TOG liaison worki group
1.48. Company Contact Details
Company Team Member Representative
Architecting The Enterprise Name Danny Weinberger
Title
Email
Phone
Fax
Architelco Name Alfred Anaya-Dubernard
Title
Email
Phone
Fax
HP Name Harry Hendrickx
Title Chief Technology Officer /
Gobal Enterprise Architect
Email harry.hendrickx@hp.com
Phone +31627329735
Fax

Glossary, Terms and Abbreviations
1.49. IPR releases and patent disclosures
1.50. Acknowledgements
This document was prepared by the members of the TM Forum TOGAF Frameworx
Collaboration Team:
o Alfred Anaya-Dubernard, UPC Broadband B.V., Team Leader
From The Open Group:
o Harry Hendrickx, HP Enterprise Services, Co-Team Leader
o Danny Weinberger, Architecting the Enterprise, Core Team and main
Report Editor

10. References

Annex Clarification of Information and Data
In order to mitigate the ambiguity, which may arise from this debate, the team looked
at the IETF definitions within RFC 3198 as well as those described within the DEN-ng
as a reference to distinguish Information Model vs. Data Model. The following is an
excerpt from RFC 3198 and DEN-ng.
Information Model:
o Abstraction and representation of entities in a managed environment
 Attributes/Properties, Operations, Relationships
o Characteristics:
 Sector specific
 Independent of any specific implementations (can have many
implementations)
 Protocol neutral (can be mapped to different protocols)
 Repository independent
 Platform independent
 Specificity / detail of abstractions vary based on need
o Described using:
 Informal natural language such as English
 Formal language such as UML
o Useful for:
 Architects to understand business building blocks
 Designers to describe the managed environment
 Operators to understand the modelled objects
 Implementers as a guide to the functionality that can be
described, limited by, and coded in the Data Models
Data Model:
o A mapping of the contents of an information model or concrete representation of
an information model into a form that is specific to a particular type of data store
or repository and access protocol.
o The rendering of an information model according to a specific set of mechanisms
for representing, organizing, storing and handling data. There are 3 parts:

 Collection of data elements such as lists, tables, relations, etc.
 Collection of operations that can be applied to the structures such
as retrieval, update, summation, etc.
 Collection of integrity rules that define the legal states (set of
values) or changes of state (operations on values).
o Concrete details can include, but not limited to:
 Implementation
 Protocol
 Rules how to map managed objects onto protocol constructs
 Assignments, such as OIDs
 Conformance statements
o Intended for Implementers
Figure 51 – DEN-ng Mapping

TOGAF Vs E-Tom

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to TOGAF Vs E-Tom (20)

More from Sandeep Sharma IIMK Smart City,IoT,Bigdata,Cloud,BI,DW (20)

Recently uploaded (20)

TOGAF Vs E-Tom