Do your architects actually work on architecture?

application architecture   architecting  

Software is eating the world. If your organization neglects its application’s architecture it is risking its existence. The solution is to let architects architect! To learn why, read on.

What is architecture?

Writing my book, Microservices Patterns, forced me to dissect the phrase “Microservice Architecture”. This ultimately led me on a trip down memory lane to reflect on topics, such as the definition of architecture and why it matters. As I write chapter 2, my favorite definition of architecture comes from Len Bass and colleagues at the Software Engineering Institute, who played a key role in establishing software architecture as a discipline. They define software architecture as follows:

The software architecture of a computing system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.

This is obviously an abstract definition. But its essence is that an application’s architecture is its decomposition into parts (the elements) and the relationships (the relations) between those parts.

As I describe in my book, the exact meaning of element and relationships depends on your perspective or view. For example, a developer is typically concerned with elements, such as classes, packages, and modules, and the relationships between them, such as inheritance, associations and dependencies. In contrast, a network engineer typically focusses on elements, such as machines, and relationships, such as networks. The 4+1 view model of software defines 4 such views with the +1 being scenarios that animate the views.

Why architecture matters?

An application has two categories of requirements. The first category includes the functional requirements, which define what the application must do. They’re usually in the form of use cases or user stories. Architecture has very little to do with the functional requirements. You can implement functional requirements with almost any architecture, even a big ball of mud.

Architecture is important because it enables an application to satisfy the second category of requirements: its quality of service requirements. These are also known as quality attributes and are the so-called -ilities. The quality of service requirements define the runtime qualities such as scalability and reliability. They also define development time qualities including maintainability, testability, and deployability, which determine development velocity and agility. The architecture you choose for your application determines how well it meets these quality requirements.

Architectural requirements is often neglected

Sadly, many organizations neglect architectural requirements unless they map directly to user visible features. For example, a typical product manager relentlessly focusses on features and schedule. As a result, they will often define performance and scalability requirements since those are visible to the customer. But development time qualities are often neglected.

The problem with neglecting development time qualities is that they invariably decline as the application grows. An application can outgrow its architecture. For example, a monolithic architecture might work well for a small application that’s developed by a six person team but it probably won’t well for a large, complex application developed by a large team. Also, technical debt typically accumulates. Given that the application’s development-time qualities determine development velocity and agility, an organization that neglects them will find that it is increasing more difficult to deliver features.

The need to deliver software rapidly, frequently and reliably

Neglecting development time qualities can very easily turn into a crisis. That’s because software is eating the world. And, the market is becoming increasingly volatile and uncertain. Every organization needs to be a software company that can deliver software rapidly, frequently, and reliably.

This requires a strong focus on the development-time attributes of the architecture. The following graph shows what can happen over time if those attributes are neglected.

As the application grows, and presumably becomes more valuable, the organizational agility and development velocity decline. The gap between actual and desired agility, which grows over time, represents an existential threat to an organization. There is an increasing risk of disruption by a competitor that can rapidly innovate because it has mastered delivering software rapidly, frequently, and reliably.

Consider this insurance industry example. Zego is a fintech startup that offers hourly commercial insurance for gig economy workers. Their CEO told the Financial Times:

We are here to build a global company, up against Axa and Allianz in ten, twenty, or thirty years time…People need proper solutions that those companies, because of their archaic infrastructure, can’t offer.

And, here is a banking example. The Hong Kong Monetary Authority recently licensed 8 new digital-only banks. As a result, HSBC, which is the dominant retail bank, now has 8 new competitors. How quickly can you organization react to these kinds of emerging threats to your business?

Let architects architect

The solution is for an organization to manage and prioritize architectural requirements, especially development-time qualities, in the same way as user visible features. It must allocate time and resources to working on the architecture in order to ensure that it meets the needs of the organization. Architects be more than smart, experienced developers who work on the complex, new features. Architects need to be given the opportunity to architect!

To learn more


application architecture   architecting  


Copyright © 2024 Chris Richardson • All rights reserved • Supported by Kong.

About Microservices.io

Microservices.io is brought to you by Chris Richardson. Experienced software architect, author of POJOs in Action, the creator of the original CloudFoundry.com, and the author of Microservices patterns.

Upcoming public workshops: Microservices and architecting for fast flow

In-person: Berlin and Milan

DevOps and Team topologies are vital for delivering the fast flow of changes that modern businesses need.

But they are insufficient. You also need an application architecture that supports fast, sustainable flow.

Learn more and register for one of my upcoming public workshops in November.

NEED HELP?

I help organizations improve agility and competitiveness through better software architecture.

Learn more about my consulting engagements, and training workshops.

LEARN about microservices

Chris offers numerous other resources for learning the microservice architecture.

Get the book: Microservices Patterns

Read Chris Richardson's book:

Example microservices applications

Want to see an example? Check out Chris Richardson's example applications. See code

Virtual bootcamp: Distributed data patterns in a microservice architecture

My virtual bootcamp, distributed data patterns in a microservice architecture, is now open for enrollment!

It covers the key distributed data management patterns including Saga, API Composition, and CQRS.

It consists of video lectures, code labs, and a weekly ask-me-anything video conference repeated in multiple timezones.

The regular price is $395/person but use coupon CCMHVSFB to sign up for $95 (valid until November 8th, 2024). There are deeper discounts for buying multiple seats.

Learn more

Learn how to create a service template and microservice chassis

Take a look at my Manning LiveProject that teaches you how to develop a service template and microservice chassis.

Signup for the newsletter


BUILD microservices

Ready to start using the microservice architecture?

Consulting services

Engage Chris to create a microservices adoption roadmap and help you define your microservice architecture,


The Eventuate platform

Use the Eventuate.io platform to tackle distributed data management challenges in your microservices architecture.

Eventuate is Chris's latest startup. It makes it easy to use the Saga pattern to manage transactions and the CQRS pattern to implement queries.


Join the microservices google group