Composable architecture is usually perceived as "breaking down the appropriate system into smaller, more manageable chunks". It is more than that.
In fact, I think it should be broken into two constituent parts, the technical architecture, and the business architecture of which I feel should be treated separately.
The beauty of composability is that you can quite quickly make decisions to modernise your platform of which this is the perfect use case. Quick decision making can be the difference between a won and lost business opportunity. Take SAP Commerce as an example. You are a customer using an SAP Commerce Cloud instance that has recently moved into our SAP Commerce cloud platform and you are looking at ways simply improve your solution by means of efficiency, usability, functionality, or scalability. Perhaps search and merchandising has been identified as an area of improvement where your business can make the most improvement.
Examples of Composability
Great, let us look at the SAP Store and evaluate some of SAP's recommendations in this space. You choose a partner, like Coveo as their offering is most likely to resonate with your customer base and help you grow your business with by tackling the identified areas of improvement first. Working with Coveo is a straight swap of search provider with low development effort. This is a quick win and should not affect the business architecture too much. It is simply connecting the third-party investment to your SAP Composable storefront and start seeing the benefits.
This example is a simple example, you are replacing SAP Commerce search (SOLR) with a third party and connecting the dots. The business architecture is also affected in a minimal way, and you have successfully modernised your platform. This can be repeated for many single solutions, adopting modern technology over time to gradually grow your customer’s experience. New capability can be added, and existing capability can be simply switched off and replaced. This enables agile business change in an ultra-competitive market. Rapid, targeted composing could put you ahead of your competition.
Fig. 01
A diagram showing how you can simply replace/override standard SAP search capability with a third party via API integration and configuration. Leading to a small change to both business and technical architecture. It is likely that a change like this can be managed with existing inhouse teams and skills. An architecture like this also allows you to take benefit of SAP’s continuous innovation and services such as blue/green deployment.
Reflection on a business architecture
I am using the term business architecture to mean the setup and structure of your business. Using the above example of replacing SAP Commerce search with Coveo means your business does not have to adapt too much. Yes, you must adopt a new technology, but the overall team/business architecture evolves to support the new solution.
Let us look at another example. The business has chosen to adopt a third-party front-end technology that is not SAP Composable storefront such as Vue storefront to align with the business requirement for an agile frontend, trading out of the box compatibility and security with faster to develop frameworks. From a technical architecture perspective, this is also fine. However, this decision has a larger impact on the business architecture to facilitate the change to a third-party frontend and this is often overlooked in the decision-making process. Impact to business architecture can be a mix of the following: additional resources, vendors, and more complex solution landscape. This can change the focus from running a successful business to chasing vendors, unplanned outages, multiple support processes to adhere to, and unnecessary integrations.
Fig. 02
A diagram showing how choosing to use a third-party storefront can add additional complexity as many additional solutions have to be added to the technical architecture to be able to offer as a minimum the same level of capability as SAP Commerce cloud. The business architecture must consider these changes and adapt accordingly. It is also worth mentioning that some of the complexity is managed by our vendors and their out of the box connectors to SAP Commerce cloud.
When is composable complex?
An example of when decomposing your frond end could be complex is the following:
- SAP Composable storefront is not selected as your chosen head and your business has decided to decompose its front end with SAP Commerce Cloud as the commerce engine.
- Digital maturity and ability to support a complex technical and business architecture is not fully considered.
- Multiple composable solutions are required to build the desired customer experience. E.g. search, content management, product recommendations, personalisation and more.
Or
Your business decides to build its own react storefront. You pick a search provider, a content management provider and personalisation engine. You now must plumb and integrate at least four solutions into storefront to provide an experience. The experience will rely on the constituent systems to be performant, available and integrated correctly and more importantly; the business architecture needs to be in place to support the adoption of these technologies. That means you need to have appropriate training, resources, and budget to select and support your chosen solution. This is the crux of composability. Trading architectural simplicity for complexity. It is paramount that you only compose when the business benefit of doing so outweighs the additional complexity to implement, maintain and support a decomposed solution.
To conclude
Is the additional complexity a problem? That depends on the goals and that your business is working towards. For modernisation and protection of original investments, selecting a couple of best of breed partner solutions will bring quick win value. For larger investments, composability is also a fantastic opportunity to bring agility to your customer experience, just make sure you consider the impact to your business in the decision-making process. When is the right time to decompose? It is imperative that your business evaluates both reasons for and against decomposing the front end. Consider the impact on people and how they will work with your decomposed and current solution. Think about the number of third-party relationships, SLAs, and contracts you may have to work with. Evaluate the potential additional strain on budgets due to additional development and maintenance. Finally, how will your solution be resilient to failure with so many outage scenarios? All things that could have business impact that exceeds the value you will extract from a decomposed solution.
Look for benefits such as:
- Future proofing.
- Modernising and protecting current investments.
- Reducing vendor lock in
- Chasing improvement in revenue and therefore ROI
- Cost saving
And start with
- Largest ROI impact
- Lowest implementation effort
- “Low Hanging Fruit”
Using these guidelines as a starting point will allow you to compose in the most effective way. Compose where it matters.
- SAP Managed Tags:
| User | Count |
|---|---|
| 8 | |
| 3 | |
| 3 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
