Architecture, moving beyond grand designs

Key Takeaways

• Traditionally architecture has been equated with the structural design of systems, e.g. Microservices architecture. In this article, I argue that there are at least two other equally important aspects of architecture.
  First satisfying quality attribute requirements and second surfacing key architectural decisions.

• Architecture, for the most part, is about satisfying technical requirements or Quality attribute requirements (also often referred to as non-functional requirements). Examples of quality attributes include performance, scalability, and availability. Collectively, they are sometimes referred to as the "ilities" of a system.

• Architectural decisions articulate the "why" and the justification behind choosing a given structural design over competing alternatives.

So architecture encompasses these three key activities:

• Uncovering technical requirements/quality attribute requirements and showcasing traceability to satisfy these requirements.

• Articulating the why (the rationale) behind key decisions.

• Structural design - Wiring components to effectively satisfy technical requirements

Introduction

Software architecture has a contentious reputation, and many self-respecting engineers would never want to be called architects, even though they do a lot of architecture.

While architecture by stealth is one way to rescue solutions, rebranding architecture is essential for making it attractive to our most talented engineers.

In this article, I unpack architecture into three key activities and argue that architecture is a valuable skill worth investing in and a far cry from the absurd designs that get branded as architecture and justified by "best practice" (Whatever that means).

Software architecture needs to be wrested from committees of people disconnected from engineering and put in the hands of the people who can actually make it executable - Pierre Pureur

Start by uncovering the technical requirements

Architecture is chiefly about satisfying technical requirements/quality attributes, also referred to as non-functional requirements.

For example, Twitter - The functional requirements are simple: sending and viewing tweets, following members and maybe a bit more. In comparison to the enterprise domains like banking or insurance, twitter's functional requirements are trivial, but the architecture of Twitter is anything but simple; Why? Because it satisfies non-trivial technical requirements like scalability (millions of tweets, millions of users) and availability (five 9's or more).

Uncovering technical requirements is a pre-requisite for selecting architectural styles (e.g. Microservices, Event-driven, Layered etc.) and developing architectural designs.

Tradeoffs - There is no best architecture, only the least worst

The most important property of architectural decisions is that optimisation never occurs at extreme values. If optimisation occurred at extreme values, then quantification would be unnecessary. In contrast, architectural decisions always require quantification because we must balance two or more competing factors.

Optimisation never occurs at extreme values. Architectural decisions always require quantification because we must balance two or more competing factors. For example performance and security.

Lastly, any discussion about architecture without addressing costs is incomplete. Just like satisfying functional requirements adds cost, meeting technical requirements also adds costs.

Architectural Decisions

I am sure you have seen architectural designs and thought, "WTH!" Why would they do X??

Architectural documents go to great lengths to explain the "how" and "what". Still, they often stay silent on the "why" One of the hardest things to track during the life of a solution is the motivation behind certain decisions.

Architecture involves making decisions seeking feedback on them and ideally building consensus by showcasing strong traceability to one or more key business drivers and/or risks.

Architecturally significant decisions are those that affect the structure, non-functional characteristics, dependencies, interfaces, or construction techniques.

• The structure refers to decisions that impact the patterns or styles of architecture being used. An example is a decision to share databases between a set of microservices.
  This decision impacts the microservice boundaries and affects the application's structure.

• The non-functional characteristics are the architecture characteristics (“-ilities”) important for the application or system being developed or maintained. If a choice of technology impacts performance, and performance is a critical aspect of the application, then it becomes an architecture decision.

• Dependencies refer to coupling points between components and/or services within the system, which in turn impacts overall scalability, modularity, agility and so on.

• Interfaces refer to how services and components are accessed and orchestrated, usually through a gateway, integration hub, service bus, or API proxy. Interfaces impact others using the system and hence are architecturally significant.

• Construction techniques refer to decisions about platforms, frameworks, tools, and even processes that impact the solution. An example is a decision to use a container a based runtime platform for all stateless components.

  The structural design comes last

  The system's structural design is the most popular aspect of architecture. It refers to the architectural style (or combination of styles) the solution implements (such as microservices, layered, or microkernel). While designing the solution structure, it is critical to focus on the relationships and interaction patterns (white space) between components.

  I'll reiterate here that describing an architecture solely by the structure does not wholly elucidate an architecture. For example, suppose an architect is asked to describe an architecture, and that architect responds, “It’s a microservices architecture.” Here, the architect is only talking about the system's structure but not the system's architecture.

  Knowledge of the architectural characteristics and decisions is needed to fully understand the system's architecture.

References

Fundamentals of Software Architecture

Continuous Architecture in Practice

Architecture decisions by Michael Nygard

Building Microservices