So far we have seen examples and case studies involving relatively simple software systems. This simplicity enabled us to use a fairly general step-by-step approach, namely, specify the requirements, model the behavior, find the classes, assign responsibilities, capture class interactions, and so on. In larger systems, such an approach may not lead to an efficient design, and it would be wise to rely on the experience of software designers who have worked on the problem and devised strategies to tackle the problem. This is somewhat akin to planning our strategy for a game of chess. A chess game has three stages—an opening, a middle game, and an endgame. At the opening, the field is undisturbed and the number of possibilities is immense; towards the end, there are fewer pieces and fewer options. If we are in an endgame situation, we can solve the problem using a fairly direct approach using first principles; to decide how to open is a much more complicated operation and requires knowledge of “standard openings.” These standard openings have been developed and have evolved along with the game, and provide a framework for the player. Likewise, when we have a complex problem, we need a framework or structure within which to operate. For the problem of creating software systems, such a structure is provided by choosing a software architecture (sometimes referred to as an architectural pattern).