The Impact of Cloud Models on OSS and BSS

This article originally appeared in the May 2012 issue of Next Gen Mobility magazine.

Last issue, I talked about clouds, the new business models that are developing around them, and some of the value CSPs can deliver in a cloud environment. In summary, CSPs have an opportunity to be part of a broader range of services, but they will provide only certain parts of a larger end-to-end service. Specifically, I noted that CSPs have opportunities in transport, QoS, billing on-behalf, and – interestingly – E2E service management. So can OSS/BSS really be a competitive advantage for our industry? Let’s see.

Assembling composite services across entities depends on the availability of published, re-usable, loosely-coupled service components. Throughout IT, this idea is really called SOA, the service-oriented architecture. In SOA, complete services are composites – meaning they are made up of smaller service components such that service A plus B plus C forms a complete, interesting commercial product. Most IT shops are embracing this internally already. It’s the logical extension of object-oriented programming and has lots of business benefits:

·         greater re-use;
·         lower maintenance;
·         faster time to market;
·         lower development costs; and
·         greater flexibility.

Let’s think about the network effect. The more that people can (re)use a component, the greater its value. Consequently, if SOA is good for IT, it’s even better on the global web or public cloud. That’s the genesis of web 2.0, and the hope for CSP’s (News - Alert) developer APIs everywhere. The problem has been that most developer APIs have suffered from weak adoption. Nonetheless, primary market research indicates that the market potential remains strong – developers universally indicate that they want richer functionality, simpler accessibility, and simpler or more attractive commercial terms. Many CSPs are actively addressing these deficiencies, and thus we may yet see the day where app developers view telco resources as absolutely critical elements of their toolkit, and as natural to reach out to as Google (News - Alert), social media or other web based resources today. So, assuming we will eventually succeed, let’s look at the implications on OSS and BSS.

If, in the emerging world of clouds, services will be composed using SOA-like principles, success demands a similar structure for OSS and BSS support processes. This is a significant departure for most operators. It means that each service must be accompanied by a set of OSS/BSS services, specifically those that:

·         allow for discovery of that service;
·         allow for provisioning/fulfillment of that service;
·         allow for assurance of that service; and
·         allow for end user and wholesale charging for that service.

In effect we need a more complex web service with multiple components that collectively support the functional interface, as well as each of the OSS/BSS functions. The service composer may now compose a working service, and, at the same time, compose the OSS/BSS support required for that service to scale commercially.

This is the same approach that manufacturers have employed for decades – in some cases for nearly a century. Interchangeable and standardized parts can be assembled into multiple different products. In manufacturing, this results in faster time to market, lower component costs, greater flexibility, and lower repair costs. (You don’t need a master machinist to make you a custom screw; you buy one for 6 cents at the hardware store.) The same benefits accrue to management process support.

But this fundamentally changes OSS and BSS. They become platforms, exposing process fragments as web services, which can be assembled as we please. Continuing the analogy to process efficiency, my employer, Telcordia (now a part of Ericsson (News - Alert)), refers to this as service studio. It is our vision that the long lead times and high process development costs that have characterized OSS/BSS support can tumble, and with it, the costs of innovation can fall.

Internally, we can easily see the advantages in terms of agility. But this also opens the door for innovative developers – from large content companies to small entrepreneurs, to utilize CSP-provided service components, and easily plug them into a full management framework. It also opens the door for CSPs to offer capabilities like end-to-end service quality management of a web service basis. (See last issue’s column for more on this.)

In summary, the cloud’s power comes from the network effect, where innovation occurs across the broadest range of capabilities and service building blocks. CSPs can participate in this ecosystem only if they expose valuable services, and make them easy and practical to employ. Among first order implications, this means flexible charging models and loosely coupled management components. In making this transformation to support public clouds, we do ourselves a great favor. We, in effect, build the internal infrastructure to innovate more agilely within our own networks, building an internal cloud architecture for both services and their management.