TR274_Digital_Services_Reference_Architecture_Guide_R17.5.1

[Audio] TM Forum Technical Report Digital Services Reference Architecture Guide TR274 Release 17.5.1 May 2018 Latest Update: TM Forum Release 17.5.1 TM Forum Approved Version 8.0.2 IPR Mode: RAND TM Forum 2018. All Rights Reserved..

[Audio] Digital Services Reference Architecture Guide 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. TM FORUM invites any TM FORUM Member or any other party that believes it has patent claims that would necessarily be infringed by implementations of this TM Forum Standards Final Deliverable, to notify the TM FORUM Team Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the TM FORUM Collaboration Project Team that produced this deliverable. The TM FORUM invites any party to contact the TM FORUM Team Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this TM FORUM Standards Final Deliverable by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the TM FORUM Collaboration Project Team that produced this TM FORUM Standards Final Deliverable. TM FORUM may include such claims on its website but disclaims any obligation to do so. TM FORUM takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this TM FORUM Standards Final Deliverable or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on TM FORUM's procedures with respect to rights in any document or deliverable produced by a TM FORUM Collaboration Project Team can be found on the TM FORUM website. Copies of claims of rights made available for publication and.

[Audio] Digital Services Reference Architecture Guide Team Administrator. TM FORUM makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims. 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 3 of 184.

[Audio] Digital Services Reference Architecture Guide Table of Contents Notice.................................................................................................................................... 2 Table of Contents ................................................................................................................ 4 List of Figures ...................................................................................................................... 6 1. Digital Services Reference Architecture Guide ............................................................ 7 2. Introduction to DSRA R17.5 ............................................................................................ 8 2.1. Defining a Digital Ecosystem R17.5 ............................................................... 8 2.2. Enabling a Digital Ecosystem R17.5 ............................................................. 11 2.3. The DSRA Approach R17.5 .......................................................................... 12 2.4. Related TM Forum Initiatives R17.5 ............................................................. 16 2.5. Who Should Get Involved R17.5................................................................... 17 3. DSRA Business Alignment Architecture R17.5 .......................................................... 18 3.1. Business drivers, requirements and models R17.5 ...................................... 20 3.1.1. Business drivers R17.5 ............................................................................. 21 3.1.2. Business models R17.5 ............................................................................ 24 3.1.3. Business requirements R17.5 .................................................................. 29 3.2. Interaction patterns and orchestration R17.5................................................ 34 3.2.1. Common Characteristics of Business Models R17.5 ............................... 34 3.2.2. Customer / Partner interactions R17.5 ..................................................... 37 3.3. Main IT requirements and principles R17.5 .................................................. 38 3.3.1. Disruptive changes for IT regarding business requirements R17.5 ......... 39 3.3.2. IT Architecture requirements R17.5.......................................................... 39 3.3.3. Proposed IT principles / architectural framework R17.5........................... 42 3.3.4. Impacted Business processes and positioning versus eTOM R17.5 ....... 50 3.3.5. Functions to be handled by DSRA and positioning versus TAM R17.5 ... 58 3.4. API identification and design R17.5 .............................................................. 62 3.4.1. Phase 0: Use cases identification R17.5 .................................................. 62 3.4.2. Phase 1: Distribute processes R17.5 ....................................................... 63 3.4.3. Phase 2: Data Architecture R17.5 ............................................................ 63 4. DSRA Technology Architecture R17.5 ......................................................................... 65 4.1. Digital Service Component R17.5 ................................................................. 65 4.2. Digital Service Management API R17.5 ....................................................... 66 4.3. DSRA Platform Capabilities R17.5 ............................................................... 68 4.3.1. Business Layer Technical Capabilities R17.5 .......................................... 69 4.3.2. PaaS Layer Technical Capabilities R17.5 ................................................ 92 4.3.3. IaaS Layer Technical Capabilities R17.5 ............................................... 112 4.4. API's mapped on DSRA Platform Capabilities R17.5 ................................. 114 4.5. DSRA Standards Index R17.5 .................................................................... 116 4.6. Web Technology Utilization R17.5 .............................................................. 119 © TM Forum 2018. All Rights Reserved. Page 4 of 184.

[Audio] Digital Services Reference Architecture Guide 5. Business Scenarios R17.5 .......................................................................................... 121 5.1. Business Scenarios overview R17.5 .......................................................... 123 5.2. Digital Health Business Scenario R17.5 ..................................................... 123 5.2.1. Description - Digital Health Business Scenario R17.5 ........................... 124 5.2.2. Use Cases - Digital Health Business Scenario R17.5 ............................ 124 5.2.3. DSRA Support Services overview - Digital Health Business Scenario R17.5 124 5.3. On-demand manufacturing Business Scenario R17.5 ............................... 126 5.3.1. Description - On-demand manufacturing Business Scenario R17.5 ...... 127 5.3.2. Use Cases - On-demand manufacturing Business Scenario R17.5 ...... 131 5.3.3. DSRA Support Services overview - On-demand manufacturing Business Scenario R17.5 ..................................................................................................... 138 5.3.4. APIs - On-demand manufacturing Business Scenario R17.5 ................ 140 5.3.5. Example sequence flows - On-demand manufacturing Business Scenario R17.5 141 5.4. Stadium App Business Scenario R17.5 ...................................................... 146 5.4.1. Description - Stadium App Business Scenario R17.5 ............................ 146 5.4.2. Use Cases - Stadium App Business Scenario R17.5............................. 153 5.4.3. DSRA Support Services overview - Stadium App Business Scenario R17.5 154 5.4.4. APIs - Stadium App Business Scenario R17.5 ....................................... 155 5.4.5. Example sequence flows - Stadium App Business Scenario R17.5 ...... 157 5.5. API Wholesale Business Scenario R17.5 ................................................... 160 5.5.1. Description - API Wholesale Business Scenario R17.5 ......................... 160 5.5.2. Use Cases - API Wholesale Business Scenario R17.5.......................... 165 5.5.3. DSRA Platform Capabilities overview - API Wholesale Business Scenario R17.5 168 5.5.4. APIs - API Wholesale Business Scenario R17.5 .................................... 169 5.5.5. Example sequence flows - API Wholesale Business Scenario R17.5 ... 170 6. Definition of Terms R17.5............................................................................................ 174 7. Reading Guide R17.5 ................................................................................................... 178 7.1. DSRA Guide Structure R17.5 ..................................................................... 178 7.2. DSRA Guide Usage R17.5 ......................................................................... 179 7.3. DSRA Guide Pictograms R17.5 .................................................................. 181 8. Administrative Appendix DSRA R17.5 ....................................................................... 182 8.1. Document History ....................................................................................... 182 8.1.1. Version History ....................................................................................... 182 8.1.2. Release History ...................................................................................... 183 8.2. Company Contact Details ........................................................................... 183 8.3. Acknowledgments ....................................................................................... 184 © TM Forum 2018. All Rights Reserved. Page 5 of 184.

