Automotive Deals HPCC Amazon Fashion Learn more Discover it Look Park Fire TV Stick Sun Care Handmade school supplies Shop-by-Room Amazon Cash Back Offer showtimemulti showtimemulti showtimemulti  Amazon Echo  Echo Dot  Amazon Tap  Echo Dot  Amazon Tap  Amazon Echo Introducing new colors All-New Kindle Oasis Water Sports

Your rating(Clear)Rate this item

There was a problem filtering reviews right now. Please try again later.

on February 6, 2012
I want to start by countering the negative review that is currently viewed as the most helpful here on Amazon. The reviewer did not like that the book did not seem to address most directly what would be needed by "project managers, team leads and most importantly developers."

I'm going to suggest that the reviewer started reading the book with a preconceived notion of what a software architect is, and what software architecture is about. It's no surprise. I'm reading several books on software architecture; all of them confront and try to address what might be a common definition, given that there are so many ambiguous definitions throughout the world.

The authors of this book make clear that ALL of the stakeholders in a software project must be appropriately addressed. That's a huge challenge! From business executives to analysts to even project managers, team leads, and developer, all of them must share a common understanding of the entire system and what will be changed. If the architect is primarily thinking about how to communicate with the development team, then that architect should have her title changed to development lead or chief engineer.

It was by reading this book for the main purpose of understanding what a software architect really is responsible for, that I can now easily distinguish the software architect role from other roles. The responsibility is to everybody that has a material interest in the project.

And how can one possibly communicate appropriately to people whose interest and technical acumen will range as wide as is possible throughout a business? That's exactly what this book explain precisely how to do, in a way that will make sense to the developers, the project managers, the executives, the project managers, the operations staff, the security team... everyone.

It does not (nor does it claim to) teach how to apply software development design patterns to construct a component, nor how to correlate a sequence diagram of a system with its structural diagram, or any of the other concerns that are probably best left to the development leads.

It does, however, consistently encourage and recommends strategies and tactics for keeping the level of abstraction at the right level for the stakeholders to which you are attempting to share that one software system solution. Architecture is not about the world of details (where developers live) -- it's about the world of models which, as a necessity, must remove details that are not necessary for all stakeholders. The model must be correct, but it must also be shared by all. That's the responsibility of the architect.

This book is definitely worth reading if you already believe that software architecture is your field, and feel overwhelmed at trying to grasp the scope of your responsibilities and the ever-changing nature of what an architect's value should be. It has a permanent place on my bookshelf, and I'll be referring to it quite often over my career.
0Comment| 32 people found this helpful. Was this review helpful to you?YesNoReport abuse
VINE VOICEon March 2, 2013
Some might look at my book collect and think I have hoarding issues. If I had to pick just one Software Architecture book to keep, this would be the one.

This is the second edition of one of the best books written on software systems architecture. If you are in the software development industry, you should read this book. If you are a Software Architect, you must read this book.

This book covers a vast amount of material but it ties it all together in a way that paints a complete picture of what software systems architecture is all about.

The book starts out covering architecture fundamentals. There is a chapter on Software Architecture Concepts, Viewpoints and Views, Architectural Perspectives, and The Role of the Software Architect.

It then presents a process for software architecture and explains all the elements involved with the process. This part of the book contains chapters on The Architecture Definition Process, Concerns, Principles and Decisions, Identifying and Engaging Stakeholders, Identifying and Using Scenarios, Using Styles and Patterns, Producing Architectural Models, and Evaluating the Architecture.

Next is a viewpoint catalog. The part of the book goes into the details of the different viewpoints the authors recommend considering as part of you architectural analysis. The viewpoints include Context, Information, Functional, Concurrency, Information, Development, Deployment, and Operational. Each viewpoint is a separate chapter. This section ends with a chapter that show how to achieve consistency across views.

After the viewpoint catalog the authors present a perspective catalog. Perspectives ensure that quality properties that cross several views are accounted for and analyzed. The perspective catalog includes Security, Performance and Scalability, Availability and Resilience, Evolution, Accessibility, Development Resource, Internationalization, Location, Regulation, and Usability.

The book ends with a chapter that ties everything together and a nice appendix that shows the relationship of the author's Viewpoints and Perspectives to other processes. They include Kruchten 4+1, RM-ODP, Siemens, SEI's Views and Beyond, Garland and Anthony, IAF, Zachman, and TOGAF.

I am lucky they came out with a second edition because my first edition is getting pretty beat up. It has scribbling from tons of different projects in it. The first edition has not left my side since I purchased it and this second edition won't leave my side either.

