Some agile evangelists assert that software architecture requires big design up front (BDUF), and that the artifacts produced by the software architects (that is, the architectural documentation) will never be used, thus you aren’t gonna need it (YAGNI). Software architecture in plain agile-aligned projects is seen as a prime agile anti-pattern (for BDUF). In fact, following the philosophy of such agile processes, architecture should emerge during sprints or directly from the code. Architecture should not be imposed by a team of architects (“architects in their ivory tower”) through documents that nobody will read during coding (and that are of little value in the hands of the customer), violating the whole team responsibility concept and some crucial Agile Manifesto (http://agilemanifesto.org/) items like “working software over comprehensive documents” and “responding to change over following a plan.” The connection between these myths and up-front design is largely discussed in the central part of the book.

At heart, what is software architecture? It “describes the solution space of a system and therefore traditionally is thought of as an early part of the design phase.” By such definition it is clear that as the solution space becomes complex, the architecture and the challenges to be solved to make customers satisfied also increase (and tend to explode). These days, software is often composed as a system of (legacy) systems, thus it is a very complex thing to manage that can hardly fit into traditional agile development processes (the last chapters of the book present a real-life scenario where a project was at very high risk to fail to deliver due to an evident miss at the early architectural phase). This fact requires a large body of knowledge, which may not be due to the development team.

The book is divided into four parts. Part 1 tackles the fundamentals of agile architecting, while Part 2 is on managing architectural aspects and metrics in agile projects. Part 3 explores agile architectures in specific domains (for example, cloud and security), and Part 4 contains industrial viewpoints.

This book stresses the limitations of agile processes and surveys existing techniques to overcome such problems. An example from the introduction: “test-driven development [TDD] can be very challenging when software really needs to exist in order to be able to define and formulate appropriate tests for nonfunctional requirements.” This fact is very well described in those sections of the book where examples of systems with strong security requirements that have to be implemented and designed in a very highly regulated scenario are presented. In these cases, without having a customer with functional requirements, and with few possibilities to request changes on nonfunctional requirements, many agile processes are shown to not perform as they should.

Of course, the book does not provide a solution for the problem above, or at least not one that fits all of the requirements. But it does provide a collection of perspectives corroborated by many applications of tailored architectures, adapted (and new) architectural metrics (for example, a tailored architecture tradeoff analysis method (ATAM)), and tailored agile processes. Project managers, product owners, and software architects will benefit from reading this book. They will be able to check what is the state of the art and how to apply specific techniques to their own projects given different dimensions, domains, and scopes. Agile team developers will also benefit from reading this book, as it will help them understand why and how software architecture is needed even in agile teams, and how to relate the team with the architects.

More reviews about this item: Amazon