These days you can’t be a BSS/OSS architect without embracing the notion of catalog-driven applications. The promise of catalog-driven architecture pushes all the right buttons for most of us – the notion that you can define something in one place and then reuse it many times is compelling. And it ought to be, if you do it right.
Most vendors claim their BSS/OSS applications are “catalog-driven” and while a few of these claims are false, that is increasingly rare. For the most part, B/OSS applications have implemented the concept that you can configure the data and processes that drive the behavior of an application without resorting to coding. I refer to this as a Catalog 1.0 architecture – each application has its own embedded catalog that you can configure instead of hardcode – a big step forward, to be sure.
Of course, the problem with Catalog 1.0 architecture arises when you try to get a few applications working together. To accept and process one simple customer order, you will at least have a quoting and order capture app, which in turn interacts with the CRM, billing, order management and provisioning apps to get the job done. This means five apps working together to process a simple order – but each of those apps has its own catalog. When defining a single new product, you now have five apps to configure, in addition to any integration points in between them to handle any necessary data transformations. A less than ideal situation.
Catalog 2.0 architectures have started to emerge. These are usually seen among the larger vendors that offer many applications. Catalog 2.0 means there is a centralized product, service and resource catalog that is the single source of truth. Changes are made in the central catalog and then “pushed” out to the applications that need them. The rest of the BSS/OSS applications still have their own embedded catalog, but their configuration can increasingly be modified by the central catalog. You see all sorts of convoluted solutions in Catalog 2.0 architectures – this is because although there is now a central catalog, most of the applications that need that catalog data really aren’t set up with proper APIs to consume that data “nicely.” Instead, a hodgepodge of code is written to allow catalog data to be pushed and pulled into the systems that need it. Again, better than it was under Catalog 1.0 architecture, but still not where it needs to be.
Catalog 3.0 architectures complete the evolution of the BSS/OSS stack. Like Catalog 2.0, there is a central product, service and resource catalog that masters all of the data – but there are two important differences. The first is that the central catalog now has a high performance API layer that can be used by other applications to obtain catalog data required at runtime. The second difference is that the other applications no longer have their own catalogs embedded in them – they reach out to the central catalog at runtime to get the data they need to do their job.
Why is this important? The consequence is a dramatic reduction in integration costs, a reduction in synchronization issues, less order fallout due to data inconsistency issues, and a MUCH faster way of launching new products to market. The Sigma product suite (Catalog, CPQ and Order Management) is an example of a 3.0 catalog-driven set of applications making it the first vendor to bring the future to market.