“Orchestration”, without qualification, is vague and misunderstood. First – and let’s get this out of the way immediately – orchestration is not “the new fulfillment”. Orchestration is a process. It serves many operations goals, from fulfilment to healing to capacity modification, and it operates in myriad places – within technology domains, within AI and other tasks, and most publicly – across domains. In this blog, I will focus on “cross domain” service orchestration.

The days of siloed orchestration stacks are over

Let’s parse that: Service orchestration operates across domains, depending on self-managing domains “below” it; these domains would include radio networks, IP, and datacenter/cloud. It focuses on end-to-end services, not the specifics of individual technologies. And beyond the words in its name (note: not standardized in the industry, but commonly used) it supports a number of operational actions in a closed loop lifecycle, from service innovation to instantiation (fulfilment), to assurance (healing), capacity management (scaling), modifications, and end-of-life. This is critical: one orchestration method must be used for every action in a life cycle, otherwise, complexity and errors ensue. So, the days of a fulfilment stack, another for assurance, etc. are over; or ought to be.

Service orchestration must cross domains for true scale and innovation

Cross Domain Service Orchestration, or “CDSO” for short, is the answer to several pressing business needs. According to upcoming research we will publish later this quarter, not only is it essential for the general progress of cost reduction for communication service providers (CSPs), it’s also a key underpinning technology for over $100B in new, incremental revenues that are unattainable without the agility and automation delivered by properly architected CDSO. One core reason for this is that the vast majority of these revenues depends on a new kind of innovation – not the killer apps that drove past growth, but rather the mass customization of services to create, secure, and manage thousands of semi-custom and self-managing enterprise networks that extend far beyond traditional SD-WAN and access. Success means operating at scale, and that means operating with a low-cost structure. This is possible only via automation and the re-use of standardized network and service components.

Service orchestration is not an option – it’s critical to innovation and new revenue

Recently, Appledore released a research report series that covers the state of the CDSO market, with in-depth analysis of suppliers and buyers. Cutting to the chase, the change in this market over the past 18-24 months is monumental. Two years ago, we could, without too much exaggeration, state that the CDSO market did not exist. All orchestration was within domains, led by virtualization and cloud-nativity in datacenters. We could also say that most entrants (although not all) barely paid lip service to the best practices that are essential for the agility and low cost we all want and need. Spend was small. And the players were, to quote Casablanca, “the usual suspects”.

Today’s roundup is vastly larger. There are several new market entrants, and many established players have completely revamped their products. One notable change from two years back, is that suppliers not only recognize intent, but almost every supplier claims support for intent-driven operations. While a techie word, intent is not an option if CSPs wish to achieve high levels of automation and low levels of ongoing maintenance. Appledore believes intent is a critical, albeit complex, capability. Similarly, most have embraced the fact that orchestration must support many steps in a life cycle, with many choices informed by AIOps. In short, it’s a good time to be a CDSO buyer, especially if you plan to chase a piece of the $100B pie in new revenues.

Nokia’s entry into this market is its Digital Operations (DO) Center. DO embraces all these trends. For starters, it’s an all-new product, built from the ground up to support tomorrow’s processes. Specifically, it’s intent-based, and includes three integrated, yet modular, components for the core of orchestration: AIOps/assurance (to inform orchestration) and a bi-directional dependency graph (“inventory”) to glue together resources, services, and users smoothly. One obvious purpose is for root cause identification; another is to move from a hardware focus to a service and user focus – both essential trends.

Final thoughts

Appledore’s recommendations are simple: First, build self-managing, automated domains for key technologies. One size fits none. Next, implement intent-based CDSO to allow for agile innovation and a high degree of automation at the E2E service layer. Finally, focus on automation and “elegant simplicity” to keep costs down and agility high. Often the “how?” is more important than the “what?” Get it right. Orchestration, as one prominent CSP put it, is the “special sauce.” Low costs, innovation and new revenues depend on it.