July 2015
TM Forum [year]. All Rights Reserved.
Digital Ecosystem Reference Architecture
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
, 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 – 10 th Floor,
Morristown, NJ 07960 USA
Tel No. +1 973 944 5100
Fax No. +1 973 944 5110
TM Forum Web Page:
© TM Forum 2015 All Rights Reserved. Page 2 of 19
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.
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 19
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.
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 what this means and how this manifests itself in the way the
© TM Forum 2015 All Rights Reserved. Page 4 of 19
Digital Ecosystem Reference Architecture 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 multiadministration.
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 this success. The DERA should accommodate and encourage the use of open source solutions evolving in the industry.
© TM Forum 2015 All Rights Reserved. Page 5 of 19
Digital Ecosystem Reference Architecture
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.
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
Assurance
Usage
© TM Forum 2015 All Rights Reserved. Page 6 of 19
Digital Ecosystem Reference Architecture
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.
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
Etc.
© TM Forum 2015 All Rights Reserved. Page 7 of 19
Digital Ecosystem Reference Architecture
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 19
Digital Ecosystem Reference Architecture
Reference Description
Project Charter <<PROJECT name>> Project
Charter
Link To Models << Hyperlinks to or location of associated models>>
<<Reference 1>> <<Type, Title, Number,
Revision, Date>>
<<Reference n>> << Type, Title, Number,
Revision, Date>>
Source Brief Use Summary
<<summary>>
<<summary>>
<<summary>>
<<summary>>
© TM Forum 2015 All Rights Reserved. Page 9 of 19
Digital Ecosystem Reference Architecture
Discussion
For: Information &
Paper title: Open Digital Strategy – Phase II
Board paper No:
Date of Meeting:
[Mirella can provide this to you]
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 oftenoverlooked 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
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
© TM Forum 2015 All Rights Reserved. Page 10 of 19
Digital Ecosystem Reference Architecture
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).
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 19
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 19
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 endto-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 interenterprise complexity, and the complexity of end-to-end management of the customer experience across the different elements of the communications network is being replaced by the challenge of endto-end management of the customer experience across all elements of the digital ecosystem.
© TM Forum 2015 All Rights Reserved. Page 13 of 19
Digital Ecosystem Reference Architecture
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 19
Digital Ecosystem Reference Architecture
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.
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 Platformas-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.
The bottom layer, called “infrastructure”, involves infrastructure providers, which operate compute, storage, network resources and device management. This includes Cloud Infrastructureas-a-Service (IaaS) providers, but also network operators and device management platforms.
© TM Forum 2015 All Rights Reserved. Page 15 of 19
Digital Ecosystem Reference Architecture
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.
© TM Forum 2015 All Rights Reserved. Page 16 of 19
Digital Ecosystem Reference Architecture
By way of example we can consider just a subset of the digital health example shown previously.
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.
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
© TM Forum 2015 All Rights Reserved. Page 17 of 19
Digital Ecosystem Reference Architecture
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.
2.5.
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.
© TM Forum 2015 All Rights Reserved. Page 18 of 19
Digital Ecosystem Reference Architecture
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 19 of 19