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

• Read my Microservices patterns book
• Talk to me about my microservices consulting and training services.
• Learn more about microservices at adopt.microservices.io