HomeCognitive Enterprise

A cognitive enterprise should look like one

Like Tweet Pin it Share Share Email

OODA loops aren’t limited to competing strategies, and there’s more to an enterprise being cognitive than making use of OODA loops.

Sorry for starting in the middle. Regular readers will recall Colonel John Boyd’s OODA loop. For the rest, it stands for Observe, Orient, Decide, and Act, after which you review the results of your Action … you Observe, starting the cycle again.

OODA holds sway in time-bound competitions, where whichever side has the faster OODA loops wins, because the faster side’s actions invalidate the slower side’s observations, orientation, and decisions, forcing it to start over.

But OODA isn’t restricted to competitions, and in fact it’s a decent general-purpose model for cognition, which is why The Cognitive Enterprise — the book I co-authored with Scott Lee on this subject — uses OODA as a general-purpose way of making an enterprise more cognitive.

Time to take a step back, because OODA is a mechanism — a way for enterprises to become more cognitive. It isn’t the essence. At the heart of the concept is that the enterprise acts with intention — it’s akin to an organism that has a purpose and acts so as to achieve it.

Look at two enterprises, one industrial, the other cognitive, as a customer, from the outside in. An industrial enterprise looks like what it is — a collection of processes you as a customer have to figure out in order to do business. If the processes aren’t designed to deliver what you want to buy, you either live with the frustration or take your business elsewhere.

A cognitive enterprise, in contrast, interacts with each customer as if the interaction was a person-to-person conversation. The ability to act with intention in ways that adapt to each customer’s needs is what lets entrepreneurships survive while surrounded by much larger competitors. Cognitive enterprises figure out how to make entrepreneurship scale — not only when it comes to strategy, but throughout.

Take, for example, Amazon’s “Customers Who Bought This Item Also Bought …” and Netflix’s “Because you watched …” features. They’re excellent examples of enterprises being cognitive, right down at the level of one-on-one customer interactions. They follow the OODA model quite nicely, too — they observe what you shop for, interpret your behavior so as to infer your preferences (they orient), decide on what to offer you, and then show you the offer in a persuasive way.

Down at the level of individual customer interactions, the most successful companies right now all seem to be as cognitive as they can be.

Your challenge: Quite obviously, no business of any size can achieve cognition without a lot of information technology, some of which interacts with customers directly, the rest of which supports employees who interact with customers directly.

Is your IT department ready to provide it?

* * *

And on a completely different topic, there’s Delta.

In case you somehow missed the story, Delta had a complete systems meltdown last week, grounding its fleet and stranding thousands of travelers for days.

Delta initially blamed the problem on a power outage, leaving all of us who know anything at all about the subject scratching our heads.

You don’t get to run a data center at the Delta scale without having sophisticated power management. Decades ago, when I was directly responsible for some of this, we made sure we were getting power from two separate substations so that a single transformer failure wouldn’t affect us; this in addition to our UPS and backup generators.

And, we tested all of the above from time to time to make sure they worked — this in a relatively small, 2,500 employee corporation.

Among the many puzzling aspects of this story, two stand out.

The first is that Delta’s explanation of what happened seems to change every day. First it was a power outage. Then it was a transformer. Then it was a failed electrical component that took down the transformer that provided power to the data center. That’s the transformer, not one of the transformers, which would mean Delta’s power distribution system was built with a single point of failure.

Then, maybe, there was a fire in the data center, too.

Which brings us to the second source of puzzlement: I’ve read few complaints about Delta’s ever-changing account of these events, but lots of speculation as to what might have been the “real” problem, even though Delta’s ever-changing account of things is an observable fact while the speculation — which includes the usual Strongly Held Opinions about Why Delta Should Be Ashamed of Itself — is largely fact-free opining.

The view from here: Let’s find out why Delta should be ashamed of itself first.

