This paper describes TIM technological effort and approach towards a platform based business model, based on state of the art microservices architecture, extensive API development for both internal and external developers and partners that will leverage the upcoming 5G deployment.
The telecom word is under continuous change. More and more data and voice connectivity services are becoming a commodity. Competition is increasing, and also several Cloud-based companies offer appealing communication services. In such an articulated market, a Telco Operator or better “Service Provider” needs to explore new business approaches and rethink how to stay relevant in its reference market.
There are several ways to shift gears and go beyond the status of a simple commodity, exploring more promising approaches and rising from a connectivity-based service to a full-fledged platform . The Telco Business Platform is a way to discover new business domains and increase opportunities in already covered ones, where the value is the ability to create, maintain and improve interactions among people, enterprises and society at large, generating value from those interactions.
In TIM we are convinced that Telco Operators are in the position to offer facilitation and innovate the interaction, through their unique capabilities such latency control, capillary presence at the edge of the network, close to the customer, and on the territory, end2end performance monitoring of the network, differentiated quality and reliability provision, network-based analytics streaming, mobility and full geographical coverage, extensive consumer and business customer base allowing the creation of a completely new business experience.
This is a radical change in the way Telcos look at market and induces a similarly radical change in the way the technology is used, implemented and managed.
Telecom Operators need to rethink their fundamental technical architecture, which capabilities and business functionalities to implement and how to foster a larger ecosystem. Good platform business requires support for an open and heterogeneous ecosystem to create value for all participants.
The platform-oriented business moves the focus from “doing” to “enabling”, from improving a product with new features to adding new networks and communities to their ecosystem.
This evolution is strictly connected to the “digital” transformation of all business segments and cannot be accomplished without proper technological support: the use of correct technologies is one of the key enablers of the platform transformation of any company and Telcos are no exception.
Introduction of 5G technologies will strongly increase the power and possibilities of the business platforms, being the first network specifically designed to support also not-human interactions. 5G will bring new relevant capabilities perfectly aligned with the business platform approach.
What we are designing is the 5G Digital Business Platform with the objectives to embrace platform thinking while adding new Telco-specific features, services and information to the traditional business platform.
5G Digital Business Platform is also targeted to the internal organization (e.g. Lines of Business) use the platform to create products and services for end customers. From this point of view the Telco’s Line of Business are regarded as ecosystem participants, exactly as any other external entity.
Of course, there are challenges and risks associated to this approach, but the outcome will be very rewarding. Most probably, the major risks to manage are related to new technology (sometimes not fully proven at scale) and from the inability to see and size risks, to explore, to learn, to change and adapt.
On the other side, “do nothing” is not a viable option and the approach described in the following is promising not only for the Telco but also for all involved entities like LoBs, end customers and partners.
5G Digital Business Platform
This section describes the approach we take to realize the 5G Digital Business Platform, what are the major component and what is the evolution path we are implementing.
Design Goals and Principles
Having a “good” architecture has been the dream of technical people for ages, e.g. Vitruvius, the Roman architect of the 1st century BC, indicated the three goals of architecture:
- Utility: It should be useful for the people using it; that is, it should solve today’s problems in an effective and efficient way;
- Durability: it should stand up robustly and remain in good condition; we could think to this as the need of being resilient to unexpected and be ready to answer to tomorrow’s requests as well;
- Beauty: it should delight people and raise their spirits. We can say that it should stimulate people around it to a “call to action”.
These goals, coming from civil constructions architecture, as still largely applicable to architectures in other technical fields.
The question today is how to reach the goals, finding the right balance among capabilities, time to realize them and needed investments. The principles to follow in this path are as follows:
- Decouple as much as possible business capabilities from all the rest and make this common to everybody. Use separation of concerns to realize loosely coupled functionalities so that each can evolve without impacting the overall solution.
- Empower the use autonomous systems. Automation is good but it is just the first step, while the ability to act in autonomy – abiding by policies and rules – is the approach to inject intelligence in the system.
- Leverage Artificial Intelligence at scale and explore new technologies in their early stages, to quickly validate them and anticipate potential benefits.
The picture below describes the main functional blocks of the 5G Digital Business Platform.
The heart of the platform is the Intelligence functional block. It merges capabilities to collect and retain data, transform it into useful information and take actions accordingly. The general approach is that information can be extracted and properly used leveraging on available data and event. To stress the importance of this functionality, all the remain domain are linked to the Intelligent functional block: the same functional block implements features that can be used across the entire platform.
The second “common” functional block is the Cloud Native Infrastructure. It provides services and support to all other functionalities, so they can focus on their specific business value.
The Communication functional block represents the well-known domain for a Telco Operator where Access (both radio and fixed), Transport (ideally all-IP over DWDM) and well as Core (e.g. user authentication, charging, voice, data and video services) technologies are located.
Correct management of the entire life cycle of a “Customer” (in a wider sense, not only end customer but also partner, supplier …) is a differentiating factor for all Telco Operators. Having this relevant role requires specific capabilities for all customer touch points, from prospect to sales and post-sales. The Customer functional block in the picture underlies the importance of these systems.
The Exposure functional block is the abstraction layer that provides all needed products, services and information to external entities (the “Customers” in the wide sense discussed above). It shadows the internal complexity and also protects the platform from malicious and inappropriate utilization (based on rules and policies defined within Security & Privacy). The exposure is composed by different entities that will grow hand in hand with business, starting from simpler SDKs to ease integrations by developers to more complete solutions able to provide complex services.
The external entities on the top of the picture collectively form the “ecosystem”; as such, they represent the main stakeholders of the 5G Digital Business Platform.
As already outlined above, the Telco’s Line of Business are regarded as ecosystem participants, exactly as any other external entity, as they are able (and enabled) to create products and services for end user customer.
The idea of block Data (top-left, external to the platform) is to consider external data in combination with internally generated data (owned by the Telco Operator) whenever this makes sense to better understand the market, the customer base and in general the needs of all platform stakeholders.
The external Cloud is also a relevant component. 5G Digital Business Platform is hybrid by design and will use external cloud services (in its different varieties such as IaaS and SaaS) every time this creates, directly or indirectly, value for the stakeholder. What is important to underline is that the orchestration and balance between different public provider and internal cloud will strictly remain a platform mandate.
The Deployment model is a more detailed view on how to implement the solution in practical terms. It is the “how”. We want to follow a Cloud Native paradigm to get all the benefits for faster time to market and increased flexibility.
The Cloud Native Environment is a system designed to provide applications with a dynamic software Infrastructure with useful abstraction layers, able to provide efficiency, scalability, operability, observability, resiliency so that applications can focus fully on functional and business capabilities.
The Cloud Native Environment has a high degree of autonomy, implying automation combined with intelligence: manual operations are required only in exceptional cases, when the environment can’t autonomously address and solve an issue.
The Cloud Native Environment requires that all processes, e.g. Application Design & Development, are realized following the “zero human touch” paradigm leveraging on Automation Tools.
The Cloud Native Environment is composed by single – at least logically – Cloud Native Infrastructure (CNI) and Cloud Native Applications (CNAs) running on it.
The Cloud Native Infrastructure is infrastructure that is hidden behind useful abstractions, autonomously managed by software, and has the purpose of managing and running applications leveraging on standardized and common way (to all application).
In the CNI, Abstraction layers and Automation tools allow exposing platform services in such a way that application can be designed independently from physical infrastructure, deployed and managed by the CNI autonomously through automation.
The CNI provides to all Cloud Native Application Efficiency (for scheduling different resources like compute, network, etc.”), Scalability (elastic fine-grained scaling), Operability (Provisioning, Orchestration and Automation, Runtime and Isolation, Service Discovery), Observability (Monitoring and Logging, Metrics Aggregation), Resiliency (Load Balancing/Shedding, Circuit Breaking, Debugging).
As mentioned, a Cloud Native Application implements specific business or support functionalities needed to run the business. It is a workload designed to natively exploit and use services offered by the Cloud Native Infrastructure (be it from a private or public provider), expressing its needs in a declarative way. Following this paradigm, the developer can optimize coding time by focusing on service and business logic only, with a gain on application development and time to market.
Despite not mandatory Microservices, Containerization, and a Declarative Interaction model are “the facto” way to implement CNAs, to allow high service agility, scaling and automated management.
In the Microservices-based Architecture the Application is partitioned into smaller components called Microservices, balancing the advantages deriving from fine-grained decompositions (increased flexibility, parts that are singularly more manageable, increased chance of reuse, etc.) with the related drawbacks (increased complexity in interactions between software modules, increased overhead, coupling between parts).
A Microservice implements a clearly context bounded capability and, together with other microservices, participating in the composition of an application. Microservices have to be designed to allow a high degree of automation and to be independent from the infrastructure, so that they will be “at home” in the highly dynamic infrastructure environment provided by the CNI.
Several CNAs are present in the platform and collaborate following at a different level the same architecture paradigm, inspired by microservices: each CNA provides its own services, exposed through a well-defined and publicly available interface that is kept stable in time (or at least evolved to avoid integration impacts), much like what a microservice does theoretically, but with a broader scope.
Before closing this section is important to notice that the Cloud Native Environment is a distributed system running as a logical unit entity, but physically deployed across a few large Data Center as well as into geographically distributed mini or micro Data Centers, as in the Figure 4.
Cloud Native infrastructure should be:
- able to manage the geographically distributed solution including underlying communication entities like access, transport, etc.
- let Cloud Native Applications to run centrally or across several geographically distributed sites, abiding by specific policies based on criteria that are geographically sensitive (such as distance, latency, etc.)
- allow Cloud Native Applications to be moved among different sites in a seamless fashion, based on defined rules and specific, contingent needs.
Innovation and Existing Operational Systems
What described above is the main target deployment architecture. Because we do not start from scratch, we need to include in the picture also the already existing solutions and technical artifacts.
In other words, the evolution path to the target architecture and deployment model should have also the goal of maximizing reuse of existing systems where they are still capable of bringing value.
To reach this goal, several options can be defined, as depicted below.
There is no single optimal choice, and the approach to take is strictly related to starting point, as well as what kind of services need to be provided to what customer segment. Just as example, for a very specific vertical service in a limited geographical area the full Greenfield approach can be easily selected; on the contrary, for large eMBB services to all consumers the same solution is surely not the optimal one, at least because of the elapsed time needed to reach the whole customer base with good coverage.
In our case we select the “Greenfield vs Brownfield” option leveraging on new available technology as primary choice (even if some existing system or component would do that functionality), more precisely we follow the golden rules below to define when to use the Greenfield way:
- Use New Technology if…
- It provides savings in investments and/or recurrent costs
- Does not introduce any Vendor lock-in
- Supports hybrid, mixed solutions that include interaction with existing systems
- Reuse Existing Assets if…
- They can be integrated with new technology
- Can potentially evolve into a new solution based on the new technology
Approaching the realization of the 5G Digital Business Platform having also in mind to reuse existing technology asset (typically Operational Systems) put additional requirements on the architecture. The proposed architecture needs to be able to:
- allow implementing new components (i.e. Services) that realize business function capabilities
- integrate “by design” the Operational Systems we want to re-use and at the same time allow potential replacement with brand new services.
The picture below describes the architecture able to give right answer for both points. The software architecture is based on service-centric architecture paradigm extended to also include the existing Operational System.
All external entities that need to interact with the 5G Digital Business Platform do this through an abstraction layer realized by the “External API GTW”. It is a single point of access where all external entities (customer, partner …) are authenticated and authorized and where specific policies are applied also to prevent unwanted use of the platform and protect it.
The Operational Systems are on the opposite side (i.e. at the bottom) and the interworking with each Operational system is realized by “Internal API GWs”. All Operational systems are clustered into separate sets and each set is exposed through a different GTW APIs. Typical Operational systems of the Telco’s environment include BSS (CRM, billing), OSS (alarm management, performance monitoring) as well as Network (HSS, EPC, IP, RAN).
This approach is well suited when some form of API GTWs are already present even if they do not control all the Operational System, which is usually the case for brownfield Telco Operators. It is also a way to apply separation of concerns, limiting interaction when not needed and enabling its tracking to ease management.
Sometimes Operational system are not able to interact natively (i.e. they do not expose any form of APIs), and so some level of customization to realize a “wrapper” around Operational system is needed.
On top of the Operational system there could optionally be an “APIs Integration Layer”, that is basically a functional layer able to:
- Implement some form of logic to elaborate data coming from Operational systems, and expose as unique result to APIs consumer.
- Realize an “event driven” cache. In such a way the upper layer can access to fresh data without interrogating the Operational system. This of course requires careful selection of the technology to ensure good performance in case of high load and easy management of the cache life cycle.
In addition to allow integration with existing Operational system, the same architecture is also suited for innovation.
Rounded elements named Service are where the innovation takes place. Service is a software artifact made (or bought) ideally following the microservices pattern and realizes a well-defined “functionally” useful for one or more needs. The following example will hopefully help highlight the importance of “Services” as innovation enablers:
- For a Video Service provider, the “recommendation engine” for movies to suggest to a specific customer
- For a Mobile Telco Operator, the capability to obtain a “personalized offer” to increment customer loyalty every time customer logs into the App
- For a Fixed Telco Operator, the ability to provide a set of connection points to an enterprise, let the enterprise manage the overlay.
So, a “Service” can be simple or complex, but in any case, is a logical component that can be usually reused for different customer services or products.
Every Service interacts only via APIs (either producing or consuming them) and lives behind a specific Internal API GTWs, so it is e.g. extremely easy to know and monitor all entities consuming its APIs; at the same time, each Service can leverage on data that are available in the Operation system like any other entity.
There are two different interaction models at the higher level.
In the first, external systems are looking for data placed in an Operational system and these do not need further elaboration: this is for example the path of API calls “1a”/”1b”. The external API GTW, after authentication, authorization and optionally protocol adaptation, passes the request to the API Integration layer where the requested data might be cached or, otherwise, directly to the Operational System involved. This is the simpler interaction model and is appropriate every time some data are needed without further elaboration.
The second interaction model (path involving the “2*” calls) happens when some services are available to perform a specific logic that could potentially be complex, for example an insight of the customer feeling leverages on some sentimental analysis. In this case the external entity (again through the External API GTW, to cater for authentication and authorization) reaches the specific Service(s) behind an Internal API GTW, so that the functionality can also be reused by other Services (e.g. future ones).
Services are software components, ideally compliant with most of the microservice-based architecture paradigms (as discussed before) and able to realize specific logic as part of wider business logic.
As such, Services are the way to foster innovation because it will be possible to introduce new functionalities without changing the software architecture and without requiring large system integration effort, thanks to the “contract” provided by the stability of the API they will expose. In other words, this means possibility to increase features offered by the platform, ability to test new capabilities and try out alternative solutions with an almost “plug & play” approach.
Data and voice services still represent a large part of a Telco Operator’s revenues, but are also increasingly becoming a commodity and so vulnerable to price erosion. Telco Operators needs to rethink their approach to the market, exploring new opportunities in traditional domains as well as in new ones.
The introduction of 5G is the compelling event; combining 5G technology with platform thinking has the potential to create an exciting new way to interact with customers, partners, suppliers and society at large. In TIM we are building a 5G Digital Business Platform as the enabler to all the stakeholders for the creation of a completely new business experience. The internal Telco organization (e.g. Lines of Business) will greatly benefit from the same Platform approach being able to create by themselves new products and services with short time to market and increased efficiency.
The 5G Digital Business Platform will be enriched by Telco specific capabilities (such as latency exposure, network slicing, massive device connection, ultra-reliability) that cannot be realized without 5G – at least not in a sustainable way. This is realized by adopting new market-proven technology paradigms and solutions, in particular we strongly enforce a cloud native approach in architectures and deployments, we put a big attention to microservice architectures and orchestration tools, we are designing with a strong focus on Artificial Intelligence that should be leveraged at scale to achieve the advantages of autonomous systems.
This journey has just started and the first evidences are very promising, with positive feedbacks from the many players (vendors, partners, key customers, peers) we have engaged in these early steps. TIM 5G trials already started in 2017 in the North of Italy in Torino and Genova, in the South in Bari and Matera, in the center of Italy in Repubblica di San Marino are involving both all the main technology providers from one side, and more than 70 partners on the service side. With the approaching commercial 5G launch, the ability to combine the digital opportunities in the traditional Telco space with the new capabilities brought by 5G opens the chance for the Telco Operator to play a transformative role in the ecosystem and to get its fair share of the digital value.