Redefining OODA Loop: Detect-Decide-Respond

Increasing the level of automation in management is a common theme today, and many companies are attempting to do so in their own way. Today I came across an interesting presentation, “Turning Automated Decision Management into Real-time Operational Advantage” by Brian Safron, a Program Manager from Websphere Decision Management, IBM. (You have to register to view the presentation or the video.)

In his presentation, Brian talks about the approach taken by BPM solution providers. Their core product is the Business Process Management engine, which is essentially a simple rule-based decision-making workflow. To increase the level of automation--to make the BPM engine work in real-time--they have to somehow close the loop. They have to go from making decisions to performing actions.

“Brilliant minds think alike,” so their solution looks pretty obvious to us. To make it happen, they capture situational information and channel it into BPM software. Then they take the generated decisions and push them to actuators for execution. Here, we can immediately see the Observe and Act states from OODA Loop.

The part that was most interesting to me about their solution lies in the middle. The OODA Loop has a known shortfall related to an unclear boundary between the Orient and Decide states. To address this issue, the people from BPM mixed those two states into one and created a simpler, 3 state Detect-Decide-Respond (DDR) Loop.

Mapping DDR to the OODA Loop is simple:

• Detect = Observe
• Decide = Orient + Decide
• Respond = Act

Should we switch to the 3 state loop? Maybe. But I don’t think so.

A problem will arise when you approach multi-level management. Goals for business processes are implicit. The biggest limitation of the BPM system is that the processes it monitors are simple horizontal constructs. There is no vertical dimension related to the goals propagated throughout management levels. Therefore, because it can be applied to any situation, the 4-state OODA Loop gives us a better, cleaner model to look at information processing in multi-level management systems.

The principle Superposition & Composition, which utilizes the relation between Goal/Action states (Decide/Act states) and Observation/Interpretation states (Observe/Orient states), gives us a good reason to stick with the OODA Loop.

• Action is the most basic goal considered at any given management level. Action, propagated down to lower management levels, becomes a high-level Goal that has to be executed.
• Observation is the most basic Interpretation performed at any given management level. Interpretation, propagated up to higher management levels, becomes a low-level Observation that has to be analyzed.

Information flows between management levels, and decisions are made based on that information. Superposition & Composition gives us a repeatable pattern that can be applied at any management level, and, using the OODA Loop, connects all those levels together. Mixing the Decide (goal-setting) and Orient (interpretation of obtained data) states together creates a less capable 3 state loop. Therefore, it is not my choice...