[Audio] Digital Services Reference Architecture Guide List of Figures Figure 1: The Digital ecosystem value fabric ............................................................... 20 Figure 2: Alexander Osterwalder Business Model Canvas ......................................... 26 Figure 3: Digital service generic lifecycle ................................................................... 30 Figure 4: Complex digital Service interactions............................................................ 31 Figure 5: Typical customer / partner journey .............................................................. 38 Figure 6: Digital services functional architecture scope .............................................. 41 Figure 7: Functional API and management API ......................................................... 42 Figure 8: Layered Architecture (simplified) ................................................................ 44 © TM Forum 2018. All Rights Reserved. Page 6 of 184.

[Audio] Digital Services Reference Architecture Guide 1. Digital Services Reference Architecture Guide The Digital Services Reference Architecture (DSRA) is the TM Forum's proposal to enable richer and yet open, distributed digital collaboration with the essential tools to support increasingly demanding technical and commercial models. © TM Forum 2018. All Rights Reserved. Page 7 of 184.

[Audio] Digital Services Reference Architecture Guide 2. Introduction to DSRA R17.5 Defining a Digital Ecosystem R17.5 Enabling a Digital Ecosystem R17.5 The DSRA Approach R17.5 Related TM Forum Initiatives R17.5 Who Should Get Involved R17.5 2.1. Defining a Digital Ecosystem R17.5 What is a Digital Ecosystem? The rise of e-commerce and the advent of the digital economy are profoundly changing how businesses think and operate. In the digital environment, products are increasingly assembled in cross-vertical collaborations, with building-block web services contributed from and exposed by myriad partners and hence are demanding management on an end-to-end basis. These complex products are increasingly critical to organizations and to customers, and require more complex commercial and revenue sharing models among diverse parties. These high value, sometimes technically demanding and crossindustry products have outgrown today's collaboration infrastructure and are placing extreme pressure on traditional operational models. Today's state of the art is either "pair-wise" collaboration, or "Over the top" loose coupling without effective end-to-end management. Platform In addition, businesses are shifting to platform businesses, whereby the business model is based on a platform. The platform creates value by connecting consumers and producers, and is owned by a curator. Revolution, book by Geoffrey Parker, Marshall Van Alstyne and Sangeet Paul Choudary Airbnb For example, Airbnb applies the platform business model to the accommodation business whereby they don't own any rooms. Instead, the company created and maintains a platform enabling individual partners in their ecosystem to offer rooms directly to customers. In return Airbnb takes a transaction fee for every rental arranged through their platform. © TM Forum 2018. All Rights Reserved. Page 8 of 184.

[Audio] Digital Services Reference Architecture Guide IG1157 DPRA Concepts & Principles The TM Forum is defining a Digital Reference Platform Architecture (DPRA), as a business architecture, a set of best practices and technical standards, metrics and open APIs that will be needed for the communications industry to collectively build the platform required to capture the global opportunities. Digital Value Fabric A digital ecosystem is an open socio-technical digital environment with properties of self-organization, aimed at building digital services to create value and revenue streams amongst networking partners. It provides access to resources, and supports collaboration, knowledge sharing and development of open and adaptive technologies and evolutionary business models, in an open environment which can span across different enterprise boundaries and different parties (operators, social networks). It clearly extends the traditional value chain beyond the evolutionary horizontal & vertical value chain paradigms to a full digital value fabric. This digital value fabric is also a characteristic of the complex relationships with producers, consumers and the platform, as businesses shift to the platform structure. A digital ecosystem is an open socio-technical digital environment with properties of self-organization, aimed at building digital services to create value and revenue streams amongst networking partners. Digital Services Reference Architecture (DSRA) The Digital Services Reference Architecture (DSRA) is the TM Forum's proposal to enable richer and yet open, distributed digital collaboration with the essential tools to support increasingly demanding technical and commercial models. © TM Forum 2018. All Rights Reserved. Page 9 of 184.

[Audio] Digital Services Reference Architecture Guide As more new products are assembled out of building blocks that are provided by a range of digital service providers, there is great opportunity, and growing complexity to be managed. The opportunity comes from placing a wide range of capabilities at a product designer's fingertips. The complexity comes from the distributed nature of those very capabilities – for example, my product may rely on the performance of your building block, building blocks from a 3rd enterprise delivered over a set of network capabilities provided by yet another enterprise – a network provider. This digital economy needs a set of standards and functions that allow product composers to learn about these capabilities, configure and fulfill them, monitor them, understand dependencies, and execute what may be multi-dimensional commercial and revenue sharing models among end users, component service suppliers, advertisers, etc. The DSRA aims to make this process simple, capable and standardized to the degree necessary. To this end, our proposed DSRA will enable collaboration and product composition from a broad set of building-block services spanning multiple companies, industries, clouds, networks and devices. And it will allow this composition to be accomplished with (if desired) commercial grade quality, accountability, business models and operational efficiencies. Finally, it will be as simple as possible, maximizing "loose coupling" and minimizing impacts on existing investments. It aims to enable, not replace. Open Digital Program The TM Forum's Open Digital Program (ODP) assumes that there will be not just one, but many ecosystems within the broader digital economy. These ecosystems must coexist, using some of the same enabling services but solving different problems; for instance, ecosystems focused on digital content and Machine-to-Machine (M2M) / Internet of Things (IoT), each leveraging similar sets of underlying cloud and network resources. © TM Forum 2018. All Rights Reserved. Page 10 of 184.

[Audio] Digital Services Reference Architecture Guide IG1157 DPRA The Digital Service Reference Architecture maps to the Actualization Platform view described in the Digital Platform Reference Architecture. Concepts & Principles 2.2. Enabling a Digital Ecosystem R17.5 What is the enabler for a Digital Ecosystem? A Digital Ecosystem is enabled by a federation of platforms that implement the Digital Service Reference Architecture (DSRA), and delivers three key value propositions: A Great User Experience – Users can access digital products, assembled from diverse building blocks, in the manner they expect. Robust Operations – Ecosystem participants, including partners, service providers and enterprises can conduct rich commerce as well as create and deploy those products and manage end-to-end performance. A Robust Developer Environment – Developers – both providers of component services and end-to-end product developers – have the tools and infrastructure to support both above goals. A Digital Ecosystem is enabled by a federation of platforms that implement the Digital Service Reference Architecture IG1157 DPRA Concepts & Principles The Business Capabilities required to achieve the above goals are described in the DPRA Business Capabilities view that maps to the Business Process Framework eTOM. Business Process Framework © TM Forum 2018. All Rights Reserved. Page 11 of 184.

[Audio] Digital Services Reference Architecture Guide Application Framework The implementation of these Business Capabilities, is the DSRA enabling the ecosystem. This is described as the DPRA Actualization Platform View that maps to the Application Framework TAM. 2.3. The DSRA Approach R17.5 What is the DSRA approach? DSRA is the name for the architecture that supports these collaborations, and specifies a set of best practices from leading edge ecosystems today, plus a set of new management capabilities designed to enable the three objectives above. The DSRA must meet two additional objectives, which at first glance may appear to be in conflict: 1. it must be distributed, spanning and encompassing many service providers and thus many platforms, and 2. it must support a logically unified approach so that the three objectives (above) may be met. © TM Forum 2018. All Rights Reserved. Page 12 of 184.

