The Art of Software Architecture: Design Methods and Techniques

Rating:
Summary: One extra star for trying.
Review: 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.

Rating:
Summary: One extra star for trying.
Review: 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.

Rating:
Summary: Just how timely reliable and practical?
Review: Much of this introduction is lost in a profusion of nouns. How useful is this: "In commercial enterprise software development, it is not always possible to produce a single-system context model, but rather may require several exemplar contexts"? All this without introducing what challenges are faced during "commercial enterprise software development" as opposed to some other kind and prior to an attempt to define a "single-system" or a "context model" (btw doesn't a model give context?)

For someone interested in the promises of the title and "Design, Methods and Techniques" I found this book lacking in a crisp description of what design is, what methods exist to get one and how to apply oneself to the getting of an understanding of the constraints that often weigh-down design decisions.

I also found the discussion that tried to introduce the term "architecting" and the differences in meaning between programming, software engineering, software development and software architecture rather odd.

Rating:
Summary: Just how timely reliable and practical?
Review: Much of this introduction is lost in a profusion of nouns. How useful is this: "In commercial enterprise software development, it is not always possible to produce a single-system context model, but rather may require several exemplar contexts"? All this without introducing what challenges are faced during "commercial enterprise software development" as opposed to some other kind and prior to an attempt to define a "single-system" or a "context model" (btw doesn't a model give context?)

For someone interested in the promises of the title and "Design, Methods and Techniques" I found this book lacking in a crisp description of what design is, what methods exist to get one and how to apply oneself to the getting of an understanding of the constraints that often weigh-down design decisions.

I also found the discussion that tried to introduce the term "architecting" and the differences in meaning between programming, software engineering, software development and software architecture rather odd.

Rating:
Summary: Good technical coverage despite academic presentation
Review: 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/concerns

All 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 by the omission of working with legacy systems, product-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 by increasing the scale/scope of view of design principles to the application of architectural patterns and architectural styles. It discusses their activation models and quality attributes for such styles and briefly describes the common architectural styles and paradigms associated with dataflow systems, call-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 by advice on applying architectural descriptions to both new and existing systems and performing an architectural assessment. Some of the different architectural frameworks described are: Kruchten's 4+1 views model of architecture (which UML and RUP use), and the reference model for open and distributed processing. The discussion for each framework and its viewpoints includes the stakeholders and concerns addressed, and the construction of t he architectural view representing the viewpoints of the corresponding set of stakeholders.

Chapter 14 finishes the book by tackling the subject of software architecture quality: its importance, how to improve it, how to evaluate it, and how to assess modifiability and performance. It discusses the use of a systematic design process, understanding the right problem with a system-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.

Rating:
Summary: Excellent discussion of design techniques
Review: This book uses real world examples and practical advice coupled with academic rigor. It provided tremendously helpful insights into how I can improve the efforts of my team.