Dr. Dobb's Journal June 2000
Depending on the context, the software-development process can range from skilled craftsmen specializing in virtuoso performances to complex systems with a myriad of software engineers armed with detailed specifications and project plans. The recent proliferation of project management and software development books and articles attest to the need to consider that the software development effort is indeed an engineering practice; a practice that places strong emphasis on both the planning and modeling of all components of the software development process and at the core has a holistic structure. One such structure is the emerging field of software architecture.
Many developers view architecture as an issue that is easily solved by selecting Microsoft's COM approach and building n-tier architectures. However, this is an oversimplification. The term "software architecture" defines a software system in terms of computational components and interactions among those components. Organizationally, we are looking at the individual pieces of the system as well as all internal and external interfaces. The content of these components and interfaces is going to be determined by the application environment in which they are invoked. Because the environmental context is so important and often is one of the most important factors in the selection of the architecture, it is important to understand different architectural styles and their successful application. Furthermore, in the event that we cannot implement a cookie-cutter style to our application environment, we may need to be able to vary existing styles or create one from scratch. Thus, it is important to understand the theory or science of software architecture as well as the practical or art of implementing that architecture in the real world.
Let's say that you are a budding software architect ready to open your own consulting firm. Your father or mother is in the construction industry and has a similar job developing designs and project plans for residential homes. Unless you are going to specialize in one industry, it would be essential that you understand both the selection and creation of an appropriate architecture. This understanding can evolve in two ways: 1. The traditional academic route; or 2. on-the-job training. Since I'm a big proponent of the latter, that will serve as the focal point of my perspective here.
Software Architecture: Perspectives on an Emerging Discipline, by Mary Shaw and David Garlan, takes the academic route. The authors state that recently software architecture has emerged as an important field of study. By moving from the status of a talented amateur to that of the professional engineering discipline, several key issues surface and need our immediate attention. These are: module interface languages, domain-specific architectures, software reuse, codification of organizational patterns for software, architectural description languages, formal underpinnings for architectural design, and architectural design patterns. Shaw and Garlan organize the book around these issues and address some of the limitations of field.
To address the problem of architectural selection, the authors develop a set of common architectural styles such as Pipes and filters, Objects, Implicit invocation, Repositories, Interpreters, and Process control. Each one of these styles is the nomenclature for the discipline and provides useful categories of classifications. The authors do not spend a considerable amount of time on any one style due to their attempt to discuss a wide variety of topics, as previously mentioned. Because of the book's academic nature, the authors spend a good deal of effort discussing how to deliver the education of software architects and how they envision the construction of academic courses for the subject matter.
Software Architecture is written in the familiar academic style that focuses on analyzing, classifying, and using terminology acceptable to the academic community. They also spend considerable time on notation for communicating architectures. Developers without a software engineering background or substantial academic training will find most of the book difficult to implement. I believe this would especially be true for those who fit into the role of skilled craftsmen mentioned in the introductory section.
Software Architecture in Practice, by Len Bass, Paul Clements, and Rick Kazman, targets practicing software managers, technical managers, and students in computer science. The authors begin their exposition by asking the fundamental question, "Why is software architecture important?" They then deliver three reasons: communication among stakeholders, early design decisions, and the transferable abstraction of a system. Using this as a motivation, the authors suggest that the software architecture of a program or computing system is a structure of structures of the system, which comprises software components, the externally visible properties of these components, and the relationship among them. Discussion of these three items is made possible by organizing the book into the following sections: Envisioning Architecture, Creating and Analyzing an Architecture, Moving from Architecture to Systems, and Reusing Architectures. In each of these sections is a case study that focuses on the application of these developed principles into practice. At the end of each section you find a summary, suggestions for further reading, and discussion questions.
These four sections form a solid foundation for the developing of software architectures in a variety of applications. The organization is sound and provides an intuitive feeling for the process of architecture assessment and implementation. The authors do a fine job of discussing reusing architectural assets within an organization. Their section on component-based systems along with the case study, to be discussed later, was very helpful.
In Applied Software Architecture, Christine Hofmeister, Robert Nord, and Dilip Soni state that their book evolved from the study of software architecture in the industry, specifically at Siemens. The book is organized into four sections: Software Architecture, Designing, Describing and Using Software Architecture, Software Architecture Best Practice, and Software Architecture in your Future.
The book is well organized and very graphical with numerous tables and diagrams. The authors take a slightly different approach than the other two books by interviewing various architects and attempt to understand the problems, learn about the architecture used and why, and find out about the strategies for implementation and maintenance of that architecture during the product life cycle. Based on these interviews, the authors developed an approach with four distinct viewpoints: conceptual, module, execution, and code. This differs from the approach of architectural style selection and focuses on asking questions for each one of these view contexts. The answers then create the style. I like this approach; however, you must remember that the answer is only important when it is associated with the right question.
While you may know all the particulars of the software-development process, countless architectural styles and an untold number of technical details, if you cannot implement this knowledge, it has no value outside the academic community. The job or goal of the software architect is to understand how to apply his/her scientific knowledge to real-world problems. Each of the books in this review understands the practical nature but none of these books address in sufficient detail one of the most important factors -- the culture in which the architecture is being imposed. Keeping this point in the back of our head, let's look at what each of these books has to offer in the way of practical guidance.
In Software Architecture: Perspectives on an Emerging Discipline, the authors utilize seven examples enclosed in four case studies presented in Chapter Three and illustrate the architectural principles discussed in the two previous chapters. These case studies include demonstrating how different architectural solutions for the same problem yield different benefits; how you can develop a domain-specific architectural style for a family of industrial products; how to compare and contrast several styles for implementing mobile robotics systems; and how to apply process-control style to system design. The authors also include examples of heterogeneous architectures.
I especially like the approach of their mobile robotics system case study written by Marco Schumacher, who examined four different architectural styles, then compared them based on how they fulfilled the set of requirements. Using the parameters of task coordination, dealing with uncertainty, fault tolerance, safety, performance, and flexibility, he provides a clear and concise way of communicating this decision process to others.
In Software Architecture in Practice, the case studies and examples are included throughout the book. Some of these include the World Wide Web, CORBA, air-traffic control, flight simulation, product-line development, and a meteorological anchor desk system. I especially like the command-and-control system for Navy, Army, and Air Force applications. The case study is based on a shipboard command-and-control system with sensors and weapons that were created in a component-based architecture. The other case studies were also well done and the authors expended a great deal of effort to brief you on all the necessary information needed to make architectural decisions. Compared to others in this review, the authors lead the pack with respect to this observation.
After discussing the theoretical issues in the first two sections, the authors of Applied Software Architecture develop several case studies that include: IS2000-imaging system, instrumentation and control system for nuclear power plant, embedded patient monitoring system, centralized patient monitoring system, and a telecommunication system. One of the smooth features of this book is the organization for designing and describing of software architecture. They use a multiple perspective approach with four views: conceptual architectural view, module view, execution view, and code view. Each of these views has a global analysis, central design task, and final design task and resource allocation.
These four real-life case studies are presented as examples in terms of vision, which then use the processes of global analysis to analyze product, technological, and organizational factors. The next steps are to invoke each of the views as listed earlier. Each case study then concludes with a summary of the software architecture concepts and experience.
The example I like most was that of the healthy vision case study, which included contributions by Tony Lanza. While the entire approach was well done and graphical, I particularly like the Healthy-vision/Lesson-learned section. Flexibility will always have a considerable impact on your architectural design, implementation, operation, and maintenance.
Going back to our example of the budding software architect and education, it is important to have each one of these books in your library. This investment is warranted because each book has a unique perspective, which no one book can provide. In Software Architecture: Perspectives of an Emerging Discipline, the comparison of multiple architectural styles for a given application provided useful insight into how to select an appropriate style. While academic in nature, it provides the necessary theoretical underpinnings necessary to be creative as well as communicate your analysis to other engineers. In Software Architecture in Practice, the focus on the architectural business cycle as an engineering process should be very helpful. The inclusion of component-based architectures and their successful attempt to provide considerable breadth of the subject matter is applauded. In Applied Software Architecture, the successful integration of environmental factors into the creation, selection, and implementation of architectural styles proved useful. I go back to the previous comment of the culture driving man's architectural decisions. Furthermore, the simplicity of their organization helped me focus on the content of the material without having to reorganize their thoughts as I proceeded through the book. The art and science of software architecture requires both sides of the brain and all current and future software architects must realize the importance of understanding both theoretical and practical solutions to their real-world problems.
DDJ