A composable approach to technology lets companies “compose” their own tech stack of best-fit tools for different parts of the digital experience. Instead of being locked into a standard set of features from an all-in-one platform, teams can mix and match the capabilities of domain-specific solutions that are designed to easily integrate.
This modular setup gives businesses a lot of flexibility to customize the customer experience, prioritize investment, and adapt the tech stack as needs change. Typically, going composable also means shifting to more modern technologies that can provide a big boost in team productivity and site performance.
Even if teams are convinced of the benefits of composable architecture , and would gladly be able to snap their fingers and have it in place, actually making the move can be daunting. Uncertainty about the cost, complexity, and potential disruption of the change can make it feel too risky to try.
Luckily, the road to composable is now a fairly well traveled one. Early adopters have paved the way with best practices, the solution landscape has matured, and companies of all sizes have now successfully made the shift. This article takes a look at some of the key strategies that many of these businesses have used to de-risk the transition to a composable architecture.
Why it’s the perfect time for SAP Commerce Cloud customers to go composable
The best practices in this article can help teams modernize any legacy system, but the move can be especially smooth for SAP Commerce Cloud users because the vendor has taken some pretty big steps to help its customers go composable.
SAP Commerce Cloud architecture now supports composable
The release of SAP Commerce Cloud 2211 , the first cloud-only version, brought substantial changes to the platform’s core architecture. This included breaking up platform functionality into distinct modules that can be used and scaled independently, and exposing the functionality of these modules via APIs.
This makes it much easier to integrate SAP Commerce Cloud capabilities with other vendor platforms. Companies can now keep using the SAP modules they like and replace other modules with third party solutions, such as search or content management. In other words, it enables them to go composable.
SAP Commerce Cloud pricing structure now supports composable
Just as important as it being technically feasible, composable needs to be financially practical for it to work. The SAP Commerce Cloud composable offering not only fully endorses the idea of supplementing SAP’s core commerce capabilities with third party solutions, it makes it possible to not pay for the redundant SAP features when you do.
In the composable pricing option for SAP Commerce Cloud the modules for product information management (PIM), order management, search, and the storefront composer are offered as optional cloud subscriptions. Giving companies a lot more freedom to explore alternatives in these areas.
Don’t replatform, modernize
One of the most common myths about going composable is that you have to go “all-in” and completely ditch legacy systems. If true, the approach would never have been able to gain the traction it has. Many companies have long-used systems that are core to the business, and trying to rip-and-replace them would be a recipe for disaster.
A core benefit of composable is the ability to choose best-fit solutions for each area of business. In some cases, the existing legacy system is simply the best fit.
The freedom to choose and combine different solutions is due to the idea that each component of a composable system should work independently and communicate in a standardized way, typically via APIs. This modularity means changes can be made to one component without risking the others, which is what makes it possible to modernize digital experience without having to replatform .
You can keep the parts of the legacy system that you like in place and gradually replace the clunky or outdated parts with modern components. This is becoming increasingly easier as legacy software vendors, like SAP, are adding APIs to their platform to keep up with the demand for composable. Which frees up developers from having to build a custom API layer for legacy functionality.
Transition in phases
Going composable often means new technology, new vendors, and new ways of working. Trying to make the shift in one big push can make change far more disruptive than it needs to be.
The modularity of a composable architecture, with each component working independently, makes it possible to break the transition into small steps. Teams can focus on updating one component at a time, quickly rolling out and seeing the impact of each step. Allowing companies to move at their own pace and easily adapt the plan as business needs, market demands, and budget availability change.
A phased approach lowers some of the biggest barriers to going composable. In a 2024 survey from the MACH Alliance , an organization that advocates for composable architectures, the most common barriers revolve around the risk of making disruptive changes without being sure of the payoff. Transitioning in stages, with complete flexibility to decide how and when to take each step, can greatly ease these concerns.
Reduce upfront investment
Composable doesn’t have to follow the rules of an old-school replatforming project. Where you’d have to completely build out the new system, go through a lengthy testing process, and do a massive data migration before you could start to see any value from the new solution.
Instead, you can start by making improvements to one corner of the digital experience, like improving site search or product pages, and begin seeing benefits in just a few weeks. Making it easier to get budget approval for the initial, relatively simple phase and only deciding to make a bigger investment once the value of composable has been proven.
Simplify change management
Being able to pivot and adapt is a major business advantage but if every change upends business as usual, requires substantial downtime, or risks a waterfall of errors then there is going to be a lot of hesitancy to use change strategically.
A phased approach offers many ways to make change less stressful and to help people build up the skills to quickly implement and adopt it.
Reduce the blast radius. Changing one component at a time helps teams uncover and solve issues before they have a chance to balloon into complex, system-wide challenges. Releasing updates in relatively small steps also makes testing easier and, if there is a problem, lets you quickly roll back to the previous state.
Introduce features at a comfortable pace. New tools, functionality, and processes can be rolled out to business users in a controlled manner. Making sure there’s enough time for proper training and to let people get used to each step so that improvements don’t disrupt business as usual.
Ramp up developer skills. Starting with the less complex parts of the system means developers don’t have to already be experts on API management, microservices, and modern frameworks but can learn along the way. In-house teams can rely more heavily on implementation partners during early phases, and gradually take on more responsibility over time.
Future-proof the system. On a technical level, a phased approach helps make sure the architecture is set up to be modular and that each component can be changed independently down the line. On a business level, it lets teams get familiar with the steps needed to plan, budget for, roll out, test, and iterate on frequent changes. Overall, making it easier to evolve digital experience with the market.
Start with a headless frontend
Most composable architectures are headless , which means backend systems do not control frontend presentation. Backend data and logic is communicated in a neutral way, via APIs, so that different frontend channels can use and display the information in different ways.
This “decoupling” offers a lot of flexibility to customize the customer experience (CX). How it looks, how it’s structured, what channels it’s delivered to, and what backend services and data are used to power it.
Creating a headless frontend is a common first step to composable because it lets companies quickly set up a modern, high performing CX while leaving backend processes, data models, and integrations in place. They can then gradually replace the services that power CX by just switching out APIs, instead of having to completely rewire the frontend with each change.
Update CX without disrupting business
The decoupled set up of headless means that changes to frontend design, templates, features, site structure, and content can be made without jeopardizing any backend systems.
This lets frontend developers deploy fast, iterative improvements without having to constantly coordinate with backend teams about dependencies. It also allows business users to frequently publish and update site content without the risk of accidentally causing breaking changes.
Ease customers into change
With a monolithic architecture, since any change requires system-wide testing, updates are usually bundled into big, periodic releases. With headless, since updates are less risky, smaller changes can be rolled out at a much faster pace.
This offers a lot more flexibility to build a CX that customers love. Teams can quickly introduce a single change, measure its specific impact, A/B test it, get user feedback, make iterative improvements, and can easily roll it back if it isn’t having the desired results.
It also lets customers get used to updates one at a time, instead of overwhelming them with a whole new website at once. Some companies even start by styling the new headless frontend to look like the existing one so that they can quickly improve overall site performance and key features without a major redesign.
Set your own standards
Moving from a single vendor suite to a tech stack of composable tools does introduce more moving pieces for teams to manage. One way to minimize complexity is to align on a set of internal standards to guide technology decisions, processes, and development. Such as:
Languages and frameworks. A benefit of the API-first nature of composable is that developers are free to work with any programming language or frontend framework. While some larger companies use different ones for different use cases, most teams decide on specific ones to streamline development.
Key performance indicators (KPIs). Decide what measurements will be used across the environment as well as how, and how often, these will be reported. It can be useful to set up a unified dashboard that shows key KPIs of each component.
Data governance. Clarify which data lives in which service, who has access to it, and how it’s updated, stored, processed, and disposed of.
API structure. An API template for in-house development helps to make sure that new features and services can easily integrate with the rest of the stack.
Deployment process. Outline development best practices, including which type of changes need to be communicated with business users or customers.
Documentation. Agree on how you will record changes to the system and where this information can be found. Such as an internal wiki.
Putting these standards in place early on helps to lower complexity during implementation and to keep it low as the system scales because, once the core architecture is set up, the modularity of composable lets teams update, add, and replace any component in the system without much additional complexity.
Whereas a monolith can be relatively simple to set up, due to its single code base, but can quickly build up customizations and workarounds that lead to a tangle of dependencies that become very expensive to maintain and challenging to scale.
Take advantage of prebuilt solutions
With many mature solutions on the market, composable is no longer only an option for advanced engineering teams that want to DIY their whole setup.
One big trend that we’re seeing is the democratization of composable. All the big innovations always start with early adopters. It’s when the technology’s a bit more expensive, and then it gets democratized. The tech becomes a bit cheaper, the entry barrier becomes lower. And right now many players in the field are developing very local pre-made integrations to facilitate composable projects. It’s very exciting because before composable projects were only for enterprise, maybe middle market; but now they are starting to be accessible for everyone.
Carole Breetzke, Senior Business Analyst @ Brave Bison
Teams of all sizes and skill sets can use a variety of prebuilt solutions to help reduce the complexity and speed up the time to value of a composable approach.
Cut development time in half with Frontend as a Service
The majority of composable solutions on the market are headless, so there needs to be a separate frontend “head” that brings all of them together into one CX. When companies take this on themselves it usually means there’s a lot of time spent rebuilding the wheel, like creating blog templates or contact forms, before teams can start to focus on the features unique to their business.
A Frontend as a Service (FEaaS) solution provides prebuilt integrations, common frontend components, and core cloud infrastructure that companies can use to accelerate time to market.
Alokai is a FEaaS designed for composable commerce that simplifies building, deploying, and monitoring ecommerce frontends. It gives merchants the tools to quickly connect any combination of modern and legacy technology, including SAP Commerce Cloud , to power a high-performing experience that can be easily evolved as business needs and backend solutions change.
Simplify integrations with data orchestration
One of the biggest culprits of complexity in a composable system is the coordination of data and workflows across the tech stack.
This has typically been done by building custom middleware or glue code, which can take up a lot of developer resources to build and maintain. Fairly recently, solutions that tackle this data management challenge have started to emerge on the market. Solutions that, like Alokai Connect , have been specifically designed for a composable approach.
Alokai Connect helps teams orchestrate data from across their composable stack and efficiently deliver it to the frontend with a single API. Making it easy to access data from all services in one place and fully leverage that data to drive rich, personalized experiences for every customer.
Reduce risk, accelerate returns
By breaking up a composable transformation into manageable steps, getting a modern frontend experience into place early, and making use of internal standards and prebuilt solutions teams can lower the barriers to going composable and quickly start to see the return value of modernizing digital business.
If you’re interested in learning what composable could do for your business, don’t hesitate to contact our experts and chat with them about making the move.
