OSS Line

Amdocs Product Catalog Win at Telenet

People are buying product catalogs! Belgium’s Telenet has purchased Amdocs Enterprise Product Catalog (EPC).  The solution fits with EPC’s core value proposition: Replace all the disparate databases and catalogs throughout the organization to provide a single view of what’s being sold.

Consolidation is step one. You then need a business process that maintains and uses a single view of products, and you would also benefit from some sort of integration that pushes product specs out to order management, fulfillment, billing and so on.

EPC can be deployed on its own to handle the data side of consolidation, either replacing existing systems or reading/updating remaining legacy catalogs. It’s a quick win as, in most cases, legacy product catalog data sources are not tightly coupled to service fulfillment automation.

EPC is one of those products that straddles OSS and BSS. Naturally much product data ‘belongs’ to the BSS tier, but EPC is also integrated with Amdocs Cramer OSS to allow service specifications to be implemented by inventory design and assign processes.

Press release is here.

Industry Blows Hot and Cold on Service Catalogs

Not everyone shares my enthusiasm for service and product catalogs despite the investment in developing products & solutions that we've seen in the last couple of years.

At Tele Management World, this May in Nice, I talked to a number of people from different OSS vendors. I have to say, some of my optimism, assumptions and beliefs were questioned. Yes, the major OSS vendors almost all have catalog products, but their approach to them was a mix of caution, skepticism, and some enthusiasm.

Catalogs are still immature. Each vendor's approach to their own products could  make or break the solution in the next 12-24 months.

Approach One - Investment and Standards Adoption

A good catalog-driven OSS solution will touch many different applications and processes. It's also a bit complicated and different from what many organizations are use to from their operations business function. This may therefore be an area where standards will drive adoption by clarifying the problem, solution and architecture, while also displaying some much needed maturity.

But standards development in OSS/BSS lags behind the development and broad adoption of proprietary technology.

Standards require investment not only in writing lots of documents, but also in pushing the product technology forward. The technology comes first, then the proof, followed by a rethink and drafting of standards. Finally a standards compliant product is released. It takes time, money and a commitment to the solution.

above. PSA and Service Model Catalyst Projects at TMW Nice 2009.

I was pleased to see at least one group at TMW taking this approach. Their catalyst project involved Tribold and Comptel's Active Catalog. Comptel have clearly invested significant resources in their catalog and are now driving standards adoption, specifically PSA (product and service assembly initiative) in this project's case. PSA attempts to bring clarity to some of the usual catalog stuff (like product/service/resource specifications), but its differentiator from proprietary solutions is the ability to construct services across multiple OSS systems, provide the targets also support PSA. A sort-of service federation to compliment your data federation.

‘Investment and standards’ sounds like the approach I’m going to advocate, right? We’ll consider the realities of business first…

Approach Two - Caution

Not everyone has drunk the service catalog Kool-Aid. Most major OSS vendors have a catalog product, but they haven't necessarily established the business case for larger scale investment in its on-going development. Equally, they don't have the conviction or commitment to drive standards forward.

above. Get pigs flying first, followed by service catalog adoption.

One senior OSS propeller-head aired his opinion that there were bigger problems to solve in BSS and OSS. While service catalogs are A Good Idea, he proposed that there's no point fixing the service factory part of the stack when network, engineering, marketing et al. are still lagging. Overall latency in product introduction would only be marginally improved, thus the business case for catalogs is pretty limited.

Fair enough, I say. I don't blame any business for taking a wait-and-see approach. The economy is slow. Catalogs are not being widely adopted yet. The industry is in a BSS development cycle.

If I were to hazard a guess at which vendors were ‘cautious-to-skeptical’ about service catalogs, I’d suggest Tecordia and NetCracker/NEC, simply because of the level of marketing and PR they put out for these types of solutions and projects. I'm not even sure Netcracker has a service catalog product, looking at their portfolio. Just a product catalog? Someone please correct me if I'm wrong.

Approach Three - OSS/BSS Catalog Convergence

