Composable commerce pays off where you can own the interfaces

Composable commerce pays off where you can own the interfaces

A new customer portal can look like a self-contained project. Then it turns out that product data sits in several systems, prices come from the business system and the order flow follows a different logic. When each channel develops at its own pace, the platform choice becomes a question of responsibility and the cost of change.

Composable commerce can help you change one part of your commerce environment at a time. But every standalone component needs integration, ongoing management and a clear owner. Here we look at how to assess the benefit, choose a reasonable degree of modularity and account for the costs after go-live.

Why you need control over your channels

You may already have a web shop, a business system and a separate solution for product information. Now the sales team wants a customer portal, marketing needs a product website and resellers are asking for their own order flows. Each initiative sounds self-contained, but the functions often rely on the same prices, product data and stock information.

Digital sales are already a large part of the business for many companies. According to Statistics Sweden, 36.7 percent of Swedish companies with at least ten employees sold through e-commerce in 2024.

For you, the practical question is how to adapt a channel or function when needs change. A new customer portal should, for example, be able to use the same product and price data as the web shop. If every improvement also requires extensive changes across the whole commerce environment, change becomes expensive to coordinate.

Composable commerce is one way of dividing up responsibility. You can keep the parts that work and decouple the function that creates a clear obstacle. The benefit depends on whether you can handle the integrations and ongoing management that come with that decision.

Composable commerce is an architectural principle

Composable commerce describes how you split commerce technology into well-defined components. One component may handle product information, another search and presentation, and a third the checkout flow or a portal. The components work together through defined interfaces, often APIs.

Think of a digital business as a chain of responsibilities. Product data needs a clear source. A frontend needs to present the information. A commerce engine can handle the transaction, while the business system owns the item, price, stock and order data. You should be able to describe what each part is responsible for and what it can expect from the others.

In a more unified platform, several functions sit close together. That can make operations simpler when catalogue, customer data, checkout and administration evolve at roughly the same pace. A decoupled architecture makes it easier to change individual parts, but you get more boundaries to manage and test.

APIs alone don’t make a solution composable. If components share unclear data models, or several systems believe they own the same information, you get decoupling on paper but continued coordination in practice. Define which system is the source for each important piece of information. That system becomes the governing source for it.

When you assess a component, check whether its responsibility can be clearly bounded, whether the data flow can be traced and whether the part can be changed without causing unexpected errors elsewhere. The explanation of how different commerce platforms are used can give a practical starting point for separating platform choice from architecture choice.

The components follow the customer’s digital journey

Follow a customer journey from product information to order. A PIM can gather product data such as names, attributes and content. Search and the frontend use that information to help the customer find and understand the right product. Customer portals and reseller portals then show content and functions suited to each user role.

The business system can remain the source for prices, stock and orders. The commerce solution fetches what it needs to present the offer and receive the order. When the order is sent back, the flow needs rules for confirmation, error handling and retries.

Take a reseller logging in to see their range. Basic product data can be shared, while the customer’s agreed price, availability and order history are fetched based on the customer relationship. The canonical product model describes the shared properties of the item. Customer-specific terms belong in data flows where permissions and business rules are handled.

Components work best when they share a clear data model and every integration has an owner. Decide how you will detect a failed price flow and who deals with it. Monitor syncs and order events so that errors become visible before they cause problems for customers.

It is also important to control which systems may change a given piece of information. If stock status is updated in several places, you need to know which source applies when the values differ. Modularity gives you room to act, but it doesn’t resolve disagreements about data ownership.

Choose the level of modularity based on need

Start with the obstacle you want to remove. If the platform works and functions change rarely, you can keep it and improve the parts that need attention. That gives you fewer supplier relationships and less integration work to follow up.

A hybrid model fits when one well-defined domain is slowing the business down. You can, for example, decouple the PIM or add a dedicated portal while the rest of the commerce flows stay as they are. You then need to define how product data or customer information is transferred and who handles errors between the systems.

A fully composable architecture becomes relevant when several domains need to evolve independently and the organisation can own the interfaces over time. Every new service adds licences, integrations, monitoring and version management. The TCO calculation therefore needs to cover operations and internal coordination as well as development cost.

The smallest reasonable step is often the one that solves a concrete problem without creating more ongoing work than the organisation can handle. Compare scenarios using the same cost boundaries: licences, integrations, testing, incident handling and the skills needed for ongoing management.

