24. The White Line

The project uses the equivalent of the white line on a tennis court to achieve a non-arguable definition of scope.

When you watch a tennis match, you see the clean white lines marking the edge of the playing area. Any ball bouncing on or inside the line is in. All others are out. Most sports involving a ball have a white line and an official to judge whether the action is inside or outside the playing area. Apart from the occasional raised eyebrow at a line call that goes against them, the players respect the white line. The call is clear—the ball has crossed the white line, or it hasn’t.

Yet many projects have no white line—they attempt to distinguish between what is inside or outside the system with either a list of features or a statement of goals. Each is too vague to constitute a usable white line.

Any feature in a feature list has to be implemented somewhere, but not necessarily entirely within the system being scoped—it may pass off some or all of its responsibility to an allied system. So, the statement that a feature is included doesn’t really define scope, just as it is by no means clear from screen sketches which system is to produce the data shown on a screen.

Similarly, goals are achieved by a combination of actions performed inside the system and immediately outside. (It could be a goal of a new system to speed up receivables processing, but that goal would still depend on the responsiveness of the guy who first enters the receivable data into the system.) It’s always worth stating goals for a project, but such statements do not give a clear indication as to what happens inside and what is outside the new system boundary.

So, what can we do to achieve a precise definition of scope? Let us start by considering the nature of what we are about to study: A system or a business area is made up of processes that transform data. This is universal; it applies to any kind of system. These processes alter the state of the data by changing one set of attributes to another before handing it off to the next process. This assemblage of processes and their data is shown in Figure 24.1.

Figure 24.1. Processes both inside and outside the system transform data before passing it along to the next process. Each flow of data is uniquely named to represent its unique set of attributes. By cutting through these flows, the white line makes a clear separation between functionality contained by the system and functionality that is carried out by the outside world.

The data, as it is passed between processes, is unique. At no other point can there be another flow in the same state with the same attributes. Immediately outside the system is another process. The important point is that the interface between the system and the outside is simply another flow of data moving between processes. Like all other flows, it is unique.

By declaring—preferably modeling—each of the unique collections of data items that cross the boundary, you are saying, “The functionality to produce this data is contained on one side of the boundary, and the consuming functionality is on the other.” To put it another way, you are defining the scope of your project by declaring each interface between the system or business area to be modified and the world immediately outside. Once you have done that, there is no ambiguity about the scope: You have painted the white line through the interfaces.