ODA Architecture Vision: TM Forum Exploratory Report

TM Forum Exploratory Report
ODA Architecture Vision
IG1166
Release 18.0.0
July 2018
Latest Update: TM Forum Release 18.0.0 Member Evaluation

Version 1.0.1 IPR Mode: RAND
TM Forum 2018. All Rights Reserved.

ODA Architecture Vision R18.0.0
Notice
Copyright © TM Forum 2018. All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative
works that comment on or otherwise explain it or assist in its implementation may be
prepared, copied, published, and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this section are included on all such copies
and derivative works. However, this document itself may not be modified in any way, including
by removing the copyright notice or references to TM FORUM, except as needed for the
purpose of developing any document or deliverable produced by a TM FORUM Collaboration
Project Team (in which case the rules applicable to copyrights, as set forth in the TM FORUM
IPR Policy, must be followed) or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by TM FORUM or
its successors or assigns.
This document and the information contained herein is provided on an “AS IS” basis and TM
FORUM DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Direct inquiries to the TM Forum office:
4 Century Drive, Suite 100

Parsippany, NJ 07054 USA
Tel No. +1 973 944 5100
Fax No. +1 973 944 5110
TM Forum Web Page: www.TM Forum.org
© TM Forum 2018. All Rights Reserved. Page 2 of 51

Table of Contents
Notice 2
Table of Contents 3
1. Executive Summary 6
2. Introduction 8
2.1. Marketplace Drivers for ODA9
2.2. The digital transformation imperative 9
2.3. Platform business models10
2.3.1. Beyond "Pipe business"...........................................................................10
2.3.2. Business Models......................................................................................11
2.4. Technology enablers 11
2.5. The collaboration imperative 12
3. Vision of TM Forum Open Digital Architecture 13
3.1. ODA Business Requirements 13
3.1.1. Lower cost of operation...........................................................................13
3.1.2. Support for flexible business models.......................................................13
3.1.3. Ecosystem-capable..................................................................................13
3.1.4. Business agility.........................................................................................13
3.1.5. Multi-vendor interoperability support.....................................................14
3.1.6. Agile governance.....................................................................................14
3.1.7. Ability to exploit the flexibility of cloud...................................................14
3.2. Architectural approach and design principles 14
3.2.1. (A) Concepts and Principles Work (Guidebook GB998)............................16
3.2.2. (B) Architecture Vision (this document IG1166)......................................17
3.2.3. (C) ODA Agile & Model Driven Requirement Management (Life-cycle
Model & Tools)......................................................................................................18
3.2.4. (D) ODA Business Architecture (including ODA Terminology)..................22
3.2.5. (E) ODA Information Systems and Architecture (ODA-ISA)......................23
3.2.6. (F) ODA Technology Architecture (ODA-TA)............................................25
3.2.7. (G) ODA Solutions Implementation..........................................................28
3.2.8. (H) ODA Deployment & Runtime Capabilities..........................................32

3.3. Key Architecture Viewpoints and personas 33

3.3.1. Business Capabilities and Architecture....................................................34
3.3.2. Information Systems Architecture...........................................................34
3.3.3. Implementation (Solution) & Technical Capabilities and Architecture....35
3.3.4. Deployment and Run-time Capablities and Architecture.........................35
3.3.5. Delivering Business Agility.......................................................................36
3.3.6. Example ODA Lifecycle Agility..................................................................36
4. What ODA can do for you 38
4.1. Internal transformation planning 38
4.2. Roadmap planning 38
4.3. Streamlining procurement 38
5. Next steps 39
6. Appendix A: Foundations of the Open Digital Architecture 40
6.1. Hybrid platform architectures 40
6.1.1. ZOOM HIP................................................................................................40
7. Appendix B: ODA Architecture and Open Group TOGAF 41
8. Appendix C: Requirements Traceability Reference List 44
8.1. Reference list from GB998 and ODA White Paper 44
8.2. ODA Vision Mappings 46
9. Administrative 50
9.1. References 50
9.2. Document History 50
9.2.1. Version History........................................................................................50
9.2.2. Release History........................................................................................50
9.3. Acknowledgments 51

List of Figures
Figure 1: Digital transformation in two dimensions..................................................................10

Figure 2: How collaboration helps transformation in the communications industry................12
Figure 3: TM Forum Open Digital Architecture Artefact Groupings..........................................15
Figure 4: Examples of Information Systems Architecture..........................................................25
Figure 5: Examples of Technical Architecture...........................................................................28
Figure 6: Example Deployment and implementation architecture...........................................32
Figure 7: Key Architecture Views & Related Personas...............................................................33
Figure 8: Organization Capability Life-cycle with TOGAF ADM..................................................36
Figure 9: ODA lifecycle Agility: software factory.......................................................................37
Figure 10: TOGAF ADM artefacts with alignment numbering for mapping to ODA artefacts in
table B1......................................................................................................................................41

Executive Summary
This initial snapshot of the Architecture Vision for realizing the TM Forum Open Digital
Architecture (ODA) is being released to solicit members' feedback.
Open Digital Architecture
ODA offers an industry-agreed blueprint, language and set of key design principles to follow. It
will progressively provide pragmatic pathways for the journey from maintaining monolithic,
legacy software solutions, towards managing nimble, cloud-based capabilities that can be
orchestrated using AI. It is a reference architecture that maps TM Forum’s Open APIs against
technical and business platform functions. [From ODA White Paper Intro page]
Evolving OSS/BSS
ODA is re-imagining OSS and BSS to address the rapidly changing commercial, technical and
regulatory environment for Communication Service Providers (CSP) including Telco, and the
services they offer e.g. 5G, IoT, etc. CSPs in the last decade had enjoyed enviable growth for
more than 20 years. Services that once returned high margins are being reduced to
commodities in the digital world, and our insatiable appetite for data demands continuous
investment in infrastructure. On the other hand, communications service providers (CSPs) and
their partners are in an excellent position to guide and capitalize on the next wave of digital
revolution. [From ODA webpage]
Business managers and architects have expressed concerns about lack of agility in traditional
Business Support Systems and Operational Support Systems practices which are seen as a
stumbling block to enabling new business opportunities in Cloud, 5G, and IoT. The envisioned
future agile enterprise must be digital at its core and possess capabilities that cover both
digital services enablement and digital service provisioning.
ODA Architecture Vision
This Vision Document sets out 8 Architecture Framework groupings that adopt TOGAF (The
Open Group) best practices and is based on an analysis of the ODA business drivers.
For each of the 8 Architecture Framework grouping:
 it defines the required Group of artefacts: architecture processes (inputs, outputs,
transformations), best practice, standards and tools.
 It lists the current ODA documents published in this release, relevant publications from
prior TM Forum work, and provides a first assessment of the future deliverables that need
to be produced to support the ODA Architecture Vision.
Notably, this and other ODA R18 documents show that achieving the goal of business agility:
 needs an automated, zero touch, model driven service lifecycle management approach to
OSS/BSS.
 can leverage prior TM Forum assets as a starting point for ODA. Specifically, prior, relevant
insights and solutions from: Next Generation OSS (NGOSS); Business Service; Business
Contracts; ZOOM OLM work on automated onboarding (commercial, technical,
operational) for software assets.

 needs a set of reusable management components - ODA Component Implementations -

for which prior work on the System Integration Map offers some concrete suggestions.
Many of the key elements that make up ODA have been studied by TM Forum collaborative
projects over the past several years, and significant proven practical assets already exist which
can be used as part of transformation projects. ODA provides a framework which brings
together this diverse range of existing work, from platform business models to management
blueprints for virtualized networks. [From ODA White paper Appendix]
Members are invited to comment and contribute to this vision document as it will be used to
inform the Future ODA work program content and priorities.

1. Introduction
The Open Digital Architecture (ODA) offers an industry-agreed blueprint, language and set of
key design principles to follow. It will provide pragmatic pathways for the journey from
maintaining monolithic, legacy software solutions, towards managing nimble, cloud-based
capabilities that can be orchestrated using AI. It is a reference architecture that maps TM
Forum’s Open APIs and assets against technical and business platform functions.
The ODA Architecture Vision defines, using an analysis of the ODA business drivers:
 The background to why a transformation is needed to the way OSS and BSS are imagined,