The gain comes from shorter waiting times and better self-service

A product website connected to the business system can show relevant products and availability based on the customer’s needs. A customer portal can let buyers find order information and handle recurring requests themselves. A reseller portal can show the right range and terms for each partner.

When every channel uses a shared model for product data, it becomes easier to keep the information consistent. A PIM can gather attributes and content, while the website, portals and reseller flows present the information in different ways. That requires someone to own data quality and have the mandate to correct errors.

Broader self-service doesn’t help if customers meet wrong products, prices or stock information. Before you add a function, follow the information from source to channel and establish who is responsible for each step. You can then decide whether the obstacle lies in the user experience, the data or the integration.

Glanser builds solutions from pre-built, tested and compatible functions and integrations through the Function Library. The scope and price are set for each function before work begins. Functions come in three tiers: Standard, Adapted and Customer-unique. A Customer-unique function is isolated so that it doesn’t affect the rest during upgrades.

The customer can start with one solution and build on the same foundation. That suits cases where you want to limit the next step, but it requires the business to make decisions about the functions’ responsibilities and priorities.

A digital customer portal can be a suitable first module when customers’ recurring requests take time from sales or customer service. Assess the benefit based on which tasks customers can actually complete themselves and which information the portal must be able to rely on.

How to connect Litium to the business system

Before you build anything, you need to know which system decides what applies to products, prices, stock and orders. Assign an owner to each data type and document which channels read or write the information. That reduces the risk of duplicate rules in the frontend and the business system.

Then define integration contracts for each data flow. A contract describes the information being sent, who sends it and what should happen when the recipient can’t process it. For products, you might specify which attributes are required before an item is published. For orders, you need to be able to trace receipt and handle retries without creating duplicate orders.

Business Central, Monitor and Jeeves are examples of business systems that can be connected to Litium. To keep the frontend simple, business rules and synchronisation should be handled in an integration layer or in standardised adapter functions. Also decide how errors are shown to the operations team and how they can be fixed without creating new orders or overwriting valid values.

The platform also changes over time. Litium’s release notes show how often new versions arrive, and each version needs to be tested against your integrations.

Integrations require ongoing product ownership, with version tracking and compatibility through upgrades. The article on integrations with business systems can help you work out which data flows need to be part of your plan.

When modularity becomes more expensive than the platform

Every standalone service gives you another interface to monitor, another version to track and another dependency to troubleshoot. When few people are responsible for the technology, multiple supplier relationships can make planning and incident handling harder. If a unified platform meets your needs, it may be simpler to run and cheaper to maintain.

Composable commerce doesn’t automatically improve performance. More separate services can increase response times and create more points where an error stops the customer journey. If you split up the architecture, each component needs clear operational requirements, monitoring and a recovery plan.

Caching can reduce the need to fetch the same product information from the source system on every visit. Real-time calls should be reserved for information where freshness affects the decision, such as customer-specific prices or order status. During temporary failures, the system may need to use the last verified information or clearly state that the information can’t be shown.

Include testing, monitoring, error handling and responsibility for suppliers’ versions in your TCO. If those costs are missing, a low purchase price can give a misleading picture of total ongoing costs. A description of Glanser Care shows how contracted product ownership can cover compatibility and bug fixing after go-live.

Three questions to ask the supplier

Who is responsible for the integrations working when Litium or the business system is upgraded? The answer shows whether responsibility continues after go-live or whether every upgrade becomes a new quote.

How is compatibility tested before a new version reaches production? The answer shows whether there is a routine in place or whether errors are discovered by your customers.

Which costs are included after go-live, and which fall on your team? The answer shows how much of the ongoing management you need to staff yourselves.

Implementation requires clear decisions and your own input

Start by mapping the current situation. Follow product data, prices, stock and orders through your systems and note where responsibility or data ownership is unclear. Then choose the channel or domain that creates the biggest obstacle for the business.

Define data models, integration boundaries and which functions are included before development starts. Include testing, error handling, ongoing management and product ownership in the scope. You can then build a foundation that solves a concrete need and extend it when the next business case arises.

We carry out a 72-hour analysis when you are assessing an existing setup or planning cost and scope. You set aside two hours for the meeting and, within 72 hours, receive an inventory of functionality and integrations, a functional specification, a prototype, and a complete cost picture with a timeline. The analysis is free of charge, and the material belongs to you.