Software Architecture in Practice

by Len Bass, Paul Clements, Rick Kazman

The award-winning and highly influential Software Architecture in Practice, Third Edition, has been substantially revised to reflect the latest developments in the field. In a real-world setting, the book once again introduces the concepts and best practices of software architecture-how a software system is structured and how that system's elements are meant to interact. Distinct from the details of implementation, algorithm, and data representation, an architecture holds the key to achieving system quality, is a reusable asset that can be applied to subsequent systems, and is crucial to a software organization's business strategy. The authors have structured this edition around the concept of architecture influence cycles. Each cycle shows how architecture influences, and is influenced by, a particular context in which architecture plays a critical role. Contexts include technical environment, the life cycle of a project, an organization's business profile, and the architect's professional practices. The authors also have greatly expanded their treatment of quality attributes, which remain central to their architecture philosophy-with an entire chapter devoted to each attribute-and broadened their treatment of architectural patterns.

Genres: Programming, Software, Computer Science, Technology, Architecture, Technical, Nonfiction

Paperback

Reviews

[Ha Truong · Rating 3 out of 5]

The book introduces many aspects of an architecture and responsibilities of an architect. There are many things I haven't known before. But all the knowledge is at the level of fundamental and kinda overview, so you have to read it along with other specific books.

If I could rewrite the title, I would put it as "Introduction to Software Architecture" because everything looks like theory lessons in school, not practical. The writing is kinda daunting: lengthy, jargon and duplication.

[Mohannad Hassan · Rating 4 out of 5]

By the time I’m writing this, I have about eight years of experience in software engineering. For a big part of it, software architecture has been a major concern for me. One of the earliest questions I pondered was the difference between software architecture as it’s practiced by the community and described in the canon and just developing some proper OOP. This distinction, although it started to clear early on, remained a bit vague for me. One of the longest-standing questions was the relationship between agile development and software architecture.

This book, as far as I can tell, is an acknowledged reference on the subject. It covers a lot of the related topics of software architecture and investigates the mutual interactions between them. The book covers a lot of theory and delves deeply into methods. I regard this as my official introduction to the field.

For several reasons, I’ll not dive into analysis. Instead, I’ll list some key takeaways:

Software architecture is the first step in guaranteeing the quality attributes of a system. It’s not alone, and the details of implementation have a significant part to play here, but the software architecture lays out the big directions.

Software architecture, if properly done, can play a great part in easing and guaranteeing many functions on the lifecycle of a software project. Starting from requirements gathering and elicitation, to testing and deployment. It operates within many contexts, such as the organizational context and the business context.

The software architecture is an abstraction. A single architecture can lead to different implementations.

Although it’s hard to draw a defining line between them, quality attributes and functional attributes are two different things. A some-what basic definition is that the functional requirements define what needs to be done, and quality attributes define how this is done.

The elicitation of most quality attributes is the job of the software architect.

Agile and software architecture can co-exist. In fact, software architecture can contribute many capabilities that are crucial for agile development, mainly quick prototyping and predictability about the system.

Documentation is just like any other kind of writing, it has to have its intended audience and expected uses while it’s being written.

The architecture is a set of views, where each view is concerned with a certain aspect and describes a set of elements and the connections between them. This approach is important while developing an architecture and while documenting it.

While explaining the software product lines, it was explained that the best cost-effective way for code reuse is sharing the full artifacts of a software, starting from the requirements, to the architecture and implementation and down to the testing artifacts. It means that quality concerns, deployment environment, organizational structures, and more, have a lot of effects on any developed software. Using any such software means adopting all these factors. That’s why the compromise is made during requirements elicitation between the expected economic gain from reusing a product line (or reusing an architecture) with the possible feature or requirements to drop that can’t be supported by this architecture.

Speak the right language. We, engineers, when we transform into hardcore nerds, tend to forget that a lot of other factors affect the project, and some factors that play a bigger role than technical aestheticism into the success of a project. The architecture’s main strong arguments are its economic and life cycle gains. Speaking about these effects is what’s likely to change the organization’s directions towards adopting a software architecture.

[Dmitry Mikhaylov · Rating 5 out of 5]

This book explains the concepts and practices of software architecure discipline as it is defined by Software engineering institute. In particular the authors share their proven methods on:

How to elicit and prioritize architecturally significant requirements (ASRs), e.g. Utility tree method

How to address these requirements with architectural tactics and patterns

How to document architecture using various views, e.g. module view (source code model), run time view (components and connectors model), allocation view (computational resources and development teams allocation models)

How to evaluate architecture, e.g. using Architectural tradeoff analysis method (ATAM)

Even though I am not a programmer it was easy for me to read the book. I learned and confirmed for myself a lot about the practical aspect and the implications of architecure on software product life cycle.

In comparison to Just Enough Architecture by George Fairbanks, this book gives much more details.

[Denis Romanovsky · Rating 4 out of 5]

