Verticality

Evolutionary Systems - Verticality

Verticality structures a system into coherent domain aspects, making the domain the main driver for high level design.

Domain aspects are allowed to share technologies, frameworks and concepts – but are not bound to it. Verticality therefore facilitates local experiments in architecturally independent system parts.

Low Rating:

  • Multiple teams work into one monolithic block of software, often triggering dependencies that make work brittle and risky.
  • Domain aspects are interwoven and/or not clearly visible in the programs code and structuring
  • If there is the concept of components, they are integrated using surreptitious coupling, e.g. by using the same database tables.
  • Frameworks and technologies are not manageable independently (including versioning)

High Rating:

  • The system is structured into meaningful parts representing the actual domain, with its contexts and concepts.
  • Parts (components or ‘services‘) are isolated through interfaces and possibly by process boundaries.
  • Teams are only marginally restricted by overarching technology-aspects. Many decisions can be taken locally without too many side-effects.
  • The integration efforts follow modern principles like ‘dumb pipes, smart endpoints‘ and ‘tolerant readers‘

Core Ideas

Understand your context and domain

Even though domain aspects drive the high level architecture work, we need some overarching standardization on technological and conceptual aspects. Normally this ensures deployability, basic security or compatibility. Summarized under the term ‘macro-architecture’ we should aim for as little restriction as possible.

Structure your system into independent domains

Using domain concepts within our technical implementation helps with maintainability and long-term evolution. Mapping domain ideas into self-sufficient services (or verticals) is even more beneficial. This implies thinking about bounded contexts, data views and mapping mechanisms.

Care for deep technical decoupling

In order to use the bigger action scope for individual teams and to allow for domain-specific optimizations, domains should be technically decoupled. Down to platform or even container level. Working with asynchronous integration mechanisms, eventing platforms and isolated data views helps to make technical standardization an option, rather than a necessity.

Sector Rating Aspects

These are aspects that can be used to assess your performance and maturity in this sector. For a detailed explanation please have a look at our how to page.

Aspect Adoption Lifecycle
Important trends, technologies and topics are discussed and worked on in small and independent peer groups Late majority
Business processes are actively managed and improved; their relation to software systems is taken into account Late majority
System parts (services) are connected by well-defined interfaces Early majority
Base frameworks and platforms are decided locally (e.g. decoupling through docker an other container technologies) Early majority
Systems are defined by business domain boundaries (e.g. Domain Driven Design) Early adopters
System parts (services) are isolated by business domain boundaries Early adopters
Patterns like ‘dumb pipes, smart endpoints’ or ‘tolerant readers’ are used Early adopters
Postel’s law is respected (Be conservative in what you do, be liberal in what you accept from others) Early adopters
Systems are decoupled temporally (e.g. through asynchronous communication / event-driven systems) Early adopters
The business domain is actively researched (e.g. Event Storming) Innovators
Teams are optimized for flow (e.g. with Team Topologies) Innovators
Technical decisions can be made on a per-team basis, without interfering with the overall organization Innovators
Abstraction of infrastructure is achieved by serverless and functional programming (e.g. AWS Lambda) Innovators
Peers support each other in their struggles (e.g. cooperative case advice) Innovators

Connections