Design Thinking

I ran across recent article by Tim Brown of IDEO on design thinking (June 2008 HBR). A statement in the introductory paragraph caught my eye:

• "...Edison understood that the [light] bulb was little more than a parlor trick without a system of electric power generation and transmission to make it truly useful."

Brown highlights the need to fit technological innovation into a larger ecosystem. Big-picture engineers probably are better at this than puzzled-oriented engineers. Brown describes the personality profile of design thinker:

• Empathy
• Integrative Thinking
• Optimism
• Experimentation
• Collaboration

He also describes a design thinking dynamic with 3 nodes: Inspiration, Ideation, and Implementation. Inspiration and Ideation would seem to be more divergent (though Ideation is a mixture of divergent and convergent), and Implementation more convergent.

Brown's article is a pointed reminder that truly disruptive innovation often spans multiple levels (system, enterprise, ecosystem), domains (technology, people, process), and perspectives (strategy, operations, consumption, complements, etc.).

Divergent-Convergent Zones

I've come to think of techies as falling into one of two camps: puzzle (likes well-defined puzzles) or big picture (likes understanding how well-defined puzzles fit into a larger context). Although I only have first hand experience with engineers, I suspect other technically-oriented disciplines (e.g., accounting, medicine) have a similar division.

I mention this in the context of a model I stumbled across recently. It's in Viv McWaters' blog and describes how groups work through a specific issue. The phases shown are (a) a new topic emerges, (b) the topic is potentially closed via "business as usual", (c) the topic diverges into a Complex exploratory space, (d) a "groan zone" is entered where the group struggles to create a frame that will move the issue into a Complicated space, (e) the topic moves into a convergent Complicated space, and (f) the topic is resolved.

Traditional engineering is largely in the convergent zone. Non-engineers (e.g., business analysts, marketing) usually inhabit the divergent zone. They are responsible for exploring topics in the divergent zone and organizing them so that they can be handed over to engineers for creating specific capabilities. Engineers use traditional processes and tools to converge on an implemented capability. And, engineering education is largely devoted to training engineers to use a range of tools that transform an abstract description into a concrete implementation.

This works well enough when capabilities are relatively decoupled (from each other and various use contexts) chunks of knowledge (e.g., systems, machines, applications, etc.). However, it becomes rigid, stovepiped, and slow when small chunks of composable knowledge (along with interoperable data) begin to dominate a topic area.

Technology seems to be in the early stages of such a shift today in the area of information technology. Traditional IT has a clear divergent-convergent divide...divergent in the need/requirement exploration phase, and convergent in the analysis/design/implementation phase. New IT (SOA, cloud computing, and similar composable technoogies) is beginning to blur the distinction between the divergent and convergent zones.

In topic areas where capabilities are information-intensive (and most capabilities are increasing in the amount of information they store and process), this shift means that the divergent and convergent zones will overlap in an increasingly fractal fashion.

This trend seems to point toward small teams of big picture-oriented explorers, puzzle-oriented implementors, topic experts, and a few part-time cognitive and social domain experts...first in IT-intensive domains, then in all information-intensive domains where agile decision making is important.

On the other hand, information storage, processing, and communication infrastructure would seem to be headed toward being a convergent commodity that requires deep and narrow technical expertise (similar to the production and dissemination of electricity)...except when new technologies disrupt (then displace) existing infrastructure technologies.

Structuring Innovation

The need and opportunity to innovate is an ongoing challenge/risk for all competitive contexts. Since the modern world has (for good reasons) an analytical bias, it's not surprising that there's a tension between incremental innovation that can be produced using analytical approaches, but yields only modest improvements, and disruptive innovation that seems to be largely the result of serendipity, but yields dramatic improvements.

This presentation by Robert Austin (HBS) is a nice discussion of this contrast/tension. My impression is that very few organizations have even a basic awareness of many of the key questions surrounding the full scope of innovation possibilities. This is especially true of large organizations whose DNA usually contains a "process maturity" gene that suppresses the expression of what Austin calls "artful making."

