The CTO Guide to Ecommerce Architectures

Chief Technology Officers (CTOs) most frequently mention these core capabilities of their ecommerce architectures:

• The ability to innovate at the digital and physical front ends that support sales channels.
• The effort required to integrate the increasing number of other IT systems.

Those who talk more about innovation are usually builders. Revenue, metrics, and innovation are on their mind. They optimize for speed to experiment. These organizations try things out and optimize. They have a high demand for data and flexibility. Ecommerce is an essential part of their business. Software development is part of their organization, even if they use an external workforce as additional capacity. Because they know how to build software, it is easier for them to come up with make-or-buy decisions, with a stronger tendency to make.

Those who talk about integration are usually technology buyers. Costs and effort are on their mind. They want to buy ecommerce features that can be easily integrated into their back-end systems (SCM, PIM, warehouse, finance, SAP). They don’t usually experiment and optimize a lot. Ecommerce is not their core business. It’s just a web shop, sometimes even without an app. They have no substantial software development capabilities and use agencies and consulting partners when necessary. Because they lack builder skills, it’s hard for them to make build-or-buy decisions, which leads to a strong tendency to buy.

If you use innovation and integration in a two-by-two matrix, you can easily map the four kinds of ecommerce architectures:

• Custom-built microservice architectures
• Commercial off-the-shelf (COTS) ecommerce suites
• Custom-built monolithic architectures
• Custom-built front ends with headless COTS back ends

I. Custom-built microservices ecommerce architectures

In this case, the ecommerce application is custom made by software engineering teams that follow a microservices, self-contained system, or serverless approach. Companies that focus on this kind of architecture have a strong builder mentality.

This architecture is optimized for innovation. It often has a diverse set of front ends and requires more integration effort in the back-end systems (CRM, ERP, finance, billing, reporting). Each customer-facing webpage or app screen consists of several small services that are easy to build, maintain, and deploy. Companies that use this architecture need to wait for the vendor to provide new front ends or integrations.

These systems are often highly optimized from a user interface, usability, and conversion perspective. This is possible due to the high flexibility of the microservices architecture and the organization’s agile build-measure-learn mindset that encourages high-frequency experiments.

COTS software might be used for some specialized business functionality (for example, product search, payment, or recommendation). Make-or-buy decisions are made on a smaller level. Microservices architectures can easily integrate cloud services to become more agile, more secure, cheaper, more elastic, and globally available. These architectures don’t just integrate cloud services for computing, storage, monitoring and backup, but for more complex services like analytics, AI/ML, and user management or recommendations. These flexible architectures allow easy cost optimization at all levels.

Organizations with a builder and innovation focus need a workforce with strong software engineering and operations skills in addition to business and other technical skills.

Companies that successfully use a custom build microservices architecture include Otto, Zalando, Adidas, Nike, Dunelm, HSE24, and many more.

II. COTS ecommerce suites

The ecommerce application is licensed from a COTS vendor like SAP, Adobe, Oracle, or Salesforce and managed by a small IT and business team.

This architecture is optimized to get the biggest feature set and easiest integration in the back-end systems (CRM, ERP, finance, billing, reporting) out of the box. The suites consist of many modules and features that are easy to implement with come customization effort.

Innovation on top of these suites is hard. Customers have to wait for the vendor to implement a feature or build it by themselves, which is difficult because these customers lack builder skills. Upgrades get harder as custom functionality is added to the core system. Some companies never apply upgrades when they make a major fork of core software. They are permanently off the upgrade path, which puts them in a high-maintenance scenario. Experimentation, build-measure-learn-thinking, and optimization are not in their DNA. They don’t optimize on KPIs or customer needs; they request features. Adding or exchanging specialized business functionality is also hard because the vendor’s systems do not support this. The maintenance costs of the solution grow over time in proportions larger than the level of customization.

Although the cost of COTS software is easy to calculate, it’s hard to optimize on an operational level. COTS architectures usually become very expansive at scale, especially when operated in on-premises data centers. Migrating the application to the cloud will likely lead to lower total cost of ownership, higher security, better elasticity, and agility. It’s possible to modernize core infrastructure components. The solutions offer good coverage of typical use cases and functionality, but don’t match the performance of best-of-breed solutions in any category.

Data in a COTS system is often hard to access and not easy to interpret and correlate. Sometimes customers are forced to do major updates for no tangible benefit.

