After all, we didn’t omit the bottom-up approach entirely. We defined key principles and paradigms of modern, cloud-native software development that the solution candidates would need to follow to match our expectations. Given the fact website delivery performance (e.g. FCP — First-Contentful-Paint, LCP — Largest-Contentful-Paint and others) is critically important for E-Commerce conversion rate and having our globally-spanning, fast-paced business in mind, we wanted to make sure the solutions are able to fulfill our requirements with the least possible effort (esp. in terms of infrastructure). Also, looking into the future, we made sure the technologies we select not only work for E-Commerce today but also can support the challenges of the new and exciting area of Sleep Tech and IoT ahead of us in 2 or 3 years.

To bring together the problem space (our understanding of the business requirements) and the solutions space (the solution candidates), again, we peeked at tech industry analyst Gartner and their recent prediction:

‘By 2023, organizations that have adopted a Composable Commerce approach will outpace the competition by 80% in the speed of new feature implementation.’

— Gartner Research, ‘Composable Commerce Must Be Adopted for the Future of Applications’, 2020

According to Sitecore ‘composable commerce is a development approach of selecting best-of-breed commerce components and combining or ‘composing’ them into a custom application built for specific business needs.’. This sounds like a very well-fitting approach for Emma and taking all these perspectives together we defined the following list of key principles for our technical evaluation.

1. Flexibility

At the size of our business and global reach it becomes important that we can use purpose-fit software services flexibly and attach or detach them as needed. With big local differences in certain geographies, it might even make sense to use specially localized solutions for some business domains, even if those would serve redundant needs from a high-level perspective. To support this flexibility of system integrations, an API-first solution design (i.e. all functionality can be triggered and all internal data of a system be consumed using APIs) is key.

Another take on flexibility is how easy or complex it will be to move to another component in terms of technology stacks used, especially programming languages and frameworks. Many of the solution providers provide only proprietary development stacks instead of Open-Source, locking you and your business in.

Therefore, all SaaS solutions (of course there is always one exception — the ERP in our case) and internally developed services MUST be built supporting APIs and using Open-Source tech stacks, while proprietary development stacks explicitly are a MUST NOT.

2. Performance

While monolithic software system designs have the advantage of low complexity, they inherently suffer from bad technical scalability in terms of runtime and persistence distribution because of their centralistic nature. That is where distributed microservices, single-purposed and thus simplistic by design, shine and help to run user-facing workloads closer to the customer / in the CDN and business logic and persistency in message queues, instead of big central databases. Designing this natively on the cloud offers high performance and global distribution with very little infrastructure efforts.

We therefore prefer light-&-lean, microservices-based solutions living distributed on the cloud.

3. Organizational Scalability

Decoupling services horizontally (microservices instead of monolith) and vertically (independently deployable tiers) does not only have technical advantages but also allows to scale-out the work in these different areas to multiple dedicated teams. This enables the organization to parallelize complex software development efforts without tight dependencies, avoiding teams being blocked by other teams.

This is precisely how we want to work.

4. Harmonized Software Development

Decoupling business domains into dedicated teams is a cool thing but if every team follows a different software development process, uses individual CI/CD tools, and builds on different tech stacks, the organization will face highly impactful downsides. It inevitably will lack a common understanding of software quality and will only have very limited opportunity of knowledge sharing across teams and almost no flexibility to move capacities when business priorities are changing.

This is why our project’s Developer Experience workstream defined a new, modern software development process from scratch, defined documentation standards (e.g. C4 architecture model, ADRs, design docs), evaluated CI/CD tools all engineers use and defined the golden standards and provide blueprints/templates for tech stacks utilized. The SaaS platforms we select would need to accommodate such modern software engineering practices with their tooling.

Also, a factor worth mentioning is talent availability. Some technologies, although maybe technically superior, are especially hard to hire for. We’re in E-Commerce and Sleep Tech, cool stuff but not exotic or extreme like building rocket ships headed to Mars and thus well-known technologies with large available talent pools are our focus.

What a MAtCH!

The technical principles laid out above have a high degree of overlap with the MACH Alliance manifesto — defining a set of 4 basic technical design characteristics (1. Microservices-based, 2. API-first, 3. Cloud-native, 4. Headless). It is no surprise the ultimate selection we took for the SaaS systems to run our business domains as a composable commerce architecture, are solution providers that are members in MACH Alliance.

A sidenote on solution and provider aptitude: While running your small business or startup on a fresh platform of an emerging solution provider or self-hosted Open Source is no problem, moving a considerable-sized business like Emma’s on one is an entirely different thing. Imagine the solution becoming deprecated due to its contributors abandoning it (in case of community-driven Open Source) or the provider company acquired and/or shut down. This is considered a real and critical business risk! That’s why our selection of a solution provider also demands for a certain business stability, especially in terms of funding.