Here's a similar Austin presentation with an IT emphasis.

And, a NYT article on the fact that very few organizations manage the radical changes required to survive more than a few decades.

Data-Centricity

I suppose that software's malleability is one reason I first heard about the contrast between data/state and process/sequence in the SW engineering domain. It seems like this tension continues to evolve as technology changes...imperative vs. functional programming, SOA vs. REST, etc.

EMC's latest technology, Maui, is an interesting take on an object-centric world where processing related to storage policy is highly decentralized. A short article describing it appeared recently in The Register.

Beyond Analysis

Since the emergence of the unique blend of empiricism and rationalism called "science", many critiques of its power and limits have been made. I've discussed some of Dave Snowden's thoughts on the topic. Here are two other perspectives that also highlight the value of non-analytical tools:

• Stacey's Agreement and Uncertainty Matrix - highlights some challenges of coherent group action
• "The Tools of Cooperation and Change" - This October 2006 HBR article by Christensen, Marx, Stevenson highlights the types of tools used to reach group agreement when there is consensus (or lack thereof) in two areas: (a) goals, (b) cause-effect structure. This diagram summarizes the article.

I suppose it's no coincidence that these two perspectives (along with Cynefin) emphasize the epistemological limits of individuals and groups. Although there's a risk that such an emphasis may overstate the limits of analysis, that risk may be justified for those whose training and experience has tended to emphasize its power.

Innovation and Sensemaking

As someone who finds Dave Snowden's writing generally thought-provoking, I was glad to see that he recently discussed innovation with an Australian government network that focuses on continuous improvement.

Although Dave seems to be more focused on disruptive improvement in the Complex domain, and continuous improvement seems to be more consonant with the Complicated domain, Dave's talk was an intriguing critique of the dangers of using analytical and/or best practice approaches to innovation. Although I found some of the rationale for his conclusions unconvincing, the overall message was a refreshing change from the Complicated/Analytical approaches to innovation usually seen in large organizations.

A nice summary is here. It contains a link to the (partial) podcast. And, here's Dave's summary: http://www.cognitive-edge.com/blogs/dave/2008/10/to_distinguish_the_ordinary.php#more

Dis-Integrating Architectures

Although SOA gets most of the attention when the topic turns to composable business capabilities, the discussion is often either superficial or trite. A couple of recent items are welcome exceptions.

The first is a series of articles in the Economist on corporate IT. Although the overall theme is cloud computing, the articles discuss a range of trends that are driving increasing composability. Despite the lack of depth, the collection provides a nice summary of how IT is dis-integrating.

The second, however, provides some real depth. Carliss Baldwin and Jason Woodard recently published "The Architecture of Platforms: A Unified View." This fascinating HBS Working Paper (09-034) reviews three waves of research on business platforms (product-oriented, technological system-oriented, and transaction-oriented), considers various aspects of platform architectures, and describes three ways of representing platforms and their architectures (network graphs, design structure matrices (a long-time favorite of mine), and layer maps). This is the sort of article that is essential for understanding how dis-integrating IT intersects the business. Unfortunately, it is also the sort of article that most technology-centric architects are unlikely to ever stumble across since there remains a largely unbridged gap between IT-centric engineers (who read IT publications) and and business analysts (who read HBR and The Sloan Management Review).

Finally, Nick Carr created a bit of a fuss recently in his discussion of cloud computing. His post describing how the emergence of the electric grid triggered a wave of products that had a standard way to plug into that grid was interesting, as was his "typology of network strategies."

These articles/posts provide valuable insight into how dis-integrating technologies are changing the business environment, especially for those who think of WS-* or ESBs when someone says "SOA" . As IT shifts from being an expense to being a source of competitive advantage, the need for those who can bridge the IT-business gap will continue to grow.