This book did not let me make a single simple opinion. It is great on the role and responsibilities of an architect, architecture qualities, architecture significant requirements, economy modeling. Then it is extremely boring on architecture process and governance, very shallow on agile and cloud. But in the end again it surprises with a “metropolis” model of architecture in holocratic-like organizations. Not a bad book after all.

[Balki Kodarapu · Rating 4 out of 5]

Picked up this book to get more familiar with large-scale architecture nuances. Good read overall. Wasn't as dense as had expected. Definitely targeted towards larger companies that need more formal processes. The authors were pragmatic and humble enough to give credibility to the emergence of agile and the inherent conflict that exists there. Another big wild-card that diminishes the value of such a book is that transition to cloud / microservices is a new normal now. Many of the elements highlighted in this book are not as relevant anymore!
(I double checked to make sure there isn't a newer edition than what I read - 3rd edition 2013)

[Danial Kalbasi · Rating 5 out of 5]

This book is both great and overwhelming. It covers all the aspects of Software Architect responsibilities and relevant techniques. And at the same time, it has much information which makes it not easy to read.

I think the level of information that this book provides is just enough. I really don't expect, a book with this agenda provides technology-specific advice or even goes into each subject deeply. That being said, this book is good to read if you already familiar/experienced with at least a few of the software architecture aspects, otherwise, it might feel too theoretical.

[Eoin Cos · Rating 5 out of 5]

Absolutely incredible book on the soft and hard skills of being an architect. It goes into the different roles a software architect will have and gives thoroughly comprehensive advice. This is a great book on anyone wondering what it is a software architect does and gives a great starting point for anyone interested.

[Matt Hartzell · Rating 5 out of 5]

It took far, far, FAR too long to read this. Don't let that speak to the quality of the text. I'm just too busy. :)

This is probably the best formal book you can read on architecture. If you are an architect, or want to be an architect, this had better be on your shelf.

[Gabriel Santos · Rating 5 out of 5]

O livro é bem abrangente e com excelente conteúdo referente a atributos qualitativos de arquitetura de software. Recomendo a leitura por todo profissional que deseja evoluir em aspectos arquiteturais.

[Jijoy · Rating 5 out of 5]

This book tells that architecture is not built on intuitions but well thought out process. It tries to bring order into the world of design chaos. A lot to digest but definitely a lighthouse for readers who wants to advance their career into architect roles.

[Franck Chauvel · Rating 2 out of 5]

Why should you read about Software architecture? Who even cares in these Agile and DevOps times. Should you, for whatever reason, still be interested, this book is the gate to approach software architecture from its theory side.

Here comes a book I had on my reading list for decades: Software Architecture in Practice, by L. Bass, P. Clements, and R. Kazman. I should have read this one when I was a PhD student, but I guess I was too lazy by then. Having enjoyed Just Enough Software Architecture: A Risk-Driven Approach and Clean Architecture, I took it upon myself and gave it a try, despite its price: EUR 24 on Amazon.

Ready for 650 pages about software architecture? Let’s go. Part I sets up key concepts: What it is, why it matters, and where it shows up. Part II dives into the many quality attributes (e.g., availability, modifiability, performances) that shape software architecture. Part III explains how software architecture fits into development processes for larger and— less convincingly— smaller teams. Part IV looks at the context and discusses product-lines and economic concerns before Part V opens up on two new technologies: Cloud and crowdsourcing.
I believe this is the reference textbook in the field. The three authors (Len Bass, Paul Clements and Rick Kazman) are all leading researchers in Software Architecture. I know some of their work though I never worked directly on this.

I see it as a tour of software architecture: It’s comprehensive and contains a load of references to research articles. The only thing I did not find is a chapter for developers, dealing with modules, dependencies, code layouts, etc. Something like day-to-day software architecture for the lay programmer. Conversely, I found it shallow on several topics, such as development processes and product-lines, to name a few.
It felt tiresome and not really relevant to me. It focuses on “heavy processes” and targets larger systems with multiple teams distributed over the globe. I liked best the discussion of quality attributes and what patterns/styles/tactics help enforce them (cf. Part II). This I can use.

I think it deserves its status of the reference textbook. I would recommend it m master students or to those building a course. I would not recommend it to programmers though, except if work on larger systems. To my fellow programmers, I recommend Clean Architecture or Just Enough Software Architecture: A Risk-Driven Approach. I also found by S. Brown, but I haven’t read it, yet.

[Michael · Rating 3 out of 5]

This book is great if you adhere to Carnegie Mellon's SEI approach and standards to Architecture. If anything, it serves a nice place to get started, but the book gets repetitive very quickly, and almost seemingly for the point of getting more pages, rather than providing valuable content. Microsoft has published works on software architecture which covers a larger and different area of emphasis than this book, but with far fewer words and less redundancy. I think this book basically could have been written much more efficiently.

[Dstuffle · Rating 4 out of 5]

This was a required textbook for a certification (software architecture) course I was taking. My one really big frustration was that one of the tests had questions that required the use of charts on this book's back cover, which the e-book format version did not have.

