Componentizing Operations: A Critical Precursor for IMS

The problem with the industry’s focus on IMS is that it obscures and distracts attention from the real steps service providers need to take to get into the application business successfully. Let’s get one thing straight: IMS is just a signaling technology. It won’t cure cancer, put men on Mars or change the fact that most service providers’ IT environments are facing the same challenges they’ve faced for the past decade. What’s different today, given IMS and its various promises, is that it has made the argument for breaking down operational silos much sexier.

For nearly a decade, the OSS value proposition was built on efficiency, cost savings and sometimes time to market. But in a world dominated by circuit-switched voice revenue, in which IP was just the next unproven promise, the idea of integrating OSSs—and going through nightmarish data normalization and modeling exercises—wasn’t all that appealing. It was expensive, it created uncomfortable organizational changes and it mostly promised expense reduction to companies that still acted like monopolies. In short, the OSS value proposition was pretty dull.

Now, IMS is OSS’s best friend. All of sudden OSS gets to play a sexy role in real-time service delivery, creation and management. It’s the key to beating competitors to market while providing better service quality and customer care. “Operators are looking at the OSS infrastructure and how they configure services from a business view instead of a technical view. It’s now about the business model for these services, how many subscribers they need to add, how they’ll bill, what they’ll offer as a promotion, and other value that will be added on top of it as they go along,” says Joe Frost, vice president of marketing for Jacobs Rimell.

The IMS value proposition is all about speed, revenue growth and moving telecom into the world of pop culture entertainment. It’s as if Alexander Graham Bell went out and got himself a haircut, a Sean John wardrobe and a Lamborghini Gallardo to go clubbing with Paris Hilton and Lindsay Lohan. All of this sounds completely ridiculous, and that’s because it is.

Back Up a Step, or Three

IMS is like glue. Its purpose is to pull services and information together to create products that are greater than the sum of their parts. The problem, however, is that the services they are supposed to pull together really aren’t ready to be glued together yet. This is where we roll back the clock, because the underlying problems haven’t changed in a decade. Everyone knows on a macro level that service providers are built on disparate silos housing product-specific processes and data, and that these silos need to be unified to provide the seamless, real-time, integrated services all of telecom wants to see. Before that kind of inter-domain management or integration can really deliver its promise and provide the components IMS needs to play its part, though, there are still many micro-level issues to contend with.

Look into any technology or service domain and what you’re likely to find are inconsistent processes, limited automation and distinct data models that have not been reconciled or normalized. Amidst distractions like mega-mergers and the race to the entertainment business, these fundamental problems have been obscured by macro-level issues like re-branding, outsourcing and reducing employees. As the dust begins to settle and the industry primps for its date with the entertainment world, the micro-level issues still exist and are perhaps the biggest threat to success with integrated, application-based offerings.

Why Micro-Level Issues Are Macro-Level Problems

One of the pitfalls of falling in love with IMS is that it is inherently network-focused. Certainly its processes hinge on user-specific policies and data, but primarily as part of the real-time authentication and authorization that must take place during on-demand delivery. One of the key tenets of IMS is componentization and reuse of service resources. The question is, what is a service resource? In the IMS world, it is arguable that service resources are applications, application features and various types of IP connections. But such components are only one part of what makes up a service.

At this point it is widely recognized that IMS mainly deals with the IP domain and is a bit weak when it comes to recognizing that IP services depend on non-IP transport and access. What’s not discussed as often, however, is that the IMS specifications do not lay out a plan for componentizing the operations and business functions that are part of every service. What would be the point of componentizing the network-facing aspects of a service for rapid, a la carte service creation if operations and business functions aren’t similarly componentized? One could design a new service, from the network perspective, in a few minutes but then wait a month until someone figures out a billing process for it.

What needs to happen is that all of the operational silos relevant to what will eventually be IMS-based or IMS-like services must be well defined and automated enough to allow for the kind of componentization IMS calls for. Just like network technologies are componentized into the service creation process as resources with specific capabilities, the same must be done with operations functions. Again, billing provides a simple example. Any new service needs to be billed. But is it pre-paid, post-paid, both, free with purchase as part of a promotion, or perhaps billed by a third party? Which system will be responsible for billing the new service? What information needs to be pulled from that system into the proxy database that supports real-time authorization? What system will be responsible for copying that information from back-end systems into the HSS? These basic questions are just the tip of the iceberg.

The issue doesn’t apply only to billing, either. Similar concerns arise in customer and service support. What call center would support the new service, based on the skills and information needed? What self-help functions need to be accessible by users? What information needs to be duplicated, normalized and moved into a customer profile? What other services, promotions, discounts or loyalty programs are triggered when this service is evoked? All of these kinds of questions must be answered when creating any new service, but it doesn’t make sense to design a new service from the network perspective and then try to divine the operational answers. Without first componentizing the operational and business functions and then making them accessible a la carte in service creation, any new service that’s created would have to be retroactively mapped and wired into the disparate silo infrastructure. Obviously this problem is what hinders rapid service creation today, so we’re not going to revolutionize speed to market without solving it.

