CxOs neglect architecture at their peril

application architecture   architecting  

---

To paraphrase Marc Andreessen software has eaten the world. It’s increasingly rare to find a business that is not dependent on software. As a result, it’s essential that an organization’s leaders pay attention to software architecture.

What is architecture?

Len Bass and colleagues at the Software Engineering Institute - pioneers in the discipline of softeware architecture - 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.

For example, two different architectures (or more precisely, architectural styles) are the monolithic architecture and the microservice architecture. The monolithic architecture structures the application as a single executable/deployable unit. In contrast, the microservice architecture structures the application as a set of loosely coupled, independently deployable executable/deployable units (a.k.a. services).

Why architecture matters?

An application’s architecture is important because it determines whether an application satisfies its non-functional requirements, which are distinct from functional requirements that define features. Non-functional requirements also known as quality of service attributes and are the so-called -ilities.

It’s essential that you:

1. Clearly define the application’s non-functional requirements
2. Pick a software architecture that satifies them
3. Evolve your architecture, when necessary, so that it continues to satisfy its changing non-functional requirements

Runtime vs. development time non-functional requirements

There are two categories of non-functional requirements:

• Runtime quality attributes - define the runtime behavior of the application such as scalability and reliability.
• Development time quality attributes - define development time characteristics of the application including maintainability, testability, and deployability, which determine development velocity and agility.

Normally, organizations focus on runtime quality attributes since they are often visible to the user. However, for many applications, development time quality attributes are also essential. For example, the need to frequently and easily change an application - perhaps it’s a source of the organization’s competitive advantage - corresponds to development time quality attributes. If the application is large and/or complex, the microservice architecture might do a better job of satisfying those development time quality attributes.

Architectural requirements change over time

An application’s non-functional requirements invariably change over time. For example, the business become more successful resulting in more users. The application and its development team grows. The definition of what’s mainstream technology changes.

As result, an application’s architecture eventually no longer satifies its non-functional requirements. For example:

• the number of users increases to the point that the application no longer scales effectively to handle the increased load
• the application increases in size and complexity and outgrows the architecture
• the application’s team increases in size and is no longer supported by the architecture
• the application’s technology stack becomes outdated and obsolete

Let architects architect

As I wrote earlier, it’s important that organizations have architects who actually do architecture. They need to focus on evolving the application’s architecture so that it continues to satisfy its changing non-functional requirements. This requires the organization (e.g. CxOs, product managers, etc) to recognize the importance of architecture, support the architects, and act upon their recommendations for architectural changes.

What happens when architecture is neglected

Sadly, it’s all too common for an organization to ignore its applications’ architecture. For example, organizations focus on what’s visible to the user - features and runtime requirements - and neglect development-time requirements. The problem, however, with neglecting development time qualities is that they invariably decline as the application grows. As a result, it becomes increasingly difficult for the organization to deliver new features and compete in the market.

When things go horribly wrong…

Slow development isn’t the only problem. Sometimes, neglecting architecture can result in catastrophic failures.

Southwest airlines appears to be an extreme example of an organization that neglected its architecture (and, perhaps more generally, its IT systems). It appears that the organization ignored warnings from employees about the fragile state of its scheduling system. As a result, a severe winter storm delayed numerous flights, which then caused the scheduling system to collapse under the load of rescheduling planes and crews. The result was a nightmare for travelers and flight crews. It has also cost South West airlines almost a billion dollars.

Another example of an apparent under-investment in architecture is October’s Kakao outage. Kakao, which evolved from a messaging app to an ecosystem that is so widely used in South Korea that it’s essentially critical infrastructure. In October, there was a fire at its main datacenter, which caused Kakao services to be unavailable for many hours. Arguably, such critical infrastructure should be deployed across three data centers in order to ensure high availability. One outcome of this outage was the resignation of the co-CEO.

Summary

To quote Brian Foote and Joseph Yoder:

“If you think good architecture is expensive, try bad architecture.