[Audio] Digital Services Reference Architecture Guide This implies: 1. a degree of federation, 2. some common supporting platform infrastructure and 3. a standardized method for ion and exposure of management functionality as end-to-end products are assembled from component services. Note, this "assembly" of component services into products is expected to be a recursive process. In the spirit of innovation and loose coupling, the DSRA assumes that most component web services are created, ed and exposed by various ecosystem partners, building a rich and changing library over time. In addition, the TM Forum believes that there exists a small set of platform capabilities that are necessary to support these ecosystems and should exist in each DSRA platform implementation. In this document we distinguish between two kinds of platform capabilities: 1. "Platform Capabilities" based on "Best Practices" culled from today's leading-edge cloud ecosystems, that the TM Forum believes are essential to the digital ecosystem and represents the best of current practices. TM Forum is making no effort to standardize such a capability, but rather to point out the importance of the availability of such a capability to the platform. Hence, these are referenced in the DSRA but not specified by the TM Forum. 2. "Platform Capabilities" that are required to meet the objectives set out in this document (e.g. Catalog Management). These represent the main work effort of the DSRA and often apply ongoing work of the TM Forum. There exists a small set of platform capabilities that are necessary to support these ecosystems and should exist in each DSRA platform implementation. IG1157 DPRA Concepts & Principles Any platform that intends to form part of future digital ecosystems should implement both the best practices and support these new "platform capabilities". The most important are shown in the diagram hereinafter, with more information available in IG1157 DPRA Concepts & Principles and on the ODE web site. Open Digital Ecosystem website © TM Forum 2018. All Rights Reserved. Page 13 of 184.

[Audio] Digital Services Reference Architecture Guide Any platform that intends to form part of future digital ecosystems should implement both the best practices and support these new "platform capabilities". The main DSRA work is an effort to describe each of these "platform capabilities", how they contribute to digital services management, and how to expose them to support distributed digital ecosystems. The following "platform capabilities" should be provided by the platform infrastructure that exposes services into one or more ecosystems. Note, each service provider (SP) could have its own DSRA exposure environment, but many smaller players may wish to use exposure environments provided by larger SPs or aggregators. Each of the following "platform capabilities" is intended to support an environment where N services, potentially from M different service providers, and even resident on K platforms, are composed ("mashed up") into a single product offering. They address the many questions across multiple parties about how one discovers, assembles, configures, assures, and charges for that composite product offering. This context is essential – it demands that information be exposed into a loosely coupled environment where the ultimate use and even composition environment is often un-known. The management services should not be confused with the functional services they support. The focus of DSRA is not about the functional services themselves but about their management. It is entirely possible that a digital service owner will offer a digital service – at which point it is blank or null, yet the service exists. © TM Forum 2018. All Rights Reserved. Page 14 of 184.

[Audio] Digital Services Reference Architecture Guide There is an implicit assumption that two kinds of services exist – functional services, most of which are real-time, and a set of supporting management services, many of which are not real-time, or at least not in the direct flow path of the service, but rather allow it to be discovered, configured, monitored etc. This distinction is of growing importance as the old paradigm of "network hardware" vs "OSS software" becomes increasingly obsolete. Most (but not all) of these platform capabilities, whether real-time or not, fall into the category of "management" services. One of the collaboration models is an API wholesale model, where an API provider with an API platform, uses APIs that are provided by another "backend" API provider owning a platform exposing APIs. In this model, the former API provider, can offer high value-added APIs by mashing up APIs, including those from the "backend" API provider. IG1157 DPRA Concepts & Principles Open Digital Ecosystem website The diagram hereinafter lists the platform capabilities that the TM Forum believes are necessary and desirable to support thriving, robust digital ecosystems. In all cases the objective is summarized. For some, if an industry best practice was generally accepted, that best practice may be noted. In other cases, TM Forum either has an interface/service that meets the objective, or plans to specify one. These too will be noted. More information is available in the DPRA whitepaper and on the TM Forum's ODE website. © TM Forum 2018. All Rights Reserved. Page 15 of 184.

[Audio] Digital Services Reference Architecture Guide 2.4. Related TM Forum Initiatives R17.5 To what other TM Forum initiatives does the DSRA relate? IG1157 DPRA Concepts & Principles The TM Forum Digital Platform Reference Architecture (DPRA) describes the business architecture, a set of best practices and technical standards, metrics and open APIs that will be needed for the communications industry to collectively enable platform business, with reference to TM Forum assets that are useful in this context. The DSRA maps to the Actualization Platform view described in the DPRA. B2B2X The TM Forum Internet of Everything Program's B2B2X Partnering initiative provides tools for forming and maintaining partnerships within a digital ecosystem. ZOOM TR262 Hybrid Network Management Platform Blueprint The TM Forum ZOOM project and the DSRA are related in that they represent specific uses of Frameworx layering. DSRA is a more general use case applicable to a broad array of digital services. ZOOM (Zero-Touch Orchestration, Operations and Management) is focused on a specific set of digital services including the management aspects of virtualized network services (NFV) such as SDN Controllers or Evolved Packet Core (EPC) related services. The ZOOM project also defines the Hybrid Infrastructure Platform (HIP) in TR262 Hybrid Network Management Platform Blueprint. HIP is a specific implementation of the DPRA and DSRA. APIs There is an ongoing effort within TM Forum to define Management APIs. For more information visit: Open Digital Ecosystem. Open Digital Ecosystem © TM Forum 2018. All Rights Reserved. Page 16 of 184.

[Audio] Digital Services Reference Architecture Guide 2.5. Who Should Get Involved R17.5 Who should get involved? The TM Forum is harnessing the best practices of its member companies and is working with other standards development organizations to deliver a reference blueprint for digital services, including APIs, information models, business processes, and extensive best practices for partnership and on-boarding. Active support and contributions by member company decision makers are critical. IoT The specification of this ecosystem marks the first comprehensive effort to understand and meet the needs of all digital services stakeholders: consumers, developers, providers, operators, and regulators. The beneficiaries extend beyond the communications industry to all stakeholders in the digital economy including Automotive, Media, Healthcare, Government and the Internet of Things (IoT). The TM Forum welcomes representatives from all different industries to take part, actively contribute to, and benefit from this initiative. Open Digital Program For more details on the information described herein or to become more actively involved in the initiative, visit us at the Open Digital Program website. © TM Forum 2018. All Rights Reserved. Page 17 of 184.

