Being customer-centric means putting your customers first. Most B2B companies live this philosophy by providing a good customer service. Nevertheless, customer centricity goes beyond this and needs an architecture that supports it. To be truly customer-centric, we have to start outside-in, from the customer perspective to provide a positive customer experience throughout the entire customer life cycle. We need to focus on personas, touchpoints and the customer journeys.
When we talk about touchpoints, it is by far not just the responsive e-commerce website (aka desktop web shop) anymore. Mobile has long overtaken desktop, and new touchpoints like voice, IoT or AR are continuing to spread and are becoming an intuitive part of the user experience. Personally, I am a big fan of voice for home automation, my favorite skill being: “Alexa, water the garden for 10 minutes”. After 10 minutes, it is turned off automatically (If someone is interested in how I built this, just let me know). The point is, I am convinced that there are huge opportunities to automate B2B use cases with voice. For example voice search can be used to streamline the buying process.
However, it is not just about additional touchpoints. To be customer-centric, we have to focus on the entire customer journey and cover all phases of the customer life cycle.
Traditional commerce solutions mainly focus on the phases “Discover”, “Explore” and “Buy”. In B2B, where you have a lot more recurring business, the phases “Use”, “Ask” and “Engage” are critical and therefore need to be supported by the commerce architecture. Do not get me wrong, the transactional (or e-commerce) part still plays a crucial role, but it needs to become more and more integrated into a unified experience that we call the digital customer portal:
In the portal, the customer could see for example the installed base and easily reorder consumables or schedule a repair appointment for a machine that is in use.
Now, what is the best architecture to support these requirements? I am in favor of the following diagram from Gartner, explaining the three approaches to commerce architecture:
- Commerce-Led: The commerce platform has an integrated storefront. It is the aggregation layer that consolidates information from the backend systems like PIM and ERP. This is classic Intershop with pipelines and ISML templates and service integrations. This still works well for a straightforward B2B shop with mainstream requirements.
- Experience-Led: Same as commerce-led, but the storefront is rendered by a WCMS / Web Content Management System (or digital experience platform). The commerce functionality is provided by the commerce engine as REST API. At Intershop we had a pre-built integration with Adobe Experience Manager or, another example, our customer Brita uses this architecture with Magnolia as CMS. This architecture works especially well for a small number of products with custom-designed pages, but also adds additional complexity and integration efforts.
- API-Oriented: This is the evolution from more siloed e-commerce initiatives to a more integrated approach that covers the whole customer journey. It natively supports multiple front-ends/touchpoints and allows the leveraging of the API-economy.
This means, an API-oriented architecture fits best to the requirements needed for customer centricity.
So: how do we build an API-oriented architecture with Intershop? Well, like this:
- On top, we see the Intershop Progressive Web App and a list of other possible touchpoints.
- Intershop is not just “headless”, it also provides a complete PWA blueprint based on Angular that is already integrated with the Intershop CMS. The Intershop PWA is the basis for a specific digital customer portal.
- At the bottom left, we see the Intershop components “Intershop Commerce Management”, “Intershop Order Management” plus additional Intershop Microservices.
- At the bottom right, we see how the architecture can be extended with custom Microservices or other existing products and services like “Microsoft Dynamics 365” to schedule service appointments. We do not have to reinvent the wheel and neither do you, but rather creatively recombine existing products and services.
- In the middle, we have the API mediation layer. This is the single point of access for API calls. It takes care of authentication and routing.
Now that we have covered the basics, there is another very important dimension of the architecture: a loosely coupled architecture and every application/service can have its own DevOps cycle. This helps to innovate faster.
A good example is the development of a Microservice. The following diagram shows how this works with Intershop:
Azure DevOps is used to automate the build and deployment process. It also contains the GIT repositories. Upon changing the Microservice source code, the build pipeline runs automatically and stores a container image in the container registry. From there the deployment pipeline deploys the container images into the Kubernetes cluster where we have three namespaces for integration (INT), user acceptance test (UAT) and production (PRD).
INT and UAT deployments are typically done automatically, but PRD deployments can require manual approval.
Sure, this article just scratches the surface of the topic, but if I made you a little curious to try it yourself, why not book a training: https://www.intershop.com/training