Amdocs has been pursuing BSS/OSS convergence since acquiring Cramer in 2006.  It’s only natural, then, that they apply some of this effort to product and service catalog solutions. At TMW this year they presented (in their lovely bus outside) the newly integrated Enterprise Product Catalog and Service Composition Manager products.

above. The Amdocs bus, again, just because I like it.

This is blurring the already blurry lines between OSS and BSS. Indeed, when I was selling Cramer service catalog products, customers would invariably ask 'who does what' when it comes to their product marketers, managers, ops teams and IT bods.

A unified product/service catalog platform is A Good Thing, there's a lot of shared technology, but does not in itself bring clarity to how such solutions will be adopted by the business.

One comment from a fellow attendee at the Amdocs bus was along the lines of "this must be for the technical team, right? Our product managers wouldn't understand this."

Comments like this serve to highlight the risks associated with this convergent approach: Is it too early to converge software applications if the market doesn't yet understand how to deploy catalog functionality in to their businesses?

What's Next?

If OSS vendors don't continue to invest in solving service introduction and fulfillment issues our little OSS industry will become a dinosaur. It will be the early 90s again: A small number of large, expensive, monolithic OSS vendors comfortably sitting on top of their stale pile 15 year old products, happy enough with a steady stream of maintenance and services revenue.

The economy is slow. Service providers are focusing on BSS to enable the introduction of new products, particularly to preempt the impact of converged services.

I predict that software vendors will not change their approach in the next 12 months. Modest investment in product development will continue, and standards will plod along but not suddenly answer everyone's questions.

Product catalogs will be picked up as soon as 'traditional' core BSS and OSS functions have been put in place by the providers to manage converged services. Service catalog development and uptake will follow soon after.

That should be a familiar sequence for anyone involved in our industry. Get the network, billing and OM going, then suddenly realize they're totally disconnected. Huge operational pain. Dissatisfied customers. OSS swoops in with a new product to save the day, again.

Developing Service Catalogs for OSS and BSS

A lesson from history...

I've been keeping an eye on the service catalog market for some time. I can't claim to be an early adopter though. My first brush with the concept was when I was given Cramer Service Catalog 1.0 to product-manage. From a professional perspective this was A Good Thing for me: It was a spanking-new product, development budget for v1.1 had already been assigned, and there was a tier-1 customer going to acceptance-testing in the next few months. I dove in: What's the difference between this and BPEL or other process automation? What's the value proposition? Where's the research or standards foundation it's built on?

It was all Very Interesting, but then things had to get pragmatic, and fast. With an imminent customer milestone and development resource ticking away, whether I had finished the v1.1 specs or not*, I had to work out how the solution was to evolve.

From talking to the project team, developers and research group, three things struck me:

1. Service catalogs are conceptually quite different from existing inventory + automation solutions, and people struggled to appreciate how this changed their overall solution design.

2. Having a SID-style service specification (customer facing services, resource facing services, and so on) on its own is not enough information to actually fulfill an instance of the service.

3. While service design in OSS is a benefit, the more immediate value of the product was its ability to offer a more granular, service-lifecycle oriented, interface to BSS applications.

Credit to Cramer research team, Service Catalog 1.0 was designed with an appreciation of the above, but it was also clear at the time that this is where further development would most benefit the end customer. And so, for the next few months, in support of v1.1 and 1.2 my efforts and resources were focused on:

1. Promoting catalog solutions internally and externally, guiding people to use a common language based on SID naming conventions.

2. Investing in the product to improve how catalog-driven provisioning processes are defined, selected and interact with each other to fulfil a single service order.

3. Reviewing tier-1 customer's requirements for BSS integration and how the product might better interact with the product catalog solutions that were emerging at the time. Again, using SID as a basis for defining roles and responsibility between OSS and BSS catalogs.

That was about two years ago, but these should continue to be the priorities for any service catalog product or project development. Our industry is traditionally good at defining and implementing data models (SID, MTOSI, inventories, and the like) and occasionally good at defining APIs (MTOSI again, NGOSS, and so on).