[Audio] Digital Services Reference Architecture Guide 3. DSRA Business Alignment Architecture R17.5 What are the characteristics of the business environment? Business drivers, requirements and models R17.5 This section of DSRA Guide document is intended for any company or person engaged in the implementation of Digital Services. The primary target audience are Business and Implementation Architects who establish the fundamental approaches and infrastructure their companies will use to participate in the Digital Service Ecosystem. Interaction patterns and orchestration R17.5 In this section, "Digital Service" is an umbrella term for any kind of virtualized service such as cloud computing, storage, applications, content or network. The key objectives of the DSRA Guide are to describe the: Main IT requirements and principles R17.5 Properties that the Digital Service components must have, as well as the business benefits that those properties will deliver. API identification and design R17.5 Principles and rules for making Digital Services. In this context, the Business Architecture: Helps to ensure the implementation is purely driven by business requirements derived from the relevant business models (business aligned implementation) Is demonstrating the business value and requirements of subsequent Technology Architecture work to key stakeholders, Defines the business drivers and scope, reflects the business models with related collaborations and partnering requirements. It also shapes the relevant process decomposition Presents the resulting implementation requirements (i.e. organization, processes and IT requirements) and principles that will be detailed in next sections So, it will describe from a business point of view the: Identified business drivers Business requirements to be considered when defining Digital Service Reference Architecture © TM Forum 2018. All Rights Reserved. Page 18 of 184.

[Audio] Digital Services Reference Architecture Guide Major business models to be supported, their common characteristics and resulting business interaction between involved parties o Digital Business Models assume a high degree of operations automation and systems support for human activities. The duration to deliver value once contracted to do so by a consumer is assumed to be supported by not only a technically enabled process, but is also assumed to be instrumented in detail to enable the management of the fulfillment of the order, the billing and payment for the value, and the delivery of sufficient fine-grained detail to provide for error correction and continuous improvement of the process. o High maturity of analytics capability is expected. Much of the value of a digital business is a rich stream of data that needs analytics to identify actionable trends. It is this stream of available information that informs business choices and delivers the data driven paradigm found in Digital Business models. o A high degree of flexibility with regards to strategy with utilization of infrastructure and products is expected. While automation of these aspects is not yet mature, maturing Digital Businesses are turning to manage market risk by providing for the capability for rapid adoption, change and deprecation of these traditionally stable portions of the business model. In its mature form, this adaption of the business model is referred to as a Platform Business model. In addition, it will describe from an IT point of view the: disruptive changes regarding business requirements functional scope covered by DSRA proposed implementation principles and architectural frameworks business requirements impact on processes and function to be handled by DSRA © TM Forum 2018. All Rights Reserved. Page 19 of 184.

[Audio] Digital Services Reference Architecture Guide Digital Value Fabric Figure 1: The Digital ecosystem value fabric The digital ecosystem is a value fabric, a mesh of interwoven, cooperating organizations and individuals or parties. To illustrate the scope covered by the DSRA Business Architecture, Figure 1 presents the digital service ecosystem in the form of a value fabric. Digital Value Fabric The value fabric is a mesh of interwoven, cooperating organizations and individuals or parties. It is an ideal concept for showing interaction among collaborating organizations and individuals, collectively called parties, in the digital ecosystem. Business drivers, requirements and models R17.5 Interaction patterns and orchestration R17.5 Main IT requirements and principles R17.5 API identification and design R17.5 3.1. Business drivers, requirements and models R17.5 What are the prevalent business drivers, requirements and models in digital services ecosystems? This section addresses: Business drivers R17.5 Business models R17.5 Business requirements R17.5 © TM Forum 2018. All Rights Reserved. Page 20 of 184.

[Audio] Digital Services Reference Architecture Guide 3.1.1. Business drivers R17.5 What are the business drivers related to Digital Services Development? The major business drivers and disruptions related to digital services development can be summarized as follows: A growing complexity R17.5 Needs for agility and simplicity R17.5 The development of new business and revenue opportunities R17.5 The need to control costs has consequences R17.5 A growing complexity R17.5 What complexity is driving and disrupting business? A growing complexity can be observed on many fronts. This growing complexity results in the need for a complete service management in a complex ecosystem. The Market is becoming more complex as growth of the digital world is driving increasing complexity for the providers who must deliver services that work reliably and deliver a great customer experience Services are becoming more complex as the market is increasingly fragmenting into discrete services because service providers introduce next generation network services combined with cloud hosting Players relationships are more complex as more complex value creation networks implies multi-lateral business interactions between players within the telecommunication industry and other adjacent industries This growing complexity results in the need for a complete service management in a complex ecosystem: as the number and types of service and service provider are mushrooming © TM Forum 2018. All Rights Reserved. Page 21 of 184.

[Audio] Digital Services Reference Architecture Guide each of them needing to work with the other requires having standards to work together in an open ecosystem, It is important to understand that the challenges of end-to-end service management exists regardless the set of business partnerships, and the complexity is multiplied exponentially as the number of partners in the service delivery chain increases. Needs for agility and simplicity R17.5 What are the agility and simplicity needs? There is a need for agility and simplicity. Keeping the business architecture simple is the only way to gain in agility. Agility means: The capability of companies to develop and deploy complex services extremely rapidly, by assembling resources from several players in an automated way The ability to quickly and cheaply adapt to changes regarding market, competition, business model and legislative requirements The ability to set up IT resources rapidly and to flex and scale quickly the amount of resources an enterprise needs in order to meet demand. Keeping the business architecture simple is the only way to gain in agility and is also a business concern. The development of new business and revenue opportunities R17.5 What is the impact on the development of new business and revenue opportunities? The development of new business and revenue opportunities is impacted in relation with business models, capability exposure and ability of 3rd parties to invent innovative services: © TM Forum 2018. All Rights Reserved. Page 22 of 184.

[Audio] Digital Services Reference Architecture Guide New business models: Business models Focus on wholesale, partners and enabling services such as: o Consumer oriented software and applications o Vertical industries (e.g. simplifying financial transactions, optimizing energy distribution, improving healthcare and education) With increasing partnership possibilities to deliver innovative services Integrating third party's building blocks in the end product/service delivered to the consumer (Open Innovation) Service, Data and networks assets are exposed: Via API such as: o Network API (access network selection, location information, etc.) o Service API (e.g. RCS, TV, OCC …) o Information System API (third party billing, sponsored data, authentication, customer profile, traffic patterns…) Allowing assets monetization as intermediary products, towards third parties that will integrate them into an end-product delivered to the consumer Providing additional revenue for the company exposing its asset and saving time and investment cost for company using these assets Giving third parties freedom to invent innovative services. The development of new business and revenue opportunities is impacted in relation with business models, capability exposure and ability of 3rd parties to invent innovative services. The need to control costs has consequences R17.5 What are the consequences of the need to control costs? © TM Forum 2018. All Rights Reserved. Page 23 of 184.

[Audio] Digital Services Reference Architecture Guide The need to control costs has consequences that manifest themselves in many forms. Need to simplify the way we do business. The need to simplify the way we do business, to reduce costs and cycle time i.e. doing more with less, or remaining cost neutral, as the digital service ecosystem is becoming more and more complex There is the need for minimizing customer and other players' interaction costs, as it is a key element of operational design and a major driver for solving the problems of managing across service boundaries. This can be achieved by providing all the appropriate information immediately accessible and actionable either on a customer portal or, possibly, via a customer service agent. 3.1.2. Business models R17.5 What is the challenge in defining business models for Digital Services? TM Forum This section presents the most common business models used for digital services based on the TM Forum Business Model Compendium that leveraged Alexander Osterwalder Business Model Canvas to structure the relevant information about each business model and to find commonalities. Business Model Compendium Alexander Osterwalder For Alexander Osterwalder, a business model describes the rationale of how an organization creates, delivers and captures value. Business Model Canvas B2B2X web So, the Business Model Canvas is a strategic management template for developing new or documenting existing business models. It is a visual chart with elements describing a firm's value proposition, infrastructure, customers, and finances. It assists firms in aligning their activities by illustrating potential trade-offs. delivery The starting point for business model innovation is a shared understanding of what a business model is. To reach this goal, we need a business model concept that everybody understands, that facilitates description and discussion, and to start from the same point and talk about the same thing. The challenge is that the concept must be simple, relevant, and intuitively understandable, while not © TM Forum 2018. All Rights Reserved. Page 24 of 184.