to address significant and concurrent business, industry, and technology changes.
 Eight key Architecture Framework artefact groupings that are needed to achieve business
agility and zero touch automated operations which is based on TOGAF(TM) concepts.
 Concepts and Principles and Vision that capture requirements, principles and an evolution
path for the ODA Architecture.
 Methods for Agile Model Driven Management to achieve agile service lifecycle
management.
 ODA Architecture Framework artefacts:
o standards specifications, capabilities based on standards, best practices,
methodologies and tooling that provide the management support needed for a
model driven agile service lifecycle; covering
o Business, Information Systems Architecture, Technical Architecture,
Implementation and Deployment Architectures.
 How to leverage and integrate, existing TM Forum artefacts to provide ODA artefacts and
capabilities for each of the eight ODA Architecture Frameworks.
Examples are shown for some of the Architecture Frameworks based on current ODA team
discussions as these provide pointers to the priorities for future ODA Vision deliverables and
implementation.
Appendices are provided to establish traceability among this IG1166 ODA Vision, GB998 ODA
Concepts and Principles and the ODA White Paper first published in January 2018.
Further work is needed to ensure accurate traceability of requirements established at ODA
workshops and the content of this ODA Vision. A few gaps are identified: for example, Model
Driven Lifecycle Management and AI.
These assets together realize full lifecycle zero touch automation by defining systematic
industrialized repeatable methods that operate at scale and at high velocity.
This document is snapshot of the ODA team discussions. It is subject to change. Specifically,
the proposals for future documents to support the ODA Architecture Vision may be changed,
and their prioritization is subject to the Release 18 onwards charter development and approval
processes.

Note: Some URLs used in this document point to TM Forum Member pages or Collaboration
Team pages and are accessible by logged in members who are registered for the Core Project
Area.
1.1. Marketplace Drivers

for ODA
The business-to-consumer (B2C) world has been transformed by social media and commerce
platforms, enabled by CSPs’ multi-billion-dollar investments in global communication
networks. However, as mobile data has enjoyed a compound annual growth rate of 66 percent
for the last five years, research by Accenture for the World Economic Forum shows that the
share of profits going to the owners and operators of these networks has declined from 60
percent a decade ago to 45 percent today. Ubiquitous connectivity has driven down prices,
eroded profit margins and lengthened the time it takes for new infrastructure to pay back,
which is slowing the innovation cycle.
Nevertheless, the opportunities for digitalization are far from fulfilled, particularly as business-
to-business (B2B) and government organizations seek to digitalize manufacturing, transport,
health and city management. Ericsson and Arthur D. Little estimate the latent value to CSPs at
more than $580 billion by 2026 and $1.2 trillion to the whole digital industry 1. With the correct
strategy, CSPs can continue to be at the center of this worldwide revolution while reaping a
significant share of the returns.
Challenges and opportunities for CSPs
66% growth in mobile data but CSPs’ profits down 15%
Digitalizing transport, health and city = $580 billion opportunity by 2026
Source: Accenture, Ericsson & Arthur D. Little
1.2. The digital

transformation
imperative
TM Forum’s research shows that CSPs are responding to the changing market dynamics in two
ways (see Figure 1 below):
 Digital efficiency – continuously driving to improve the efficiency and scalability of the core
business, from omnichannel customer centricity to automated network operation centers
(something like this)
 Digital enablement – exploring how to enable new digital ecosystems, from
manufacturing, automotive and health to smart cities (something like this)

Figure 1: Digital transformation in two dimensions
The situation presents CSPs with a choice of business strategies:

1. Focus only on existing markets, providing continual improvements in connectivity and
content
2. Establish new entities to innovate in digital enablement
3. Combine both approaches
While all CSPs continue to try to make improvements in their existing businesses, some are
experimenting with enabling new digital ecosystems. Progress has been slower than many
proponents had hoped. However, after several years of development, monetizable lines of
business are beginning to emerge.
For examples of how some CSPs are improving existing lines of business and opening new
ones, see our Case Study Handbook 2017: Digital business – how to make the leap.
1.3. Platform business

models
1.3.1. Beyond "Pipe business"
Traditional competition was built on exclusive access to network-side resources e.g. Mobile,
Fixed, Long-distance cable networks etc. Platform business is built on exclusive access to the
ecosystem around the "platform" and the data about their interactions. Times have proven
now that platforms with the most active ecosystems, and the ability to mine their interaction
data, win.
While traditional competition played zero-sum games, platforms focus on growing the “pie"
with others in the industry and beyond participating on them. Collaboration co-exists with
competition. Today, CSPs don't simply have to worry about competing with Apple or Google,

we must also figure out how to participate in other ecosystems, like Apple’s ecosystem,
Google's ecosystem, Microsoft's ecosystem, other Independent Software vendor ecosystems,
Automobile ecosystems or Network Equipment supplier ecosystems.
As the industry looks beyond the current pipe-like business paradigm, strategic considerations
on recognizing competition (existing and new) and their key sources of competitive advantage
aren’t straightforward anymore and need to be explored, and, in many cases, anticipated and
designed (Case in point: Android repeatedly staved off competition from members of its own
ecosystem, like Samsung and Amazon.).
CSPs must look beyond governance and operating models where they play a fixed role, or
engagements where they have absolute control, to become facilitators of digital economies.
This means a new architecture that can enable CSPs to become platform-centered.
1.3.2. Business Models

Digital ecosystems exploit the principles of platform-based business models, which facilitate
exchanges between consumers and producers. CSPs can benefit from platform business
models in two ways:
1. Monetizing their network and IT assets via a third-party platform using open APIs
2. Operating their own platform and acting as a platform curator
CSPs have several advantages as platform curators. For example, they control the
communications infrastructure which enables parties to connect. They also have large
customer bases, and they own highly developed and secure business support systems. Finally,
they manage customer service and logistics operations to support their existing business which
could be extended to support new business lines.
For more about platform business models, see these publications:
Platforms: How to join the revolution, provides case studies about TM Forum members who
have explored these business models
5G: Is platform the killer use case? includes a survey of executives from CSPs and suppliers
showing how operators are using platform business models
1.4. Technology enablers

Digital ecosystems, as well as traditional communications businesses, will benefit from a move
to a fully cloud-native infrastructure. Modular, cloud-based systems allow rapid innovation and
low-risk experimentation that will help CSPs compete with digital natives.
Virtualization in the data center and the network promises to radically improve agility and
operational efficiency. In 2016 our research found that operators were successfully deploying
network functions virtualization (NFV) for flexibility and agility, but that OSS was not ready to
take advantage of this flexibility.
As the business environment becomes more complex and dynamic, manual systems and
processes increasingly will be unable to cope, and automation will be key. CSPs are beginning
to use simple programmed automation widely, but increasingly they are looking to the
promise of machine learning and AI to take automation to the next level [DM1].

1.5. The collaboration

imperative
A key challenge for CSPs, compared to global digital natives, is fragmentation. CSPs are
competing with companies that have global development scale and can offer a single business
interface worldwide. Regulators usually require multiple CSPs within a market, and even the
largest operator groups do not have global coverage. However, these constraints do not apply
to hyperscale over-the-top (OTT) providers like Google and Amazon, which have built
multinational footprints and accumulated enormous cash reserves.
Collaboration has consistently proved to be CSPs’ best response. By collaborating to develop
common standards, they can leverage development at global scale and offer a business
interface to partners in their own territory, confident that ecosystem partners will find the
same interface from CSPs in other markets. Commonly agreed language and blueprints reduce
the time and cost associated with digital business transformation for CSPs and suppliers alike
(see Figure 2).
Figure 2: How collaboration helps transformation in the communications industry
Ed Note: This diagram would be better with y-axis reversed I.e. Reward pointing upwards.
A collaborative approach to solving industry challenges (for example in TM Forum’s Catalyst

program, or open source projects such as the Open Network Automation Project (ONAP)) can
greatly reduce R&D costs, accelerate innovation and create reusable solutions. Sharing
industry best practice can make transformation more effective for all parties.

2. Vision of TM Forum Open Digital Architecture

With the reasons for a digital transformation now widely understood, the next question is:
‘How to do it?’
TM Forum-led collaboration among chief architects from leading CSPs including AT&T, Bharti
Airtel, BT, Orange, Telefónica and Vodafone has identified common requirements for
reimagined OSS/BSS, which in turn has led to an overall blueprint for transformation called the
Open Digital Architecture.
2.1. ODA Business

