Good technical coverage despite academic presentation

The book is well organized and the writing style is clear, albeit very dry/academic. The author gives a well-researched overview of:* Software architecture concepts and architectural descriptions* Architectural lifecycles, views, and representations* Architectural quality, quality models and their attributes* Architectural styles, patterns, frameworks, and design principles* Software architecture and design methods, domains, models, and metamodels* Software design fundamentals, philosophy, general heuristics* Software architectural quality, complexity, modularity, and other aspects/concernsAll in all, The Art of Software Architecture looks to be a very informative book that covers the basics of software architecture, design, and quality that I wish all software developers knew. I was surprised line/family architectures and model-driven architecture (MDA). Software evolution and maintenance tends to be about 80% of the lifetime of a software project. Issues of dealing with legacy systems, reworking dysfunctional or decaying architectures, interfacing and integrating with other legacy systems, managing to create and sustain survivable architectures amidst the real world of ever-changing volatile requirements with aggressive deadlines and unreasonable expectations, all seem largely underemphasized for this reviewer's tastes. Important non-technical issues of leadership and communication, coordinating with project and program management, and playing the role of architecture "salesman" to management and stakeholders aren't addressed strongly enough. This is enough to prevent the book from serving as a complete and practical "how to" guide or "survival guide".The book comprises fourteen chapters, summarized below ... Chapter 1 provides an introduction to software architecture that discusses software development evolution and software engineering fundamentals along with the basic elements of software architecture. It touches on the subjects of reusability, general and special purpose programming languages, and modeling languages and notations. Basic software architectural elements presented include components, connectors, qualities, architectural descriptions, types of architecture, and the difference between architecture and design methodologies.Chapter 2 covers the product lifecycle including a RUP-like management view (inception, elaboration, and construction); a waterfall-like engineering view (requirements analysis, specification, design, implementation, testing, deployment and maintenance); an engineering design view of the specification of information, principles, layout, and production; and an architectural view of predesign, domain analysis, schematic design, development and build.Chapter 3 delves into the architecture design process of understanding the problem, identifying design elements and their relationships, defining system context, identifying modules, describing components and connectors, and evaluating and transforming the architecture.Chapter 4 introduces basics of software architectural design, including the Vitruvian triad of function, form, and fabrication, and their interaction with planning, interaction and architectural design, "cognitive friction" and application architecture. It then discusses overall design activities and tasks, the psychology and philosophy of design, and general methodology of analysis, abstraction, synthesis and general heuristics such as: persistent questions, negation, forward steps, backward steps, factorization, and systematic variation.Chapter 5 is devoted to complexity and modularity. It covers granularity and context, modules and their import/export, coupling, cohesion, design elements and rules, the task structure matrix, and modular operators of: splitting, substituting, augmenting, excluding, inversion, and porting.Chapter 6 is about models and knowledge representation and talks about the use and purpose of models, the roles that models play, problem and solution domain models, functional/behavioral models, information/data models, and nonfunctional models (e.g. performance models). It segues nicely into chapter 7, which is concerned with architectural representations and architecture description languages.Chapter 8 is all about quality models and quality attributes for process and product quality and quality requirements. It mentions issues of measuring quality attributes and system knowledge, barriers to achieving quality, and some common quality attribute misunderstandings. Quality attributes covered include functionality, interoperability, security, performance, resource efficiency, modifiability, availability, reliability, recoverability, usability and portability.Chapter 9 dives into principles of architectural design and applying systems thinking. It discusses design "operators" such as decomposition (including identifying functional components, composition/aggregation, and component communication), replication, compression, abstraction (including virtual machines and adaptability), resource sharing, and functional design strategies of self-monitoring, recovery, and instrumentation.Chapter 10 builds upon the previous chapter and-return systems, independent components, virtual machines, and repositories.Chapter 11 introduces metamodels and reference models. It describes the three-layer model of knowledge representation, the Seeheim and Arch/Slinky reference models, enterprise application reference models, and technology stacks and architectural layers. It goes on to describe a fundamental metamodel for describing software components and then gives an example of content management system reference models.Chapters 12 and 13 discuss architectural descriptions, and common architectural frameworks (sets of architectural views). They touch on how to identify stakeholders, select and specify viewpoints, view interdependence and traceability, recording view inconsistencies and capturing rationale for the viewpoints and the overall architecture. This is followed level view of the requirements and differentiating between requirements and design. The section on assessing software architectures talks about scenarios reifying nonfunctional requirements and the role of an architectural description, before moving on the subjects of evaluation, modifiability, and performance.

One extra star for trying.

Ever since "The Mythical Man-Month", it has been clear that lack of strong architecture will sink a software project. (It was probably true before TMMM, but that was before my time.) Architecture, implying an architect, is a requirement for any major piece of software.I can agree with Albin only to a point: architecture is not implementation, analysis, or software engineering. It's different even from "design", as the word is usually used. An architect really does a different job than other members of a software team (but the architect may design and implement, also).That said, I didn't quite make out how to go about -- training someone as a software architect,- developing a sound and appropriate architecture, - measuring its success in objective and repeatable ways, - making it a part of the project plan and documentation, or- preserving it across generations of maintenance.Most importantly, I did not see any discussion of adapting an existing architecture to new needs, or of extending an archtecture beyond its original bounds. Typical software spends 10% of it's life in design and implementation, and 90% in maintenance. The initial 10% is the fun part. I have real reservations about authors who choose not to discuss the other 90% of the problem.The book has value to the extent that it opens the topic for discussion. Too often, though, it confuses the skill of architecture with the tools of an architect - sort of like looking at a pencil drawing by Rembrandt and saying "Wow, if I get a pencil like his, I'll be able to draw like that too." I've been looking for books and articles about software architecture. This one has some value, but I'm still looking.