Comments (12)

  • I think Delta was hacked/raided/sabotaged. They didn’t have a clue what happened, and don’t want to admit their vulnerability. It didn’t kill anyone, so it is likely not an ISIS invasion, but some Russian kid is laughing his head off.

  • Your lead in ‘verbal tic’ reminded me of one of my pet peeves – people who praise others by saying ‘s/he walks the walk and talks the talk’ It is so accepted that even makes it into paid advertising. It grates like ‘irregardless’. And make me feel old, since I knew (and used) the phrase when it was simply and meaningfully ‘s/he walks the talk’

    RE: Delta – made me think that maybe there is too much attention on cyber attacks and not enough on other potential risks.

    • There’s a ManagementSpeak in there … mind if I use it? And if so, email me with permission to give you credit, if you’re willing. Thanks!

  • Bob,

    Interesting that you picked Amazon and Netflix as examples, because to this customer, they are good examples of how to do cognitive enterprise right and also how to do it so it looks right, but isn’t.

    I enjoy Amazon’s “Customers who bought…” feature. Often when I know what I want to buy but not the exact brand model, etc., I’ll do a search, pick the first item that is similar to what I want, and then follow the “Customers who bought…” suggestions to find what I wanted to buy. I find it’s much faster (and more fun) than multiple loops of search, slog through pages of results, tweak the search, slog through pages of results…

    In contrast, Netflix’s “Because you watched…” feature leaves me scratching my head. Often what follows the “Because you watched…” phrase is a show that I started watching but then shut off after 15 minutes because it was so bad. You don’t need sophisticated statistical analysis to realize that when I abandon a show after 15 minutes and then never return to finish it, I’m probably not interested in seeing other shows similar to it.

  • Bob,
    My favorite–Delta is running a 35+-year-old data system that was “updated right before the ‘problem’ manifested itself”!!! They obviously couldn’t afford to upgrade their PDP-11s to PCs Limited 386s! STEM and science are, of course, too complicated for the “sheeple” of the world. YIKES!
    Have a grand week…
    Fr. Bob [analytical organic chemist by day]

  • I stand with Delta in proclaiming I have absolutely no idea what happened.

    Rumors are a software change was made right before the outage. What, the Change Manager was on vacation and the janitor signed off instead? And so much for the rollback plan. Unless that was the problem.

    And how about that pesky power thingy? Redundancy; it’s a wonderful concept. Look it up, you’ll be amazed.

    I’m sure the rank-and-file are taking the heat for this (not to mention the long hours for making it right), but if my scars from doing this for many years are any indication, the finger is pointing in the wrong direction. In my experience it generally goes something like this …..

    Peon (usually me): “Boss, it’s time to conduct our scheduled end-to-end system check”.

    Boss: “Are you nuts? We are right in the middle of (your choice: end of quarter, monthly closing, …..). We can’t possibly take an outage now”.

    Peon: “Sorry. I thought that’s why we did this — you know, in the event something failed we could recover without taking an outage”.

    Boss: “Go away”

    Peon: “Besides, a failover test is a reportable item to the BoD. You signed off on it. And remember, you have to witness it”.

    Boss: “Oh, right. OK, run your test. But don’t fail the power. Or the network. Or any of the servers or disk arrays. And don’t use any stuff from the hot site; we may need them if there is a failure”.

    Peon: “So, let me get this straight: you want me to run an end-to-end test without using any of the end-to-end components?”.

    Boss: “That’s right. I told you I couldn’t afford an outage, so get moving. If your test is successful we’ll extrapolate and call it good for the enterprise. I want to leave at 5”.

  • I have no clue what caused the outage, and won’t speculate on that. I do think, though, that the extent of the calamity, for lack of a better term, is the lack of a backup system that could be cut in within a matter of double-digit minutes. When your operation is 100% dependent on operating computer systems, you MUST have a hot backup running — preferably at another site!

  • Forward the above comments to Delta. They could benefit from studying them.

  • Interesting article, but I respectfully disagree with you when you said, “And on a completely different topic, there’s Delta.”

    My sense of things is that 50% of the population is a priori, meaning they already know what the answer is before they have seen the specific problem and 50% is a posteriori, meaning that they base what their answer should be, at in part, on observation.

    For example, to invent a computer driven car, the a priori people would need for their computer to know the exact road and terrain that car would driving down in great detail, which is good in case of sensor malfunction. The a posteriori people focus the efforts on reliable and highly discriminating sensing devices. Either can work, but they usually don’t understand each other.

    If these percentages are correct, it means that half the population is well suited for areas like accounting and poetry, where the need for rapid procedural modification is low. Unfortunately, it suggests to me that this group would have real problems with OODA, regardless of the benefits or circumstances. This could be a real problem in situations where the technology or customer demands change quickly, but where there is an a posteriori oriented person in charge or who has veto power.

    The Delta connection is that, if the person making final IT operations decisions has a deep a priori orientation, that person may have decided that systems backup was not as important now, as in the past, or some other narrative easier to understand than the truth.

    Actually, I would think that best practice in the airline industry, for a major airline, would be to have emergency response systems in place, even if they were hacked by a foreign state. Hard for me to imagine a scenario after the Target hack, where any competent CIO wouldn’t have procedures in place against a hack…except if there is someone with a posteriori orientation stepped in to add his or her 2 cents to the decision making.

    And, that’s my 2 cents.

    • I guess we’re destined to disagree. The first rule of design is “form follows function.”

      Not “form follows preference,” or “form follows biases.” Form follows function, which means an individual’s cognitive comfort zone has nothing to do with the best way to build and run Delta’s data center. The logic of the situation is what matters.

      The view from here (and I’m hardly an expert on the subject): For a company Delta’s size and dependence on information technology, I’d think this would mean having two geographically separated data centers with automated load overflow and transaction mirroring from one to the other, plus a monthly switch from one data center to the other as the primary. This way, if one data center fails the ops team “simply” follows the monthly switching procedure. Voila! Back in business.

      The last thing you’d want is dependence on an emergency response team. That means figuring things out on the fly instead of knowing what to do when there’s a failure.

      • My bad! I was being far too sloppy in my use of the term “emergency response team”.

        Actually, it’s a failure of imagination on my part. I’ve been thinking about this for the 5 days since you wrote your article…and I still can’t imagine a scenario where even an experienced AND somewhat incompetent CIO would have an information infrastructure not designed, really, for any conceivable emergency.

        Mirrored systems in at least 2 separate locations, as you suggested; physical and cloud backups done in real time; have the software run on linux, Novell (if they still are in the high security business), or Unix, at worst… And, I am nothing close to being a security or large computer systems infrastructure expert, yet the above would seem to be fairly obvious basic steps in Delta’s situation.

        Honestly, I hope all the facts do come out because, on the face of things, it just doesn’t make sense. Thanks for bringing this little issue back up in our consciousnesses.

Comments are closed.