Frameworx Exploratory Report

Digital Ecosystem Reference

Architecture

White paper to bootstrap the Digital Ecosystem

Reference Architecture Project Team

July 2015

Latest Update: Frameworx Release xx.x Document Status: Draft

Version IPR Mode: RAND

TM Forum [year]. All Rights Reserved.

Digital Ecosystem Reference Architecture

Notice

Copyright © TM Forum [year]. 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:

 
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

© TM Forum 2015 All Rights Reserved. Page 2 of 18

Digital Ecosystem Reference Architecture

Bootstrapping the development of a “Digital Ecosystem Reference

Architecture
This document is intended to bootstrap the Digital Ecosystem Reference Architecture
(DERA) project recently approved by the TM Forum Board at their meeting June X,
2015.

The Board paper explaining the high level business drivers justifying the effort and its
importance to the TM Forum is attached in Appendix X. This document is intended to
provide the initial thinking on the technical direction and scope for the Project Team. It
strongly suggested that if the reader is not familiar with the Board paper they read this
first as it sets the stage for this document. This document can be considered Chapter 2
Initial Thoughts on Technical Direction of the initial Board paper.

Primary objective of the DERA is to create a communication device that will allow us to
explain the value of the current TM Forum assets as they apply to Digital Ecosystems.

One of the Forum’s key strengths is the vocabulary of the Business Process and
Information Frameworks. It has been proven out in many different business scenarios
over the last 25 years. It is believed this vocabulary can be enhanced to address the
new challenges of the Digital Ecosystem. The strength of this proven vocabulary should
allow business partner from many business verticals to communicate with a common
understanding.

It is also believed that many of the TM Forum APIs will have value in realizing the Digital
Ecosystem. The APIs are candidate to play at many different layers within the proposed
architecture and as noted in the Board paper there are existing proof points of their
relevance.

It is important to note DERA is not intended to replace Frameworx or the Digital Service
Reference Architecture but represent a natural extension of those works targeted
specifically at the challenges of developing Digital Ecosystems.

Key Tenets:
1. KEEP IT SIMPLE. The overriding objective is to provide a communication
tool for people communicating between business sectors who currently
don’t have any common base. The reference architecture must be simple
enough to grasp and understand within the first 10-15 minutes but
sophisticated and complete enough to address complex business
interactions and also allow a complete mapping of existing TM Forum
assets. This is a very challenging goal should be continually validated as
work progresses.

2. All work will be Business/User scenario driven. It is key that any work
undertaken in DERA have immediate business relevance and value.

3. DERA will be API centric in its concerns as this as key to enabling the
flexibility and speed required by Digital Ecosystems.

4. The project should use catalyst and proof of concept work to validate their
work as soon and as often as possible.

© TM Forum 2015 All Rights Reserved. Page 3 of 18

Digital Ecosystem Reference Architecture

5. The scope and nature of this work is such that working with other
standards organizations will be critical. The team should reuse rather than
create whenever feasible.

6. The DERA must be applicable in hybrid environments where

implementation technologies may be at different levels of evolution,
wireless, wireline, virtualized and non-virtualized. This should also be done
with an eye to the future when the next technologies are introduced. For
example the Internet of Things is sure to introduce new infrastructure
demands and the architecture should be designed to accommodate
change as much as feasible.

The figure below is a simple visual of the proposed DERA.

There are several key concepts represented on the diagram that will translate into
specific work items for the project team. This document will attempt to provide enough
explanation regarding those concepts to allow the Project Team to sharply focus their
work.

Key Concepts

 Infrastructure
o The infrastructure vision is of a virtualized IT oriented infrastructure
with Compute/Storage/Network all being managed as a
coordinated resource. However, the reality is Infrastructure will a
hybrid mix of different technologies for the foreseeable future.
 Clean separation of concern between Service and Infrastructure
(represented by the Runs on IaaS solid line in the diagram)
o While this concept has received wide industry endorsement there
needs to be some detailed technical work done to define exactly

© TM Forum 2015 All Rights Reserved. Page 4 of 18

Digital Ecosystem Reference Architecture

