Best in Class Enterprise Catalog-driven Ecosystems
In the last article we talked about transformation projects going wrong, often taking years to materialize, repeatedly missing production deadlines and resulting configurations that were fraught with integration complexities. We discussed the challenges in implementing simple changes to product offerings and the beginning of the evolution away from best-of-breed architectures to catalog-driven architectures. Catalog-driven architectures were based on the premise that if data was centralized, changes to that data could be more easily pushed out to BSS and OSS systems, resulting in improved TTM and a reduction in fallout. The syncing processes however were highly error prone, could rarely be fully automated and required sophisticated versioning and reconciliation processes to be put in place.
Vendors were also able to claim they were catalog-driven by making little to no modifications to the way their software worked. So where are we today? The concept of “Enterprise” Catalog-driven ecosystems was introduced about a decade ago as a way to not only centralize the master data model but to also ensure that all ecosystem application participants were directly driven off the data in the central catalog. In short, no application would be allowed to house its own configuration data.
One of the very first Enterprise Catalog-driven ecosystems to address many of these challenges was implemented by Vlocity Inc., a company acquired by Salesforce in 2020 as a result of its innovations and approach to BSS architecture. Vlocity took the bold step of building an enterprise catalog-driven ecosystem from scratch (no acquisitions allowed) on top of the Best-In-Class cloud technology of Salesforce. They invested in building the entire range of BSS systems including Configure Price Quote (CPQ), Order Management (OM), Contract Lifecycle Managed (CLM) and provided tools to streamline the introduction of Digital Sales processes onto the platform. All of the applications in the ecosystem were driven in real-time off an enterprise catalog (EPC) where Offers, Commercial Products, Customer Facing Services (CFSs), their attributes, relationships and selling and fulfillment rules were centrally defined. The key guiding architectural principles followed were:
- Offer and Product modeling must be centralized in a single master location (MDM). This includes both Commercial and Customer Facing Services (CFSs) as well as their relationships, associated rules and attributes.
- Users must have the ability to seamlessly navigate through the product hierarchy from top to bottom, review the latest changes made to the model and make updates as needed.
- Users must have supporting tools that allow them to communicate proposed configuration changes across roles and responsibilities.
- All users must have a consistent user experience in the cloud regardless of the role being performed (Product Modeller, Fulfillment Designer, CPQ Modeller etc.).
- Users must have complete abstraction away from underlying operating systems and databases to allow them to focus on delivering value rather than managing the platform.
Within Enterprise Catalog-driven ecosystems duplication of rules and data across the stack is eliminated and users have full end-to-end visibility as quotes are created, contracts generated, the perfect order is raised and ultimately submitted down to order management for fulfillment. With a few clicks CSRs can watch as orders flow through the ecosystem and monitor their progress from inception to assetization post fulfillment rather than having them disappear into a back office black box. This brings about large benefits to CSRs who can, with a few clicks, find out where an order is in the fulfillment lifecycle and assess why it might be delayed. More accurate orders are also generated, reducing fallout and streamlining the fulfillment process.
Figure 2: Enterprise Catalog-driven Approach to BSS / OSS
With the right architectures now in place it is still possible to lose sight of a few important first principles to follow during transformation projects. Critical areas to stay on top of include:
- Use centralized scrum teams where all interested parties agree on product specifications representative of all applications in the BSS including both COM and SOM.
- Avoid carrying bad habits from the old stack to the new, such as allowing for continued product proliferation rather than normalizing products down to a realistic set.
- Applications can easily be misconfigured with too many hierarchies of products, poor placement of lookup logic or service qualification logic and lack of proper separation of concerns between COM and SOM functions.
- Ensure that commercial data is mastered in the front office (COM layer) and technical data is mastered in the back office (SOM layer). Commercial data should be pushed down from the BSS layer into the back office for technical enrichment, not the other way around. It is the business that decides what gets sold based on customer needs and demands.
In many cases customers have legacy applications and custom code that cannot be changed in a short period of time. However, a little precaution can go a long way to delivering an ecosystem that substantially addresses the TTM problem based on an enterprise catalog-driven architecture. Additionally, we can achieve a significant reduction in fallout while reducing IT costs, increasing the degree of real -time collaboration and knowledge sharing as product offerings change, and focusing on meeting customer market needs rather than dealing with constant changes to integration logic and individual application configurations.
Along with these transformation principles in mind, the applications in an enterprise catalog-driven ecosystem can still be complicated, often requiring experts that understand how they are deployed together. It's important to ensure that best practices are followed not only for each application but for the overall end-to-end configuration as well (e.g. an overly complicated product model can have knock-on effects in CPQ as well as Order Management). IdeaHelix provides its Best Practice Assurance Platform which is an extensible rules-driven engine that analyzes Salesforce Industry Cloud applications configurations at both design-time and runtime to ensure that the application guardrails are being followed.
