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?
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.