Verticalization

The Problem with Layered Architectures

Traditionally, complex platforms were (and often still are) built in layers, in a so-called “layered archtecture”:

Each of this layers is “loosely coupled” with the other layers, meaning that the internal logic of each layer is encapsulated and hidden away from the others. Layers can only interact with each other through well-defined public interfaces (APIs).

While this approach is not inheritly wrong or bad, it has one major downside: The entire development of the platform is constrained by technology, regardless of the business logic it implements.

In a complex platform, you have lots of very different business concerns, usually even implemented by different teams. Now all these business concerns and teams must submit to working within several monolithic layers.

Imagine the following situation: Team A has implemented, and is ready to deliver, a feature which causes changes in the Presentation, Interaction, State layers. At the same time, Team B is also working on the same layers, blocking Team A from making a release. Now think what happens if you have five or more teams working on the platform, blocking each other.

As such a “horizontal” platform grows, this web of inter-dependencies can lead to some unpleasant side effects:

• Technology lock-in, i.e. you are bound to the existing technology and can’t pick the right tool for the job.
• A lot of documentation and upfront specifications necessary for consistency.
• A lot of post-release testing.
• Large, risky releases with platform-wide release dates, “feature-freezes” and a lot of crunch time.
• “Circumvention features” and anemic code:
  • A circumvention feature is one that doesn’t have any business value by itself, but instead allows business to deal with architectural quirks.
  • Anemic code also has no business value and is only there to keep different development teams from stepping on each other’s feet.
• Alienation and demotivation due to low delivery performance.

Why not (only) Microservices?

Are microservices a possible solution? Not really.

(NB: Microservices are not to be confused with Microfrontends!)

As a layered platform grows over time, the layers tend to eventually dissolve and morph into smaller, specialized services which don’t really care about horizontal boundaries. Take this imaginary setup for example:

In a microservice architecture, most parts of the platform are isolated services, and there are smart patterns to decouple them and make them fault tolerant. This is great, and certainly a step in the right direction. However, the boundaries of microservices are often still very technical.

Although in a well-crafted microservice ecosystem most services follow a domain model which is directly derived from business logic, the features which constitute the user experience are still spread across several services. In the end, we often need to deploy multiple independent services to deliver a feature, anyway.

Verticalization to the Rescue

A vertical architecture, will put the business in the driver seat, and focus on feature delivery. This is possible because the boundaries between software modules (and thereby: teams/suborganisations) are primarily defined by business concerns and user experience.

Each of these slices is an isolated application, and each application is a product of its own. It is managed by a dedicated product team, which is lead by a Product Owner. (Look! The term “Product Owner” finally makes sense!) Each product team chooses their optimal “software stack” with the technology and tools which suit them best, regardless of what other teams do. The ecosystem itself is technology-agnostic.

Technology is treated as a commodity here: What is great today can hold you back tomorrow, so be prepared to throw it away in favour of something new. Don’t get locked-in or too invested in a particular technology.

End-to-end Responsibility

In a platform based on a layered architecture, you often have technical teams. For instance, you might have the UI team, the frontend team, backend team, the database team, the infrastructure team. Implementing a feature requires work from multiple teams. And delivery only happens after a certain set of features are finished in all areas.

On a “vertical” platform, on the other hand, each team will develop one or more isolated applications. These applications have no hard dependencies on the work of other teams. When a product team is fully responsible for their application and has a high degree of autonomy, we speak of “end-to-end responsibility”. This means two things:

1. Regarding the workflow: The team, including the PO, owns every step in the development process; including things like business analysis, ideation, UX/UI, software architecture, development and operations.
2. Regarding technology: The team maintains all functional parts (the “full stack”) of the application: UI, frontend, backend, database, infrastructure.

End-to-end product teams need to be crossfunctional, meaning that they should not rely too much on external resources to do their job.

Scaling Through Slicing

The verticalization paradigm alone does not provide sufficient guidance for building a plattform. The technical concept to implement a “verticalized” platform is called microfrontend architecture. We have an entire article about microfrontends, but in the context of verticalization, it is most important to understand how a microfrontend architecture scales.

In the images above, we have a few thick slices, in our example this would mean that we have one application per product type (e.g. package, accomodation, flight, cars, cruises, …). As long as our platform is rather small, this would be a viable approach: Each application could be managed by a “two pizza team”. As soon as the platform starts growing, we must either increase the team size per application, which would result in a handful of large monolithic applications. Or we must cut the applications in ever smaller, autonomous slices.

This is exactly what a microfrontend architecture is: Rather than maintaining a few large product applications, we have many tiny applications, each one solving exactly one business problem. The “slices” are very loosely coupled and only integrated at runtime in the browser, allowing product teams a high degree of autonomy, resulting in fast delivery and high value.