Read an Excerpt

Chapter 2: Antipatterns Reference Model

Primal Forces

• Which details to expose and which details to abstract.

• Which features to include and which features to exclude.

• Which aspects to make flexible and extensible.

• Which aspects to constrain and guarantee.

Software design choices are often complex, with numerous issues (or forces) to consider, such as security, cost, adaptability, reliability, and so on. In order to make good choices, it's very important to clarify the context of the decision. Choices are clarified in several ways, such as:

• Separation of concerns.

• Establishing priorities.

To separate concerns, we need to limit the scope of each choice. Partitions in a software architecture are used to allocate and delineate the boundaries of concerns. Each partition is responsible for resolving a limited set of issues, which simplify decision making. The architecture represents the union of the partitions and provides coverage of all the relevant issues. This separation of concerns is a fundamental role of architecture.

Decisions are also clarified by an understanding of priorities. If we know what is important and what is not, it's much easier to choose what to include and what to exclude in a design. Decisions are difficult because they include some items and exclude many others, and we must be able to justify such choices. This is another fundamental role of architecture, to explain significant decisions and design choices.

Risk is a force that is always present in software decisions. Software projects are amazingly prone to failure. As noted, approximately one-third of all software projects are canceled, and approximately only one-sixth of software projects are considered successful. The remaining projects are typically over-budget and over-schedule by factors of two or more. The unsuccessful projects are also incapable of delivering the desired features. Once the systems are delivered, there is high risk involved in changing the system. Correction or extensions are likely to cause new software problems.

Considering these statistics, five out of six software projects are destined to fail. These figures are essentially unchanged by new technologies and approaches such as client/server and object orientation. As software professionals, the outlook is grim, unless something significant changes. We believe that significant changes are necessary in the way that software systems are architected and the way that risks are managed.

We see risk as a generalized force, which is an underlying factor in most other forces. To various degrees, management of risk is a universal force that motivates the patterns and solutions described here.

What Is a Primal Force?

Forces are concerns or issues that exist within a decision-making context. In a design solution, forces that are successfully addressed (or resolved) lead to benefits, and forces that are unresolved lead to consequences. For any given software problem, there are a number of forces that can influence a given solution. The application of a design pattern leads to a solution that resolves the forces in a particular way. In the solution, some forces are resolved more completely than others. The choice of a design solution establishes a priority on the forces, to the extent that the highestpriority forces are resolved the most completely.

Some forces are domain-specific. Domain-specific forces (called vertical forces) are unique to a particular situation due to the domain or problem addressed. Since vertical forces are unique (or local) to one software situation, resolution of vertical forces usually results in unique solutions for each software problem.

Another class of forces, horizontal forces, are applicable across multiple domains or problems. Horizontal forces are those that influence design choices across several software modules or components. With horizontal forces, design choices made elsewhere may have a direct or indirect impact on design choices made locally. For example, if the horizontal force is "design consistency," it is necessary to coordinate software designs across multiple software modules to ensure such consistency.

A certain class of horizontal forces are pervasive in software architecture and development. These are the primal forces, and are present in nearly all design situations, and should be considered part of the contextual forces driving most solutions. One role of the primal forces is to keep architecture and development on track. For example, a software decision that seems to be local can have a cumulative impact when there are other software groups making conflicting choices elsewhere in the same enterprise. The primal forces represent the pervasive forces, which arise from the interrelatedness of software decisions.

The primal forces are an important part of the guidelines presented in this pattern language. Each primal force is horizontally applicable across many domains of software architecture and development. The primal forces represent the common-sense basic considerations, which are necessary for successful software architecture and development. Primal forces comprise a fundamental value system for software architects and developers that are independent of particular situational forces.

The primal forces include:

• Management of functionality: meeting the requirements.

• Management of performance: meeting required speed of operation.

• Management of complexity: defining abstractions.

• Management of change: controlling evolution of software.

• Management of IT resources: controlling use and implementation of people and IT artifacts.

• Management of technology transfer: controlling technology change.

The primal forces have different relative importance at different scales. Functionality and performance are critical forces at applicationlevel and finer grains, whereas management of IT resources and technology transfer are enterprise and global in scope. Before we can discuss these fully, we need to define the scales through the scalability model.

Table 2.1 identifies the degrees of impact of forces at the different levels of scale:

Critical. The impact is fundamental, as it affects all of the software.

Important. The impact must be seriously considered, as it affects a significant amount of the software.

Marginal. The impact can often be ignored, as it affects a minimal portion of the software.

Unimportant. The impact should not be considered....