Requirements
CSPs have cited several key requirements that are guiding the realization of the Open Digital
Architecture. These requirements include:
2.1.1. Lower cost of operation

Automation, ultimately enabled by AI, is key to success in the complex businesses of the future
because it reduces the cost of operating the network and IT systems and processes. Although
CSPs clearly intend to exploit the power of automation, it will take time.
ODA informs the design choices and architectures members are putting in place today to
support automation in the future.
2.1.2. Support for flexible business models

CSPs are likely to use a wide range of business models until the most successful ones emerge.
Today’s systems are typically designed with assumptions made about business models which
may no longer be valid. This results in constraints, such as the limited operational data shared
with charging systems.
The ODA architecture supports multiple, and evolving, business models with flexible
integration and interoperability facilitated by Open APIs and B2B Ecosystem Management
assets.
2.1.3. Ecosystem-capable
CSPs participate in many ecosystems, so flexibility in engaging with partners is key. The ODA
team is drawing on the work of TM Forum’s Digital Platform Reference Architecture (DPRA)
and B2B2X partnering projects to understand these requirements in detail. A key concept is
‘sideways integration’, referring to creating offers delivered in partnership by multiple service
providers.
ODA is developing standardized patterns for inter-CSP integration, based on existing TM Forum
work, which should reduce the cost and complexity of setting these up, enabling lower-risk
innovation.
2.1.4. Business agility

The ODA Architecture identifies several detailed agility requirements and draws heavily on
many years of work in the TM Forum Zero-touch Orchestration, Operations and Management

(ZOOM) project to develop detailed requirements specifications and implementation assets.

These assets assist the objectives of minimizing the time, cost and risk of launching a new
product or service or bringing onboard a new enabling service.
2.1.5. Multi-vendor interoperability support

For many years CSPs have built IT systems with components from multiple vendors, these
typically have been multiple telecoms vendors. With CSPs now competing on a much larger
stage, the ability to integrate components developed outside telecoms becomes critical. When
a new way of interacting with customers becomes available, (chat-bots, for example) it is no
longer acceptable to wait for the ‘telecoms version’.
With the rise of projects such as ONAP, Open Source MANO (OSM) and Open Baton, any
definition of multi-vendor must also include support of open source software. Many CSPs are
embracing open source in their future IT systems.
TM Forum through pro-active collaboration with key Open Source groups and Standards
Defining Organizations (SDO) incorporates relevant assets into the ODA Architecture.
2.1.6. Agile governance

ODA incorporates governance principles that allow rapid changes to be managed in a complex
environment. Systems and operational teams are likely to be distributed geographically, with a
mixture of centralized and local products and processes.
The ODA governance system and best practice provide teams with the autonomy that they
require to be agile in response to their markets, while maintaining consistency through
centralized oversight.
For example, ODA provides detailed guidance by way of design patterns combined with a
lightweight governance approach to validate boundaries of functionality, naming and version
control, management of the lifecycle of assets, and standard development best practices such
as software development governance on use of "microservices".
2.1.7. Ability to exploit the flexibility of cloud

To realize a system that takes advantage of the power of the cloud requires the ODA to define
correct architecture principles and design approach.
For example, a key benefit of cloud is elastic scaling, but this requires the right design
approach to be of value. Legacy applications ported to a cloud environment rarely support
independent scaling.
2.2. Architectural
approach and design
principles
The ODA Framework defines an approach to decoupling and separation of concerns which is
essential to facilitate rapid independent evolution of solutions, whilst retaining Architectural
cohesion, minimizing the complexity and cost of integration, and achieving implementation
interoperability for e2e services.
The ODA Architecture is captured in eight main artefact groupings which are inspired by
TOGAF Enterprise Architecture best practice. Together these groupings provide a

comprehensive Architecture for complete service lifecycle automation within an enterprise -

such as a Communications Service Provider.
Figure 3: TM Forum Open Digital Architecture Artefact Groupings
Each of the core ODA Framework artefact groupings provide capabilities to support the
responsibilities of different ODA Architecture users/stakeholders. These capabilities cover key
aspects of the TOGAF Architecture Development Methodology (ADM) described in Appendix B.
Together the ODA Framework artefact groupings deliver agility in managing the zero-touch
automation of a service lifecycle - which is a key ODA requirement.
The architectural approach to realizing the ODA is achieved through ODA requirements
management creating the following ODA Architecture artefact groupings:
 (A) ODA Concepts and Principles - documents the architecture principles, concepts and
the requirements that each Architecture Framework grouping must fulfill.
 (B) ODA Architecture Vision Document – this document - defines the 8 ODA Architecture
Framework groupings, provides a definition of the artefacts required in each, such as:
specifications, capabilities, best practices including architecture methods/methodologies
and metrics, code and tooling.
The ODA capabilities to achieve service lifecycle agility are captured in the following artefact
groupings:
 (C) Agile and model driven Management defines the requirements, modelling and tooling
approach for ODA lifecycle which is the key to accomplishing business agility. The
methods/methodologies, metrics and tooling described here will be used to manage
requirements across all these artefacts to address different stakeholders' needs.
 (D) ODA Business Architecture, that will describe product and/or service strategy, the
organizational, functional, process, information, and geographic aspects of the business
environment, based on the business principles, business goals, and strategic drivers
(Including common vocabulary, ODA Terminology etc. - Including TMF071 ODA
Terminology R18.0.0 , etc.)

 (E) ODA Information Systems Architecture (ISA), which must provide the Functional
Architecture (IG1167 ODA Functional Architecture R18.0.0) and concepts of Data and
Applications Architecture.
 (F) ODA Technology Architecture, an architecture that will form the basis of
implementation work. The main concept being the definition of the ODA Component for
reuse and simple integration. As part of these artefacts, ODA will consider what relevant
Technology Architecture resources are available (e.g. Linux Foundation ONAP, Linux
Foundation Acumos, ETSI ENI, ETSI ZSM, etc. 3GPP 5G technical standards etc.)
 (G) ODA Solution Implementation artefacts, that will provide mechanisms to evaluate and
select among the implementation scenarios, best practices (for example, build versus buy
versus re-use options, and sub-options within those major options), and outline of the
strategic parameters for change (environment assessment, risk management etc.). The
view should also include implementation and migration best practices as well as
governance models to enable implementation planning. (It will include the concepts of
componentization, IG1171 ODA Component Definition R18.0.0)
 (H) ODA Deployment and Run-time Models will establish an architecture change
management process for the ODA architecture deployment and runtime baseline. It will
include a framework for continual monitoring of developments in technology and changes
in the business environment. It will outline best practices for deployment and run-time
operations and mechanisms to feedback into ODA evolution.
Each of these artefact groupings are described in the following sections and are based on the
evolution of current TM Forum artefacts including Frameworx. The notion is that each
grouping defines a set of reusable capabilities that allow lifecycle management automation
across 4 capability viewpoints - Business Capability, Information Systems, Technology
Capabilities and Implementation Capabilities, and Deployment & Runtime Capabilities. It is
based on prior TM Forum work on model driven service lifecycle management - TMF053
NGOSS Technology Neutral Architecture (TNA) Suite Release 6.3. Each view in the lifecycle
management will contain different types of artefacts, capabilities and processes that are used
by different groups of stakeholders and personas.
In each artefact grouping there are currently varying levels of maturity and completeness with
the Information Systems and Technical Architectures having the greatest maturity arising from
use of Frameworx artefacts.
2.2.1. (A) Concepts and Principles Work (Guidebook GB998)
Defines the architecture principles that will inform the constraints on any architecture work. It
will include the scope and assumptions (particularly for a common architecture view) and
define the framework and detailed methodologies that are going to be used to develop ODA. It
will set up and monitor a process (normally including a pilot project) to confirm the fitness-for-
purpose of the defined principles.
It includes:
 the scope and assumptions (particularly for a common architecture view) and defines the
framework and detailed methodologies that are going to be used to develop ODA.
(typically, the TOGAF and the Architecture Development Methodology has been adopted
as the framework and methodology).

 It will set up and monitor a process (normally including a pilot project) to confirm the
fitness-for-purpose of the defined principles.
 As part of the evolution of the Concepts & Principles work, it will define a set of criteria for