Hurdles to Operations Componentization

Mapping a new service into disparate operational and business silos is a difficult, macro-level challenge, but it runs deeper. In order to componentize operations and business functions and present them as a la carte options for service creation, they must be well defined, repeatable, as error-free as possible and ideally automated end-to-end. The fact is that there just aren’t many silos out there that display all of these characteristics. Engineers have been working toward maximized automation, but most silos remain heavily dependent on manual handoffs. Advanced service providers may be at the point where their order management and decomposition process is centralized and thoroughly automated, but even those providers find they have poorly defined processes and lack automation once the decomposed orders hit their relevant silos.

Service providers can continue to get away with the lack of end-to-end automation and process consistency as long as services remain relatively simple as they are today. While sexy new video and music applications are innovative from a service perspective, operationally they are delivered from stand-alone silos like any other service, though those new silos may be built with end-to-end automation in mind. That said, they take a long time to design and launch, and they aren’t integrated, coordinated or synchronized with other offers in the way that IMS promises. To get to that next level and realize ultra-rapid service creation and real-time, free flowing service integration, the micro-level problems within silos must be solved.

In the real-time IMS delivery process, nearly everything on the operational back end will depend on functional proxies. It doesn’t make sense to replicate all of the functions that silos are designed to handle, or to get the real-time service delivery process too tightly coupled to the specifics of how these silos work. The real-time process needs a trigger that in turn kicks off a designated process within a silo. If all of those processes are well defined, automated and mostly error free, then tying them to a real-time trigger or identifier in a proxy system that supports real-time delivery is relatively simple.

The siloed process doesn’t need visibility into the macro-level delivery process. An overseeing system is needed to handle service orchestration at the top of the stack. This system must make sure that all of the IMS components in the control plane are loaded with the necessary data to function properly. This loose coupling makes a ton of sense, because it will allow for silo-based systems and processes to change without seriously affecting the macro-level service logic. All that might need to change is the defined trigger.

But this whole beautiful architecture falls apart when silos aren’t automated and processes aren’t well defined and consistently repeatable. It also falls apart if one only follows the IMS specifications because they don’t define service orchestration. They don’t deal with the management aspects of all of the complexity they bring to network and service interactions.

It has been left up to OSS vendors and developers to fill in these gaps and create solutions that provide a high-level, centralized service management capability that can handle all of the proxy functions, and can coordinate distinct activities among silos and between the IMS domain and other domains on which IMS will rely. IMS needs to have some type of service management system to cater to its needs. It requires easily accessible billing and OSS triggers. It also requires that the paths it needs for moving traffic have been provisioned statically ahead of time. In addition, IMS must have processes that can be rolled back and reinitiated easily and in real time if something goes wrong. In other words, IMS is like an overpaid athlete that will sit on the bench and sulk if everyone around him doesn’t serve his needs.

Belgacom Puts Operational Silos First

Service providers that recognize these immature aspects of the IMS specs are making the decision to nail down their silos first in order to set the stage for IMS introduction. This makes sense, because it puts the proverbial horse before the cart where it belongs.

“Our position is that IMS is a way in the IP world to integrate, control multiple types of services, coordinate that, do signaling, and be a platform for some new services like presence, but it is only one piece of the total solution.” says Benoit Goodenir, enterprise architect for IT and network at Belgian incumbent Belgacom. “We want to see what would be the effort … to align with the IMS [specification]. The other track is to look at some other components that are becoming a bit more mature in the marketplace, but we won’t jump very early. It will take a year or two. We know we have to go in this direction, but it seems not to be mature enough—and we have bigger issues to tackle, like better definitions, our architecture roadmap, and better alignment with partners and suppliers.”

These issues are by no means unique to Belgacom, which is in fact a very typical incumbent from an OSS perspective. “We have a lot of legacy apps and the background of the company is the legacy voice product, but over six or seven years all of the services that can be supported over a DSL connection started to be deployed in the legacy systems,” Goodenir explains. What Belgacom is doing about it is pursuing an inter-domain management approach that focuses on aligning existing silos while creating highly automated processes within and between them. The operator has started from the top down, focusing on centralizing order management and decomposition with one consistent logic set that applies to all domains and services and yet helps to unify disparate silos at the same time.

Belgacom has also worked to abstract the capabilities of various technology silos into systems that make intelligent decisions about the best way to deliver a given service, based on the network and service resources available between the user and the source of the application. While the company has made significant progress and advanced many of its operational capabilities, Goodenir says that Belgacom recognizes this is a process that will take several years of consistent work. “We still have silos and sales channels that are specialized. We don’t sell everything through every sales channel yet. We’ve had to come up with a roadmap to evolve to a target architecture … that allows customer interaction that is more understandable for the customer, and that has to be central to the sales and support processes,” Goodenir says. The architectural focus in this instance is on consolidating sales channels and ordering processes, and improving the customer interaction. These are issues that IMS, down in the signaling control layer, obviously doesn’t deal with or solve.

