In this fourth blog post about the TM Forum report on Orchestration, we look at key steps and architectural requirements service providers must consider as they move toward the Operations Center of the Future (OpCF).
Participants in workshops and Catalyst projects (including CIOs and VPs in networking and operations, network and systems architects, IT managers, OSS/BSS directors, and software developers) have responded to ranked seven orchestration components in order of importance.
Here are some takeaways from the report.
Close to forty percent of participants ranked common information models and APIs as their number one concern, while two-thirds put standardized patterns in their top-three. According to Shahar Steiff, Assistant Vice President, New Technology, PCCW Global, end-to-end service orchestration is a lot like playing with Lego blocks and Meccano parts—it’s easy until you try to combine them. Network operators must partner to deliver the services customers are demanding, but some partners don’t speak the same language. The joint MEF and TM Forum Network-as-a-service Catalyst is developing the common language, definitions, information models and APIs needed to help service providers automatically order, provision, manage and assure virtualized services across partners’ boundaries. Using Catalyst, time-to-service-delivery can be reduced from as long as three months to fewer than ten minutes, with the potential to get that down to milliseconds in future phases. Time-to-market is faster because there is no physical equipment to install. Service providers will have to agree to use the same information and data models along with APIs so that orchestrators in different domains can communicate. This, combined with intent-based management (which abstracts the complexity of the network and uses a customer’s intent and policy to manage it), allows service providers to automate provisioning and management, end to end.
While it is unlikely that the industry will coalesce around a single data model, service providers and suppliers will probably adopt a few and map them to one another. TM Forum’s high-level information model provides standard definitions for information that flows between communications service providers and their business partners, and defines a common vocabulary for implementing business processes. This reduces complexity by providing an off-the-shelf model that can be easily and quickly adopted by all parties.
API wave of the future. Dynamic APIs are the wave of the future. They can mediate connections between diverse systems, allowing the payload to vary depending on the product or service that’s being ordered, procured or managed. In the case of the Catalyst, the Open Digital API acted as a bridge between an orchestration system and the OSS/BSS, allowing suppliers to invest in a single set of APIs and use them to supply multiple products to many buyers. Conversely, buyers could also use a single API investment to integrate with many suppliers, which allows a true marketplace to form.
Dynamic APIs will likely be certified against core components. As long as any extensible parts follow the pattern as defined by the API, they will be certified. If a set of APIs are extended in the same way by multiple service providers the extension may be integrated into the core.
APIs are so important that nine of the world’s largest operators have officially adopted TM Forum’s suite of Open APIs for digital service management, committing to adopt TM Forum Open APIs as a foundational component of their IT architectures. More service providers are expected to announce their endorsement of them shortly.
Control Loops and Assurance
Close to half of TM Forum respondents ranked autonomic control loops and service assurance high in their requirements for orchestration. By collecting and analyzing performance data, figuring out how the network can be optimized and then applying policy in an automated way, service providers can achieve zero-touch provisioning and management. Orchestration allows operators to activate services on any vendor’s device in a standardized way.
Close to half of respondents put intent-based management in their top three architectural requirements for orchestration. Customers access a self-service portal to specify the service they want to use and the desired end state. An abstraction describes what the service is supposed to do and the agreed terms for QoS, then the orchestration system provisions and manages the required service automatically. The goal is to build a Hybrid Network Management Platform that provides for modularity, flexibility and adaptability.
Orchestrating a way forward.
Service providers must set a clear migration strategy—both technologically and culturally—in order to transition to end-to-end orchestration and a platform approach. Thirty-eight percent of respondents said setting a clear technology path was a top-three consideration for orchestration, while twenty-four percent ranked setting a clear cultural migration path as important. Orchestration may seem to be mainly a technology challenge, but it won’t happen without learning to think like a software company. That means focusing on services more than functions and learning to allow for failure – something that is in complete opposition to the way network operators have done business since their inception.
Still, a majority of service providers agree they need to become much more software-savvy. Setting a clear cultural migration strategy should be a top priority for all.