Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Article Series: Continuous Architecture

Article Series: Continuous Architecture

As organizations sought more agile approaches to delivering software, software architecture got short shrift. In some ways, it deserved it, because the old way of architecting software had become cluttered with empty ceremonies and diagrams of dubious value, drawn by people who were going nowhere near the code. Many agile teams felt that the architecture of a system would simply, almost magically, emerge from simply using modular coding techniques and refactoring. Modular, well-written software is important, but as the "can’t see the forest for the trees" analogy suggests, there is something more to architecture than simply well-structured, modular code.

In this series of articles, we reframe software architecture in terms of decisions that teams make about how their system will handle its quality attribute requirements (QARs). QARs include things like scalability, security, performance, throughput, sustainability, and the like - things that the system must achieve beyond the functional requirements that it must satisfy. Looking at the code can give a reasonable picture of how the system satisfies its functional requirements, but how it meets its QARs is far more subtle, even hidden. In our view, software architecture, reframed in terms of decisions, completes the picture of how the system works by making clear the choices that the team has made, and why.

There is something more in these articles that you might have even noticed from just the paragraphs above: We have taken the responsibility from software architects working separately from developers and have reframed software architecting as a skill that all developers need. This does not mean that there is no role for specialization and professionalism in architecting software; far from it.  We believe that software architecting needs to play a much greater role in development, and that every development team needs to be skilled in it. This means that the role of the software architecture professional needs to grow to include coaching and mentoring developers, helping them to grow their architecting skills by saying "let’s work on this together."

We hope you enjoy these articles and find them valuable. We hope they provide you with practical ideas that you can apply to your work, and sometimes even challenge you to look at problems in new ways.

Series Contents


Software Architecture: It Might Not Be What You Think It Is

Software architecture is often a misunderstood idea. Unlike traditional architecture, where the design is separated from construction, in software how something is built influences what is built, and vice versa. Software architecture is about decisions, not structure. Architecting is a skill, and architect should not be a role.


Why You Should Care about Software Architecture

Software development teams have resisted "big upfront designs" in favor of architectural designs emerging from self-organizing teams, which can lead to a mindset that software architecture is not really that important. Greater awareness of the implicit decisions they are making, and forcing these decisions to be made explicitly, can help development teams make better, more informed decisions.


A Minimum Viable Product Needs a Minimum Viable Architecture

Creating a Minimum Viable Architecture as part of an MVP helps teams to evaluate the technical viability and to provide a stable foundation for the product that can be adapted as the product evolves.


Minimum Viable Architecture in Practice: Creating a Home Insurance Chatbot

Even a simple application, like the one described in this article, needs a minimum viable product (MVP) and a minimum viable architecture (MVA). This is the second article in a series on MVA.


Architectural Frameworks, Patterns, and Tactics Are No Substitute for Making Your Own Decisions

Software frameworks greatly amplify a team’s productivity, but also make implicit decisions. The benefits and limitations must be understood because of the impact on the resulting system architecture.


Chipping Away at the Monolith: Applying MVPs and MVAs to Legacy Applications

Legacy applications actually benefit the most from concepts like a Minimum Viable Product (MVP) and its related Minimum Viable Architecture (MVA). Once you realize that every release is an experiment in value in which the release either improves the value that customers experience or doesn’t, you realize that every release, even one of a legacy application, can be thought of in terms of an MVP.


Location, Location, Location: MVA Considerations for Distributed Processing and Data

In this article, we explore patterns and tactics related to distributing computing workloads and related data, while discussing the issues that MVAs have to consider when distribution comes into play (and it almost always does.)

About the Authors

Rate this Article