[Audio] Digital Services Reference Architecture Guide oversimplifying the complexities of how enterprises function. Alexander Osterwalder believes that a business model can best be described through nine basic building blocks that show the logic of how a company intends to make money. The challenge is that the concept must be simple, relevant, and intuitively understandable, while not oversimplifying the complexities of how enterprises function. These nine building blocks, foundation of the Business Model Canvas, are: 1. Customer Segment: CS; 2. Value Proposition: VP; 3. Channels: CH; 4. Customer Relationship: CR; 5. Revenue Stream: RS; 6. Key Resources: KR; 7. Key Activities: KA; 8. Key Partnerships: KP; 9. Cost Structure: CO. © TM Forum 2018. All Rights Reserved. Page 25 of 184.

[Audio] Digital Services Reference Architecture Guide Business Model Canvas Customer Key Partners Key Activities Value Propositions Relationships Customer Segments For whom are we creating value? Who are our most important customers? Who are our key partners? Who are our key suppliers? Which key resources are we acquiring from partners? Which key activities do partners perform? What key activities do our Value Propositions require? Our Distribution Channels? Customer Relationships? Revenue Streams? What type of relationship does each of our Customer Segment expect us to establish and maintain with them? Which ones have we established? how are they integrated with the rest of our business model? How costly are they? What value do we deliver to the customer? Which one of your customer's problems are we helping to solve? What bundles of products and services are we offering to each Customer Segment? Which customers' needs are we satisfying? Key Resources Channels What Key Resources do our Value Propositions require? Our Distribution Channels? Customer Relationships? Revenue Streams? Through which Channels do our Customer Segments want to be reached? How are we reaching them now? How are our Channel integrated? Which ones work best? Which ones are most costefficient? How are we integrating them with customers routines? Cost Structure Revenue Streams What re the most important costs inherent in our business model? Which Key Resources are most expensive? Which Key Activities are most expensive? For what Value are our Customers really willing to pay? For what do they currently pay? How are they currently paying? How would they prefer to pay? How much does each Revenue Stream contribute to overall revenue? Figure 2: Alexander Osterwalder Business Model Canvas © TM Forum 2018. All Rights Reserved. Page 26 of 184.

[Audio] Digital Services Reference Architecture Guide Alexander Osterwalder is focusing on how the value proposition is provided to the customer segments and which key partners, resources and activities (concept-tomarket) are required and their implication on the cost and the revenue side of the business model. TM Forum TM Forum enhanced Osterwalder's model to accommodate information on partner interaction (touchpoints) and drivers and barriers to establish the business model in the market. Business Model Compendium Documents already published by TM Forum provide a wide range of typical business models such as: B2B2X web delivery TM Forum B2B2X web delivery R17.5 What business models are covered by the TM Forum B2B2X Partnering Step by Step Guide? TR211 Online The TR211 Online B2B2X Partnering Step by Step Guide distinguishes following business models: "SaaS store" B2B2X Partnering Step by Step Guide "Smart TV" The "SaaS store" is the business model of an offer sold by several CSP where application and tools for SMB hosted in CSP Cloud and available in SaaS mode for CSP and Non CSP customers with free trial period and ATAWAD access. The "Smart TV" is he business model of an offer where a content provider and a CSP partner to provide a premium product based on higher quality delivery of streaming video leveraging their respective capabilities through common API. TM Forum Business Model Compendium R17.5 What business models are covered in the TM Forum Business Model Compendium? © TM Forum 2018. All Rights Reserved. Page 27 of 184.

[Audio] Digital Services Reference Architecture Guide TR218 B2B2X The TM Forum Partnering Guidebook: Concepts and Examples TR211 distinguishes following business models: Partnering Guidebook Step by Step Guide "Internet proxy" "Consumer brand" TR211 Online "Digital assets marketplace" B2B2X Partnering Step by Step Guide "SmartGrid" "Cloud Service Broker" 0.facebook.com The "Internet Proxy" is a business model based on an offer where mobile operators propose limited free access to popular Internet sites bundled with their data packages offerings. Specifically, it is based on 0.facebook.com offer available through more than 53 mobile operators in 45 countries and territories 139.com The "Consumer brand" is the business model of a converged telecommunications and Internet service based on an operator built and owned platform for rich communication services offered to their own subscriber base; the platform allows 3rd party to contribute to the offering, 3rd party brand bundled inside but services are offered as part of the operator branded product. It is based on China Mobile's 139.com service enabling those of China Mobile's post-paid subscribers who sign up for it to access a range of voice, messaging and Internet services, using multiple devices attached to a single SIM. The "Digital assets marketplace" is a business model where operators sell access to Network and Content Service Enablers to 3rd Party Developers that will have revenue sharing over their applications usage by customers. It is based on Portugal Telecom/SAPO Service Delivery Broker Marketplace which is a concept-to-cash solution, supporting services management from Development to the Marketplace The "SmartGrid" presents the business of a next-gen utility service provider enabled by one or more CSPs with an increased use of communications and a greater use of IT systems, that can support real-time services, including an increased interaction and integration of formerly separated systems. © TM Forum 2018. All Rights Reserved. Page 28 of 184.

[Audio] Digital Services Reference Architecture Guide The "Cloud Service Broker" presents a business model for Brokerage and management of all cloud service relevant aspects towards the upstream partners and customers and downstream partners. Cloud Services can be Software as a Service, Infrastructure as a Service, Platform as a Service. 3.1.3. Business requirements R17.5 What are the business requirements for Digital Services Development? In conjunction with major business drivers and disruptions previously presented, the main business requirements can be summarized along the following themes: Ability to develop new business and revenue opportunities R17.5 Digital Service Lifecycle R17.5 Digital Service Stakeholder interactions R17.5 High quality of experience R17.5 Miscellaneous Digital Service Characteristics R17.5 Partnership capabilities increase R17.5 Simplification and automation R17.5 Ability to develop new business and revenue opportunities R17.5 How is the ability to develop new business and revenue opportunities enabled? The ability to develop new business and revenue opportunities is enabled by: new business models allowing new capabilities New business models must be supported including capabilities such as: Business models Billing on behalf of (BoBo); Split billing; Business Process as a Service. New capabilities must be allowed: Easy personalization of offers and promotions targeting the buyer by using the buyer's profile; © TM Forum 2018. All Rights Reserved. Page 29 of 184.

