If, in the past, one was used to tackle the conflicting priorities, requirements, and capabilities in E-Commerce projects with the most complete suite solution or so-called best-of-breed approaches, the pursuit of the perfect customer experience often requires new approaches nowadays. Maybe even a new Architecture Blueprint for great Digital Customer Experiences …
Do not get me wrong, there is still a huge market for boxed solutions, but depending on the actual situation of the organization, its goals, and challenges, it might be a wrong choice. If you are at the very beginning of your journey towards digital business models, it might be helpful to have a basically complete solution with consistent tooling and processes.
But what happens if you do not just want to provide the basics to your customers? And in my world basic is almost everything that vendors like Salesforce, SAP, Intershop, Spryker, Adobe/Magento, Shopware & Co have to offer. Sorry to burst this bubble, but an online shop is not really a competitive advantage in 2021. And it was no impressive differentiator in 2010 either. Fortunately, there are hard-working creative product marketing departments exploiting the latest trends and tweaking the sales pitches to the flavor of the month.
With terms like Cloud, Microservices, API, headless, serverless, PWA, JAM and MACH, software manufacturers and service providers try to bridge the gap between reality, technical feasibility, and anticipated user experience. Almost every solution is provided as-a-Service and headless today and without almost no exception all software providers are trying to address these new paradigms with their offerings. In reality, most software vendors and implementation partners are continuing to pursue stuff they know – big software and big implementation projects.
But standard is no differentiator by literal means and project usually means high efforts for adapting commodity to actual needs. It is becoming more and more imperative to break radically with old thought patterns, there is no all-in-one-device-suitable-for-every-purpose and it will remain an illusion. Unless you are looking for standard.
Microservices, API, Cloud and Headless
Relatively new as a term, but by no means a new idea, MACH is an architectural approach that attempts to address the disadvantages of monolithic systems and architectures through lighter, more flexible, and faster solutions. Ultimately, the logical evolution of the SOA concept (service-oriented architecture) is favored by the availability of cloud infrastructures and almost infinite functions and services that can be consumed relatively cheaply and easily and integrated into one’s own offerings.
Microservices: Lightweight development, composition and, if necessary, easy exchange of independent services
API-First: APIs as a connecting element to link all application components and services and achieve maximum reusability
Cloud-native: Flexible scaling and focus on benefits of native cloud technologies instead of maintenance of own infrastructure
Headless: Decoupling user experience and back-end logic enables complete freedom in the design and use of modern front-end technologies
Let us assume the next statements are generic enough to fit every digital customer experience project: What are consequential approaches to digital customer experience architecture and technology selection?
Time-to-market, business value, and customer satisfaction
- Proven and business-ready building blocks for business and development with focus on value creation, customer experience, and optimization of processes instead of maintenance of expandable commodity
- Flexibility and scalability with focus on reusability and interoperability based on existing capabilities
- Adaptability to changing conditions and new requirements instead of functions and features in stock
Prevention of dependencies and technological dead ends
- Simple interaction of the various components through robust and scalable architecture with proper separation of data, processes, and presentation
- Modern technologies for “Developer Happiness” and implementation speed
Architecture Blueprint as the foundation of a digital customer experience
As with building a house, important decisions regarding architecture and requirements come before selecting the picture frames or decorative objects. In fact, you will change these anyways in a few weeks. And very likely you are going to change wall papers and even the room layout a few years from now. In the same way you are planning a house, technology is supposed to support, not dictate, or even limit the goals to be achieved.
Even though it is totally human to get lost in feature comparisons very quickly when making decisions, it if often not the crucial part. First and foremost you need to define the basics. What is supporting your business in achieving goals? So, let us start with a look at a proper target architecture blueprint first. It will get more complex quickly enough.
Beginning with an analysis of internal and external stakeholders, we see that an excellent digital customer experience is more than just an online shop, multiple services and systems need to be involved and connected.
What customers ultimately experience – its touchpoints – is not what you have to work with daily. Certain information come from existing backend systems, some processes are orchestrated in another one and you will work with even other tools. Depending on the complexity of the business and the use cases to be covered it can undoubtedly be an overwhelming number of individual solutions and services that are involved.
But again, if you are aiming for excellent customer experience, the resulting tasks for you are much more comprehensive today than in the pioneering years of e-commerce. That is why there are so many service providers, solutions, technologies, and systems in the customer experience game. SAP, Oracle, Microsoft, and Adobe might cover all or most of the building blocks with their Experience Suites, but not with one singular product.
In fact, it is usually a sales bundle of different, often acquired solutions with different technologies and roadmaps and comparable integration challenges as a result. Again, this is not wrong by definition and probably a necessary step for the providers, but maybe not what you are looking for and need. It might be even the perfect choice for you, but you must dig deeper in the evaluation process.
Technology decision to define the development plan
Assuming you defined which building blocks of the architecture blueprint are required for your digital customer experience, ‘you’re gonna make some big decisions in your little world (Bob Ross)’. Crucial questions for selecting specific technologies and systems are:
- Where do you need standards (real commodity capabilities) and where do you have to differentiate yourself to achieve defined goals?
- Which systems and technologies support these specific requirements?
- Which building blocks fit to existing systems and your capabilities?
- Do you need to “own” these building blocks or can they be consumed as needed?
The illustration above is an example result of this decision-making process, of course results will vary. But they provide essential barriers to fill the architecture blueprint to objectify technology decisions. Everyone loves a good sales pitch with a compelling product demonstration, but the question remains:
Is this relevant, viable, and feasible for your organization?