what this means and how this manifests itself in the way the
systems will interact and the changes necessary in the APIs to
support this delegation of responsibility.
 Well Enabled Service
o A clear separation of the functionality of a service and the
management and control of that service where every service,
including management services have a well-known management
and control interface/capability. (reference DSRA and FMO work in
ZOOM)
 Service assembly (represented in the diagram as part of the Uses PaaS
layer)
o The reference architecture must enable assembly of service
components to deliver a complex service. This assembly should be
possible both within a single administration as well as across multi-
administration.
 Digital Ecosystem Platform (DEP)
o The DEP is a collection of underlying service required to enable
services to interact with each other and with the infrastructure to
deliver end to end services.
 Support of multiple Digital Ecosystem Platforms (represented by the
Service Platform in the diagram)
o The reference architecture should define characteristics necessary
to allow heterogeneous Digital Platforms both within and between
administrations to seamlessly interact, coordinate service delivery
and support flexible business models. These characteristics should
establish the base set of services required for a well enabled
Digital Service Platform and potentially at test suite.
 A “backplane” of additional supporting assets on which the ecosystem is
founded
o The backplane is the foundation material that may not actually
manifest directly in a service component but contains the patterns,
methodology, models and governance that allows the services,
platform and infrastructure to interact in a seamless way.
Candidate capabilities candidates provided as examples to clarify
intent:
 Governance
 Trust
 Security & Privacy
 Business Process and Information Frameworks
 API catalogue
 Metrics
 Use of policy & orchestration to enable flexibility
o The use of policy and orchestration will be critical to the success of
the Digital Ecosystem. They must be defined in such a way that
Service and Infrastructure policies and orchestration can interact
seamlessly. The differing types of policy will also need to interact,
security, service quality, configuration will need to share
information and concerns. The ability to test and confirm policy and
orchestration interaction needs to be built into the ecosystem
fabric.
 Use of dynamic Open APIs and open source services
o Recent catalyst have shown the power and flexibility by enabling
the use of dynamic APIs, DERA should learn from and leverage

© TM Forum 2015 All Rights Reserved. Page 5 of 18

Digital Ecosystem Reference Architecture

this success. The DERA should accommodate and encourage the

use of open source solutions evolving in the industry.
 CEM built in as a first level objective
o It has become increasingly apparent that CEM capability must be
considered and build into the Ecosystem fabric from the onset.
Effort to retrofit CEM into systems are expensive and often the
results are less than satisfactory. Data collection, analysis and end
to end experience need to become a repeatable pattern in the
reference architecture.
 Security and privacy built in as first level objectives
o There has been much lip service paid to the need to make security
and privacy first order concerns in the past few years but the reality
it has not resulted in progress. The increase in exposure with
service assembly and multi-administration interaction this must be
addressed in the DERA.
 Multi-tenancy
o The Digital Ecosystem will be a multi-tenant environment. This
consideration for security, policy and acceptable service assembly
must be built into the system.

Key output of the effort

 Definition of required minimal set of functions and capabilities a
Platform must provide to be considered a well enabled Digital
Ecosystem Platform and the API necessary to allow two ecosystems to
exchange information sufficient to allow services to be assembled across
platforms. This is not limited to platforms with a single administration but
includes interactions between administrations.
Potential Sources of Platform Services

The definition of the minimal set of services for a Digital Ecosystem

Platform should not be developed as a green field effort. The work
should be based on existing work with in the DSRA project as well as
reference external work such as the MEF LSO for example.

DSRA Technology Architecture

http://projects.tmforum.org/wiki/display/PUB/DSRA+Technology+Archit
ecture
 Identity Management Support Service
 Profile Management Support Service
 Analytics Support Service
 Policy based Routing Support Service
 Configuration & Activation Support Service
 Assurance & Traceability Support Service
 Charging Support Service
 Invoicing Support Service
 Catalog Lifecycle Management & Federation Support Service
 On-boarding Support Service

MEF Lifecycle Service Orchestration (LSO) services

https://www.mef.net/Assets/White_Papers/MEF_Third_Network_LSO_
Vision_FINAL.pdf
 Fulfillment
 Control
 Performance

© TM Forum 2015 All Rights Reserved. Page 6 of 18