[Audio] Digital Services Reference Architecture Guide Extreme flexibility for sellers to promote their products, allowing creation of dynamic product bundles, promotions, pricing, targeted offers, and even entirely new types of products; Ability to expose and monetize data and networks assets. Digital Service Lifecycle R17.5 What are requirements from a Digital Service Lifecycle perspective? The Digital Service Reference Architecture must be able to support the digital services lifecycle from developer to commercial actors & processes. The digital service lifecycle is organized in 3 phases summarized in the diagram below: 1. On-boarding digital service provided by another player 2. Adding value to this digital service by adding complementary services o Construction of operational E2E functional services o Creation of management services to operate the functional service 3. Delivering it to final customer i.e. operating the E2E services Figure 3: Digital service generic lifecycle Digital Service Stakeholder interactions R17.5 What are requirements related to the interactions between the different Stakeholders? © TM Forum 2018. All Rights Reserved. Page 30 of 184.

[Audio] Digital Services Reference Architecture Guide Interactions allowing building the digital service can become more and more complex depending on the number of stakeholders involved in service construction and delivery. This is illustrated by the diagram below where: Customer 1 buys service A from Digital Service Provider 1 (DSP1) DSP1 has composed service A with: o a syndicated service Z from DSP3; o a federated service Y from DSP2. DSP3 has composed syndicated service Z with: o a purchased service X; o a federated service W; o a syndicated service V coming from DSP4. Figure 4: Complex digital Service interactions High quality of experience R17.5 What is the quality of experience? The quality of experience is manifested for the user, the developer and operation. High quality user experience, whatever the service or content the user is consuming, for both: Seller: Provide support for the end-to-end product and offer lifecycle; Buyer: Provide rich and intuitive search, browse and navigation © TM Forum 2018. All Rights Reserved. Page 31 of 184.

[Audio] Digital Services Reference Architecture Guide High quality developer experience: The developer community must be provided with the tools and guidance needed to build easily the types of applications necessary to deliver great experiences High quality operation experience: All stakeholders in the service delivery and assurance processes need to be able to manage their services efficiently and effectively, notwithstanding that they rely on components hosted by different services providers in different clouds Miscellaneous Digital Service Characteristics R17.5 What are the general Digital Service Characteristics Requirements? The Digital Service Reference Architecture must be able to support the digital services business scaling, security, service awareness and versioning. Partnership capabilities increase R17.5 What are capabilities partnerships should embrace? Partnership capabilities must increase in terms of: End-to-end (i.e. complete) partnership management Flexible partner relationship Agile partner relationship End to end partner management: After implicit or explicit commercial agreement, automated Partner registration and on boarding including developer journey for API integration Federated catalogue management supporting aggregation of multiple 3rd Parties catalogues with a customized seamless experience. Automatic calculation of settlement and invoice for partners Automated "business process as services" (e.g. Billing on behalf of or trouble ticketing) subscription channel © TM Forum 2018. All Rights Reserved. Page 32 of 184.

[Audio] Digital Services Reference Architecture Guide Flexible partner relationship: Provide a flexible set of business relationships options for the participants in the ecosystem. For instance, a partner might be able to choose a relationship: o where the ecosystem markets, enable and charge for the usage of a partner's service and provide settlement periodically to the creator of the service; o that enables and operates the service while managing himself charging and billing functions, to only leverage the ecosystem to market. Agile partner relationship: Ecosystem participants can continuously improve the joint business model and are able to adapt to changes imposed by the market, competition, business model or legislative requirements. To enable this all participants must have the ability to: o measure KPIs and provide immediate feedback to their partners o adopt quickly and cheaply to changed requirements o expose new features quickly if required Simplification and automation R17.5 What are simplification and automation requirements? Simplification and automation requirements are: Automated processes whenever possible Homogeneous solution independently of the partner Easy integration between partners Partnership capabilities increase Fluidity of interactions and roles © TM Forum 2018. All Rights Reserved. Page 33 of 184.

[Audio] Digital Services Reference Architecture Guide "real time" expectation High availability system allowing to do installations of new functionality while the service continues to run with no impact on users Real-time creation of new products Real-time change of existing products 3.2. Interaction patterns and orchestration R17.5 What are the interaction patterns and orchestration in digital services ecosystems? Interaction patterns and orchestration for digital services ecosystems are described in this section in terms of: Common Characteristics of Business Models R17.5 Customer / Partner interactions R17.5 3.2.1. Common Characteristics of Business Models R17.5 What are common characteristics of business models in digital services ecosystems? The table below summarizes the common characteristics of the major part of the business models presented in the Business models section. Name Short Description Business Model Maturity level Priority Market players/competition Customer Segment Channel Relationship Multi-sided markets Online and automated on Self Service and © TM Forum 2018. All Rights Reserved. Page 34 of 184.

[Audio] Digital Services Reference Architecture Guide any web enabled device Retail: Enterprises and Mass MarketPartners: Digital Services Providers resellers automated Services (internet or mobile) Customer / Market Co-selling with 3rd parties Value Proposition Benefits: Product Offering Self-service capabilities One stop shopping Cost reduction Easy-to-use Easy-to-access Activities Resources Partners Platform set up C2M API and Portal set up Communication Service Providers SDK development Device Providers Partners management Network, hardware, device, software or content resources on boarding Service Delivery Platforms Providers contract negotiation Resource Providers Offer packaging FTE for personal assistance: customer support and Sales forces Software Providers Vendors training Marketing campaign Content Providers Platform development/ operations API / Portal development / maintenance Partner management Data Analytics and BI Cost Structure Revenue Streams © TM Forum 2018. All Rights Reserved. Page 35 of 184.

[Audio] Digital Services Reference Architecture Guide Partnerships costs: revenue sharing Marketing campaigns and packages Customer services: Recurring fees / One shot fees Enterprise Management FTE for Customer support and Sales forces Infrastructure set up and operations, Partner services: commission Platform set up and operations Portal development and maintenance Customer loyalty and ARPU increase New partnership and revenue sources Advertisement Business related Technical Barriers Strategic portfolio Revenue Streams Drivers Upstream Downstream Catalogue distribution Order receipt Request for delivery and delivery status Order delivery Touchpoints/Use Cases Service request and answer Service request and answer Settlement note and payment Technical problem and solution Invoice and Payment Deactivation request Bill dispute SLA data request Trouble ticket submission and resolution Order cancellation Business Process Model (a.k.a. eTOM) Information Model (a.k.a. SID) Other teams Impact on other TM Forum teams © TM Forum 2018. All Rights Reserved. Page 36 of 184.

