Contextualizing the Web

The techno-centric approach to adding context to the Web is the Semantic Web. Two recent articles make me wonder if the sensemaking approach to adding context will be the Mobile/Social Web:

• Techcrunch has an interesting discussion of a presentation by Morgan Stanley analyst Mary Meeker highlighting the astonishing growth rates associated with the Mobile Web and the iPhone/iTouch. The entire presentation is available and worth reviewing.
• Dion Hinchcliffe has a much longer discussion of the shift from traditional Web sites to the Mobile/Social Web.

Neither really address what may be the truly revolutionary aspect of this shift: dramatically improved sensemaking driven by the contextual aspect of mobile/social. Instead of the user being almost totally responsible for framing and crafting IT/data to fit a use context, mobile/social IT can automatically sense key aspects of the use context and perform some of the framing/crafting work. The result: a potentially dramatic increase in the sophistication/depth of data/services that can be incorporated into a use context.

I suppose I should note that it's not either Semantic or Mobile/Social...it's both.

Limiting Innovation

Peter Merholz (Adaptive Path) talks about the "Highlander Principle" in this HBR blog post. He asserts that "there can only be one" true innovation in a new product if it is to succeed.

This is another area where cognitive & social limitations are often obvious only in retrospect. A use context of any complexity is usually tightly coupled to a larger ecosystem in ways that are difficult for both novices and experts to see. If an innovation is not almost "friction-free", the odds of it successfully carving out a niche (which usually means displacing existing capabilities and/or re-allocating/configuring existing resources) are low.

MIT's Sloan Management Review has a related discussion: small-fast use context experiments are a significant new tactic for innovation...at least for IT/data-intensive ecosystems.

DoD SOA Acquisition

The SOA craze has generated massive volumes of techno-talk, moderate volumes of biz-talk, and little discussion of how to move from acquiring systems to acquiring services.

Thanks to a colleague, I just ran across a good discussion of this issue: the AFEI's "Industry Recommendations for DoD Acquisition of Information Services and SOA Systems (7 July 2008)."

What I liked in the paper:

• Mission Logic and Mission Data receive equal attention
• The SOA stack shows dependencies up and down (i.e., SLAs & Reverse SLAs)
• The need for a different set of roles/rights/responsibilities is addressed. Table 1 seems to imply that the "role center of gravity" is shifting from technology to mission...which seems appropriate.
• Appendix A is a thoughtful proposal on how to incrementally employ SOA concepts

Things I wish had been discussed more:

• How organizational structures and processes need to change to cohere with the changes in roles.
• How agile is implemented at the mission level

Figure 4 ("Evolution of Mission Capabilities via SOA") is interesting...it traces the structure of the stack from the 1960's mainframe to today's virtualized service-based open system. It shows how standardization/interoperability has moved up the stack, resulting in finer-grained plug-n-play functions that allow solutions that are more agile/adaptable. But, it seems to be mostly techno-centric...there's no discussion of how this affects the way IT, data, decision making, decision makers, and groups are woven together to complete a task or mission.

Incremental Transformation?

This statement from Chapter 1 of "The Great Transformation" (Scott D. Anthony) caught my eye last week:

"Transformation comes from entering new markets and leaving old ones. Companies rarely transform themselves through cost cutting or improved operational effectiveness....in almost all cases, operational effectiveness is insufficient to stave off disruption and drive long-term competitive advantage."

In a footnote Anthony references a 2008 book by Steven Spear ("Chasing the Rabbit") that looks at some exceptions (Toyota, Southwest Airlines, Alcoa) that are characterized by a "learning culture."

I don't quite know what to think about the exceptions...is their synthesis of Exploitation and Exploration possible (at least in part), for example, because their business/capital/knowledge/etc. ecosystems are at the lower end of the complexity and/or rate-of-change spectrum? Or is this kind of incremental longevity possible in any ecosystem? Speculation is probably all that's possible...a large range of intertwined factors, many of which are impossible to analyze with any rigor, are likely responsible. About the only observation I feel comfortable making is that recipes are a sure path to failure.

Constraining Disruption