evaluating architecture tools (Artefact group C), repositories, and repository management
processes to be used to capture, publish, and maintain architecture artefacts.
Artefacts
Status Reference Addresses ODA White

Paper Requirements
Current GB998 Open Digital Architecture (ODA) Concepts  Business agility
baseline & Principles R18.0.0  Lower cost of
operation
 Support for flexible
business models
 Ecosystem-capable
 Multi-vendor
support
 Agile governance
 Ability to exploit
the flexibility of
cloud
Future ODA Requirements document (formal RFC 2119

style requirements) extracted and agreed from
ODA White Paper
(team draft published as ODA-42 ODA
Requirements synthesized from ODA White
Paper )
Future GB998 enhancements to include formal mapping
between GB998, ODA White Paper and ODA
Requirements (Traceability requirement)
2.2.2. (B) Architecture Vision (this document IG1166)
 Records the vision for evolving the ODA initiative by capturing current baseline artifacts,
relevant prior publications and proposing future artefacts to realize the ODA
requirements.
This ODA Architecture Vision Document ensures that:

 the evolution of the ODA development cycle has proper recognition and endorsement
from membership, and
 the support and commitment of the Collaboration Steering Committee of the TM Forum.
It will also:
 validate that the business principles, business goals, and strategic business drivers of the
ODA Initiative have been captured within the developed artefacts.
 enable the scoping, and prioritization of the Baseline ODA Architecture effort.
 identify the architecture artefacts (static items) and how these are used to achieve agility
through model driven approach (dynamic usage) that will realize the vision and
requirements of automated service lifecycles.
Artefacts
Status Reference Addresses ODA White Paper

Requirements+
(bold primary support - see
Appendix B and C)
Current IG1166 ODA Architecture Vision R18.0.0  Business agility
baseline  Lower cost of operation
business models
 Multi-vendor support
 Ability to exploit the
flexibility of cloud
Future Update to IG1166 based on detailed work

on other architectural assets (D) through
(H)
+ This needs to be extended to cover traceability to GB998 Open Digital Architecture (ODA)
Concepts & Principles
2.2.3. (C) ODA Agile & Model Driven Requirement Management (Life-cycle Model &
Tools)
An agile and model driven requirements, tooling and implementation approach for ODA
Service Lifecycle is the key to accomplishing business agility.

This ODA Framework grouping delivers business agility by industrializing and automating
change, especially that needed to create and modify services.
It extends the TOGAF Architecture Development Methodology (ADM) concepts of
requirements management throughout the service lifecycle. It documents Life-cycle models,
methodologies and tools, TM Forum ODA Architecture Governance Board, and "How to’s"
that:
 Baselines common and unique requirements – business, operations and technical -
by formally capturing single purpose requirements from this IG1166 ODA Architecture
Vision and the IG1167 ODA Concepts and Principles documents.
 Manages the lifecycle of requirements across all ODA Architecture Framework groupings
and ensures alignment to principles (with prioritization and impact assessment)
 Defines an agile Model Driven implementation approach which supports models for each
of the lifecycle viewpoints described later, their transformation methodologies and tools
to move from one viewpoint to another.
The tooling described here will be used to manage requirements across all the ODA artefacts
used to address different stakeholders and implementations to automate and accelerate the
service lifecycle.
Early results arising from ZOOM OLM catalyst work on software asset onboarding have shown
that this is a critical and challenging area to address.
Artefacts
Status Reference Addresses ODA

White Paper
Requirements
(bold primary
support - see
Appendix C)
Current baseline TMF053 NGOSS Technology Neutral Architecture  Business
for enhancement (TNA) Suite Release 6.3 agility
Describes, in TMF053, the implementation of a
 Lower cost of
model driven service lifecycle approach based on
operation
notion of NGOSS Contract and Components and
provides the metamodel TMF053D that  Support for
underpins automated tooling to run an flexible
automated service lifecycle (does have some business
gaps as described below). models
Only industry document addressing the  Ecosystem-
complete Business through to Deployment capable
lifecycle.  Multi-vendor
Proposed in ODA-6 ODA from the Lens of support
operators  Agile
governance
 Ability to
exploit the

flexibility of
cloud
Relevant GB945 Frameworx Solution Methodology Release  Support for

Publication 12.0 GB945M flexible
describes an implementation methodology for business
Frameworx models
 Ecosystem-
capable
Relevant GB942CP Business Services Concepts and

Publication Principles V3.2
further evolution of NGOSS Contract concept and
aligned with GB945
Relevant Product Lifecycle Management Introductory
Publication Guide V1.1
Relevant IG1129 Product Lifecycle Management:
Publication Comparison of Traditional and Virtualized PLM
R15.0.0
Relevant  Business
Publication/Tool Curate FX agility
Tool of choice for Business Architecture and  Lower cost of

Information Systems Architecture. operation
 Support for
flexible
business
models
Future Need a set of artefacts to support model driven

automated service lifecycle management
comprising:
 Metadata driven description of software
assets that are composed and orchestrated to
provide management of a service. Based on
evolution of:
o Concepts described TR269 Onboarding
Automation and Package Metadata
R17.0.1
o IG1141 Procurement and Onboarding

Suite R17.5.1 (also part A) proposes a

model-driven approach to streamline
general software onboarding
processes with special focuses on
onboarding automation of Virtual
Network Functions (VNF). ....
standards-based model-driven
approach is essential to scale with the
growing demand for interoperability
and to evolve as technology
advancement and innovation happens.
o Extensions to OASIS TOSCA Simple

Profile to support metadata extensions
for composition and orchestration of
components to cover commercial and
operations as well as technical
metadata.
 Tool chain requirements and specification:
o Requirements based on evolution
TR144 Tooling Environment
Requirements and Description
Its structure sets out the scope of the
tooling needed for automated service
lifecycle management
- Needs review and update to support
ODA.
- Need to move current focus from
creating software to creating
configuration data and alignment with
commercial virtualization and cloud
native tooling approaches.
o Formal metamodel for tooling chain

covering: contracts / business services,
components, Open APIs based on
converging:
o
 TMF053D NGOSS Technology
Neutral Architecture:
Metamodel V1.1

o
 GB986 Frameworx Metamodels
Concepts and Principles 1.0.3
o
 and evolving to meet new ODA
requirement around
virtualization and cloud native.
Future Curate FX enhancements to provide outputs /
requirements into the ODA Information System
Architecture. as a part of an ODA tool chain
2.2.4. (D) ODA Business Architecture (including ODA Terminology)

Describes product and/or service strategy, the organizational, functional, process, information,
and geographic aspects of the business environment, based on the business principles,
business goals, and strategic drivers (including common vocabulary as documented in TMF071
ODA Terminology)
 Identifies the Enterprise Organization for a Digital Service Provider/Digital Service Enabler
 Elaborates the Enterprise Functions and management models
 Identifies and establishes common vocabulary (TMF 071 ODA Terminology). Note:
Progressively all the detailed artefacts and capabilities will be aligned with these
definitions.
 Provides Capability maps, process models along with value maps of digital business
ecosystem stakeholders.

Artefacts

White Paper
Requirements
(bold primary
support - see
Appendix C)
Current TMF071 ODA Terminology R18.0.0 Lower cost of
baseline operation
 Support for
flexible business
models
 Ecosystem-
capable
Relevant Curate FX  Business agility

Publication Provides tool support for Business Architecture  Agile governance
modeling.
Current proposal is to provide read-only access to
the Curate FX ODA project with 2 modules
including:
 DPRA - ODA - TAM - API mapping
 ODA - eTOM - SID - API mapping
Future Incorporation of Curate FX best practice into the  Business agility

Business Architecture artefacts and describing  Agile governance
how it is used to provide outputs / requirements
into the ODA Information System Architecture.
2.2.5. (E) ODA Information Systems and Architecture (ODA-ISA)

