I've recently had an opportunity to engage in some insightful conversations with colleagues, customers, prospects, and competitors about the creation of BSS/OSS solutions for telecommunications providers and network operators. Quite a lot (sometimes too many) of discussions were focused on the trending topics such as artificial intelligence or machine learning. However, when it comes to practical aspects, we almost always return back to fundamentals that form the basis of any BSS/OSS solution, including product and service catalogs, the demarcation between BSS and OSS, TMForum ODA framework, integration patterns, etc. Real fundamentals. And I though to share some of the findings and insights with you.

The articles I'm writing are a part of my personal endeavor, separate from my professional work at Salesforce. My aim is to share my knowledge and observations with the community, source additional feedback, and ultimately create better solutions for the future.

One of the most intriguing topics from my recent conversation was about managing multiple commercial catalogs in the context of a telecommunications service provider. It's an interesting subject with a lot of "it depends" aspects. So, let's dive in.

Terminology

And the very first thing it is worth to start with is clarify the terminology. In the context of this discussion, a commercial product catalog is a repository of product offerings and specifications offered by a telecommunications company to its customers. This includes product definitions, pricing, bundling, lifecycle states, and associated business rules. Effectively, a commercial product catalog is a dictionary of what and how a telecommunications service providers offers to a market. Look at these products, for example. These products and services (among other things) are defined and managed in a commercial product catalog (source: https://www.eurofiber.com/).

For the sake of completeness, a commercial product catalog is often considered as a part of the unified enterprise product catalog - a concept combining all the different perspective of telecommunication products and services. This includes:

• Commercial behavior (i.e. how a product is offered to a market)

• Fulfillment behavior (i.e. how a product is delivered to a customer once ordered)

• Support behavior (i.e. how a product is supported as it is used by a customer)

• Billing behavior (i.e. how a product is invoiced to a customer)

• etc.

Today we will focus on the tip of the iceberg - let’s focus on commercial product catalogs only. There is enough hidden gems to explore.

Service Providers Expectations

Service providers often anticipate (and ask) their commercial catalogs to be a single, unified commercial product catalog. This catalog would detail the commercial behavior across all product portfolios, customer segments, and communication channels. All commercial product definitions would be centrally managed in one location, serving as a unified repository. This setup enables service providers to craft relevant product bundles and solutions, enhance operational efficiency, reduce time-to-market, make informed decisions, and swiftly adapt to market demands. All underpinned by consistent product modelling methodology adopted across the organization. Nice and easy. If you are reading this and think “Hey, I do have a single, unified commercial product catalog” - you are the lucky one and I would be happy to learn from your experience.

Service Providers Reality

The reality often presents a stark contrast to these expectations. A common scenario I've witnessed with numerous customers and prospects involves managing a separate commercial product catalog for each product line (e.g., fixed, mobile, IoT, value-added services, etc.). Occasionally, the situation is slightly better - a service provider may have already undergone some form of transformation program and managed to consolidate a number of product lines under a single commercial product catalog. However, it's almost never a single, unified commercial catalog.

So, what could be the reasons for this discrepancy? Here are a few:

• As new technologies and business models emerge, new IT solutions (including catalogs) are created. Often, existing IT solutions (including catalogs) are unable to accommodate new products and offerings

• Even within a single IT solution there may be “silos”. Different teams effectively create independent sub-catalogs to manage their own portfolio (kingdom) using their own tools and practices (rules). Just because it is often easier and faster to not align between the teams

• There are instances where existing IT solutions (including catalogs) are entirely capable of onboarding new products and offerings, but the process turns out to be too expensive or complicated (or both)

• Sometimes, consolidating IT solutions for legacy products and services simply does not make sense as it will not create new value for the business

• And there are always transformation programs that have been halted due to various reasons

The key takeaway is that for any communication service provider with a diverse set of products, there will always be more than one commercial product catalog. Therefore, we must figure out how to accommodate this reality.

What is Practically Achievable?

So far, we've discussed that while communication service providers would ideally have a single unified commercial catalog, they usually operate several catalogs per product portfolio. This isn't ideal as it impacts their business performance. It limits the ability to offer customers cohesive solutions across multiple product lines, increases time-to-market for new products and changes to existing ones, and raises operating costs. Not a winning combination.

Can this situation be improved, you may ask? Yes! The short answer is “commercial catalog consolidation and integration”. Our goal is to consolidate existing commercial product catalogs in a smaller number of larger catalogs (less is more!) and integrate these catalogs, where necessary, to improve overall catalog management processes and enable business with additional capabilities. Just look at this beauty!

A word of caution: consolidating and integrating commercial product catalogs, or any other applications or functions, can be quite costly for a large telecommunication provider. These IT transformations often enable broader business transformations. A business case and executive support are absolutely necessary for such initiatives. Some examples I've encountered include:

• Adapting to new business models, including partnerships and marketplaces.

• Losing customers to competitors due to an inability to offer cohesive solutions across multiple product lines.

• High costs associated with creating and maintaining customer offers due to inefficiencies in the company's IT solutions and processes, which impacts profitability.

• High costs to ensure a consistent customer experience across all interaction channels.

How to Consolidate Commercial Product Catalogs

The next big question is “How do you actually consolidate commercial product catalogs?” This is exactly where the answer is “it depends”. But don’t stop reading. While there is no single right answer, let’s discuss some guiding principles that will help you to optimally cover your product portfolios.

There is always more than one way to federate your product portfolios across commercial catalogs. In other words, you'll need to decide which part of your portfolio each commercial product catalog will manage. It is like slicing a pizza (or a pie or cake, whatever you prefer). The “slices” are typically determined based on business value from a catalog consolidation transformation. Ultimately, you need to answer to these three fundamental questions for each commercial catalog in your IT ecosystem:

• Is there business value in consolidating a particular catalog?

• If so, which target commercial catalog should it be consolidated into?

• If not, is it beneficial to integrate it with other commercial catalogs?

From the portfolio perspective, service providers often focus on:

• High revenue, high growth portfolios and segments

• Portfolios and segments which are significantly limited by current IT capabilities

Art print courtesy of @society6

What to Do with Partner Catalogs

The last thing we need to discuss before actually approaching the catalog consolidation is partner catalogs. Your partners (suppliers) help you to create truly relevant customer solutions by extending your commercial portfolio with additional products and services, be it value added services, subscriptions, professional services hardware, and more. Differentiating your customer offerings is particularly important in the B2B context where customers are looking not just for products to buy but for solutions to address their specific needs. And partners often add the finishing touch to a proposition.

The difficulty here is that your partners are independent companies with their own portfolios, processes and systems. Partners (suppliers) will always have their own commercial catalog management solutions (with their own applications and challenges) and they will provide access to their catalog using an appropriate way:

• Through spreadsheets and emails

• Via partner portals, including marketplaces

• Through partner-specific APIs, such as those used by Amazon, Cisco, Westcon

• Via industry-specific APIs, like TMF620 or TMF622

Generally, you have no control over these partner systems, processes, and interfaces. You cannot alter or remove them, with a few exceptions. However, these commercial catalogs can be considered as additional ones for you to manage. While you can't consolidate them, you can integrate them into your commercial catalog management process. Read on to learn how you can accomplish this.

Transforming Commercial Product Catalogs in “Just” 4 Steps

When tackling the catalog consolidation project, often part of a broader business or IT transformation program, I typically break it down into four steps:

• Determining What and Where to consolidate

• Consolidating the catalogs

• Integrating consolidated and remaining catalogs

• Integrating partner catalogs

Important note: Consolidating commercial catalogs can provide significant benefits to a service provider. Technically, this involves migrating data from certain catalogs to others, and adjusting catalog management and catalog-driven processes. However, this usually doesn't alter the portfolios themselves, but rather the way they are managed. Caution is advised, as the current methods of defining and managing telecommunications product portfolios could be one of the major reasons for operational inefficiencies. Therefore, if a service provider consolidates sub-optimal product models into a new catalog, the existing problems are not necessarily going to go away. This is the famous 'garbage in - garbage out' principle.

Therefore, before consolidating commercial catalogs, it's often recommended to first thoroughly review current product models and portfolios. Identify opportunities to streamline your product portfolio first, then proceed to the consolidation stage. Product catalog rationalization can dramatically improve the outcome of the consolidation initiative. At the same time, not doing product catalog rationalization can negate any positive outcome of the consolidation initiative.

Good, now let’s briefly discuss each of the steps mentioned before.

Determining What and Where to consolidate

The first and arguably the most crucial step is deciding your target architecture. In this stage, you will collaborate with your business champions, enterprise architects, and solution architects to agree on the number of necessary catalogs and their usage. This process involves aligning business requirements with technical constraints to develop a practical architecture. Let’s imagine these circles represent your commercial catalogs.

• Begin by identifying all currently used commercial catalogs.

• Assess which ones are worth consolidating from a business value perspective.

• Evaluate which ones can be consolidated based on architectural and technological considerations.

• Create a shortlist of target commercial catalogs that will support your business, ideally without overlaps or dependencies.

• If overlaps or dependencies exist, designate the master catalog for that specific overlap. Also, identify key processes for data authoring and management, such as which catalogs will create and manage data and which will receive data "replicas."

• If the consolidation process involves stages (which it almost always does), define your target and transition architectures. This plan will guide your journey from your current state to your desired end state.

A quick yet crucial note about product models: every commercial product catalog in your ecosystem has unique technical capabilities, product modeling practices, business requirements, and support teams (people). A model that works perfectly for one catalog may be disastrous for another. Since we are discussing consolidation, it's vital to align product modeling principles and guidelines before moving data between systems. For such cases, we typically establish "product modeling guilds" or a "product modeling authority" where people and teams can agree on strategies before starting the actual implementation. Setting up a product modeling guild is actually very beneficial for any catalog-driven solution, even those that do not require commercial catalogs consolidation. Curious about setting up your own guild? Let me know

Consolidating the catalogs

Finished crafting your target architecture? Great work! The next step is consolidating commercial catalogs. Essentially, for every catalog you've decided to retire, you'll need to transfer both data and business processes to the target catalog.

• Begin by migrating data from source catalogs to target catalogs. Depending on the situation, this can be done manually or automatically. While it might sound simple, it's actually a complex process that warrants its own discussion. If you're interested in a deeper dive, feel free to ask.

• Next, transfer the processes and potential integrations from source catalogs to target catalogs. Use your judgement to decide what needs to be migrated to your target architecture.

Here is how consolidation plan can look like.

Integrating consolidated and remaining catalogs

At this stage, you should have two groups of commercial catalogs: those you will retire (source) and those you will incorporate into your future architecture (target). Now, let's address the potential overlaps and dependencies you might encounter within your target architecture. These scenarios are quite common and must be managed effectively, typically by integrating the remaining consolidated catalogs. Here are a couple of examples I've seen:

• Catalog A is used to master fixed connectivity offerings, while Catalog B masters offerings for customer solutions that include fixed (from Catalog A), mobile connectivity, and partner offerings.

• Both Catalog A and Catalog B manage the same fixed connectivity offerings but cater to different channels or market segments.

Integrating these commercial catalogs is crucial to ensure data consistency. This task, in my opinion, is one of the most complex and frequently underestimated aspects of the transformation we're addressing. One catalog will be designated as the master, with others serving as replicas of the product definitions. The specifics of how these replicas will be distributed from the master catalog to other catalogs is a topic for another conversation. The solution can range from manual catalog synchronization (which isn't ideal) to fully automated product catalog reconciliation or event-based configuration distribution from the master catalog. The integration approach will vary for each pair of commercial catalogs. If you're interested in a deeper dive into this process, feel free to reach out.