Was far heavier on the how to gather user requirements than how to determine which design pattern will fit the user's requirements than I was expecting.

Overall, It was a good book for the course.

[Daniel Ivanov · Rating 5 out of 5]

The book is very challenging to read, although it has plenty of useful information in it.
I think myself as a Junior Solutions Architect and that's why I decided to read it.
I must say that this book covered a lot of my Software Engineering courses in the University (this is a good thing as these things tend to be forgotten).

Overall I would suggest this book for every aspiring Developer that wants to go in the Architects career path.

[Michael · Rating 5 out of 5]

An incredible compilation of all the information you could ever need on software architecture. It contains a thorough list of patterns to achieve stability, performance, security, testability... but also covers more general topics such as integrating architecture into your Agile practices, methods for auditing an architecture, project management, skills...

I have found in this book many things I've learnt from experience that I wished I had read about sooner. Strongly recommend.

[yubo · Rating 5 out of 5]

I wrote 3rd version of this book. The book is organized and explained smoothly. What i loved most is it introduce the QA, RSA and the relationship, impact among architecture, business goal, pattern, tactics.

[Ruben Maldonado Tena · Rating 5 out of 5]

Extensive and useful

So far I liked the book. It really covers everything in a good level of detail. If you’re new to software/solution architecture you can use this book as a strong starting point.

[Jaiprakash · Rating 2 out of 5]

Great ideas. Book could have been better written to be engaging and more relevant to startups.

[Francisco Bertoni · Rating 3 out of 5]

Good book but outdated. I feel it has twice the size it should have. Same could have been said in half of it.

[Dima · Rating 4 out of 5]

Way to pass "Examination of Software Architecture: Principles and Practices"

[Alison · Rating 3 out of 5]

A good textbook to learn and review software architecture. Good examples available in each chapter.

[Kirill · Rating 4 out of 5]

Good compendium with (mostly) basics. Still worth reading.

[Sergey Machulskis · Rating 3 out of 5]

The book is very complex. The topic is not easy and the writing style of the authors makes it worse.

Some ideas are good but explanations are overly long. It could be much shorter, maybe a medium-sized blog post. I had a feeling that authors tried to cram into it everything they find useful about architecture. Links to aerospace standards (who need them in a book like this?), clumsy discussion of product lines (an entire chapter is useless) and many more. Authors use “Source of stimulus - Stimulus - Environment - Artifact - Response - Response measure” framework to discuss quality attributes like modifiability, performance and so on. It’s a pretty interesting attempt but it’s worthless, in my humble opinion.

Some chapters are very useful. One explains how to deal with architecture documentation. It even has advice on how to structure the architecture presentation. Another chapter explains why architecture and implementation part ways sometimes. Using this book you can find new ways to improve a particular quality attribute.

I loved a section with questions at the end of each chapter. Most of them are open-ended and very deep.

Quotes

[Kai Weber · Rating 3 out of 5]

Knowledge on software architecture is probably much less common than knowledge on software analysis and design. The three authors of this book have spent their life teaching software architecture and convincing people of the benefits and importance of architecture. So, there's a little bit of a missionary undertone at work here. But if you as a reader can cope with that, it's an interesting book, presenting a wide overview of aspects where software architecture integrates with other IT and business disciplines. At the core there's a discussion of quality attributes, like availability, interoperability, modifiability, performance, security, etc. Architectural measures to achieve those attributes are presented in a systematic fashion.
The book is introductory and general in nature, so it is a good start for students or programmers who want to learn to respect their architect.

[André · Rating 4 out of 5]

Techniken zur Erhebung und Realisierung qualitativer Anforderungen wie Verfügbarkeit, Sicherheit, Performanz usw. (Zur Skalierbarkeit sind die AKF-Bücher besser). Nennt Methoden zur Architekturanalyse und -dokumentation sowie interessante Fallstudien, z.B. das A-7E Avionics System oder ein System zur Flugverkehrskontrolle.

[Eric · Rating 5 out of 5]

Great overview of a complicated and rapidly evolving space. While the material is bone dry, I appreciated the inclusion of exercises within the text.

If you're designing complex, distributed systems and you want to avoid discovering fundamental architectural problems very late or post release, then this book will show you how to think about, document, and evaluate your architectures in enough detail to avoid repeating painful mistakes.

[Tuba · Rating 5 out of 5]

Great book to learn about most important qualities of software and the clearly explained tactics to improve each quality. A book that I occasionally open up to remind myself of the tactics to improve a given quality.

[William Cantin · Rating 4 out of 5]

Great book for a reference book. Full of great information about software architecture and good practices when defining and structuring software. Not so much of a book suitable for school tho, but we managed to make good use of it in class.

[Harshdeep · Rating 5 out of 5]

A great book for aspiring and/or old-hand architects. I wish I had read it a few years back to enhance my career earlier but it's certainly not too late.

Thanks to this book, I am at least equipped to handle architecture oriented discussions within and around organization.

[TK Keanini]

great text on the process of architecture.