10. Final Words

In this chapter we reflect, once again, on the nature of design and why we need methods for design. This is, after all, the major point of this book! And we leave you with a few words about where to go with the information and skills that you have gleaned from reading this book.

We all need methods when we are performing complex tasks that have serious consequences if we get them wrong. Consider this: Jet pilots and surgeons are two of the most highly trained groups of professionals in the world, and yet they use checklists and standardized procedures for every important task that they perform. Why? Because the consequences of making a mistake are serious. You probably will not be designing the architectures for systems that have life-and-death consequences. Even so, the systems that you do design, particularly if they are large and complex, may very well have consequences for the health and well-being of your organization. If you are designing a throwaway prototype or a trivial system, perhaps an explicit architecture design step may be omitted. If you are designing the nth variant of a system that you have created over and over in the past, perhaps architecture design is little more than a cut-and-paste from your prior experiences.

But if the system you are charged with creating or evolving is nontrivial and if there is risk associated with its creation, then you owe it to yourself, you owe it to your organization, and you owe it to your profession to do the best job that you can in this most critical step in the software development life cycle. To achieve that goal, you need a method. Methods help to ensure uniformity, consistency, and completeness. Methods help you take the right steps and ask the right questions.

Of course, no method can substitute for proper training and education. No one would trust a novice pilot at the controls of a 787 or a first-year medical student wielding a scalpel in an operating theater, armed only with a method or a checklist. A method, however, is a key to producing high-quality results repeatedly. And this is, after all, what we all desire as software engineering professionals.

Fred Books, writing about the design process, said:

Any systematization of the design process is a great step forward compared to “Let’s just start coding, or building”. It provides clear steps for planning a design project. It furnishes clearly definable milestones for planning a schedule and for judging progress. It suggests project organization and staffing. It helps communication within the design team, giving everyone a single vocabulary for the activities. It wonderfully helps communication between the team and its manager, and between the manager and other stakeholders. It is readily teachable to novices. It tells novices facing their first design assignments where to begin.

Design is just too important to be left to chance. And there needs to be a better way of getting good at design than “shoot yourself in the foot repeatedly”. As the Nobel Prize–winning scientist Herbert Simon wrote in 1969, “Design . . . is the core of all professional training; it is the principal mark that distinguishes the professions from the sciences. Schools of engineering, as well as schools of architecture, business, education, law, and medicine, are all centrally concerned with the process of design”. Simon went on to say that lack of professional competence is caused by the relative neglect of design in universities’ curricula. This trend is, we are happy to note, gradually reversing, but nearly 50 years later it is still a cause for concern.

In this book we have provided you with a road-tested method—ADD 3.0—for doing architectural design. Methods are useful in that they provide guidance for the novice and reassurance for the expert. Like any good method, ADD 3.0 has a set of steps, and these steps have been updated somewhat from prior versions of ADD. But just as important, we have focused on the broader architecture life cycle and shown how some changes to the design process can help make your life as an architect better, and provide you with better outcomes. For example, we have expanded the set of inputs that you need to think about to include things like design purpose and architectural concerns. This broader view helps you create an architecture that not only meets your customer’s requirements, but also is aligned with the business needs of your team and your organization. In addition, we have shown that design can and should be guided by a “design concepts catalog”—a corpus of reusable architectural knowledge consisting of reference architectures, patterns, tactics, and externally developed components such as frameworks and technology families. By cataloging these concepts, design can be made more predictable and repeatable. Finally, we have argued that design should be documented, perhaps informally in sketches, and should be accompanied by a consistent practice of analyzing the decisions made.

If we are to conceive of ourselves as software engineers, we need to take the title of “engineer” seriously. No mechanical or electrical or structural engineer would commit significant resources to a design that was not based on sound principles and components, or that was not analyzed and documented. We think that software engineering in general, and software architecture specifically, should strive for similar goals. We are not “artistes”, for whom creativity is paramount; we are engineers, so predictability and repeatability should be our most cherished goal.

Our advice to you, as an individual, about how to proceed is simple: practice. Like any other complex skill worth having, your skill as an architect will not come immediately, but your confidence should increase steadily. “Fake it till you make it” is the best advice that we can give. Having a method that you can consult, and a ready supply of common design concepts, gives you a solid foundation on which to “fake it” and learn.

To help you practice your skills and to engage your colleagues, we have developed an architecture game. This game, which is called “Smart Decisions”, can be found at http://www.smartdecisionsgame.com. It simulates the architecture design process using ADD 3.0 and promotes learning about it in a fun, pressure-free way. The game is currently focused on the Big Data Analytics application domain, similar to the extended design example in Chapter 5, but it can be easily adapted to other application domains.

You might also think about next steps to be taken in your organization. You can be an agent for change. Even if your company does not “believe in” architecture, you can still practice many of the ideas embodied in this book and in ADD. Ensure that your requirements are clear by insisting on response goals for your requirements. Even when facing tight deadlines and schedule pressures, try to get agreement on the major architectural design concepts being employed. Do quick, informal design reviews with colleagues, huddled around a whiteboard, and ask yourself reflective questions. None of these “next steps” needs to be daunting or hugely time-consuming. And we believe—and our industrial experience has shown—that they will be self-reinforcing. Better designs will lead to better outcomes, which will lead you and your group and your organization to want to do more of the same.

Finally, you can contribute to your local software engineering community, and even to the worldwide community of software architects. You could, for example, play the architecture game in a local software engineering meetup and then share your experiences. You could contribute case studies about your successes and failures as an architect with real-world projects. We strongly believe that example is the best way to teach and while we have provided three case studies in this book, more is always better. Self-publishing is easy in today’s web.

Happy architecting!

Many of the ideas in this chapter, in this book, and in the field of software architecture in general can be traced back to Herbert Simon’s seminal book on the science of design: The Sciences of the Artificial, MIT Press, 1969.