OODA Loop: How to Understand the Use Cases for Big Data

J. C. Herz (Batchtags LLC)
Business & Industry, Ballroom E
Average rating: ****.
(4.00, 1 rating)

This talk uses Mike Loukides’ essay on the evolution of data products (from “overt” to “covert”) as a springboard. The dichotomy between power-user interfaces and “just tell me which app to buy” is rhetorically powerful and conceptually seductive. But it’s more useful to think about data services in the context of an OODA loop: Is the system augmenting the user’s ability to observe, orient, decide, or act.

The Google self-driving car is clearly acting on behalf of the user, based on a “where do I want to go” decision.

The notional ultimate app-recommender is deciding, based on a passively constructed orientation of what the user has relative to what’s out there, and some clever algorithms that produce what the user thinks is serendipity but is actually a high degree of affinity along different axes. Having done a substantial amount of targeting and profiling work in analytics, my sense is that there are usually implicit meta-axes of affinity which make it fairly easy to proposition someone with what seems like an out-of-the-blue option (whether a physical/digital good or a message/idea), but actually maps very closely to some affinities that cross categories. This happens in politics all the time – the art there is not only modeling the meta-axes (which evolve) but ultimately expressing those axes in a way that customers (e.g. innumerate politicians and media) can understand. E.g. “soccer moms” as political shorthand. The apparel business does this as well, by creating data-driven narratives around types of customers, and even giving human names to those profiles – because it’s all about selling the customer an item that she doesn’t currently own, but that speaks to her sense of personal style. As Jean Cocteau said, “Style is a simple way of saying complicated things.” When you get into a realm as complicated as politics or fashion, there’s a lot of meta-modeling you have to do in order to provide decision support (or influence) that an end-user is going to respond to and trust.

If you walk back the OODA loop to “Orient,” you get a lot more of what Loukides calls overt data products, because these these products are provisioned at a point in the knowledge chain where a decision has not only not been made, but it often isn’t clear what type of decision should be made. There is a strategic process that has to happen before that decision is reached, and therefore the most important thing to do is orient, so that you can decide, “Do I even need to buy a new camera?” vs. “What kind of camera should I buy?” Orientation is where you discover that the new models are coming out in four months, and that nothing on sale right now is going to substantially improve on your camera’s performance as much as the new models that are coming out in four months. Of course, if your strategic question was made explicit and the criteria mapped out, you could advance that to a more “covert” decision support capability. But framing a decision is a reflective process, often a non-standardized one (i.e. the decision about “do I even need to buy a camera” varies based on budget, interest in photography, technophilia etc. Orientation support isn’t just the provision of data – it actually helps that what-type-of-decision process along. So it’d be difficult or undesirable to dispense with entirely. That said, orientation support is mostly useful when you have to figure out what kind of decision to make, and most people don’t have to figure out what kind of decision to make, most of the time. Hence Loukides’ argument for more “covert” decision support capabilities, vs. tools that simply orient a user in what’s out there.

Walking the loop all the way back to “Observe,” this is where you actually do want to see all the data (although you may want to see it visualized vs. listed), because if you’re in a situation where you’re not even sure of what context in which to orient yourself, you need to observe anything that might be salient. Essentially, this is the domain of difficult, complicated problem-solving, deep investigation, and scientific inquiry in complex systems where not all relevant variables are known. This is an episode of House: something is horribly wrong with a patient, and not only is there no diagnosis but it’s not even clear what kind of diagnostic context is appropriate. Is it an auto-immune reaction? An environmental/toxicity issue? A congenital problem, or the fact that one medication is suppressing the symptoms of a hidden disease? Or a combination of any or all of these factors? In situations like this, all kinds of evidence has to be gathered and examined in detail, and you need to be able to generate hypotheses along the lines of “if I do X, then Y should happen. Oh, Z happened in a completely different physiological system? Why would that happen, and which of my hypotheses would Z disprove?” It’s the evidence you weren’t looking for, because it’s part of a different context, that solves the puzzle. Or it’s the reversal of figure ground, where the problem is what’s absent vs. what’s present. And all of that requires lots of (very expensive) observation.

House is basically a contextualization exercise, and contextualization problems are like crack for me, which is why House is my favorite TV show.

It’s a useful exercise for anyone who has a data-driven capability (or is building a capability) to game out how that capability would best serve in an observation vs. orientation vs. decision vs. action capacity, and where delivering on one part of the OODA loop reduces functionality in another part of the loop, i.e. lots of information is great for observation, not so great when you have to make a quick purchasing decision. A reflective process that enables new kinds of question-asking is great in an investigative context. Not so great in a pacemaker.

The OODA loop provides a powerful, broadly useful and transportable tool for product strategy and design.

Photo of J. C. Herz

J. C. Herz

Batchtags LLC

J.C. Herz (jnhq@yahoo.com) is a technologist with a background in biological systems and computer game design. Her specialty is massively multiplayer systems that leverage social network effects, whether on the web, mobile devices, or more exotic high-end or grubby low-end hardware. She is the founder of Batchtags LLC, which provides large data analytics and interactive visualization and decision support technologies and services to Fortune 500 companies and the federal government.

Sponsors

  • EMC
  • Microsoft
  • HPCC Systems™ from LexisNexis® Risk Solutions
  • MarkLogic
  • Shared Learning Collaborative
  • Cloudera
  • Digital Reasoning Systems
  • Pentaho
  • Rackspace Hosting
  • Teradata Aster
  • VMware
  • IBM
  • NetApp
  • Oracle
  • 1010data
  • 10gen
  • Acxiom
  • Amazon Web Services
  • Calpont
  • Cisco
  • Couchbase
  • Cray
  • Datameer
  • DataSift
  • DataStax
  • Esri
  • Facebook
  • Feedzai
  • Hadapt
  • Hortonworks
  • Impetus
  • Jaspersoft
  • Karmasphere
  • Lucid Imagination
  • MapR Technologies
  • Pervasive
  • Platform Computing
  • Revolution Analytics
  • Scaleout Software
  • Skytree, Inc.
  • Splunk
  • Tableau Software
  • Talend

For information on exhibition and sponsorship opportunities at the conference, contact Susan Stewart at sstewart@oreilly.com.

For information on trade opportunities with O'Reilly conferences contact Kathy Yu at mediapartners
@oreilly.com

For media-related inquiries, contact Maureen Jennings at maureen@oreilly.com

View a complete list of Strata contacts