Disruptive innovation is often thought of as an unexpected and significant shift in how an offering addresses a job need. By that definition, it's unclear whether the MIT picture taking example John Sviokla discusses in "Getting Started in Disruptive Business Design" is really disruptive...it's not clear exactly what job/market is being served by a $150 high altititude picture-taking capability.

However, each of the four ideas he discusses shows how important constraints are in sparking disruptive innovation. One key constraint is the importance of focusing on a radical improvement in only *one* area (e.g., cost in the MIT example).

The MIT example also, perhaps inadvertently, illustrates two other aspects of disruptive innovation...one positive and one negative.

First, very expensive IT-intensive infrastructure is becoming cheap, pervasive, and interoperable. The MIT students leveraged the cell phone and GPS systems to quickly and inexpensively cobble together a basic capability.

And, as one of the students admits (in the Boston Globe article), most of their engineering classmates are unimpressed...what they did was just not complex enough. This may be the most significant barrier to disruptive innovation---engineers who prefer "cool engineering" over "cool capabilities."

Sensemaking - The Toyota Way

The Toyota Way and Toyota Production System are often thought of in terms of process-orientation and continuous problem solving. A manager in the West tends to translate this into a system that is more about analysis than sensemaking. This article in the Financial Post highlights how just-in-time distributed decision making in the system is a complex mix of analysis and sensemaking...which may explain why it's been more successful in the East.

Matching Tools to Needs

We're in love with "magic incantations." Over the past hundred years or so, a popular version of the scientific method has been slapped on top of almost every area of knowledge. In this version, someone creates a model, gathers data to "prove" the model, and then promotes the model as a magic incantation that will solve all (or at least most) of your problems.

In the management domain especially, the fads come thick and fast. Usually, they have a valid use, but they rarely come with specific instructions of when/where to use them (and, maybe more importantly, where/when *not* to use them).

This is equally true with IT...SOA, wikis, Enterprise 2.0, etc., etc., etc. I've discussed this previously, but didn't have any suggestions beyond noting that a new tool will probably involve some exploring to determine where it does (and doesn't) fit. So, it's nice to see Ken Oestreich propose a framework for evaluating whether an application belongs in a cloud.

CapGemini's Take on Exploration

CapGemini is promoting a framework that emphasizes how IT is enabling exploration.

I like the direction this points to, but it feels a bit on the fluffy side. However, it may provide some structure in a conversation with folks who are unfamiliar with recent developments in IT.

Streaming Sensemaking

John Jonas has about the only techno-centric/analytical take on Knowledge Management I've seen that seems to avoid the traps of (a) thick/clunky semantic-trending-toward-AI technology, and (b) large complex models. Not surprisingly, it focuses on (a) context, and (b) streaming processing of event data.

This presentation needs the voice track to fully communicate (especially his description of how these concepts informed the fraud detection systems he built for casinos), but it clearly shows the challenge posed by the hyperconnectivity-driven growth in data and decisions. Regardless of where this particular technology goes, Jonas has some of the key nouns right (context, sensemaking, etc.).

Complex Enterprise Architecture

Formal enterprise architecting frameworks tend to emerge in a systems engineering context. As a result, they have an analytical bent that is often ineffective at the enterprise scale, especially as IT continues to dis-integrate into finer-grained composable chunks (e.g., services).

This post by Dion Hinchcliffe reflects a growing realization that enterprise-level architecting must be capable of operating in a Complex (Cynefin) domain....where the key issues are better addressed by orchestrating boundaries and attractors than by sophisticated analysis. Key issues mentioned include COIs, adaptable policy/governance frameworks, and edge-driven capabilities.

Exactly where this is headed is unclear. Experienced architects understand that the enterprise is a mixture of the Complex, Complicated, and Simple, and that our tools for effectively engaging the Complex are immature and few. And, as the boundary between IT and decisions becomes more fractal, the fundamental impedance mismatch between the analog world of human decision making and the binary world of IT becomes increasingly problematic.

Exploration as a Core Competency

More on the shift toward IT-catalyzed experimentation from the Sloan Management Review. It's mostly an up-beat take, with hints of COIs, governance, security, and the challenge of integrating the enterprise's Executing Core with its Exploring Edge.