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 Vs E-Tom

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to TOGAF Vs E-Tom

Similar to TOGAF Vs E-Tom (20)

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

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

Recently uploaded

Recently uploaded (20)

TOGAF Vs E-Tom