The organization needs employees who are familiar with the COTS suite. Because people with these skills and experience are often hard to recruit, the organization might have to depend on expensive external consultants and agencies. Due to the limited capacity and know-how, the full potential of COTS suites is often not achieved.

If organizations migrate these systems to the cloud and in the longer term, move the architecture into one of the upper innovation-focused quadrants, it will be easier for them to attract talents. Modernizing the technology stack is an important step to introducing a culture of innovation.

Sainsbury’s, the UK’s second largest supermarket chain, successfully moved to Amazon Web Services and achieved 70-80% improvement in performance. They went from five or six releases per year to multiple daily releases and were able to reduce their infrastructure by 30%.

III. Custom-built monolithic ecommerce architectures

In this architecture, software engineering teams create a custom ecommerce application using traditional layered architecture patterns. The organizations using this architecture are usually early ecommerce adopters. They were originally focused on innovation or were not convinced by vendor capabilities at the time they laid the foundation for their architecture.

Monolithic architectures have many downsides. They become complex and are hard to maintain. Changes cause side effects, which increases the development and testing effort. Integrating new back-end systems or adapting new front-end channels is slow and error-prone. Because everything is custom, experimentation and innovation are possible, but at a limited scale because in a monolithic architecture, it’s hard to iterate often and fast.

Due to the inherent complexity of the monolithic application, cost optimization is possible, but requires a lot of effort. Sometimes major cost drivers are expensive COTS databases and on-premises data center infrastructure.

Compared to the other architectures, monolithic architectures require the most maintenance and operations effort, which can prevent or limit innovation and growth and lead to conflicts with business stakeholders. In addition, organizations with legacy systems and architectures find it more difficult to recruit business and tech talent. However, microservices architectures need software engineering and operations skills. Therefore I recommend organizations take an evolutionary approach. Retailers and consumer brands should migrate to the cloud and modernize in the cloud in the short term and then move into one of the upper innovation-focused quadrants.

IV. Custom-built front ends with headless COTS back ends

This architecture promises the best of both architectures already described, but it comes with some downsides. In this architecture, the front ends (web, mobile, social, video, physical store) are made by software engineering teams while the ecommerce back end is a COTS solution from vendors like Spryker, Elastic Path, or commercetools.

These vendors apply the headless pattern to their architecture. In this pattern, the ecommerce business logic is encapsulated in a back-end layer, which consists of microservices. This layer supports, through an API, the diverse front ends with the same and consistent business logic (product catalog and search, user management, inventory).

It is optimized for fast innovation at the front ends and sales channels and the biggest feature set and the easiest integration in the back-end systems (CRM, ERP, finance, billing, reporting) out of the box. The headless back end consists of many modules and features that are easy to implement with some customization effort.

Although innovation is easy on the front end, it is harder on the back end. The vendor must build new features. Depending on the choice of COTS, customers can build new back-end functionality by themselves because they have builder capabilities. Often Amazon AppFlow can be used to enable a modern event-driven architecture around the COTS system. Amazon AppFlow transfers events from these third-party systems and pushes them into a cloud-based event bus that is the backbone for any custom build service.

The organization can make decisions about whether to make or buy on the component level. To some extent, depending on the restrictions of the COTS vendor, these companies can use cloud services too. Where the back-end landscape consists of multiple systems, some integration and orchestration effort is required.

These systems are often highly optimized from a user interface and usability perspective. This is possible due to the high flexibility of the front-end architecture. Experiments and optimization that touch back-end services are harder and take more time, which leads to a limited optimization of the overall conversion rate.

Cost optimization is easy on the front end, but harder at the COTS back end. Comparable to ecommerce suites, this architecture might become expensive at scale. Cost optimization is usually just possible through contract negotiations and the use of cloud infrastructure. Data in the COTS system is often hard to access and not easy to interpret and correlate. Sometimes customers are forced to do major updates from which there is no tangible benefit.

The organization needs software engineering and operations skills at the front end and COTS admins at the back end.

Organizations with this kind of architecture need strong software development skills at the front end and the overall system. They need employees who are familiar with the COTS suite. Because people with these skills and experience are often hard to recruit, the organization might have to depend on expensive external consultants and agencies. Due to the limited capacity and know-how, the full potential of COTS suites is often not achieved.