Another pre-IMS step that’s necessary is creating a central customer database that will act as a repository for customer profiles, accounts and billable services. In IMS, the HSS calls for similar information, but the HSS only functions to serve the IMS signaling control functions. It would not provide the database for service support, customer care, margin analysis or any of the other operations and business functions that would take advantage of a common repository for customer, billing and product information.

Goodenir says the challenge is actually more complicated than just that. “If you want to go to bundling and be able to handle bundles in the selling layer, what is missing is the aggregated assigned product,” he says. An aggregated assigned product is the record of all of the combinations of products and capabilities that make up the entirety of what is delivered to the customer. “It must be defined according to a product model, which is the model I’ll use to do my selling,” Goodenir says. “If you can rely on or make reference to a model, then you can use components for some processes, and different product or service design is just a variation in the process that can be controlled using reference data,” he says.

The Industry’s Next Top Model

This modeling exercise is extremely challenging because “it takes a lot of thought and planning to directly model the relationships you need to represent but also accommodate things you can’t think of today,” says Siggy Maier, director of product management for Sigma Systems. “Any organization that wants a consolidated view needs to go through the process of coming up with an information model that doesn’t break. If a service provider wants to offer any converged or bundled services, it is difficult to do that without a converged view of the customer,” Maier says.

He also notes that because there are many different databases of record at the heart of different processes, a service provider can’t expect to “take all of that information and plug it into one database—you have to work in a federated system and have a consolidated model, but source that information from other places and make it look like it is in one database. If you can’t do that, it would be too costly and risky to pull everything in and migrate it,” says Maier.

Defining a common model has been a major challenge for the industry, though the TMF’s SID has come into wide use with some vendors developing tools that take the model from paper into something that can be implemented as part of an integration framework, EAI bus or SOA. To facilitate integration and data federation “you don’t need to get hung up on what the individual models look like, but rather what the APIs look like that will pull out this federated view,” says Brian Cappellani, CTO for Sigma Systems. “You should use technology that allows this loose coupling to exist, like XML which is extensible so you aren’t coding yourself to a specific schema. You can add new attributes and change the interface, but the systems don’t get hung up on what the data model looks like behind the scenes.”

Identifying all of the appropriate data from disparate silo systems and mapping it into the common model is also hard work, sometimes the dirtiest of the dirty work for systems integrators. “Cross-domain complexity, synchronizing and accounting for the discrepancies in data semantics across the systems … is really the challenge that catches [service providers] flat footed,” says John Petrie, vice president of business development for Pantero.

Lacking that centralized, normalized model and database, Goodenir says, a provider must “go into several silos to repeat information into each of their own data models. It’s replicating some logic.” Though they will be brought into a loosely coupled, federated model, the data transformations necessary now are “hard-coded everywhere, so when we are about to implement a new product there is spaghetti code all over and usability is very low,” he says. Defining a common product model and normalizing information through it will allow Belgacom to “create catalog items that we link together in a hierarchy to describe the product,” Goodenir says. “We see the product catalog as a repository of the decomposition between the different layers.”

Having a central repository that all applications and processes can refer to provides the basis for “one central place to process selling information as well as one central place to coordinate among the different silos,” says Goodenir. Looking at this from the perspective of setting up the environment for IMS, what’s being put in place here are several layers of abstraction.

Processes and data models within the existing silos won’t be broken down or apart, but rather automated and optimized. The data necessary to higher level processes like sales and product development is then pushed or pulled into the common data models for customer and product information and stored in a centralized database. This database therefore provides the federated reference point back to the silo systems. A subset of this normalized, federated information can then be provisioned into an HSS to provide the IMS control layer the information it needs to drive authorization, authentication and service delivery.

On the process side, with strict process definition and high levels of automation, a federated model can also provide the mapping point for process triggers or pointers. This sets the stage for IMS by providing loosely coupled but common reference points for the back-end processes IMS wants to trigger but doesn’t manage and doesn’t need visibility into.

This kind of architecture is not unique to IMS, though. “With some customers we’ve seen that knowledge needs to be close to the network, like in an LDAP repository. The extension of that is the HSS in IMS. [A major cable operator], for example, is looking to try and bring together information about the customer and their entitlements and put that into a repository across the network, but with a pared-down set of information,” says Cappellani. This abstraction allows for back-end processes and responsibilities to change without affecting IMS, or whatever set of systems handles real-time service delivery and therefore houses the high-level service delivery logic. All that would need to change is which process the reference point in a federated model points to.

All of this effort is related to the operations layer, and while IMS depends on it, IMS—residing in the signaling control layer—does not provide the solution for it. All the same, the fact that IMS pushes service providers toward rapid service creation, integration and delivery to any end point does make the business case much more compelling for all of the OSS systems integration, automation and data mapping. But it is time to recognize that IMS isn’t a panacea and that all of the hard work in operations finally needs to be prioritized to make IMS a reality.