Telcos don't make money from having nicely formed data models; they make it from doing stuff with that data. How data and process and APIs interact is the hardest problem to solve, and not something that is generally covered by standards (it's considered an implementation issue). You have to nail this though. Allow users to interact effectively with the model; enable systems to drive the service fulfillment processes; these things actually deliver a return on investment.

*Imagine your taxi driver starting the meter as soon as you glanced his way from down the street; it was a bit like that.

The (Slow) Rise of Product and Service Catalogs in the BSS / OSS Industry

I don't think the whole catalog 'proposition' has made much progress in the last twelve months. Today, service catalogs and product catalogs provide essential, if a little mundane, data and business process integration between systems. But done properly, they also have the potential to revolutionize how a service provider reacts to market trends. I'm a big fan, but catalogs only have a cult following at the moment.

I've said before that catalogs are an emerging solution, but when I read this Billing & OSS World blog it struck me that catalogs are still being discussed as something new. It's a good write up. Ari Banerjee cuts through the hype and explains in piggy-ducky-horsey language, what catalog solutions attempt to address. But, six years after Tribold was founded and three years after Cramer (now Amdocs) released Service Catalog, why does Yankee Group still have to spell it out for us?

Why doesn't the industry 'get' product and service catalogs yet?

Last year at TMW 2008, the big OSS/BSS vendors had very similar marketing messages, mainly pushing their market-leading-ness, each measured in different ways. None of them were shouting about the next big thing. Only start-up Tribold, who's entire product offering is based on product catalog, were seriously promoting catalog-driven solutions on the expo floor.

Despite this business-as-usual approach, software vendors are investing significant R&D money in catalog development. Telcordia has a service catalog. Oracle has product catalogs and a new service catalog solution. Amdocs has a new product catalog and has consolidated Cramer Service Catalog capabilities in to Service Order Manager and Service Composition Manager. A lot of money is being spent on engineering.

If the industry gorillas want to create a service/product catalog market, they need to make a big noise about it. Instead, to-date, marketing has focused on the status quo: A reliable supplier of OSS/BSS solutions; catalogs offering an incremental improvement to the existing value proposition; reduced 'integration tax'; faster time to market; and so on...

It is difficult to articulate the value of catalogs without using the benefits claimed for previous OSS product releases. After all, catalogs are not solving a new problem as such. Rather, the immediate need is to solve existing problems that have increased in magnitude since the boom in network technology, product offerings and data services. While the magnitude of the problem has increased, so too has the potential value of the solution, compared with traditional inventory + automation solutions. Nail the OSS complexity issue, get it under control, and the service provider finally has the opportunity to turn network flexibility in to product flexibility.

Inventory is becoming a commodity. I don't mean that in a bad way; it's natural evolution. Inventory is essential, but the industry 'gets it', and its profile in bid questionnaires is diminishing to the point where it's pretty hard to compete on inventory capabilities. So, start with catalogs. Create a new value proposition for OSS. No more “inventory centric OSS”, we want “service centric OSS”. Don't sell catalogs as an upgrade to existing solutions built for a ten-year-old paradigm. Vendors, look at how your entire solution can embrace service-driven OSS and sell that.

I appreciate 'service' is a well-worn words in the industry. I'm not suggesting a more service-oriented message at the top-level, expo-stand-banner-level, or staff-polo-shirt-tag-line-level. That level is pretty much saturated with ‘services’ and ‘customers’. What is needed is for the service-centric message to be embraced by product managers, sales-engineers and architects. When we see PowerPoint slides with a “Service Catalog” box in the middle, rather than an “Inventory Database”, we may be making progress. OSS is about delivering services after all. Storing data and executing complex design code are essential, but ancillary, tasks.

When the telco business really understood inventory-centric service provisioning things really took off. Cramer, Granite, Metasolv (and the rest) grew from start-ups to dominate the OSS industry, marginalizing legacy vendors. A similar revolution could happen in OSS. There's start-ups and incumbents with the capability to lead a second revolution in OSS if they're willing to shake things up a bit.