[Audio] Digital Services Reference Architecture Guide (Critical issues etc.) Partners The most important common characteristics highlighted are as follows: Customer Segment type is multi-sided market involving enterprise and mass market customer and partners such as digital services providers, etc.; Channel type is mostly online and automated; Customer relationship is mostly automated and self-service and can be handled by third parties; Value proposition focuses on simplicity (one stop shopping, self-service, ATAWAD) and ease of use; Key activities performed are mostly focused on software development (API, SDK, SPF), partner management and offer marketing; Key Resources are Network, hardware, device software and content one plus FTE for assistance, IT development and partner management; There is an extensive Partner Network; The Cost structure is value driven, variable, mostly IT and revenue sharing costs; Revenue streams come from customer service and service provided to partners. 3.2.2. Customer / Partner interactions R17.5 What are Customer / Partner interactions in digital services ecosystems? Business models New business models consist in multi-actor scenarios with dependencies on other party's processes and actions, as well as various interactions between the different actors. The diagram below presents the interactions between customer and partners during digital service lifecycle. It is a typical example based on a mix of real world offers (a mobile security offer and a medical image sharing offer) and it depicts interactions in a simple use case where only two partners are involved in digital service management. © TM Forum 2018. All Rights Reserved. Page 37 of 184.

[Audio] Digital Services Reference Architecture Guide Figure 5: Typical customer / partner journey In this use case, Partner A has the commercial relationship with final customer and partner B provides a product or service that partner A resells to final customer. Main touch points between partners involve: Catalogue management; Digital service ordering (including cancellation); Digital service delivery; Digital service use; Billing and settlement; Trouble tickets management; SLA management (not displayed in this diagram). 3.3. Main IT requirements and principles R17.5 What are the IT requirements and principles? Main IT requirements and principles are grouped according to following themes: Disruptive changes for IT regarding business requirements R17.5 IT Architecture requirements R17.5 Proposed IT principles / architectural framework R17.5 Impacted Business processes and positioning versus eTOM R17.5 Functions to be handled by DSRA and positioning versus TAM R17.5 © TM Forum 2018. All Rights Reserved. Page 38 of 184.

[Audio] Digital Services Reference Architecture Guide 3.3.1. Disruptive changes for IT regarding business requirements R17.5 What are the disruptive changes for IT regarding business requirements? Regarding business requirements presented previously, the most disruptive changes brought about for IT are related to its ability to: Support development of new business and revenue opportunities relying on: o New business models including features such as Billing on Behalf of, split billing, business processes as a service; o New capabilities such as personalization of offers or flexibility for their promotion; o Ability to expose and monetize data and network assets; o Seamless access to DSP offers & products catalogues. Support the digital services lifecycle from offer creation to customer delivery and support with the following characteristics: o Automated processes whenever possible; o Flexible, homogeneous and generic solution; o Easy integration between partners leading to the need of open interfaces; o "real time" behavior. Manage partners industrially meaning: o An automated and end to end (from partner registration to billing and settlement) partner management; o A flexible partner relationship allowing partners to choose between several levels of services. Provide a great user, developer and operation experience, based on an end to end digital service management and monitoring. 3.3.2. IT Architecture requirements R17.5 What are the IT Architecture requirements? The IT Architecture requirements are described in terms of: The Functional scope to be covered by DSRA R17.5 Types of APIs managed in the DSRA R17.5 The Functional scope to be covered by DSRA R17.5 What is the functional scope to be covered by DSRA? © TM Forum 2018. All Rights Reserved. Page 39 of 184.

[Audio] Digital Services Reference Architecture Guide From a functional point of view, the Digital Service Reference Architecture must cover: Digital Service (as a product) lifecycle management from new product concept to possible withdrawal: o Service construction; o Service monitoring. Digital service fulfilment, assurance, billing and revenue management: o Customer identification and authentication; o Catalog management; o Ordering and delivery management; o Billing and invoicing; o Customer financial management (payment, collections); o Customer problem management; o SLA management; Partners and interactions with partners management: o Partner on-boarding including developer journey management; o Contract management; o Partner catalog management; o Billing and settlements including assessment and approval; o Partner support management; o Physical goods delivery management (for example, if partner provide a connected object). Some impacted processes and functions are not specific to digital services. The diagram below illustrates DSRA functional scope. © TM Forum 2018. All Rights Reserved. Page 40 of 184.

[Audio] Digital Services Reference Architecture Guide Figure 6: Digital services functional architecture scope Types of APIs managed in the DSRA R17.5 What are the type of API types managed by the DSRA? API managed in Digital Services Reference Architecture can be classified into 2 types: 1. Service management API also called management API; 2. Service usage API also called Functional API. APIs managed in the Digital Services Reference Architecture can be classified into 2 types: management APIs and Functional APIs. A Functional API reflects the service provided and used alone or bundled to deliver directly the service or to build an associated application. It exposes assets and encompasses a wide range of service / resources such as: Video; Communications; Cloud; Security; © TM Forum 2018. All Rights Reserved. Page 41 of 184.

[Audio] Digital Services Reference Architecture Guide Data; Network; Etc. A Management API allows to perform all management operations before, during and after the use of a service such as: Customer registration; Customer account creation; Service ordering; Service delivery; Partner settlement; Service monitoring; Trouble management; Etc. The diagram below illustrates the positioning of functional and management API. Figure 7: Functional API and management API 3.3.3. Proposed IT principles / architectural framework R17.5 What are the proposed IT principles and Architectural Framework? © TM Forum 2018. All Rights Reserved. Page 42 of 184.

[Audio] Digital Services Reference Architecture Guide The IT principles and Architectural framework for DSRA are: Layered exchange architecture R17.5 Flexible, simple and robust set of functions R17.5 Open API exposure R17.5 Use of a standard management API R17.5 Federated catalog management R17.5 Modular capabilities in business process management R17.5 Flexible role and rights management for 3rd parties R17.5 Analytics capabilities R17.5 Runtime performance R17.5 Online autonomy and availability for services and functions R17.5 Business contribution importance of each IT principle R17.5 This section ends with an overview of the business contribution importance of each IT principle. Layered exchange architecture R17.5 All API based exchanges between platforms are handled by a technical architecture composed of 3 layers: Implementation layer: network, infrastructure or IT platform delivering services such as telecommunications services, storage or processing services, cloud services, all types of data and video services; Exposition layer: brokerage, federated identity and profile management, transaction management, event notification management, service catalogue…; Consumption layer: channels, marketplace, store… The business architecture is also layered and will differentiate roles like infrastructure enabler, service enabler, aggregator, service provider, etc., each business role needing the 3 technical layers as described above. The diagram below illustrates this architecture. © TM Forum 2018. All Rights Reserved. Page 43 of 184.

