How to build a distributed application: Introduction

If you set out to devise a theoretical framework for both the design of distributed applications and the process of building distributed applications, it seems unlikely that you would base it on a theory for armed conflict. Even though we may talk of "death march" projects, I've never experienced any real life or death struggles in the world of software development. And yet, I've come to use Col. John Boyd's OODA loop as my framework for how to build a distributed application (this will seem doubly ironic to those folks who know me well). Boyd had a laser-like focus on destroying the enemy in the most efficient manner possible by improving "our" OODA loop while disrupting "their" OODA loop. In software development, there is no "them" (even if we developers, in fits of extreme perversity, sometimes think that our customers or the system administrators are enemies). I use the OODA loop with a completely inward perspective. That is, I use it as a measure of how well my team or application is working.

A complete discussion of the OODA loop is well beyond the scope of this blog, but Boyd's fundamental thesis was that the quicker you iterate through the loop, the more effective you become. The most common misimpression is that his thesis is simply about speed. To the contrary, the real key to understanding the loop is that quicker iterations come primarily by combining an initially accurate orientation, which allows you to favor implicit guidance and control (the thick green arrows in the diagram above) over explicit decision-making, with the flexibility to accommodate changes in your orientation based on observation. Automated unit testing makes a good example from the world of software development. Many developers believe that writing unit test will inevitably slow them down. If you take a static view of the process, this seems obvious:

production code + unit tests > production code

But once you experience developing with effective unit testing, you realize that you can actually write better code faster. In OODA loop terms, you've made the creation of unit tests part of your Orientation ("requirements") phase. Each time you make changes to your code, you run the whole set of unit tests (this is implicit guidance and control) and you can observe whether the changes have adversely affected your conformance to spec (red light/green light). You gain the ability to tighten your coding loop which, in turn, leads to an overall decrease in the amount of time it takes to deliver the right code.

Another way to look at this diagram is to use it to model the architecture of a distributed application. In this view, the decision diamond represents a user decision, the "implicit guidance & control" boxes represent application logic, "outside information" represents external system inputs, and orientation represents application state. I suspect trying to visualize a distributed application this way will be very disorienting to most application architects and developers because it is initially very difficult to relate this view to our normal mental constructs for application design. I find it extremely useful, because by concentrating on designing applications that can speed up this OODA loop, I can discover application patterns and techniques that provide more effective business process automation. Using this model leads directly to distributed applications that are, in today's parlance, service oriented.

This post is designed to lay the groundwork for a series of posts that will translate this somewhat esoteric theoretical framework into practical advice. Before I write those posts, I'm interested in some specific feedback. Would you like me to explain more about the OODA loop and how it's commonly used outside of software development? Do the examples I used make any sense at all to anyone besides me? Does anybody think it's important to a theoretical framework for building distributed applications (whether or not you think mine's full of hot air)?