A clear and actionable definition of Software Architecture

By loading the video, you agree to YouTube’s privacy policy.
Learn more

Load video

Always unblock YouTube

There are many definitions of software architecture. Some are broad and wage; others take a more scientific approach. I prefer Martin Fowler’s and Ralph Johnson’s definition because it is clear and actionable.

The important stuff

This quote is rather simple in its form, but we need to dig a little deeper to understand its meaning and its clarity.

When expert engineers and software developers work on a software system, they share a common understanding of the software design. They can document this understanding in diagrams, code, or any other form, but the essence is the social agreement on components and models in the heads of the experts.

The second aspect is about “the decisions that are hard to change later“—an essential quote by Martin Fowler. We can’t predict the future. We don’t know what areas need to change as the product evolves as the company pivots. What we can predict is the cost of change. If the cost of change of a component is high and essential to the business, we have identified something of importance.

Follow these aspects to find the important stuff.

Whatever that is

Ralph’s second sentence, “Whatever that is.” is vital as well. Software architecture is not only about selecting high-level architectural patterns like building microservices or a monolith. It’s not only about the selection of the perfect persistence layer. It really can be anything that makes future changes easy.

When I work with clients on existing software products, finding the common understanding of the architectural design is my first move. It often reveals a lack of communication and misaligned understanding. The process of aligning the understanding upon experts usually yields necessary actions to make their architecture more flexible to change. Documenting the important parts of the architecture at that point can help to preserve that understanding.

On greenfield projects or new features, the focus lies more on identifying areas that are hard to change later. This could, for example, be the responsibilities of individual microservices, the general choice of the architecture, or the programming languages to use. These areas are worth being designed and thought through more thoroughly than areas that are easy to change. These discussions aim to develop solutions that make the area easier to change later and build the common understanding.

As a software architect, this definition never failed me. It is easy to explain and actionable, even for people without a background in software engineering. This is practical because the work of a software architect always boils down to creating a strategic technical plan that is well-aligned with the product vision.