Software Architecture Definition: A Clear and Actionable Approach
Software architecture is crucial to the success of any software development project. It’s essential to have a clear and actionable definition that helps guide decisions and make future changes easier. In this blog post, we’ll discuss the definition of software architecture according to Martin Fowler and Ralph Johnson, and explore how this understanding can benefit your projects.
Architecture is about the important stuff.
Ralph Johnson
Whatever that is.
Understanding the Important Aspects of Architecture
Ralph Johnson said, “Architecture is about the important stuff. Whatever that is.” This quote may seem simple, but its meaning becomes clearer when we dig deeper. Expert engineers and software developers share a common understanding of software design when working on a system. This understanding can be documented through diagrams, code, or any other form, but the essence lies in the social agreement on components and models among the experts.
Martin Fowler emphasizes the importance of “the decisions that are hard to change later.” We can’t predict the future, so we don’t know which areas of the product will need to change as it evolves. However, we can predict the cost of change. If a component’s cost of change is high and crucial to the business, we’ve identified something important.
Applying This Definition to Projects
Ralph Johnson’s second sentence, “Whatever that is,” is also vital. Software architecture isn’t only about selecting high-level architectural patterns like building microservices or a monolith. It’s not only about choosing the perfect persistence layer. It can be anything that makes future changes easy.
When working with clients on existing software products, the first step is finding the common understanding of the architectural design. This process often reveals a lack of communication and misaligned understanding. Aligning the understanding among experts usually leads to necessary actions to make the architecture more flexible to change. Documenting the important parts of the architecture at this point can help preserve that understanding.
On greenfield projects or new features, the focus is more on identifying areas that are hard to change later. Examples include the responsibilities of individual microservices, the general choice of architecture, or the programming languages used. These areas are worth designing and thinking through more thoroughly than areas that are easy to change. The goal of these discussions is to develop solutions that make the area easier to change later and build a common understanding.
As a software architect, this software architecture definition has never failed me. It’s easy to explain and actionable, even for people without a background in software engineering. This practicality is crucial because a software architect’s work always involves creating a strategic technical plan aligned with the product vision.
Written by
Founder Lasssim, Software Architecture and Development Expert
Written by
Founder Lasssim, Software Architecture and Development Expert
