This article originally appeared in the Dec. 2012 issue of Next Gen Mobility Magazine.
In the last issue, I wrote about service agility as a holistic endeavor – neither a single magic bullet nor a series of Band-Aids. Rather, I opined that our industry was changing from a low-volume manufacturing paradigm (in which a small number of services are introduced) to a high-volume innovation environment.
In one-off environments, you build from scratch. In mass manufacturing environments, you invest in tooling, standardized components and flexibility. In effect, we’re moving from a world defined by a few, widely adopted, stable services (e.g.: POTS, pre-paid, 450 minutes, IPTV (News - Alert), DSL, etc.) to far more varied and specialized services in which experimentation, continuous innovation, and niche offerings drive up the number of products we must create and manage, and drives down the cost and time allowable for each – possibly by orders of magnitude!
Now I’d like to move from the “what” and “why” to the “how.”
Let’s begin with a simple premise: For commercial success an operator must both create the real-time session flow for a service (e.g.: deliver the video; set up the VoLTE call), but it must also create management support for it. If any process is slow or expensive, it becomes the limiting factor.
Let’s continue with a second premise: Most new service/product offerings are really combinations and permutations of a much smaller number of building blocks – a charging service, a call leg, a QoS building block, a video delivery service, an index lookup service, etc.
So the reusable components are like Legos, and our job is to create new logos, and assemble them in order to win share and revenue in the marketplace.
The concept of reusable building blocks is not new, but it is really starting to take hold today. It began with IN and is the basis of web service mash-ups. Within the service provider community, it is gaining favor recently as the business shifts I talked about last edition are becoming more real and more accepted. ETIS has its PLM initiative for what amounts to service definition and fulfillment. The TMF has its Software Enabled Services Management Interface – beginning down the road to modular B/OSS operations.
Many vendors have catalog-driven approaches to next-generation operations.
Two things are new. First, we’re seeing the initial products capable of supporting componentized assembly without extensive SI science projects. Second, we’re seeing the first solution that encompasses all the necessary and sufficient processes – such as discovery, order, fulfillment, charging, assurance and settlement.
This is absolutely critical; the process is not effectively modular and componentized until all the key processes are supported with near-equal agility. A chain is only as strong as its weakest link.
Recently, I felt a bit like a link doctor, examining the weak links in this chain. Some are subtly difficult – such as real-time charging (in which creating components can be slightly iterative) or service assurance, which is not necessarily a linear process.
Yet they can and must be solved.
Once these solutions are found, we can enter an environment where a service creator can assemble a new product from catalog-resident service components, and at the same time have catalog data drive similar processes across operations. The result is truly faster time-to-market (no more multimillion-dollar, year-long trips to IT for OSS/BSS support), and a cost structure that allows for innovation, experimentation and even (very inexpensive) the occasional failure.
This is the key to Web speed innovation, and make no mistake – the Web is the competition.
Similarly, a truly agile componentized environment enables third-party collaborative innovation. Third-party exposure demands a catalog-driven, componentized process – because third parties can only consume the API (components) that you expose. Here again, the inclusion of agile management is essential. Without it, third parties can create a service, but cannot manage or easily monetize it.
That may be fine for free services where consumer demands are low, but it is not acceptible for premium, enterprise or financial services that present a huge opportunity for all of us.
I certainly don’t have the space here to dive into all the details, but then again, this column is about how we apply technology to money issues – business and revenue challenges and opportunities. Suffice it to say that:
- Not only must we become more agile, but the process technology is being developed to make it practical.
- Agility is not an add-on; rather it is a re-architecture of your processes.
- Agility must span the session/network domain, and the B/OSS domain.
- A catalog-driven, componentized architecture is at the core of this.
- And finally, it is possible to apply this thinking beyond PLM and fulfillment, but it takes a fresh approach to how operations are implemented – thinking at the service level, not the network level.
Now, back to the money. Service agility is important today, and its time has come, for one reason: The emerging business environment demands rapid innovation, and justifies the investment. For many years the technical dream existed, but the financial motivation was uncertain. It seems clear that we must now innovate or truly become the dumb pipes we have long heard of. Let’s innovate. We know how.
Grant Lenahan (News - Alert) is executive director and strategist, BUSS, Ericsson.
Edited by Braden Becker