Flow and OODA: How Shared Events Will Accelerate Economic Automation

John Boyd’s famous outline of a rapid, iterative, and responsive decision making framework, the OODA loop, is famous in technology circles. Boyd’s concept has been used to define product management strategies, Agile development processes, and complex systems operations practices. And, I will argue here, it is the reason that Flow architectures will own the dominant mindshare of architecture practices in the next five to ten years.

OODA and Software — A Refresher

The basic concept behind OODA is simple. Every action starts with an observation (“Observe”), which is then tempered with genetic, cultural, experiential and other contexts (“Orient”). Once that context is applied, a decision can be made (“Decide”) and an action taken (“Act”). But equally important to the process steps themselves is the iterative feedback nature of the relationships between those steps. Most importantly, orientation, decisions, and actions are all themselves “observed” and — along with unfolding circumstances and other outside information — can influence the next decision cycle (or even change the current cycle). Boyd’s original diagram of this process is at the top of this post.

The idea that agility can defeat strength is also something Boyd used OODA to illustrate. According to Wikipedia, the argument goes like this:

According to Boyd, decision-making occurs in a recurring cycle of observe–orient–decide–act. An entity (whether an individual or an organization) that can process this cycle quickly, observing and reacting to unfolding events more rapidly than an opponent can thereby “get inside” the opponent’s decision cycle and gain the advantage.

This is the core argument behind why rapid iteration on small batches of work will out perform large, infrequent deliverables in software development. By constantly delivering software, and observing the user outcomes, business success, and customer feedback of that software, agile teams are able to “get in the decision cycle” of slower moving competitors and customers alike, and gain an advantage in following cycles.

OODA and Business

The speed at which businesses can “observe, orient, decide, and act” is critical to long term success, as has been demonstrated often in the last several decades. IBM went from a potential technology monopoly to one of many in a sea of enterprise IT players thanks to disruptions from startups and online businesses. (The same is true for Microsoft, although in their case they have reestablished themselves as a major player in the new technology landscape.) High frequency trading (HFT) accounts for up to 40% of US equity trading, and profits largely by out observing, orienting, deciding, and acting other trading systems. (In fact the success of any given HFT system often depends on its ability to run through the OODA loop faster than all other HFT system.)

And this gets to the heart of why the demand for Flow is, in part, supported by the OODA loop concept. Just as HFT creates financial benefits simply by being able to react faster to trading opportunities than its rivals, there are a number of business elements where the combination of speed and intelligent decision making is of the essence. In hospitals, sensors trigger responses from support systems, such as medication dispensers, to save lives. In news media, stories are discovered and details are delivered to the consumer in order to inform and provide insight. In insurance, details about driving behavior can fine tune actuarial tables in order to optimize cost to the consumer without sacrificing profit.

New industries are popping up that will require even more real-time understanding of both physical and business events. Self-driving vehicles, for instance, may need to know about police actions in real-time to avoid certain streets. Cloud providers could use a heads up when major online retail campaigns show unexpected success. The space industry is increasingly concerned with changes to the expected trajectories of the junk we leave in space.

An OODA Loop For Flow

One way to take a look at why Flow will accelerate the pace of business decision making is to put events and a few other technical components that will drive Flow into the OODA loop model, as I have below:

In this model, observation is triggered by an event — which could come from a human, a sensor, other software, or any other event source that be represented digitally. Orientation is handled by bringing in other sources of context: human insight (through a UI of some type), historical data, queues of previous events, tenets (including laws and regulations), and so on. Decisions are then triggered by some sort of model: a machine learning model, a rules engine, or maybe a function. Decisions can also be made by humans, of course, but that would generally slow down the loop. Finally, action will be taken by publishing a new event or calling a function.

Most of the same feedback loops apply, as far as I can tell. Please let me know if you see any reason to think otherwise.

What would speed this loop up even further for business? I believe the answer is an ecosystem of event sources, published via standard mechanisms, with easily interpreted payloads, shared (for free or under some payment model) for all to consume. Every business finding the value in the events they generate, and building new business on events published by others. Literally, simplifying and accelerating the automation of the flow of money and information across the business landscape.

Accelerating Economic Automation

I’ve always said that the reason business software exists is to, in fact, automate our economy. One of the great things I think will happen as businesses take advantage of these events is that a network effect will happen; more businesses using events will create demand more events, which will attract more businesses to both create and consume events, which will drive more demand, and so on. Now, if you stop and think about it, the events that will be in demand are those that represent flow of information (including, but not limited to, financial transactions) across business. By subscribing to — and automating response to — events, businesses will be further automating our economy.

The Mechanism May Be Close

Since joining Pivotal, I’ve been spending quite a bit of time getting to know the work being done on Knative, the Kubernetes-based “serverless” workload platform. An event-based mechanism for executing functions in a container environment, Knative is defining some interfaces publishing and subscribing to events. These mechanisms hold great promise to form the foundation of Flow eventing. I would be interested to see if the community or a member of its ecosystem figures out a way to allow people to charge for certain events.

The answer may come from elsewhere, but I like the odds here.

Some sort of discoverable event format seems like it would also be necessary to me, but I think there are others who have more expertise in this area. I’ll be watching closely for how an event consumer can interpret arbitrary events published for general use by a diverse set of providers. When we have that combination: a pub-sub mechanism we can all use, and a way of understanding the events that we may receive, I think the floodgates will open as fast as the industry can adopt the necessary technologies.

Of course, there’s no way I have this entirely right. As always, I write to learn, so if you have insights to share, or questions you’d like to ask, do so in the comments below, or find me on Twitter where I am @jamesurquhart.