book book
Software Architecture in Practice, 4th Edition
star rating fill star rating fill star rating fill star rating fill star rating fill
By Len Bass, Paul Clements, Rick Kazman
TIME TO COMPLETE: 12h 53m
TOPICS: Software Architecture
PUBLISHED BY: Addison-Wesley Professional
PUBLICATION DATE: July 2021
The Definitive, Practical, Proven Guide to Architecting Modern Software--Now Fully Updated
Now with nine new chapters, Software Architecture in Practice, Fourth Edition, thoroughly explains what software architecture is, why its important, and how to design, instantiate, analyze, evolve, and manage it in disciplined and effective ways.
Three renowned software architects cover the entire lifecycle, presenting practical guidance, expert methods, and tested models for use in any project, no matter how complex. You'll learn how to use architecture to address accelerating growth in requirements, system size, and abstraction, and to manage emergent quality attributes as systems are dynamically combined in new ways.
With insights for utilizing architecture to optimize key quality attributes--including performance, modifiability, security, availability, interoperability, testability, usability, deployability, and more--this guide explains how to manage and refine existing architectures, transform them to solve new problems, and build reusable architectures that become strategic business assets.
Discover how architecture influences (and is influenced by) technical environments, project lifecycles, business profiles, and your own practices
Leverage proven patterns, interfaces, and practices for optimizing quality through architecture
Architect for mobility, the cloud, machine learning, and quantum computing
Design for increasingly crucial attributes such as energy efficiency and safety
Scale systems by discovering architecturally significant influences, using DevOps and deployment pipelines, and managing architecture debt
Understand architecture's role in the organization, so you can deliver more value
Preface
When we set out to write the fourth edition of Software Architecture in Practice, our first question to ourselves was: Does architecture still matter? With the rise of cloud infrastructures, microservices, frameworks, and reference architectures for every conceivable domain and quality attribute, one might think that architectural knowledge is hardly needed anymore. All the architect of today needs to do is select from the rich array of tools and infrastructure alternatives out there, instantiate and configure them, and voila! An architecture.
We were (and are) pretty sure this is not true. Admittedly, we are somewhat biased. So we spoke to some of our colleaguesworking architects in the healthcare and automotive domains, in social media and aviation, in defense and finance and e-commercenone of whom can afford to let dogmatic bias rule them. What we heard confirmed our beliefthat architecture is just as relevant today as it was more than 20 years ago, when we wrote the first edition.
Lets examine a few of the reasons that we heard. First, the rate of new requirements has been accelerating for many years, and it continues to accelerate even now. Architects today are faced with a nonstop and ever-increasing stream of feature requests and bugs to fix, driven by customer and business needs and by competitive pressures. If architects arent paying attention to the modularity of their system (and, no, microservices are not a panacea here), that system will quickly become an anchorhard to understand, change, debug, and modify, and weighing down the business.
Second, while the level of abstraction in systems is increasingwe can and do regularly use many sophisticated services, blissfully unaware of how they are implementedthe complexity of the systems we are being asked to create is increasing at least as quickly. This is an arms race, and the architects arent winning! Architecture has always been about taming complexity, and that just isnt going to go away anytime soon.
Speaking of raising the level of abstraction, model-based systems engineering (MBSE) has emerged as a potent force in the engineering field over the last decade or so. MBSE is the formalized application of modeling to support (among other things) system design. The International Council on Systems Engineering (INCOSE) ranks MBSE as one of a select set of transformational enablers that underlie the entire discipline of systems engineering. A model is a graphical, mathematical, or physical representation of a concept or a construct that can be reasoned about. INCOSE is trying to move the engineering field from a document-based mentality to a model-based mentality, where structural models, behavioral models, performance models, and more are all used consistently to build systems better, faster, and cheaper. MBSE per se is beyond the scope of this book, but we cant help but notice that what is being modeled is architecture. And who builds the models? Architects.
Third, the meteoric growth (and unprecedented levels of employee turnover) that characterizes the world of information systems means that no one understands everything in any real-world system. Just being smart and working hard arent good enough.
Fourth, despite having tools that automate much of what we used to do ourselvesthink about all of the orchestration, deployment, and management functions baked into Kubernetes, for examplewe still need to understand the quality attribute properties of these systems that we depend upon, and we need to understand the emergent quality attribute properties when we combine systems together. Most quality attributesperformance, security, availability, safety, and so onare susceptible to weakest link problems, and those weakest links may only emerge and bite us when we compose systems. Without a guiding hand to ward off disaster, the composition is very likely to fail. That guiding hand belongs to an architect, regardless of their title.
Given these considerations, we felt safe and secure that there was indeed a need for this book.
But was there a need for a fourth edition? Again (and this should be abundantly obvious), we concluded an emphatic yes! Much has changed in the computing landscape since the last edition was published. Some quality attributes that were not previously considered have risen to importance in the daily lives of many architects. As software continues to pervade all aspects of our society, safety considerations have become paramount for many systems; think about all of the ways that software controls the cars that we now drive. Likewise, energy efficiency is a quality that few architects considered a decade ago, but now must pay attention to, from massive data centers with unquenchable needs for energy to the small (even tiny) battery-operated mobile and IoT devices that surround us. Also, given that we are, more than ever, building systems by leveraging preexisting components, the quality attribute of integrability is consuming ever-increasing amounts of our attention.
Finally, we are building different kinds of systems, and building them in different ways than a decade ago. Systems these days are often built on top of virtualized resources that reside in a cloud, and they need to provide and depend on explicit interfaces. Also, they are increasingly mobile, with all of the opportunities and challenges that mobility brings. So, in this edition we have added chapters on virtualization, interfaces, mobility, and the cloud.