These days you can’t be a business or operations support systems 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 applications are “catalog-driven” and while a few of these claims are false, that is increasingly rare. For the most part, they have embraced 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, for sure.
Of course, the problem with Catalog 1.0 comes 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 systems to get the job done. This means five apps working together to process a simple order – but with each having its own catalog. When defining a single new product, you now have five systems to configure, in addition to any integration points in between them to handle any necessary data exchanges. 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 centralised 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 applications still have their own embedded catalogs, but these can 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 it “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 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 synchronisation issues, less order fallout due to data inconsistency issues, and a MUCH faster way of launching new products to market. The Hansen Create-Deliver-Engage Suite for CSPs (Catalog, CPQ, OM, Portfolio, Provision and CCB) is an example of a 3.0 catalog-driven set of applications, and we were the first vendor to bring the future to market.