Introducing “Continuous Architecture In Practice”

It has been a few years since we published the first edition of “Continuous Architecture”, and we felt that some rework may be in order, as much has changed since our book was first published, especially in the technology domain. However, what started as a simple revision turned into a major rework, so the new book is very different from the original “Continuous Architecture” and not only because this book has the added benefit of Eoin Woods as an additional author.
While “Continuous Architecture” was more concerned with outlining and discussing concepts, ideas and tools, “Continuous Architecture in Practice” provides more hands-on advice. It focuses on giving guidance on how to leverage the continuous architecture approach and includes in-depth and up-to-date information on topics such as Security, Performance, Scalability, Resilience, Data and Emerging Technologies.
In our new book, we aim to revisit the role of architecture in the age of Agile, DevSecOps, Cloud, and Cloud Centric Platforms. We want to provide technologists with a practical guide on how to update classical software architecture practice, in order to meet the complex challenges of today’s applications. We also revisit some of the core topics of software architecture. This includes the role of the architect in the development team, meeting stakeholders’ quality attribute needs, and the importance of architecture in achieving key cross-cutting concerns including security, scalability, performance and resilience. For each of these areas, we provide an updated approach to making the architecture practice relevant, often building on conventional advice found in the previous generation of software architecture books, and explaining how to meet the challenges of these areas in a modern software development context.
We have grouped the new book’s chapters into four distinct parts. In the first part, we provide context, define terms and provide an overview of the Case Study (further described in the Appendix) that will be used throughout each chapter. We believe that using a consistent and well defined case study, based on a simplified trade finance (letter of credit) system, makes the book more interesting and practical. In the second part, our key ideas are laid out, providing the reader with an understanding of how to perform architecture work in today’s software development environment. In the third part, we explore a number of architecture topics that are central for developing modern applications: Data, Security, Scalability, Performance and Resilience. For each topic, we explain how software architecture, in particular the Continuous Architecture approach, can help to address the particular topic, while also working in an agile way that aims to continually deliver change to production. Finally, in the fourth part we look at what is ahead. We discuss the role of architecture in dealing with emerging technologies and conclude with the challenges of practicing architecture today in the “Agile and DevOps” era, as well as potential ways to meet those challenges.
Since you are reading this blog, we expect that you are familiar with the classical fundamentals of the field, perhaps from books like Software Architecture in Practice – SAiP (Bass, Len, Paul Clements, and Rick Kazman. Software architecture in practice. Addison-Wesley Professional, 2012) or Software Systems Architecture – SSA (Rozanski, Nick, and Eóin Woods. Software systems architecture: working with stakeholders using viewpoints and perspectives. Addison-Wesley, 2012) . However you may want to update your approach to meet the challenges of today’s fast moving software development environment. This new book may also be of interest to software engineers interested in learning about software architecture and design, and who will be attracted by our practical, delivery-oriented, focus.
To keep the scope of this book manageable, and focused on what has changed since our last book, we assume that you are familiar with the basics of mainstream technical topics such as information security, cloud computing, microservice-based architecture and common automation techniques such as automated testing and deployment pipelines. We expect that you are also familiar with the fundamental techniques of architectural design, how to create a visual model of your software, and associated techniques such as the Domain Driven Design (DDD) approach. For those who feel unsure about architectural design fundamentals we would suggest starting with a well-defined approach like the SEI’s Attribute Driven Design (Cervantes, Humberto and Rick Kazman. Designing Software Architectures: A Practical Approach. Addison-Wesley, 2016. The AAD approach is also outlined in Chapter 17 of SAiP) or a simpler approach such as the one outlined in Chapter 7 of SSA. Software modeling, although neglected for a few years, seems to be returning to mainstream practice. For those who missed it first time around, Chapter 12 of SSA provides a starting point and Simon Brown’s books (Brown, Simon. Software Architecture for Developers. Lean Pub. https://leanpub.com/b/software-architecture) are a more recent and very accessible introduction to it.
The other foundational architecture practice that we don’t discuss in this new book in how you assess a software architecture. This was covered in Chapter 6 of our previous book, Chapter 14 of SSA and Chapter 21 of SAiP. You can also find a lot of information about architectural evaluation methods like ATAM via an Internet search.
We also assume an existing knowledge of agile development and so do not provide in-depth discussions of software development life cycle processes such as Agile, Scrum, or SAFe, or discuss software deployment and operation approaches, such as DevSecOps in any depth. We deliberately do not include details on any specific technology domain (e.g. database, security, automation). We of course refer to these topics where relevant, but we assume our reader is generally familiar with them. We covered these topics, except for technology details, in “Continuous Architecture”.
The foundations of software architecture haven’t changed in the last four years. The overall goal of architecture remains to enable early and continual delivery of business value from the software being developed. Unfortunately, this goal isn’t always prioritized or even understood by many architecture practitioners.
The three of us call ourselves architects, because we believe there is still no better explanation of what we do every day at work. Throughout our careers covering software and hardware vendors, management consultancy firms and large financial institutions we have predominantly done work that can be labeled as software and enterprise architecture. Yet, when we say we are architects we feel a need to qualify it; as if an explanation is required to separate ourselves from the stereotype of an IT architect that adds no value. Readers may be familiar with an expression that has gone something like this: “I am an architect but I also ‘deliver/write code/engage with clients…’ (Fill in with your choice of an activity that is perceived as valuable).”
No matter what the perception, we are confident that architects who exhibit the notorious qualities of abstract mad scientists, technology tinkerers or presentation junkies are a minority of practitioners. A majority of architects work effectively as part of software delivery teams, most of the time probably not even calling themselves architects. In reality, all software has an architecture (whether it is well understood or not) and most software products have a small set of senior developers that create a workable architecture whether or not they document it. So perhaps it is better to consider architecture to be a skill, rather than a role.
We believe that the pendulum has permanently swung away from conventional software architecture practices and perhaps from conventional Enterprise Architecture as well. However, based on our collective experience, we believe that there is still a need for an architectural approach that can encompass Agile, Continuous Delivery, DevSecOps and Cloud Centric computing, providing a broad architectural perspective to unite and integrate these approaches to deliver against our business priorities. The main topic of this book is to explain such an approach, that we call Continuous Architecture, and show how to effectively utilize this approach in practice.
“Continuous Architecture In Practice: Software Architecture in the Age of Agility and DevOps” https://www.amazon.com/gp/product/0136523560?pf_rd_r=W6DHS5HCKQNZYKBMWF22&pf_rd_p=5ae2c7f8-e0c6-4f35-9071-dc3240e894a8
Reply