Governance and Strange Loops

I remember a retrospective on the 90's asserting that the two least read books of the 80's were Bloom's "Closing of the American Mind" and Hofstadter's "Godel, Escher, and Bach" (Hawking's "Brief History of Time" is a 3rd candidate).

Although I disagree with some of the basic assumptions in each book, their books are interesting explorations of key issues. Bloom helped catalyze my interest in various understandings of basic questions in philosophy. And, Hofstadter remains the only person I've run across to explore the epistemological implications of recursion.

Since I've never finished GEB (unlike Bloom's book), I'm not familiar with all the nuances Hofstadter explores. However, the basic theme of the intertwining of what might be called "sensemaking of a context" and "the governance of that sensemaking" is a profound one.

It recognizes an aspect of sensemaking that we constantly juggle, but rarely think about. Both Boyd's OODA loop and Klein's Data-Frame model recognize that sensemaking is perhaps most distinguished by the pervasiveness of a GEB-style "strange loop" of Orientation (Boyd) or Questioning/Reframing (Klein).

Since engineers are grounded in the "sensemaking execution" thread that is basically analytical, the orientation challenge of "governance" is often ignored or assumed to be static...which may be why I've found few engineers who really latch on to frameworks that place equal (or more) emphasis on the "strange loop" that makes all sensemaking adaptable, agile, and real-world.

And, it may be yet another reason why engineers seem to have a difficult time grasping why sensemaking governance must be distributed/decentralized, limited in scope to a specific type of context, as informal as possible, and an 80/20 solution (i.e., not optimized).

My Virtual Crews

Will it become feasible to assemble a virtual crew from composable IT chunks (local and “in the cloud”) to automate significant aspects of a decision making context? The following comments explore this question.

The decision maker faces several simultaneous challenges. Among them are (a) managing goals, strategies, and tactics by constantly seeking alignment across all three levels, (b) understanding an evolving decision context, and (c) constantly making adjustments to goals, strategies and tactics to more effectively address the decision context. Sensemaking frameworks are intended to provide insight into the dynamics of these challenges.

The sensemaking frameworks I’m most familiar with seem to assume a “single CPU” decision maker. John Boyd’s OODA loop, Mica Endsley’s Situation Awareness model, Gary Klein’s Data-Frame model, and Karl Weick’s Enact-Select-Retain framework all highlight key aspects of sensemaking, but only Weick’s E-S-R seems to have been intended to apply to both individual and group sensemaking.

In addition to individual and group sensemaking, there seems to be a middle ground emerging where a single decision maker “outsource” contextually-oriented chunks to IT that is partially autonomous. These chunks are “smarter” than traditional IT, but are also more coupled to the decision maker’s sensemaking process than traditional IT.

Most discussions of IT in this context involve systems (or “intelligent” agents) which are largely decoupled from the decision maker. However, technologies/styles that are loosely coupled raise an interesting question about how decision makers interact with technology…will the increasing fragmentation of IT eventually result in a complex interleaving of decision maker and technology that allows an individual to achieve the kind of sensemaking agility currently only achievable by a group…specifically the kind of group often referred to as a crew?

The use of traditional IT by a decision maker looks more like a carpenter with a hammer than a human with a hand. IT is generally not much “smarter” than a hammer…it does what it’s told to do, and nothing more. Although a hand also does what it’s told (usually), it also provides complex feedback that allows the hand to take on several roles simultaneously.

The following is a proposal for four fundamental roles (and one meta-role) that IT can take on to allow a composed “IT Crew” to act more like a hand.

• Watcher – IT that observes a specific context (physical, logical, semantic, etc.) for events of interest, and issues reports about these events. This includes rules about how events are linked (causually or correlated) and about what events to report. Depending on how complex the watched context is, it might include meta-rules that allow the Watcher to “shift focus.” And, it probably involves an ability to do some predictive modeling of the context.
• Miner – IT that “digs” deeply into a specific context when a Watcher detects events of interest. The context must be constrained enough to allow mining, but ambiguous enough that further information is needed before a decision can be made.
• Actor – IT that initiates actions in a specific context to achieve goals
• Decider – IT that consists primarily of rules-based models that tie Watchers, Miners, and Actors together. As with the Watcher, this probably includes meta-rules that allow the Decider to exhibit a limited amount of adaptability. It almost certainly includes some predictive modeling of the decision context.
• Executive – forms goals, composes Watchers, Miners, Actors, and Deciders (WMAD) patterns to pursue goals, creates and deploys WMAD packages to achieve the desired effects, and monitors and modifies WMAD patterns and packages as needed to cope with environmental changes. Includes predictive modeling of how contexts affect progress toward a goal. While some of this involves IT, complete automation would seem to be feasible only for constrained and predictable contexts/goals.

This sort of taxonomy is similar to that seen in discussions of autonomous software agents (see, for example, IBM’s ABLE toolkit (). Although the IT Crew taxonomy resembles an AI (techno-centric) taxonomy, it differs in several ways. First, it uses a sociological construct (a crew) instead of a brain/mind construct. Second, it focuses on dynamic crew composition and deployment by the decision maker for a specific decision context. And, as noted above, autonomous agents usually do not involve the complex human-tool coupling that is seen between a person and their hand.

In an “IT Crew” framework, IT is built to fill one of the roles listed above. It is also built to be composable (loosely-coupled). Each composable IT chunk is explicitly designed for a specific range of contexts. A designer defines key aspects of a decision context, brings up a palette of IT crew members for each role listed above, and selects and assembles the selected crew members into a WMADE package to be tested and deployed. Note that a package may have multiple members of a given type (e.g., Miners), or it may have only one member type (e.g., Actor).

While much of the research on crews appears to have been focused on high-reliability contexts that require group agility and adaptability (e.g. operating room, aircraft carrier, airplane, etc), it seems to me that a similar pattern could also describe an individual decision maker using a wide range of local and remote Information Technologies to cope with a complex sensemaking challenge.

I suspect that variants of this sort of thing have been discussed in association with artificial intelligence, complex adaptive systems, agent technologies, etc. If someone knows of proposals or research where the organizational concepts associated with crews have been combined with recent types of composable IT, I’d be very interested in hearing about it.

Bits and pieces of today’s IT that seem to fit into this framework continue to appear in the Web domain: e-Bay sniping software, wiring frameworks like Yahoo Pipes and Ubiquity, etc. However, I can’t remember seeing a taxonomy (like that mentioned above) that would provide a crew-style plug-n-play design framework.

Bottom line: I’ve been a bit frustrated by the lack of architectural structure associated with most composable IT technologies/styles (e.g., SOA). Perhaps connecting these concepts to the organizational concept of crews would catalyze some useful design activity by (a) focusing on types of decision contexts, (b) parsing a context type into a small number of decoupled roles, and (c) providing enough structure to enable relatively simple, but robust, interoperability.