Digital Ecosystem Reference Architecture

 Assurance
 Usage
 Analytics

 Definition of the “line of demarcation” between Services and

Infrastructure, the minimal set of information required to be exchanged at
that boundary that allows for service assurance and management for end
to end service delivery. This would include the APIs necessary to
exchange that minimal set of information. (this is potentially a radical
departure from today’s API where implementation technology information
is propagated throughout the support system stack.

 The DERA work should further define the backplane capabilities

identified in the Board paper, defining the criteria for a backplane asset and
develop an initial list of assets required to support the high priority user
scenarios.

 The DERA work should build on prior work defining well enabled services
and ongoing work in the ZOOM project to develop a concise definition of
a well enabled service and explore the feasibility of developing a
test/certification capability to verify a service is indeed well enabled
service, independent of functionality.

Next steps/Work plan

Currently it is planned that the Digital Ecosystem Reference Architecture will launch at
Action Week July 2015 as a work stream as a independently chartered. As this viewed
as the umbrella architecture for all TM Forum work it is recommended that it not be
placed in any one strategic program. The initial workshop of the Work stream Team
would be at a face to face early September in Paris. With initial draft material being
published as available with primary targets for Nov. 14 and major release April 2016
prior to TM Forum Live!.

Priority work items

Identify high priority Business/User Scenarios – source from ZOOM, DSRA,

ETSI, MEF, ATIS, etc.

Based on agreed scenarios:

 Agree scope and deliverables of Phase 1, at minimum the 3-5
page DERA explanation document must be available
 Define Service/Infrastructure line of demarcation
 Develop a concise definition of a well enabled service and potential
test capability
 Define “definitive” set of Platform Services that define a well
enabled platform – coordinated with DSRA Team
 Define role of backplane and populate with candidate assets – this
will require interaction with a number of project teams and external
organizations.
 Identify enhancements required to Frameworx
 Coordinate with ZOOM team on Management & Control
Continuum and role of Policy and Orchestration
 Identify key SDOs and establish working relationship via joint
member interest

© TM Forum 2015 All Rights Reserved. Page 7 of 18

Digital Ecosystem Reference Architecture

 Etc.

As stated earlier as many concepts as possible should be validated through

Catalyst/PoC or sourced from production systems.

As approved by the board there is a substantial commitment to this effort already.

Members are encouraged to assess their company’s interest in this effort and the
subject matter expertise they are willing to commit to provide this valuable tool to
the industry and the TM Forum. The reference architecture will enable companies
to more successfully engage in the emerging Digital Ecosystem and communicate
with potential partners with less ambiguity, without the reference architecture the
risk factors will remain unmitigated and born by each company individually.

© TM Forum 2015 All Rights Reserved. Page 8 of 18

Digital Ecosystem Reference Architecture

1. References

1.1. References
Reference Description Source Brief Use Summary
Project Charter <<PROJECT name>> Project <<summary>>
Charter
Link To Models << Hyperlinks to or location of <<summary>>
associated models>>
<<Reference 1>> <<Type, Title, Number, <<summary>>
Revision, Date>>
<<Reference n>> << Type, Title, Number, <<summary>>
Revision, Date>>

© TM Forum 2015 All Rights Reserved. Page 9 of 18

Digital Ecosystem Reference Architecture

1. Board Paper Appendix

Board Paper Executive Summary For: Information &
Discussion

Paper title: Open Digital Strategy – Phase II

Board paper No: [Mirella can provide this to you]
Date of Meeting:
Owner of paper: Nik Willetts
Authors: Laurent Leboucher; Nik Willetts; Barry Graham; Pete Dunmore; Ken Dilbeck
…………………………………………………………………………………………………………………………………………………………………
1. Purpose of this paper
This paper provides an introduction to the Forum’s strategic plans to enable dynamic, seamless management
of digital services across complex ecosystems, and unlocking considerable growth for our members in the
process. It introduces a number of new concepts, identifying the need for an overarching framework for
design, management and scalability of highly profitable digital ecosystems. These concepts build on the value
of the Forum’s existing, extensive work in digital service management. The paper is provided for the Board’s
review and input to help shape and drive this initiative forward.
2. Background information the Board of Directors need to know
Launched in 2013, the Open Digital Program has established a number of fundamental building blocks for
digital service management. By taking a pragmatic approach, this work has been progressively tested and
improved through a series of Catalyst (proof-of-concept) projects exploring use cases such as digital health,
smart energy and smart cities.
3. Proposal Overview
The digital economy creates growth opportunities for every industry. Providers of all kinds, and their supply
chains, are rapidly transforming to establish their position in the emerging digital landscape. The next
generations of digital services hold significant potential for established verticals such as healthcare, insurance,
energy and transport, and the enterprise-grade requirements of these industries create new opportunities for
communications providers to thrive.
To succeed, all members of the ecosystem – whilst transforming their own agility – need to create the
conditions for co-opetition: collaboration, co-innovation and partnerships, built at the speed of the internet on
a global scale, in a competitive landscape where such collaboration is traditionally challenging. This will require
a common approach to non-functional requirements and the end-to-end management challenge, using a
shared language, definitions and interfaces.
The Forum intends to play a central role in this revolution by addressing the end-to-end management
challenge, and expanding our membership to deliver the benefits of common languages, processes and APIs to
the entire digital ecosystem. Without the collaborative work led by the Forum, the number of interactions that
must be managed to scale globally is not viable, as Facebook’s Internet.org initiative is discovering.
TM Forum has a proven track record of developing collaborative solutions, which become de-facto standards
through widespread adoption. We have a substantial set assets for digital business that are already used in
commercial deployments, by companies such as BT and BearingPoint. We have many of the building blocks
today, and must now bring them together under a single framework, and prove their value through
deployments in a broad range of verticals.
To achieve this, we will introduce a new vision for the digital ecosystem, delivering a common language and
framework for companies to understand the complex interactions between the partners, and the often-
overlooked challenges of non-functional management information. Key elements of this vision are:
 A Digital Ecosystem Framework (a logical architecture) to accelerate the creation of scalable
platforms and services

© TM Forum 2015 All Rights Reserved. Page 10 of 18

Digital Ecosystem Reference Architecture

 Customer experience analytics, metrics and processes to ensure that the customer remains at the
center of complex business models, drawing on our existing Customer Centricity program
 A ‘backplane’ of governance, modular business process and information elements based on
Frameworx
 Common components to form the ‘digital bridge’ between partners, including APIs and business
process definitions
 Dynamic infrastructure orchestration and management capabilities based on the work of our ZOOM
program
This will structure the TM Forum’s existing work streams into a unified vision for the digital economy.
4. Recommendations
In order to ensure the success of this initiative, we are asking for the Board to:
1. Formally endorse, own and drive this initiative forward.
2. For each Board company to:
a. Provide expert resources to contribute to and lead this vision and work streams relevant to
their business
b. Commit to test, iterate, adopt the architecture, framework and APIs as relevant to their
business
c. Once proven, commit to endorse and require relevant suppliers and partners to adopt the
framework and APIs
3. Set explicit and ambitious KPIs for API adoption and broader adoption of the framework on the
whole organization, including the Board companies (See page 6 for details).

1.1. The Shifting Landscape

The old era, where the majority of digital services were controlled by the telecommunications sector, is gone.
Popular consumer brands such as Alibaba, Amazon, Apple, Baidu, Facebook, Google and Tencent now play a
central role in the digital experience for users, and are expanding to encompass ever more verticals. To date,
these providers have used last-mile networks in a ‘best efforts’ fashion, limiting the control they have over the
ultimate customer experience. By building a deeper collaboration between ecosystem partners, a new
business model is possible, offering differentiated services with a high quality of experience to the end user
by leveraging all the capabilities of the networks: the “User Defined Network” (as defined by AT&T in 2013).
The combined advantages of universal connectivity (everything/everyone can be connected to
everything/everyone at a very low cost, even on the move) and cloud universal access (scalable, low-cost
compute and storage capacities provided to anyone on the cloud) create many scenarios where traditional
business operations can be decoupled without friction, and traditional businesses can easily be disrupted.
Countless examples across multiple sectors show that it is now a common phenomenon, predicted and clearly
explained by John Hagel III and Marc Singer in a “premonitory” paper in 1999 (“Unbundling the
Corporation”).
This phenomenon impacts the core business activities of communications service providers. Communication,
voice and messaging services have already been dramatically disrupted by so-called “over the top”
applications, which deliver a similar, or enhanced, service with a strong emphasis on user experience. Their
success comes despite offering no Quality of Service (QoS) guarantee and operating under very different
business models (often ‘freemium’ or two-sided, providing a compelling proposal to consumers).

© TM Forum 2015 All Rights Reserved. Page 11 of 18

Digital Ecosystem Reference Architecture

Figure 1. The industry is shifting

In this new paradigm, the management challenge is shifting from the complexity within a service provider, to
a much more dynamic, open but ultimately complex ‘Internet-of-Everything’ environment. To enable robust
ecosystems, and significant new growth opportunities for our members, a common approach to management
is required. A common framework is needed to bring the benefits of a common language, metrics, information
and process model and APIs that can be easily adopted by device manufacturers, app developers, service
providers and others. It must accelerate and improve the rollout of new business models and services,
enabling a truly flexible and dynamic, end-to-end management capability to ensure the right experience.
In the new digital landscape, partnerships will be the rule and nimble players will have the advantage.
Business processes will cross boundaries between partners who will follow a loosely coupled business
architecture. The partnerships themselves will be complex, with many value relationships between the
parties.
By way of example the emerging digital health vertical involves interactions between patients, medical
services, medical suppliers and insurers as well as the communications service provider who can provide
enabling platform services, as illustrated in Fig. 2.

© TM Forum 2015 All Rights Reserved. Page 12 of 18

Digital Ecosystem Reference Architecture

Figure 2: The e-health value map

Whilst the map above has many parties and relationships, it is in fact a simplification of the real ecosystem:

 In many cases there will be multiple health services, either state or private sector and the
relationships will need to exist with all of them and it is not commercially viable to recreate them
each time and maintain them in parallel.
 Regulatory requirements and interactions are not shown, global enterprises will have to interact
consistently with very different regulatory environments in different territories and treating these on
a case by case basis impedes the ability to scale globally
 Medical / Pharmaceutical research adds another overlay of value relationships and is a major
business opportunity for many partners.
 There are new ecosystem-to-ecosystem relationships being developed that are not shown here, such
as linking lifestyle data from gyms and personal fitness trackers into health and insurance systems.
A new opportunity for Communications Service Providers
The opportunities for communications service providers in this new paradigm are considerable. As a
horizontal industry, or enabler, communications providers can deliver services that guarantee the end-
to-end experience complex ecosystems demand. However, to seize this opportunity, whilst continuing
their long-term focus on improving internal efficiency and agility (a transformational journey which
the TM Forum has been supporting for many years) they must also establish and manage an increasing
number of simple, agile, external partner relationships.
Attempting to integrate digital service providers with communications providers on a case-by-case
basis simply does not scale, and inhibits growth, as is being demonstrated by Facebook in its
Internet.org initiative, and Microsoft through its experience of retailing Office 365 through
communications service providers. Operators must transform to provide a common edge in order to
thrive in the digital market.
The Forum has extensive experience of enabling business transformation within telecoms operators,
by providing a common language and frameworks to optimize processes and systems across the
business. The current situation has many parallels to that which led to the development of building
blocks of TM Forum’s Frameworx, in the early 2000’s. Today, intra-enterprise complexity is being
replaced by inter-enterprise complexity, and the complexity of end-to-end management of the
customer experience across the different elements of the communications network is being replaced

© TM Forum 2015 All Rights Reserved. Page 13 of 18

Digital Ecosystem Reference Architecture

by the challenge of end-to-end management of the customer experience across all elements of the
digital ecosystem.
TM Forum recognized this change as early as 2013 and within the Open Digital and Agile Business & IT
programs members have started to address the new challenges, and have already created significant
assets, which are already in use today.
The time has come to bring all of these activities together in one unified vision of the industry.

© TM Forum 2015 All Rights Reserved. Page 14 of 18

Digital Ecosystem Reference Architecture

1.2. TM Forum’s Vision for the Digital Ecosystem

To support this evolution, the Forum is creating a vision for the industry that will form a common language
and representation to address the end-to-end management across ecosystems, and facilitate the cooperation
between ecosystem partners. This vision will position the new and existing TM Forum assets as enablers for
this cooperation.

End-to-End Management Framework

Enabling Backplane:
Service Realiza on
(Customer Experience Service)

Service Pla orms (PaaS)

Infrastructure (IaaS)

Figure 3. The Digital

Ecosystem

Figure 3 gives a high level view, which consists of a number of major components:

 The top layer, called “service realization”, is where the services are delivered to the customers
and experienced by them. In many Internet of Things (IoT)-based services, the customer may be
another device, or a customer who has very limited interactions with the underlying services.
This layer brings together the whole digital experience, which may be more or less fragmented
depending on the interoperability of the digital ecosystems. Those services are developed and
deployed on top of the underlying digital platforms represented at the middle layer.
 The middle layer, called “services platforms” can be understood as an extension of the Platform-
as-a-Service (PaaS) cloud model. It represents the cooperation of multiple ecosystem partners,
and it brings the necessary support functions to develop, deploy and execute digital services.
Examples of the categories of common services within the platform would be: Application
lifecycle management, identity and access management, data analytics, commerce and social and
personal communications. The Services Platform layer is absolutely essential because it shapes
the digital ecosystems. Moreover, digital platform instances will not live in isolation. They will
need to cooperate.

© TM Forum 2015 All Rights Reserved. Page 15 of 18

Digital Ecosystem Reference Architecture

 The bottom layer, called “infrastructure”, involves infrastructure providers, which operate
compute, storage, network resources and device management. This includes Cloud
Infrastructure-as-a-Service (IaaS) providers, but also network operators and device management
platforms. Thanks to software defined networking and network functions virtualization, network
providers should be able to customize on the fly the properties required by applications in the
layers above, and providers have the opportunity to provide a wrapper around the infrastructure
layer to allow it to be simply managed.
 The “enabling backplane” provides the common assets, models, governance and definitions to
allow ecosystem partners to interact in a standardized way and share non-functional
management information, such as the metrics and analytics definitions to facilitate a shared
understanding across all parties of end-to-end customer experience. It acts as a “digital bridge”,
providing standardized ways of interacting, including business processes and digital service
management APIs that will become the key building blocks of ecosystem partner interactions

Many existing TM Forum assets provide the foundations for enabling this vision:

 Frameworx provides the foundations of the enabling backplane, defining the core business
process application and information models, as well as security and privacy frameworks.
 The Customer Centricity program has created a framework of metrics and analytics that allow a
shared consistent measure and understanding of customer experience.
 As part of the Open Digital Program, a primary set of concrete APIs definitions for the Services
Platform have been developed and tested. These APIs provide initial coverage of the commerce
area: product ordering API, catalog management API, trouble ticketing API, service level
agreement API, performance management API, customer management API, party management
API, usage API, billing API, product Inventory API, service Inventory API, resource Inventory API.
 Reference architectures for both the technical management of the ecosystem interactions – the
Digital Services Reference Architecture (DSRA) and the commercial aspects (B2B2x) – have also
been developed with the Open Digital Program.
 The Zero-touch Operations, Orchestration & Management (ZOOM) program is developing many
of the underlying information models and specification for elastic infrastructure and end-to-end
management across the ecosystem.

These assets and reference architectures are in use today, being tested by Catalyst projects in verticals
as diverse as health, utilities and smart cities. The architectures will evolve to become a complete
reference architecture for the entire ecosystem – the Digital Ecosystem Architecture.

By way of example we can consider just a subset of the digital health example shown previously.

© TM Forum 2015 All Rights Reserved. Page 16 of 18

Digital Ecosystem Reference Architecture

Figure 4: Ecosystem partners in a simplified e-health service

In this case the patient is the focus of the service and so plays the role of the customer. Three ecosystem
partners must cooperate to realize the complete service.

 The communications provider is providing monitoring and communication with the patient,
which is used by:
o The medical provider to adjust treatment plans based on collected data, and allows them to
collect payment from the insurance provider.
o The insurance provider is able to provide analytics across multiple payments and provides
this data to the medical provider as well as using it internally for risk management.

All three ecosystem partners must exchange patient data, payment data and in a secure way which preserves
patient privacy. The enabling backplane provides standard process definitions, data models, APIs and
security and privacy frameworks to allow this interaction to be rapidly defined and developed. The medical
provider may work with multiple insurance providers, and by using standards based interactions the
interface can be the same and critically, the customer (or in this case patient) experience can be assured
regardless of insurance provider.

1.3. Adoption to Date

In order to assess the success of this program, SMART objectives and easily measured KPIs will be essential.
One of the most tangible forms of adoption is use of the Forum’s digital service management APIs, created
over the last 18 months.

Responses to API Adoption Surveys sent in April 2015 to a set of targeted members clearly show early
adoption of APIs. 5 companies out of the 12 companies surveyed indicated early adoption of a number of
APIs:

 Orange adopted 5 APIs deployed in 11 projects

 Ericsson adopted the Catalog and Ordering APIs, deployed in their Service Innovation
Framework
 Infonova adopted 8 APIs, already deployed in their Products
 DGIT noted adoption of the Ordering APIs already deployed in their Product
 Teoco noted adoption of the Performance API
 
In addition, companies from APAC are becoming involved in defining upcoming APIs, and have mentioned
their desire to adopt the APIs as soon as they are specified. For example, NTT and ZTESoft are leading the
development of pre-Ordering APIs; Huawei is leading the Service Test and SQM APIs, with a desire to host a
Spec Jam in China in 2015.

Furthermore, the Metro Ethernet Forum (MEF) has also indicated their desire to align their APIs with the TM
Forum API.
 
Given this early momentum, we propose setting a target to double the number of deployments of these
APIs every six months.

© TM Forum 2015 All Rights Reserved. Page 17 of 18

Digital Ecosystem Reference Architecture

1.4. Conclusions and Next Steps

The next wave of the digital revolution presents many new opportunities for our members. The Forum
is well positioned to support our members in seizing this opportunity, taking our experience from
intra-organizational efficiency improver to inter-business partnership builder. The Forum can act as a
hub for digital business, spanning multiple verticals and
Our current core Frameworx assets provide a solid base on which to build the new assets that will be
required. Many of our existing best practices and toolkits are immediately relevant, while others will
need to be expanded and re-purposed.
Our strategic programs over the past two years have positioned us in a good starting point for this
journey. We have transformed how we create work collaboratively, embracing agile working methods
to great effect. We have rapidly created new assets that are already being commercially deployed.
These activities need to continue and expand, whilst at the same time the assets they create must be
structured into a single coherent set.
At the same time as expanding and evolving our underlying assets, we must make these ever easier to
adopt, through a focus on toolkits, best practice documents and a rich portfolio of practical, business
outcome focused adoption training and coaching services.
The next step is to take the high level work completed to date and to work at the next level of detail.
The next workshop is planned for TM Forum Live! which will:
 Validate the existing scenarios and uses cases
 Identify additional use cases
 Validate and roadmap requited assets
 Identify next steps to:
o Advance the technical work
o Enable broader adoption
During planning for all the TM Forum’s work in the remainder of 2015 all of work streams will be
aligned with and validated against the overall roadmap for expansion and adoption of the digital vision.
With the Board’s endorsement and direct support, longer term KPIs can be put in place to measure the
maturity and adoption of this vision in order to track progress.

1.5. Requests of the Board

In order to ensure the success of this initiative, we are asking for the Board to:
1. Formally endorse, own and drive this initiative forward.
2. For each Board company to:
a. Provide expert resources to contribute to and lead this vision and work streams relevant to
their business
b. Commit to test, iterate, adopt the architecture, framework and APIs as relevant to their
business
c. Once proven, commit to endorse and require relevant suppliers and partners to adopt the
framework and APIs
3. Set explicit and ambitious KPIs for API adoption and broader adoption of the framework on the
whole organization, starting with a goal to double API adoption every six months for the next 2 years.

© TM Forum 2015 All Rights Reserved. Page 18 of 18