Information Systems Architecture (ISA), will include a Functional Architecture (IG1167 ODA
Functional Architecture R18.0.0), and concepts and artefacts for Data and Applications
Architectures.
It includes - Documents, IS Architecture diagrams, Models, Guidebook(s) covering:
 Functional Architecture.
 Data Architecture (models, flows etc., Application-data matrix, security, migration,
lifecycle.

 Service Portfolio, interface catalogs, Applications-organization matrix, roles-application

matrix, application interaction matrix, etc.
 Data & Applications Model.
Several ODA Vision requirements have been identified that are recorded below, noting that in
TOGAF Data and Application Architecture are considered part of the Information Systems
Architecture.
Artefacts

White Paper
Requirements
(bold primary
support - see
Appendix C)
Current IG1167 ODA Functional Architecture R18.0.0  Business agility
baseline  Lower cost of
operation
 Support for
flexible business
models
 Ecosystem-
capable
 Multi-vendor
support
the flexibility of
cloud
Relevant GB921 Business Process Framework (eTOM) Suite  Support for

Publications Release 17.5.0 flexible business
models
GB922 Information Framework R17.5.1
 Ecosystem-
Used to confirm mapping to ODA Functional
capable
Architecture.
 Multi-vendor
support
Future IG1167 ODA Functional Architecture. Populate

missing 'Decoupling and Integration' Functions by
mapping to GB929 Application Framework (TAM)
Suite R17.5.1 and other sources.

Example ODA Information System Architecture mapping to Frameworx
Figure 4: Examples of Information Systems Architecture
ODA Functional Architecture will provide a set of structured and simplified implementation
independent views for Information Systems Architecture stakeholders. These Functional views
enforce decoupling whilst enabling integration and are based on explicit mappings to
Frameworx comprising: Business Process Framework (eTOM GB921), Information Framework
(SID GB922) and The Application Framework (TAM GB989).
These are highly mature Frameworks but need to have simple views that can be used in the
definition of ODA Component specifications that are reusable and configurable for many
business contexts. These ODA Component specifications define ODA Components' realizations
which are part of the Solution Implementation viewpoint.
2.2.6. (F) ODA Technology Architecture (ODA-TA)

This forms the basis of implementation work. It evaluates what relevant Technology
Architecture resources are available (e.g. TM Forum Open APIs, Linux Foundation ONAP, Linux
Foundation Acumos, ETSI ENI, ETSI ZSM, 3GPP 5G technical standards etc.) and makes best
practice recommendations on their use.
Specific artefacts are Technology Architecture diagrams, Models Guide book(s) covering:
 Reference Tech standards & portfolio catalog(s).
 Application-Technology matrix for different environments, location, platform specific and
engineering concerns.
 Integrate related SDOs engineering work – MEF, ONAP, Decomposition.
 Baseline architecture description.
 ODA Componentization design - IG 1171 ODA Component Definition.
 ODA Open API mapping to functionalities and ODA Components.

Artefacts

Paper Requirements
(bold primary support
- see Appendix C)
Current IG1171 ODA Component Definition R18.0.0
baseline Defines Modularity concept and structure and  Lower cost of
imposes technical constraints on ODA operation
implementations to achieve manageable
composition and use across multiple Run-time
business models
environments.
 Multi-vendor
support
the flexibility of
cloud
 Componentization
and modularity
 Microservices
 API-based
architecture
 Component models
 Dynamic
integration
Relevant IG1117 OSS / BSS Futures Overview R14.5.1  Business agility

Publication
and modularity
Relevant IG1118 OSS / BSS Futures: Preparing the Future  Business agility
Publication Mode of Operation R14.5.1
and modularity
 API-based
architecture
 Dynamic
integration

Relevant TR263D Platform Security and Policy  Security by design

Publication Management R17.0.1
Uses notion of Software Defined Perimeters,
security domains and applies to Management
Platform - a concept related to ODA components.
Relevant NGOSS Contract Scope and Granularity  Microservices
Publication Guideline1.doc (Frameworx Project Area)
 API-based
architecture
Relevant NGOSS  Microservices

Publication Contract_Lessons_Learned_20010627.doc
 API-based
(Frameworx Project Area)
architecture
Future See also Solutions Implementation (since

technical architecture and solution
implementations are coupled
Future ODA Component Security and Privacy by design  Security by design
model and APIs requirements.
 Privacy by design
Use TR263D as starting point for creating ODA
Component examples as well as current
Management Platforms
Future ODA Componentization design: Produce  Component models
normative ODA Component Specification
template (for Solution Implementation)
Future Address Common Data architecture  Common Data
enhancements to IG1167 Architecture
Examples of Technical Architecture Concepts
The benefit of a standard Component Model is that it makes management and composition of
functions easier and lowers the complexity of integrating multiple components together from
different sources.

Figure 5: Examples of Technical Architecture
Shown above are several TM Forum Component model concepts that have been proposed:
 Management Platform model which is about deployment governance boundaries and
 the IG1118 Component Model which are software function composition boundaries.
 the ODA proposal for ODA Components described in the implementation section which
can be used in conjunction with the Management Platform concept.
All require Open APIs to support simultaneously diverse stakeholder requirements.
2.2.7. (G) ODA Solutions Implementation

These are a set of IGs & TRs covering:
 Constraints for implementation,
 Gap analysis template for implementation,
 Interoperability requirements and dependencies,
 Risk management traps & best practices,
 Migration strategies,
 Sample Architecture migration roadmaps & implementation migration plans.
In this viewpoint there are several IT run time technologies that need to be considered for the
deployment view:
 Virtual machines,
 Bare metal,
 Containers,
The challenge in creating ODA Solution Implementations is to provide reusable and agile
means of using a diverse set of IT driven technologies, many of which are decisively moving to
cloud native thinking.

This is primarily about taking Technology Architecture guidance - especially ODA Components
specification templates - to generate specific implementations of ODA Components and
deployment configurations that make the implementation of selected ODA Components
collectively perform the required business purposes.
A further challenge is that components can be implemented using different software
technologies and deployed across multiple run time environments, so the solution
implementation artefacts have to support plural approaches.
Artefacts

Paper Requirements
(bold primary support -
see Appendix C)
Current IG1171 ODA Component Definition R18.0.0
baseline Describes modularity and componentization  Lower cost of
concept and structure - Sets an ODA operation
technical constraint on ODA Solution  Support for flexible
Implementations. business models
Does define specific ODA Component  Ecosystem-capable
Specifications or implementations and how
they are mapped to common run time and  Multi-vendor support
deployment environments.  Ability to exploit the
and modularity
 Microservices
 API-based
architecture
 Dynamic integration
Current Open APIs  Microservices

baseline  Open API Table  API-based
architecture
 TMF630 API Design Guidelines 3.0
R17.5.1  Dynamic integration
Relevant GB914 4-5-00.doc GB914 System Integration  Componentization

Publication Map Deliverable 1: Concepts and Principles

Describes structure /taxonomy and and modularity

organization of components in GB915.
Relevant GB915 System Integration Map Deliverable 2:  Componentization

Publication The Component Descriptions and modularity
GB915-6.doc (Frameworks project area)
Definition of Component types which may be
candidates for ODA Component Types
Relevant TR262 Management Platform Blueprint and  Componentization
Publication Application to Hybrid Infrastructure R17.5.1 and modularity
Describes how to create operational  API-based
Management Platform that may be architecture
constructed from ODA Components or legacy  Dynamic integration
applications.
 Security by design
Future ODA Component Implementation Library - a  Componentization
set of reusable business components that and modularity
implement the functionality in IG1167 ODA
Functional Architecture
(Consider using GB915-6 GB915 System
Integration Map Deliverable 2: The
Component Descriptions)
Future ODA Reference Implementations with focus  API-based
on ODA Component Implementations(code), architecture
security and privacy  Security by design
 Privacy by design
Future Microservice guidelines based on API team
drafts
Future Guidelines for dimensioning capacity and  real time
scaling
Component models
Component model concepts were initially developed in the TR274 Digital Service Reference
Architecture Guide and then refined in IG1118 OSS/BSS Futures – Architecture R15.5.1 for
application in the BSS/OSS space.
The models are based on defining modular boundaries for implementations that define
Microservices based capabilities supporting: exposed application, operations/management,
security/privacy, and also the capabilities on which they depend. They define the fine grain
software engineering specification boundaries.

ODA Components
The ODA Component model evolves these concepts to support real time, dynamic integration
and common data architecture functionality, where the capabilities can be realized in solutions
using TM Forum Open APIs.
ODA Component specifications are also defined which realize standard mapping from the ODA
Functional Architecture specifying the implementation of re-useable and individually
deployable software components (fine grained). Support for the management of composition
also permits implementation of coarse-grained components. These ODA component
realizations can be dynamically integrated by configuration in the chosen run time
environment.
Management Platforms
Management platform concepts provide a means for defining the operational and governance
boundaries (coarse grained) for operationally deploying groups of ODA Components.
Management Platforms formally scope governance of policies, security, change management
and runtime configurations and other operational matters. (Note the granularity of Platform
and components can be different, or in some case may be the same: ODA Components are
about Software component boundaries whereas Management Platforms 1 are about defining
operational boundaries).
Examples of Solutions: Reference Implementations, Deployment and Run-time architectures
Figure 6: Example Deployment and implementation architecture

Implementation of the Business and Technical architecture can be done in multiple ways, often
conditioned by the current deployed solutions. Examples of implementation are reported in
CSP architectures: e.g. AT&T (ONAP/ECOMP), BT Matrix, Vodafone (Ocean) Orange and
Telefonica.
ODA Workshops recommended a reference design which captures the common elements of
these CSP architectures. The ODA Reference Design is used to validate Business and Technical
1
A Management Platform is technically a type of Domain with additional constraints e.g. Non-
overlapping

Architecture in a model driven agile lifecycle. It takes ODA Components (each realizing a
specific collection of ODA Functional Architecture specifications) and configures them in a
specific way capturing: composition, concatenation and dependencies between ODA
components.
Since ODA Components are realized by TM Forum Open APIs, a typical deployment will use a
flat deployment architecture for those components. The ODA Deployment / Run Time design is
based on the use of an API Gateway which flattens the assumed hierarchical relationships in
the ODA Reference Implementation Design.
2.2.8. (H) ODA Deployment & Runtime Capabilities

These are a set of IG’s & TR’s covering:
 Constraints for Deployment and Operations.
 Environment readiness templates.
 Management and Operations best practices.
 Governance and Security Management.
In this viewpoint there are several Operating models that must address implemented ODA
instances, Including:
 Classic operations.
 Hybrid operations.
 etc.
Artefacts

Paper Requirements
(bold primary support - see
Appendix C)
Current None Identified
baseline
Future Assumed that ODA will identify a set of  Microservices
preferred run-time platforms such as:  API-based architecture
 IBM Bluemix  Dynamic integration
 Kubernetes  Real time
 Microsoft Azure
 Open stack
Future Run-time operational guidelines? Maybe  real time
point at Cloud Native Computing Forum?

2.3. Key Architecture

Viewpoints and personas
Figure 7: Key Architecture Views & Related Personas
A challenge for the Open Digital Architecture is that it addresses the concerns of many
stakeholder personas each with their own requirements.
ODA in delivering business agility provides a consistent, reusable way of capturing those
requirements as appropriate capability specifications, such that the specifications generated in
one viewpoint becomes the requirements in the next lifecycle stage i.e. Lifecycle viewpoints
are formally linked thus enabling business agility and lifecycle automation.
Four viewpoints are identified that address ten TM Forum defined personas:
 CCO: Chief Commercial Officer
 COO: Chief Operating Officer
 CMO: Chief Marketing Officer
 CTIO: Chief Technology & Information Officer
 DST: Director of Strategy & Tech Innovation
 HCM: Head, Change Management
 EA: Enterprise Architect
 SD: Senior Developer
 EI: Ecosystem Innovator
 PM: Product Manager
 ND: Telstra proposed the addition of Network designer for Domains and Technology

The four viewpoints are based on the five lifecycle-related ODA Vision architecture viewpoints
in which Technical and Implementation Architecture are combined for simplification for a large
common set of stakeholders, and for simple alignment with prior conceptual work on NGOSS.
The following sections document, for each of the four ODA Framework quadrants, the involved
stakeholders, the artefacts and capabilities that are defined and recorded in catalogs,
mappings captured in Matrices, and the type of diagrams that are created and maintained
along with Case examples (terms based on TOGAF).
The RACI roles for the stakeholders and the concrete artefacts and capabilities should be
developed based on service lifecycle examples derived from practical analysis experiences such
as 5G.
2.3.1. Business Capabilities and Architecture

Addresses: CCO, COO, CTIO, CMO, DST, HCM, EI, EA, PM
OUTPUTS:
CATALOGS: Biz models, Org/Actor, Driver/Goal/ Objective, Roles, Business Service/Functions,
Process/Event/Products
MATRICES: Business Interaction, Stakeholder + Actor /Role matrix
CORE DIAGRAMS: Business Service/Information, Functional org. decomposition, Product life-
cycle, Value maps, solution concept, Organization diagrams, Functional decomposition
diagrams
CASE-BASED DIAGRAMS: Process flow, event, Organization decomposition, Business user
stories and use-case
2.3.2. Information Systems Architecture

Addresses: CTIO, HCM, EI, EA, PM, SD
OUTPUTS:
CATALOGS: Components, Data Entities, Application Portfolio, Interfaces, Tech Standards, Tech
Portfolio catalog
MATRICES Data Entity/Biz Function, Data/App, App/Org, Role/App, App/Function, App
Interaction, App/Tech
COMMON DIAGRAMS: Functional software diagram, Component architecture, Conceptual and
Logical Data architecture & Models, App interaction, platforms, platform decomposition
CASE-BASED DIAGRAMS: Data Security, Data Migration, Data Lifecycle, Enterprise
management, Proc/App realization, HL Software Engineering, App Migration strategies, App
packaging and distribution
2.3.3. Implementation (Solution) & Technical Capabilities and Architecture

Addresses: CTIO, HCM, DST, CMO, DST, PM, EA, EI
OUTPUTS:
CATALOGS: Case-based Solution blueprints, functional
MATRICES: Problem/Solution, Opportunity/Solution
COMMONDIAGRAMS: SDLC, Integration diagrams, Solution Blueprint/Roadmaps
CASE-BASED DIAGRAMS: Integration diagrams, Solution Blueprints/Roadmaps

2.3.4. Deployment and Run-time Capabilities and Architecture

aka BUSINESS & IT OPERATING MODELS
Addresses: CTIO, COO, DST, CMO
OUTPUTS:
CATALOGS: Responsibilities, Services, Products, Resources
MATRICES: RACI, Service-Responsibility matrix, Service-Production matrices, Resource-
Production matrices etc.
COMMON DIAGRAMS: Operating Model, Service Management, Party-type Management etc.
CASE-BASED DIAGRAMS: Resource-modelling, Testing, etc.
2.3.5. Delivering Business Agility
Figure 8: Organization Capability Life-cycle with TOGAF ADM
Agile and Model Driven Requirements management-- shown in the center - drives the
evolution of capabilities in all four viewpoints of a Service Lifecycle, each of which supports
defined stakeholder persona roles supported by specific ODA Framework artefacts and
capabilities, as described earlier.
Within each ODA viewpoint the architecture capabilities are reusable across multiple services;
and for the implementation, Deployment and Runtime capabilities they are reusable across
multiple tenants (customer service instances).
Each ODA viewpoint is scoped by contexts and constraints as shown and are supported by the
ODA architecture capabilities shown in grey circles.
2.3.6. Example ODA Lifecycle Agility

The ODA Lifecycle is related to the concept of software factories, and structured use of current
TM Forum assets.

This need is explicitly identified in the ODA White Paper in the requirements Section 3.2.8:
Separation of design time and run time (“nonstop” principle).
Figure 9: ODA lifecycle Agility: software factory
This example representation of ODA Lifecycle agility shows that different lifecycle stages are
focused on separation of concerns between logical and physical viewpoints and between the
service provider viewpoints and the developer viewpoints.
All are evolved using requirements management, architectural principles, and methodologies.
Examples of different types of ODA artefacts/ capabilities are shown in each quadrant. For
example:
 In the ISA Quadrant: the ODA Functional Architecture and Frameworx capabilities
 In the Implementation Quadrant: Management Platforms, Open APIs ODA Components
and an ODA implementation (reference model) example from the original ODA White
Paper.
Noting that there will be multiple concurrent implementation choices.
Also shown are some of the current tools that are used to develop those Capabilities, whose
outputs are used as inputs to the next stage of the lifecycle –thus using a model driven
approach.
The notion of Software Factories has grown recently in popularity, notability in the ONAP
example of a Service Design Center (SDC) and a Run Time. The SDC is a software factory that
designs a service by taking the IST capabilities and forms them into an implementation
(comprising code and configuration files in e.g. TOSCA). These are passed to the Run time
environment. The run time takes the code and uses the configuration files (e.g. TOSCA CSAR)
to instantiate running instances of the code configured to deliver the designed service.

3. What ODA can do for you

Many of the concepts in the ODA are in use in the industry today in a fragmented way, but
ODA brings them together in a standardized form. Although CSPs could execute a digital
transformation by themselves, vendors would be faced with adapting their products to a
widely varying set of requirements. Standardization creates a marketplace for common
solutions to common problems, including open source solutions that can interwork with
commercial offers.
This approach increases the possibility of managing digital ecosystems across borders, at scale.
For example, global vehicle manufacturers will be able to reach agreement with multiple CSPs
about their requirements for autonomous and connected vehicle protocols.
ODA also embraces key requirements and concepts for the future that may not be considered
in standalone projects, such as being AI capable, having a unified architecture for BSS and OSS,
and a unified data-centric approach.
CSPs and suppliers alike are already finding ways to use ODA:
3.1. Internal
transformation planning
As CSPs embark on internal IT transformation projects, ODA acts as a key resource to inform
and guide the future architecture. Although many operators are already on a transformation
journey, ODA provides a holistic best practice view that can identify additional areas for
consideration and guide towards more specific design and implementation assets in TM
Forum’s Toolkits.
3.2. Roadmap planning

ODA began as a set of common requirements from leading CSPs and vendors, who already use
this early work to prioritize their product roadmaps and are collaborating to develop future
deliverables to ensure their next generation of products are adapted to their customers’
common needs. Today, many CSPs map the TM Forum Open API suite to each of the business
projects captured in the organizational roadmap. This approach is allowing transformation
towards the new vision of a flexible API-enabled architecture.
In the individual ODA architecture artefact grouping described earlier there is a view of the
current baseline, relevant publications, and future candidate artefacts.
3.3. Streamlining
procurement
Creating and responding to RFIs and RFPs can be a time-consuming process. Both CSPs and
suppliers are using the ODA deliverables firstly as a common language to describe functionality
of interest and secondly as a set of best practice principles and requirements.


4. Next steps
For more information visit our web resources at:
Open Digital Architecture and the ODA White Paper

5. Appendix A: Foundations of the Open Digital

Architecture
Many of the key elements that make up ODA have been studied by TM Forum collaborative
projects over the past several years, and significant proven practical assets already exist which
can be used as part of transformation projects. ODA provides a framework which brings
together this diverse range of existing work, from platform business models to management
blueprints for virtualized networks.
5.1. Hybrid platform

architectures
The ZOOM project has produced a number of significant deliverables that help operators adapt
their systems to effectively manage virtualized infrastructure and begin the transformation to
more agile business. These can be found in the Agile Operations and Agile OSS Toolkits.
Throughout this project the focus has remained firmly on hybrid architectures made up of
physical and virtual components. Where other initiatives focused on the new virtualized
infrastructure in isolation, the ZOOM project recognizes that operators will need to
successfully manage both new and legacy networks, for many years to come.
5.1.1. ZOOM HIP

In 2017 the ZOOM project brought many elements together to publish a complete
implementation blueprint for managing hybrid infrastructure. This blueprint includes practical
design and implementation assets such as information models and APIs to realize a complete
hybrid management platform that supports automation. Support for automation is key to
unlocking the business potential of NFV, and this was demonstrated by several vendors in the
5G service operations Catalyst project at TM Forum Live! 2017.

6. Appendix B: ODA Architecture and Open Group

TOGAF
The ODA Framework also leverages concepts from the Open Group TOGAF Architectural
Development Methodology (Fig B1) which defines the best practice for Enterprise
Architecture. In combination with the model driven Service Lifecycle automation which is part
of the Next Generation OSS (NGOSS) specifications in TMF053, eight key artefacts are
distributed over the four lifecycle views in Fig 3.6 in order to serve the needs of the relevant
personas and provide an integrated view that will support realizing the vision.
Figure 10: TOGAF ADM artefacts with alignment numbering for mapping to ODA artefacts in table B1
The TOGAF Architecture Development Methodology (ADM) describes a requirements

management process for the complete lifecycle of services, their implementation and
deployment. ADM is divided into a number of Phases each addressing specific requirements
and stakeholder needs shown in Fig 10. The ODA Framework mapping to TOGAF ADM
supports specific stakeholder groupings that are coarser grained than TOGAF to support an
agile service lifecycle described in this document.

Key mappings between TOGAF concepts and the ODA architecture structure are captured in
Table B1 below:
Table B 1. Key Mappings Between TOGAF Concepts and ODA Architecture Structure
Alignment TOGAF ADM ODA Artefacts in this Key Comments

Numbering View release 18.0 Stakeholder
1 Preliminary  GB998 Open Digital  Concepts and
(Concepts & Architecture (ODA) Principles
Principles) Concepts & released in R18
Principles R18.0.0  Metrics to
measure
conformance to
principles - TBD
2 Architecture  IG1166 Open Initial Draft

Vision Digital Architecture
Vision R18.0.0
3 Requirements  TBD TBD

Management
4 Business  Ecosystem Business Initial Draft

Architecture Vocabulary
(Including
terminology) -
TMF071 ODA
Terminology
R18.0.0
5 Information  Functional Initial Draft
Systems Architecture:
Architecture IG1167 ODA
Functional
Architecture
R18.0.0
6 Technology  Component Initial Draft
Architecture Definition: IG1171
ODA Component
Definition R18.0.0
7 Opportunities  TR262 Published
and Solutions Management

Platform Blueprint
and Application to
Hybrid
Infrastructure
R17.5.1
 Open API Table
8 Deployment & TBD TBD
Runtime

7. Appendix C: Requirements Traceability

Reference List
The Vision document proposes a set of Architecture Framework grouping that must support
the requirements set out in GB998 Concepts and Principles, and the ODA White Paper first
published in January 2018.
7.1. Reference list from

GB998 and ODA White
Paper
The following table lists the raw requirements listed in the GB988 Concepts and Principles, and
the ODA White Paper.
GB998 is structured along the lines of TOGAF and for each principle there are a number of
implications (not listed in Table below).
The ODA White Paper simply groups its requirements into: Business Requirements and
Architecture approach and design principles.
It is not clear yet whether the implications for each of the ODA Concepts and Design principles
are formally tracked back to the ODA White Paper.
It is also likely there are some gaps in the requirements; for example, a Model Driven Lifecycle
solution is essential to achieve business agility, yet this does not appear as an explicit
requirement from either source.
This table is the input material for the comparison (in the next Section) of these two sources to
define the structure and content of the ODA Vision Architecture groupings.
GB998 ODA White Paper

For reference the current list of Concepts Business architecture related:
and principles listed in GB998. They are 1. Ability to exploit the flexibility of cloud
grouped into TOGAF based groupings.
2. Lower cost of operation
Some architecture Framework artefact
groupings are not addressed. 3. Business agility
Business: 4. Support for flexible business models
1. Different stakeholders, different 5. Multi-vendor support

viewpoints 6. Ecosystem-capable
2. Technology functions must operate as 7. Agile governance
businesses
3. Think out of the box
Grouped under architecture approach

4. Stepwise evolution to target / Walk, covering: business, technical,

Crawl, Run Implementation and deployment:
5. Business architecture is iterative 1. Decoupling of functions and
Integration (Layering)
6. Business architecture is reusable
2. Common data architecture
7. Governance is integrated
3. Agile governance
Information (Data): 4. Intent (based Management)
1. Information is a shared asset 5. Componentization and modularity
2. Information is accessible 6. API-based architecture
3. Information must be secure 7. Dynamic integration
4. Information must be analyzable 8. Real time
5. Information is quickly available 9. Separation of design time and run

time (‘nonstop’ principle)
10. Catalog-based
Application:
11. Security by design
1. Ease of use
12. Privacy by design
2. Technology agnostic
3. Modular and reusable
Ed Note
4. Decoupled
1. Model driven lifecycle not stated as a
5. Capability Exposure specific input requirement but
6. Convergence with the Enterprise essential to achieve business agility.
Architecture 2. AI /ML is not stated as a specific
requirement
Technology:
1. Cross-Function
2. LEGO Blocks Architecture
3. Stepwise evolution to target
4. Interoperability

7.2. ODA Vision

Mappings
This this table shows the current understanding of the mapping of the ODA Architecture Vision
artefact grouping to GB998 ODA Concepts and Principles and the requirements stated in the
ODA White Paper.
It is clear that a further cycle of review of the alignment and completeness of GB998 with the
ODA White Paper and other sources is needed.
IG1166 GB998 ODA Concepts ODA White Paper

Architecture
Vision Groups
(A) ODA Concepts N/A From Section 3.2 ODA
and Principles White Paper
Purpose of GB998 is to transform the
ODA White Paper Requirements into 1. Separation of
a set of Principles and Implications concerns- Decoupling
that capture all of the ODA White of functions and
Paper requirements; plus, any others Integration (Layering)
identified during the formal 2. Common data
development of ODA. architecture
In this version there is partial 3. Intent (based
coverage of the ODA White Paper management)
requirements shown in the column
on the right. 4. Componentization and
modularity
5. API Based Architecture
6. Managing
Stakeholders
7. Real time
8. Separation of design
time and run time
(‘nonstop’ principle)
9. Catalog-based
12. Agile Governance

(B) ODA ? N/A see below

Architecture Vision
Document
(C) Agile and None? From Section 3.1 ODA
model driven White Paper
requirements and Candidates used in this
tooling version:
 Business agility
 Lower cost of
operation
business models
 Additions to ODA WP:
 Multi-vendor support
 Ability to exploit the
 MODEL DRIVEN
(D) ODA Business Business From Section 3.1 ODA

Architecture White Paper Business
1. Different stakeholders, different
architecture related
viewpoints
1. Ability to exploit the
2. Technology functions must
operate as businesses
2. Lower cost of
3. Think out of the box
operation
4. Stepwise evolution to target /
3. Support for flexible
Walk, Crawl, Run
business models
5. Business architecture is iterative
4. Multi-vendor support
6. Business architecture is reusable
5. Business agility
7. Governance is integrated
6. Ecosystem-capable
(E) Information Information (Data) Information Systems

Systems 1. Information is a shared asset Architecture related

Architecture 2. Information is accessible 1. Common data
architecture
3. Information must be secure
2. Intent (based)
4. Information must be analyzable
3. Decoupling of
5. Information is quickly available
functions and
Integration (Layering)
Application 4. Managing
1. Ease of use Stakeholders
2. Technology agnostic 5. Componentization and
modularity
3. Modular and reusable
4. Decoupled
time and run time
5. Capability Exposure (‘nonstop’ principle)
6. Convergence with the Enterprise 7. Catalog-based
Architecture
(F) ODA Technology Technical Architecture

Technology 1. Cross-Function 1. Componentization and
Architecture modularity
2. LEGO Blocks Architecture
2. Microservices
3. Stepwise evolution to target
3. API-based architecture
4. Interoperability
4. Dynamic integration
5. Manage Diversity
5. Real time
6. Common data
architecture
time and run time
(‘nonstop’ principle)
8. Catalog-based
(G) ODA Solution ? Candidates?

Implementation 1. Separation of design time and run 1. Componentization and
time (‘nonstop’ principle)?

modularity
2. Microservices
3. API-based architecture
4. Dynamic integration
5. Real time
6. Common data
architecture
7. Ecosystem-capable
8. Catalog-based
11. Business agility
13. Agile governance
14. Ability to exploit the
(H) ODA ? None?

Deployment and
Run-time Models

8. Administrative
8.1. References
[1] https://www.tmforum.org/customer-centricity/
[2] NFV: Bridging the chasm
[3] TM Forum Future Architecture Strategy Discussion Paper
[4] Digital Platform Reference Architecture
[5] Zero-touch Orchestration, Operations and Management
[6] See TM Forum collaboration documents TR274 and IG1118.
[7] 5G Service Operations: Closed Loop Assurance of 5G Network Slices
8.2. Document History

8.2.1. Version History
Version Date Modified by: Description of changes

Number Modified
0.1.0 02 May 2018 Dave Milham Initial Version in MS Word
0.2.0 29 May 2018 Alan Pope Transferred to Confluence
1.0.0 26 June 2018 Dave Milham Final version for publication
1.0.1 18 Jul 2018 Adrienne Formatting/style edits prior to R18
Walcott publishing.
8.2.2. Release History
Release Number Date Modified Modified by: Description of changes

18.0.0 18 July 2018 Alan Pope Initial Release

8.3. Acknowledgments
This document was prepared by the members of the TM Forum ODA project:
 Emmanuel A. Otchere Huawei
 Naotaka Morita NTT
 Johan Vandenberghe Bell Labs, Nokia
 Dave Milham TM Forum Editor
 Alan Pope TM Forum Confluence Best Practice Advisor
 Member contributions from the ODA /ODE Workshops in 2017 /18
[DM1] Check whether to retain this reference and the URL
[DM2] From Original slide but needs re wording

ODA Architecture Vision: TM Forum Exploratory Report

Uploaded by

Copyright:

Available Formats

ODA Architecture Vision: TM Forum Exploratory Report

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ODA Architecture Vision: TM Forum Exploratory Report

Uploaded by

Copyright:

Available Formats

What is the purpose and scope of this document?

What is the purpose and scope of this document?

What are the business requirements for ODA?

What are the business requirements for ODA?

TM Forum Exploratory Report

ODA Architecture Vision

Latest Update: TM Forum Release 18.0.0 Member Evaluation

TM Forum 2018. All Rights Reserved.

Copyright © TM Forum 2018. All Rights Reserved.

Direct inquiries to the TM Forum office:

4 Century Drive, Suite 100

© TM Forum 2018. All Rights Reserved. Page 2 of 51

© TM Forum 2018. All Rights Reserved. Page 3 of 51

3.3. Key Architecture Viewpoints and personas 33

© TM Forum 2018. All Rights Reserved. Page 4 of 51

Figure 1: Digital transformation in two dimensions..................................................................10

© TM Forum 2018. All Rights Reserved. Page 5 of 51

© TM Forum 2018. All Rights Reserved. Page 6 of 51

 needs a set of reusable management components - ODA Component Implementations -

© TM Forum 2018. All Rights Reserved. Page 7 of 51

© TM Forum 2018. All Rights Reserved. Page 8 of 51

1.1. Marketplace Drivers

1.2. The digital

© TM Forum 2018. All Rights Reserved. Page 9 of 51

Figure 1: Digital transformation in two dimensions

The situation presents CSPs with a choice of business strategies:

1.3. Platform business

© TM Forum 2018. All Rights Reserved. Page 10 of 51

1.3.2. Business Models

1.4. Technology enablers

© TM Forum 2018. All Rights Reserved. Page 11 of 51

1.5. The collaboration

Figure 2: How collaboration helps transformation in the communications industry

A collaborative approach to solving industry challenges (for example in TM Forum’s Catalyst

© TM Forum 2018. All Rights Reserved. Page 12 of 51

2. Vision of TM Forum Open Digital Architecture

2.1. ODA Business

2.1.1. Lower cost of operation

2.1.2. Support for flexible business models

2.1.4. Business agility

© TM Forum 2018. All Rights Reserved. Page 13 of 51

(ZOOM) project to develop detailed requirements specifications and implementation assets.

2.1.5. Multi-vendor interoperability support

2.1.6. Agile governance

2.1.7. Ability to exploit the flexibility of cloud

© TM Forum 2018. All Rights Reserved. Page 14 of 51

comprehensive Architecture for complete service lifecycle automation within an enterprise -

Figure 3: TM Forum Open Digital Architecture Artefact Groupings

© TM Forum 2018. All Rights Reserved. Page 15 of 51

2.2.1. (A) Concepts and Principles Work (Guidebook GB998)

© TM Forum 2018. All Rights Reserved. Page 16 of 51

Status Reference Addresses ODA White

Future ODA Requirements document (formal RFC 2119

2.2.2. (B) Architecture Vision (this document IG1166)

© TM Forum 2018. All Rights Reserved. Page 17 of 51

Status Reference Addresses ODA White Paper

Future Update to IG1166 based on detailed work

© TM Forum 2018. All Rights Reserved. Page 18 of 51

Status Reference Addresses ODA