Editor's note: As service providers roll out next-generation networks and services, they need next-generation operations and business support systems (OSS/BSS) to go along with them. The introduction of more complex service offerings on multiple platforms, and the sheer volume of services rocketing across multiple carrier networks, means more complex revenue tracking, too.
In this series, OSS expert Jeff Cotrupe looks at meeting next generation-network and service challenges with next-generation OSS/BSS. For more information on next-gen OSS/BSS, check out Tackling next-gen network OSS/BSS challenges and Wireless OSS includes quality testing and location-based services. At the end of this article, check out Cotrupe's expert podcast, From NOCs to ROCs: Helping service providers monitor business operations, to listen to what it takes to establish a revenue operations center to track complex service revenue.
Next-generation operations support systems (OSSs) and business support systems (BSSs) hold the key to service providers' new Holy Grail, which is the ability to deliver 'any service to any device over any network, anytime, anywhere.' But it takes a service delivery platform (SDP) to open the door.
A core concept I used to tell clients at ADC Telecommunications and Visionael Corporation was: 'You can't provision what you can't see.' In other words, you can talk all day about launching and activating new services to open new revenue streams, but you'll run aground if you don't have good command of your network inventory. A core group of next-gen OSS providers has specialized in deploying network resource management (NRM) systems that render 95% to 100% inventory accuracy and render the oft-stated goal of 'flow-through provisioning' attainable.
Instead, you must top rock-solid inventory with service fulfillment systems that can configure any part of that inventory at a moment's notice to deliver services -- today's services and those that don't yet exist. And these systems must be integrated and cost-effective and must leverage common components and resources.
In the early 2000s, a self-respecting vendor could consider itself 'a next-gen OSS provider' merely by building a system with the capacity to deploy an IP or wireless service, and that's exactly what went on. Vendors built 'new legacy systems' that differed from the 'old legacy systems' merely by virtue of the new services they could support. We may have slapped sparkling new graphical user interfaces (GUIs) on them, but from a structural perspective, we were trudging across the same old legacy ground: creating software silos for the packet-switched world, just as we had built software silos for the circuit-switched world.
Service delivery platforms transcend the legacy
SDPs transcend these limitations by providing a common way to introduce and integrate new services into an operator's existing network and services fabric, slashing the time, risk and cost of launching new offerings. An SDP brings together many OSS/BSS disciplines, providing a unified view of subscriber data, service configuration and device-level information that strengthens every link in the service fulfillment chain. It includes everything from subscriber/order management to inventory, configuration management, design-and-assign/provisioning, activation, reconciliation and verification back into billing and customer relationship management (CRM).
SDPs provide far more than a way to carry out service fulfillment mechanics, however. They ensure that fulfillment processes are informed and controlled by policy management considerations and that services are delivered securely and reliably. An SDP also provides a centralized framework for dealing with two of an operator's most important external constituencies: users and content providers. Content providers can quickly and easily deliver the services users want by interacting with an SDP's standard interfaces, which simplify the complexity of the underlying network and systems. Users like to consume services they can 'see and touch,' interacting with and managing their services via intuitive, user-friendly, Web-enabled, self-service portals. Applications like bandwidth on demand are virtually impossible to deploy without an SDP because (for a fee) users need to instantly and temporarily increase bandwidth and/or quality of service (QoS) to enable particularly bandwidth-intensive applications.
Best of all, service providers can provide all of this welcome interactivity and on-the-fly service consumption while experiencing much lower operating expenditure (opex) internal costs because the cost factors associated with IT equipment (normally associated with the corporate/enterprise world) are lower than those of traditional telecom gear.
While an SDP enables content providers to quickly do potentially lucrative business with an operator, in a not-so-subtle way, it also builds service-oriented architecture (SOA) and Web services into the operator's infrastructure. This means it can quickly plug in (or unplug) any content provider, at least from a technological if not contractual standpoint. This should prove quite useful when it comes to keeping content providers on their toes and constantly competing to be a favored content source to the operator.
What SDPs are made of
Now that we've looked at some of the key benefits SDPs can deliver for service providers, let's lay out the essential ingredients that constitute an SDP. Subscriber service management provides a unified view of each subscriber and user. In today's 'maybe I'm a subscriber or maybe I'm an intermittent user' environment, it is important that an SDP be able to manage both scenarios. This is much the same as what makes session initiation protocol (SIP) invaluable: its ability to quickly set up and tear down connections as users hop on the network (for example, to download a media file) and just as quickly hop off when download is done. Order management provides end-to-end tracking, management and control of subscriber or user requests. We have already described the roles of two other SDP components: NRM and service provisioning.
The final ingredient is integrated service configuration, which pulls all of this together to create, configure, deliver and manage any type or class of service. An SDP provides a 'place' where an operator can define a common information model and mechanism for pre-integrated service delivery and can orchestrate disparate services into innovative new packages.
It is important to understand one other thing that makes SDPs totally and legitimately different from anything that has been done before when it comes to delivering services. We have been discussing SDPs as the best way for operators to become masters at rapidly rolling out the service-of-the-moment. Yet their highest value is not their day-to-day, run-time service fulfillment functionality but their ability to provide operators with a semi-permanent (at least) launching pad for any service, present or future. In a manner of speaking, 'any silo system can provision a service,' but only an SDP can future-proof an operator's ability to launch all services.
About the author: Jeffrey Paul Cotrupe is the CEO of MarketPOWER, LLC. Cotrupe is a former practice leader at Gartner and director at ADC Telecommunications who helped relaunch an OSS/BSS research practice at RHK (now Ovum). Cotrupe has provided analyst services to Yankee Group and strategic consulting services to a variety of companies, relaunched companies and helped others win venture capital funding.