Composable Business Support System

Introduction

To thrive in the post-pandemic era, corporations have to shift from business models, focused on sheer efficiency, to models that enable a high degree of modularity, flexibility, and agility. As Gartner Group puts it, previously efficient businesses became fragile and had to pivot to a more modular setup, creating a composable business to stay successful in the new era. Businesses should be comprised of interchangeable building blocks that can be changed quickly to respond to different internal and external factors, such as shifts in customer values or sudden changes in the supply chain or materials. According to Gartner, enterprise architecture, based on interchangeable building blocks, is called “Compostable Enterprise Architecture”. Figure 1 depicts the development of enterprise application architectures since the 1990s. The latest stage in this development is the composable application architecture that complies with the requirements of the composable enterprise architecture.

Figure 1: Composable Application Architecture; source: Gartner Group, 2020

As a part of their “Open Digital Architecture” (ODA), TeleManagement Forum tries to establish an open architecture, that would enable communication service providers (CSPs) to compose their business support systems (BSSs) using components, sourced from different vendors. These components should be interchangeable. Semantic interoperability is enabled via standardized, ODA-compliant open APIs. In this respect, ODA paves the way for CSPs to implement Gartner’s composable enterprise architecture.

We designed the new generation of our customer care & billing system following guidelines of the composable enterprise architecture. The system is comprised of interchangeable building blocks called “packaged business capabilities” (PBC). Each building block covers a specific business domain, for example, customer management, product management, ordering. Packaged business capabilities expose their functionality through a standard and TMF certified Open API. Building blocks may be part of different setups solving various business problems. Open APIs enable them to integrate with packaged business capabilities of other vendors to fully cover information needs of wider business domains (e.g. BSS – business support system, CRM – customer relationship management, etc.).

Composable architecture

Composable application architecture is comprised of packaged business capabilities covering different business domains. Business-wise, each packaged business capability sufficiently covers a specific domain and is typically (technically) comprised of several microservices and a shared persistant storage (database). Depending on the selection and configuration of business capabilities, different business problems may be addressed, e.g.:

• customer management: customer management capability is sufficient;
• product catalog management: product catalog capability is sufficient;
• 360-degree customer view with all customer’s subscriptions: includes customer management & product inventory capabilities;
• quoting: includes customer management, product catalog management, and CPQ;
• ordering: includes customer management, product catalog management, order management (and optionally CPQ);
• subscription management: includes customer management, product catalog management, product inventory, and order management;
• customer care & billing: includes customer management, product catalog management, product inventory, order management, and billing.

Figure 2: New generation customer care & billing system, implementing composable architecture

Composable application architecture is heterogeneous and implies the use of packaged business capabilities, sourced from various vendors. Each business capability exposes its functionality through a standard API. API standardization significantly simplifies integration, reduces costs & risks, and shortens time-to-market.

Cloud-native microservices architecture

Packaged business capabilities are implemented in a modern, cloud-native microservices architecture. Each capability is usually comprised of several microservices. Deployment-wise, various models are supported: on-premise / data center, hybrid cloud, or public cloud (e.g. hosting on Amazon Web Services, Google Cloud Platform, Microsoft Azure). Cloud deployment options enable elasticity (scale-up, scale-down), required by businesses.

The microservice architecture enables reliability, availability, responsiveness, and resilience, required by modern, enterprise-grade applications.

Business model support

Integration of selected packaged business capabilities solves different business problems. Different commercialization models are possible, from classic B2B (business-to-business) sales, through SaaS (Software-as-a-Service) to B2B2X, where entities in the value chain establish a revenue-sharing business model.

Components / modules

Customer management is responsible for managing customers' and prospects' data. The module supports fully user-configurable categorizations, customer contact management, addresses, payment methods, and billing accounts. Customers can be related to each other, e.g. “is an employee”, “is contact person”, “is parent company” etc. The module exposes a TMF-629 compliant API.

Product catalog is responsible for managing resource, (customer/resource facing) service, product, offering, and price data. It serves as a basis for every catalog-driven information management system. The product catalog defines basic building blocks that drive behavior and business logic of other modules, e.g. CPQ, order management, and billing. Basic building blocks can be extensively adapted to different environments and business use-cases by parametrization. Basic data can be enriched by adding multimedia content. The module exposes a TMF-620 compliant API.

Product inventory serves as a subscription/product instance repository. Product inventory connects customers with any product configuration that can be modeled in the product catalog. Individual product instances may reference general price (as defined in the product catalog) or override priced on a per-subscription basis. The module exposes a TMF-637 compliant API.

Order management is responsible for managing subscriptions i.e. creating new subscriptions, and changing & terminating existing subscriptions. Order management behavior (business logic) is driven by the product catalog. The product catalog defines basic semantic building blocks for order entry & order handling. Order management includes a business process for order fulfillment which is separated from the data management. Order fulfillment business process may be trivial (immediate subscription creation/alteration) or complex (branching/decision logic, manual tasks, programmatic tasks by service invocation, etc.). The module exposes a TMF-622 compliant API.

CPQ – configure, price, quote is responsible for creating custom quotations for a specific customer taking into account customer’s and product’s specific properties. Customer quote includes proposed resources, services, products, and offerings, specific parameter values, prices, and discounts. The quote may include multimedia content that additionally represents the qualities of offered products. In case a customer accepts a quote, an order in the order management module is automatically generated saving the sales rep’s time and effort. The module exposes a TMF-648 compliant API.

Billing generates onetime & recurring charges & discounts and makes the data ready for invoicing, i.e. issuing invoices. Billing it catalog-driven, its semantic is defined by the product catalog building blocks.

Invoicing is responsible for generating a convergent invoice comprising billable items, generated by internal and external sources. The internal source is billing. External sources may be various service platforms, capable of generating billable events. Invoicing calculates taxes using internal logic or by invoking an external taxation engine. The invoicing issues invoices invokes necessary external systems e.g. tax authorities (IRS), renders invoices, and exports them to consumer systems (e.g. general ledger/account receivables, data warehouse, etc.).

Intelligence collects transactional data, generated by other modules, and applies artificial intelligence and machine learning to perform customer analytics and make business recommendations and decisions. These findings are then made available to various transactional modules, e.g. propensity to churn is provided to customer management and product offering recommendation is provided to CPQ and order management.?

Conclusion

The article explains how to apply composable thinking to communication service providers' business support systems. A composable business support system should be comprised of packaged business capabilities implemented in modern, could-native architecture. For easy integration and semantic interoperability, each capability should expose a standardised API implemented according to TeleManagement Forum's Open API specification. Such BSS system addresses both major challenges CSPs face nowdays: how to stay efficient and cost-effective on the mass-market segment and how to become agile on more complex corporate, B2B, and B2B2X market segments, where a high degre of flexibility is required.