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.