One of the things I like about this book is that the authors complete the picture. They don't say here is one example of a pitfall, concern, or tactic, they present a nice long list that really helps lead you through the process. Keeping this book handy helps me think of things I am sure to overlook.

Another thing I like about this book is that it is not a reinvention of the wheel. The authors do a great job of incorporating industry best practices that have withstood the test of time, as well as included all the newer elements of software architecture that have come about in recent years.

If you have the first edition, the second edition is worth getting. There is updated information scattered throughout the book as well as a new Context viewpoint. There has been 132 pages added.

I said this about the first version and it still holds true with the second edition... Even if you are not an architect it is a great book to buy so you understand what to expect out of one. I may buy a few extra copies to give out on projects so they understand why I am supposed to be there. Anyone reading this book should have a great and complete understanding of architecture and the value it adds to a project.
0Comment| 12 people found this helpful. Was this review helpful to you?YesNoReport abuse
on July 6, 2014
This is the book that should be taught in universities. It is far better than "Software Architecture in Practice" by Bass and "Documenting Software Architectures: Views and Beyond" by Clements, both of which seem like they go around in circles talking about intangibles. Not to mention they are littered with mistakes and inconsistencies (oh the horrible diagrams in the Celemnts!!!)
The current book presents a clear recipe for creating software architecture. I've used it to create an Architectural Description document at my work and was very happy with the result. Especially useful for practical applications, but also provides a superior (imo) model for looking at the system architecture as a whole.
The terminology is clearly defined, the concepts are easy to grasp. The only downside is that there is a lot to read --- but as much should be expected should you want to create a cohesive architecture. You have to cover a lot of ground. The nice thing is you can probably ignore the irrelevant parts/views if your practical application is on the smaller scale.

Overall, this is a must for any programmer who ever wanted to call him/herself a system architect (the term, which the authors, give a great definition of, and not elevate it above the "programmer" as many other books would have you believe).
0Comment| 4 people found this helpful. Was this review helpful to you?YesNoReport abuse
on April 23, 2012
I started out excited to read this book, and ended up somewhat disappointed. The two biggest challenges in software architecture are keeping that architecture "In Sync" (for some sufficiently confident "In Sync") with

(A) requirements, as they are uncovered or evolve, and
(B) implementation, as it gets built and evolves.

While this book does a fair job on (A), it unfortunately does an inadequate job on (B).

The separation of viewpoints from perspectives is useful (re-named, though not new), the potential pitfalls listed are useful, and including an "Operational" viewpoint is useful for a large class of systems. But the content and boundaries of both viewpoints and perspectives is quite ambiguous e.g. I was surprised to see the authors suggest that replication of application servers would change the Functional view. I would try quite hard to avoid this e.g. limit it to, at most, an annotation on connectors.

Lastly, for the number of "Definitions" included in this book, it was disappointing that those were not consolidated and formalized into a model (beyond the Viewpoints / Perspectives / Stakeholder level).
0Comment| 8 people found this helpful. Was this review helpful to you?YesNoReport abuse
on January 24, 2015
I found this book to be both very enlightening and very practical. It helped me to structure my view on some areas of software development and allowed to start using many valuable ideas immediately.
It also works great as a tabletop reference for a working architect. I found checklists at end of many chapters to serve as a safety net for me.
0Comment|Was this review helpful to you?YesNoReport abuse
on September 12, 2014
This book is truly well written, even though I brought it for another purpose.

However, If you're a software architect and think that reading this book will increase your understanding about how software systems are architected, you may be wrong. It provides for methods for software architecture, but no examples of how real world systems are architected. If you're looking for such things, you're better of with the architecture pattern book series.
0Comment|Was this review helpful to you?YesNoReport abuse
on January 29, 2013
This was an exceptional review on the entire practice of Architecture. Throughout this work, the authors provide very detailed (yet easy to read) guidance on every element of view-based architecture. This book provides an enterprise perspective of the practice of architecture and outlines all of the things to watch out for at various stages of system design.

I would recommend this book both as a comprehensive briefing as well as a reference book if you are an architect.
0Comment| One person found this helpful. Was this review helpful to you?YesNoReport abuse
on April 18, 2014
There's good content within, but I found myself skipping a majority of the pages. If it were 100 pages shorter I'd say it's a solid 4 star book.
0Comment| One person found this helpful. Was this review helpful to you?YesNoReport abuse
on April 20, 2014
This is a great book about software architecture. Very technology-independent and with great solutions to how creating, structuring and documenting architectures.
0Comment|Was this review helpful to you?YesNoReport abuse
on August 9, 2015
I think this book is a standard for the Software Architecture
0Comment|Was this review helpful to you?YesNoReport abuse