The External Control Paradigm

Rationale

The Paradigm states that every outbound requirements flow implies a control mechanism within the context process that will try to assure that the external agent, normally outside of our control, conforms to the requirements. For example:

In the logistics context, PROCESS BACKORDERS will check to verify that inventory is received from manufacturing and that backorders are reprocessed back into the main PROCESS ORDER flow.
In the accounts receivable context, AGE RECEIVABLES will check to see that customers are paying invoices so that open invoices don’t stay in INVOICE ORDERS permanently.

The External Control Paradigm helps reduce project risk by forcing us to acknowledge potential trouble spots in our application right up front.

Some will argue that this discussion is premature. It forces us to think about issues that will arise and be documented at lower levels of detail during N-level data flow diagramming. These people are correct in a purest sense. Whatever process is responsible for controlling the external agent's activity will be a subject for analysis later.

That's why this paradigm doesn't ask analysts to attempt to define the controlling process, but only to identify it. Granted, the line between identifying and defining is a fine one. We believe that the benefit to be gained from knowing about a trouble spot sooner than later outweighs these theoretical objections.