[Audio] Digital Services Reference Architecture Guide Figure 8: Layered Architecture (simplified) Flexible, simple and robust set of functions R17.5 The DSRA must support the following BSS functions: Partner management (registration, Contracts management, invoicing, settlements, support management, etc.); Retail customer management (customer registration, billing account administration, invoicing, financial management support, etc.); Order management (capture, validation,) for partner and retail customer; Offer & Product catalog management; Installed offer and products management; Rating and bill calculation. Main relation between partner and retail customer management lies in billing domain as the partner will be invoiced / settled based on retail customer consumption. B2B2X Business models Having a flexible set of functions is mandatory to be able to create value networks based on "business model factories" managing B2B2X contractual relations. In such situation, the offer is not a classic product but an offer (such "as "Billing on Behalf of" for example) based on and operated by a collection of processes aka "business process as a service" and determining each player role in the value chain. So, flexible assignment of functions among players is essential to provide such capabilities and support different kinds of business models especially B2B2X ones. © TM Forum 2018. All Rights Reserved. Page 44 of 184.

[Audio] Digital Services Reference Architecture Guide Open API exposure R17.5 API exposure means: Accessibility before run phase by developer; Use during run phase. APIs must be extremely easy to use and access: To access via a simple self-service web portal: to maximize reach and adoption among developers; To use via the exposition layer: to facilitate communication and integration of software between a company and its business partners. Offering APIs in a self-service mode: To increase dramatically agility with partners; To reduce integration costs; To spur innovation and open innovation. DSRA will allow exposing 3 kinds of API: Private APIs used internally by each player (a company or its business partners) to facilitate the integration of different applications and systems used within its IT Restricted APIs used to facilitate communication and integration of software between a company and some selected business partners Public APIs, by contrast, allow companies to publicly expose information & functionalities of one or various systems & applications to third parties that do not necessarily have a business relationship with them Use of a standard management API R17.5 To facilitate interoperability with partners and reduce integration cost, the DSRA must rely on a set of well documented standard management API such as the TM Forum ones. APIs currently specified by the TM Forum encompass: Customer and Party management; Product, service and resources Ordering; Product, service and resources catalogue; Product, service and resources inventory; Trouble ticket management; © TM Forum 2018. All Rights Reserved. Page 45 of 184.

[Audio] Digital Services Reference Architecture Guide Usage management; Billing account (CustomerBillSpec) management; Invoice line (applied customer billing charge) management; Settlement note advice Management. Federated catalog management R17.5 The term "catalog" designates a database collecting all useful information concerning offers, the products, services, resources and entities of a company. With development of partnerships, the catalog is extended to information about offers that customers can buy from a company's partner and about products and services that a company can purchase from a partner to constitute an offer or as an element of his offer. This leads to the need of federated catalog management. A federated catalog: Supports aggregation and translation of multiple catalogs into a single federated catalog; Supports inclusion of partner/supplier/developer offers as product offers into a federated catalog; Support multiple ISVs (Independent Software Vendors) and their catalogs with a customized catalog experience; Is multi-tenant and hosts multiple catalogs in the most cost-effective manner providing isolation between them. Support associated business processes (ordering, fulfillment, assurance and charging for these offers etc.) Modular capabilities in business process management R17.5 DSRA must allow building business processes based on a set of modular and reusable sub-processes and functions. Several processes must be able to share agnostic functions and sub-processes thanks to a modular architecture based on a normalized and shared services approach. This principle allows proposing a flexible set of business relationship options also allowing functions and data mutualization. In addition, it improves Information Systems (IS) interoperability and facilitates service exposure towards partners. To do so, use of a BPM engine allows ability to: Describe sub processes that can be used or not depending on the player position in value chain; © TM Forum 2018. All Rights Reserved. Page 46 of 184.

[Audio] Digital Services Reference Architecture Guide Standardize and automate the exchange process between players. Flexible role and rights management for 3rd parties R17.5 For each party, DSRA manages associated roles and rights (usage, operation, and administration) stored in repositories depending on its position in the value chain. For example, the Assignment of a role to a partner (supplier, distributor, customer, etc.) opens to him rights to: Access to partner portal; Access to all APIs associated with the chosen offer; Supply its product catalog. In addition: the roles of a party must be easily and quickly modified depending on party lifecycle events; DSRA allows consent management, i.e. a way to authorize parties give other parties access to data. Similarly, rights related to a role must be easily and quickly modified. Analytics capabilities R17.5 Analytics provide the ability to interrogate Event Logs in a common and standard way. It collects information from any source and exposes services related to these data exploitation. It allows improving User experience by providing: o Proactive notification of issues. Developer experience by providing: o Dashboard; o Reporting / analysis capabilities Operations experience by providing o Additional security to manage and perform correctly Information Security processes; o Fault tracking; o Reporting / analysis possibilities enabling architecture scaling; © TM Forum 2018. All Rights Reserved. Page 47 of 184.

[Audio] Digital Services Reference Architecture Guide o Cost Analysis. Runtime performance R17.5 DSRA must allow to: Install new functionality while the service catalog continues to run without impact on users; Create new products or change existing products in real time; Support multi-tenancy; Provision / de-provision environments rapidly with no associated hardware provisioning; Reconfigure dynamically provider chains to work around failures as soon as they are detected. Online autonomy and availability for services and functions R17.5 DSRA provides a web portal and automated interfaces (standard API, URL call, sending files). The Partner management portal exposes self-service APIs. Availability of web portal and automated interfaces allow customer and partners to be autonomous and interact quickly with service provider. Web portal and automated interfaces allow managing all interactions between a company and its customers or partners such as: Customer/ partner management; Online ordering; Installed Offer and Product Management; Customer / partner support; E-billing Business contribution importance of each IT principle R17.5 The following matrix shows the business contribution importance of each IT principle. © TM Forum 2018. All Rights Reserved. Page 48 of 184.

[Audio] Digital Services Reference Architecture Guide This matrix can be read two ways: by line, it shows the contribution of IT principle to business objectives; by column it gives the IT initiatives which should be achieved to provide expected benefits for a given business requirement. Overall, it appears that a business driver cannot be satisfied with a single IT principle and that an IT principle provides benefits for several business drivers. Business requirem ent Layered architec ture Run time performa nce Open APIs expos ure Federate d catalog manage ment Analytic s capabili ties Use of stand ard API Modular capabiliti es in business process manage ment Flexible role and rights manage ment for 3rd parties Flexibl e, simple and robust set of functi ons Online autono my and availabi lity for service s and functio ns Support of new business models Ability to expose and monetize data and network assets "real time" behavior Flexible, homogen eous and generic solution Automate d process Easy integratio n between partners Automate d and end to end partner managem ent flexible partner relationshi p Great user, © TM Forum 2018. All Rights Reserved. Page 49 of 184.

[Audio] Digital Services Reference Architecture Guide Business requirem ent Layered architec ture Run time performa nce Open APIs expos ure Federate d catalog manage ment Analytic s capabili ties Use of stand ard API Modular capabiliti es in business process manage ment Flexible role and rights manage ment for 3rd parties Flexibl e, simple and robust set of functi ons Online autono my and availabi lity for service s and functio ns developer and operation experienc e 3.3.4. Impacted Business processes and positioning versus eTOM R17.5 What are the impacted business processes? The table below summarizes the eTOM business process being part of DSRA scope. For each of them, it provides: The actors involved in the process: o The digital service provider is the one selling the service to the final customer; Business Process Framework o Infrastructure / enabling service providers supply to digital service provider services or resources used to build the offer sold to final customer. The IT principles described above impacting the process; The high-level touchpoints between actors. It is partly based on a summary of technical specifications of B2B Interaction Business Processes contributed by NBNCo Impacted Assurance processes R17.5 Impacted Billing and Revenue Management processes R17.5 Impacted Fulfillment processes R17.5 Impacted Operation Support and Readiness processes R17.5 Impacted Transversal processes R17.5 © TM Forum 2018. All Rights Reserved. Page 50 of 184.