The Limitations of “Horizontal” Platforms

Layered platforms don’t scale, and microservices aren’t much better. They are anti-agile and keep organizations from adapting to change.

Agility and Adaptivity

Agile development is certainly the prevalent paradigm in most areas of IT these days, especially in e-commerce. Markets change rapidly, and if you can’t respond to changes, you’re out. While there are very different interpretations of what “agile” means and how to do it, it is always useful to remember the agile principles, and especially Martin Fowler’s true words:

“Agile development is adaptive rather than predictive.”

In regard to technology, adaptivity is the key characteristic of agility. A fair metric of adaptivity could be the combination of two factors:

  1. How much net increase in customer value can you deliver per cycle, assuming a constant size of your workforce?

Layered Architectures

A typical web application is built as a so-called multi-tier (or, “layered”) application. As the name suggests, it consists of layers, where each layer implements a set of similar technical concerns, and is decoupled from other layers with different concerns. Each layer consists of modules, i.e. building blocks which implement the functionality of a layer. (Some environments use different terms than layer/module, but they mean the same.)

The Evolution of E-Commerce Platforms

At the beginning, an e-commerce platform has only few layers and it is usually “monolithic”, meaning that there is exactly one deployable piece of software.

Wait, Did You Just Say Microservice Architectures Are Horizontal?

There, I said it: Even an SPA + microservice architecture is horizontal. Just look at it! The frontend is one big layered monolith, especially from a delivery perspective. Below that you have multiple layers of services, where some are public and some are shared or private. If you draw a dependency graph between these components, it will resemble a layered architecture.

The Hidden Layers

Software ecosystems are often being described only from a runtime application perspective, meaning that the supporting functionality around the application is out of scope. But when we talk about dependencies and complexity, there are many hidden “layers”, which have similar behaviour and effects as the runtime layers. For example:

  • Administration tools are usually “layered” as well. While you could argue that they usually have a rather narrow scope, like CMS, ERP or CRM tools, they are similar to microservices in that they have no implicit restriction on “incoming” dependencies, and therefore cannot simply adapt to changing requirements.
  • The same is true for external dependencies. An e-commerce platform is connected to a plurality of other services such as payment providers, suppliers, shipment, performance marketing, web analytics and many more.
  • Runtime infrastructure is often set up in a way that all modules within the same layer use the same infrastructure: one database for all data, one S3 bucket for all frontend artifacts, one EC2 + EKS cluster for all microservices. Fixing or updating parts of the infrastructure is complex and risky.

Horizontal Architecture, Tedious Workflow

For our scenario, we will assume an imaginary IT department and look at a typical workflow to implement a feature. Of course, this is simplified and hypothetical, but it is derived from real-world organizations, and the insights are well applicable in practice.

  • An architect specifies the necessary technical changes in the platform and how they are are integrated across all layers and/or microservices. A designer makes pixel-perfect mock-ups of every possible UI state.
  • After product managers, architects and designers agree on the specifications, the feature request is approved for implementation.
  • Each development team derives a set of tasks and start working on them in accordance with their backlog priorization. As soon as the last team has finished their implementation, the new feature is ready to be rolled out.
  • Because we have changes in different parts of the platform, we do a lot of testing before the final customer roll-out. And a lot of bug-fixing. And re-testing again.
  • Finally, we’re ready to release!

Do Designers Specify or Implement?

By the way, there’s an interesting observation to make when we look at the UX/UI team, and this is something we see far too often, sadly: Why do the designers make detailled UI mockups before the implementation? And shouldn’t the UI designers be part of the frontend team?

Adaptivity vs. Technology Lock-in

The tedious workflow aside, large-scale horizontal platforms are not at all adaptive. The more monolithic parts it has, the worse they suffer from the technology lock-in.

  • You can’t pick the optimal tool/framework/library for the job, because it is incompatible with the existing ecosystem, and migration costs and risk would too high.
  • The platform is full of pseudo-features (i.e. features which don’t have any customer value by itself, but instead allow business to deal with historical quirks and the long delivery cycles) and anemic code (code has no business value and is only there to keep different development teams from stepping on each other’s feet).

Technical Lead at TUI. 16+ years of experience as Software Architect, Fullstack Developer and Agile Coach.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store