Integration is not as easy as just drawing an arrow but I needed some graphical representation.

Integrating partner catalogs

Finally, let's discuss partner (supplier) commercial catalogs. These catalogs are managed by the partners themselves using their own systems and processes, which are typically beyond your control. You won’t be able to modify or remove these processes, so you'll need to integrate them into your target architecture.

The good news is that you can treat these partner catalogs as another type of commercial catalog that must remain in your target architecture. Such catalogs will master a certain part of your commercial offerings. Thus you need to integrate them. You can follow a similar approach to how you integrated your internal commercial catalogs.

Once you synchronize and integrate partner commercial catalogs into your ecosystem, you'll be able to leverage partner offerings to support your business needs. This includes reselling partner products and bundling them with your own products, among other possibilities.

A Quick Visual Recap

And here we are! With these four steps we

• Determined What and Where to consolidate

• Consolidated the catalogs

• Integrated consolidated and remaining catalogs

• Integrated partner catalogs

Now we have set up a platform that lets service providers craft relevant product bundles and solutions, boost operational efficiency, cut down on time-to-market, make smart decisions, and quickly adjust to market demands. Sky's the limit!

Quick Remark on Enterprise Product Catalogs

After completing the commercial catalog consolidation project, your entire product portfolio will be covered by a small number of commercial catalogs, ideally integrated. This likely resulted in improved customer experience, enhanced operational efficiency, significant time and cost savings, and potentially new, differentiated commercial offerings ahead of your competitors. Well done!

However, this is just the tip of the iceberg. Beyond slicing a catalog vertically by product portfolio, we, architects, often slice it horizontally to separate sales, fulfillment, care, and billing behaviors (layers).

For example, consider a cake representing your commercial offerings, sliced into individual (and hopefully integrated) commercial catalogs. Let’s zoom in on a particular slice and examine its layers.

Commercial offerings are typically represented through a hierarchy of:

• Products: Commercial offerings provided to customers.

• Services: Sets of functions offered to the customer, providing value and satisfying specific needs.

• Resources: Physical or logical components used to realize and support services.

These layers are often managed by different applications. This is because various applications (and their vendors) usually specialize in specific layers, while they may lack the capabilities to support others. It's a fascinating topic in itself.

As you might have guessed, the consolidation issues we discussed for commercial product catalogs also apply to service catalogs and resource catalogs. The cuts and integrations will likely differ (unfortunately, it's not as simple as slicing a cake, more like using jigsaw). While we won't dive into solutions in this article, keep in mind that as a solution or enterprise architect, you'll need to address these problems too. The multi-dimensional nature of this challenge can be daunting, but rest assured, there are solutions!

Happy catalog management!