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.
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.
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.
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.