Overview

In any business application, there is (or at least, there should be) a distinct understanding of what business problem the application is meant to solve. For example, the side effect of a customer billing application is the generation of bills to be sent to customers. Other side effects may include registering accounting details and the calculation of a monthly usage report, but overall the application is meant to create bills.

Unfortunately in practice, as applications are modified, merged, and expanded, the high-level understanding of the business problem gives way to dependence on implementation details and decisions that impose artificial constraints on the system. By virtue of the structured algorithm design in which most implementers are trained, we impose a control structure on the way that information flows through the processing. But this control structure does not always reflect the true dependencies inherent within the original application, because, for instance, we may have decided to break up a single subprocess into two stages that could truly have been executed in parallel, but an implementation decision may force one stage to precede another.

And as the system evolves, technical employee turnover leads to a loss of knowledge about how that application really models the original business problem. Interim decisions have imposed a strict flow of processing control, which may no longer reflect the true data dependence of the application. So when they attempt to dissect the way information is being used within the system, most analysts might throw up their...