Ironick

Design Thinking Comes to the US Army

Great review by Roger Martin of the US Army Field Manual 5-0: The Operations Process and its embrace of design thinking. His review was published yesterday on the Design Observer website. Martin gives a GREAT backgrounder on how the field manual came to be revised to emphasize design thinking (lots of great links to earlier Army thinking and debate on the topic). I just left a comment on the article that will hopefully show up on the page soon. Here's what I said (partially in response to a comment by "Jason"):

For me, this is one of the most important passages in FM 5-0:

The introduction of design into Army doctrine seeks to secure the lessons of eight years of war and provide a cognitive tool to commanders who will encounter complex, ill-structured problems in future operational environments.... As learned in recent conflicts, challenges facing the commander in operations often can be understood only in the context of other factors influencing the population. These other factors often include but are not limited to economic development, governance, information, tribal influence, religion, history and culture. Full spectrum operations conducted among the population are effective only when commanders understand the issues in the context of the complex issues facing the population. Understanding context and then deciding how, if, and when to act is both a product of design and integral to the art of command. (paras. 3-16 & 3-17, emphasis added.)

For me, the key word "if" (as in "deciding if to act") speaks directly to Jason's legitimate concern that design thinking might merely be used to inflict pain, suffering, and death (one of the explicit objectives of warfighting) more efficiently. Design thinking will only be a success in influencing Army doctrine if it sometimes leads to decisions NOT to engage in armed combat; to try a different, less lethal approach to achieving an objective.

I think if you read FM 5-0 more closely Jason, you'll see that this is one of the primary reasons for introducing design thinking into battlefield operations doctrine: to better understand when force of arms is NOT the right approach.

That said, I am somewhat disappointed that one needs to read FM 5-0 so closely to see this message. The concept of "human centeredness", which I feel is essential to design thinking is not highlighted in the field manual. I hope that in discussions of FM 5-0 and eventually in revisions to it, that the concept of "human centered experiences" and meaningfulness take center stage.

Epiphany: Replace HATEOAS With "Hypermedia Describes Protocols"

As a few of my friends know, I live for epiphanies. I love to connect concepts. So I'm really happy to be having one now (it's been a while as regular readers of my blog -- if any remain -- can tell).

For a LONG time, I've been talking about how all interfaces can be defined in terms of IFaPs (Identifiers, Formats, and Protocols). My canonical example of an interface composed of IFaPs is of course the Web: URL (I), HTML (F), and HTTP (P). All three intersect in a particular instance of HTML, say my blog's home page. The HTML for my blog's home page is filled with URLs, HTML tags, and even HTTP "verbs" (though these are quite rare, mostly in an HTML form or embedded JavaScript).

Then along came REST and with it the concept of HATEOAS: Hypermedia As The Engine of Application State. And everyone, myself included, spent a lot of time trying to grok it and explain it to others. We're still trying. One way I try to explain it is by highlighting that HATEOAS requires that each server response must contain not only the requested data -- but also control information (in the forms of specially tagged URLs) describing the next set of permitted interactions with the server. It is this additional control information (at a bare minimum just some links to more data) that turns mere media into hypermedia.

Now along comes Jim Webber with a much better (dare I say brilliant) way of explaining HATEOAS and hypermedia: "Hypermedia Describes Protocols!" (See slide 26.) At first this might seem counterintuitive, since I said that HTTP is the Protocol and HTML is the Format in the WWW. But URLs, HTML, and HTTP are just generic description languages for describing domain-specific identifiers, formats, and protocols. Thus, think of a web of specific HTML pages as a domain-specific protocol. Jim Webber uses the example of ordering a Starbuck's coffee. (What's important is that each hypermedia DSL is composed using the generic languages of URL, HTML, and HTTP.)

This notion of bringing together identifiers, formats and verbs to describe a protocol is not new. One of the best descriptions of this was in the WS-BPEL 1.1 spec:

In thinking about the data handling aspects of business protocols it is instructive to consider the analogy with network communication protocols. Network protocols define the shape and content of the protocol envelopes that flow on the wire, and the protocol behavior they describe is driven solely by the data in these envelopes. In other words, there is a clear physical separation between protocol-relevant data and "payload" data. The separation is far less clear cut in business protocols because the protocol-relevant data tends to be embedded in other application data.

So if WS-BPEL was already thinking about mixing protocol data with "payload" data, what's so new about HATEOAS? The fundamental difference is that WS-BPEL is based on the concept of providing an entire static protocol description up front once and for all -- and providing it out of band. But HATEOAS is based on the notion of progressive description (don't bother Googling the term, I coined it; and not to be confused with progressive disclosure). More and more of the description of the protocol is provided to the client (in band in the protocol itself) as the client executes its part of the protocol. I guess another good term might be JIT Protocol Description (Just In Time). Another good term might be "self-describing protocol". So now when explaining HATEOAS, instead of saying "each server response must contain control information" (huh?), I can say "each server response progressively self-describes the current protocol."

Now there are pros and cons to static/complete vs dynamic/progressive protocol descriptions. How can I program a client to execute its part of a protocol if I don't have a full description of it up front? But if I encode the complete static description of the protocol into my client up front, how can I change the protocol dynamically?

Love to hear others' thoughts. I'm going to think about this some more. That's why I love epiphanies -- they make you think about things in new ways.

Some historical roots to Mass Innovation.

Nice article in Forbes on Mass Amateurization (seen on Martin Koser's Furl feed). I especially like the quote about the mass amateurization enabled by the Model T:

To be fair, all this amateur energy isn't exactly a new force. When exciting technologies emerge, Americans have always pounced and created something original. In his 1936 New Yorker article "Farewell, My Lovely," E.B. White eulogized the Model T and the creativity it inspired in its owners: "When you bought a Ford, you figured you had a start--a vibrant, spirited framework to which could be screwed an almost limitless assortment of decorative and functional hardware.... Gadget bred gadget. Owners not only bought ready-made gadgets, they invented gadgets to meet special needs." The difference today is simply the technology, says University of Virginia technology historian Bernie Carlson: "I would call it the Ralph Waldo Emerson or Henry David Thoreau theme, that it's as important to produce as it is to consume." Forbes Article Page 2

BTW, it wasn't just the gadgetry that was done by amateurs; the very act of driving was now a mass activity, where chauffeurs had previously been required. Also, according the PBS series A Science Odyssey, the Model T also amateurized automobile maintenance: owners could and did do basic maintenance to their Model T's.

Democratizing Innovation.

Just came across a wonderful new book on user innovation (aka mass innovation) in Virgina Postel's recent article on same (Innovation Moves From the Laboratory to the Bike Trail and the Kitchen). The book is Democratizing Innovation by Eric von Hippel (MIT Sloan School). And of course, it is downloadable for free. As the following passage from the introduction suggests, this is a must read:

When I say that innovation is being democratized, I mean that users of products and services--both firms and individual consumers--are increasingly able to innovate for themselves. User-centered innovation processes offer great advantages over the manufacturer-centric innovation development systems that have been the mainstay of commerce for hundreds of years. Users that innovate can develop exactly what they want, rather than relying on manufacturers to act as their (often very imperfect) agents. Moreover, individual users do not have to develop everything they need on their own: they can benefit from innovations developed and freely shared by others.

The user-centered innovation process just illustrated is in sharp contrast to the traditional model, in which products and services are developed by manufacturers in a closed way, the manufacturers using patents, copyrights, and other protections to prevent imitators from free riding on their innovation investments. In this traditional model, a user's only role is to have needs, which manufacturers then identify and fill by designing and producing new products. The manufacturer-centric model does fit some fields and conditions. However, a growing body of empirical work shows that users are the first to develop many and perhaps most new industrial and consumer products. Further, the contribution of users is growing steadily larger as a result of continuing advances in computer and communications capabilities.

In this book I explain in detail how the emerging process of user-centric, democratized innovation works. I also explain how innovation by users provides a very necessary complement to and feedstock for manufacturer innovation.
[emphasis added]

This notion of users as solely the provider of "needs" or "requirements" pervades the manufacturing and services industries. Yes, users have needs, but the new approach is to give such users the tools they need to easily and affordably customize generic products and services to meet their own needs. By making the user the key designer we transcend the dichotomy between user and maker.

This applies directly to the relationship between the IT organization and the business it serves. ITOs usually do a terrible job of initially meeting the needs and requirements of the business, much less keeping up with them. Instead, the ITO should focus on providing users the open-ended tools for creating their own solutions.

The Long Tail.

I recently realized that not everyone is clued in to one of the hottest (new) blogosphere buzzwords: the Long Tail. The catalyst was this Wired magazine article. The author of the article, Chris Anderson, now has a site devoted to the Long Tail and is writing a book. Here is his brief description:

The Long Tail is about how the mass market is turning into a million niches. The term refers to the yellow part of the sales chart at left, which shows a standard demand curve that could apply to any industry, from entertainment to services. The vertical axis is sales, the horizontal is products. The red part of the curve is the "hits", which have dominated our commercial decisions to date. The yellow part is the non-hits, or niches, which I argue in the article will prove equally important in the future now that technology has provided efficient ways to give consumers access to them thanks to the "infnite shelf-space effect" of new distribution mechanisms that break thought the bottlenecks of broadcast and traditional bricks and mortar.

The two big points of the Long Tail theory are these: 1) The yellow part potentially extends forever to the right; 2) The area under that line--the market it represents--may become as big as the hits at the left.

The Wikipedia entry on the Long Tail does an excellent job of expanding on this.

The shift from hits to niches is a rich seam, manifest in all sorts of surprising places. This blog is where I'm going to collect everything I can about it.

As the Wikipedia entry on LT emphasizes that it is simply a popular name for a "long-known feature of statistical distributions (Zipf, Power-laws, and/or Pareto distributions)". Accordingly, it applies to various aspects of all phenomena, including software production.

LT is fundamentally based on the dialectic between "convention and invention": when a process becomes very convenient and affordable through commoditization, this enables more unique needs to be met through invention.

A great software example of this that I just ran across is machinima: "a new form of filmmaking that uses computer games technology to shoot films in the virtual reality of a game engine." (See also the Wikipedia definition of machinima.) In this instance, the "convention" is a commoditized "game engine" and the invention is the variety of scenes that individual "artists" create with it. Red vs. Blue (movies created with the Halo engine and images) is the most popular example of machinima, but check out the growing number of examples, including an MTV machinima video at machinima.com.

Mass customization is how large corporations can address the LT, but mass innovation (aka mass amateurization) shifts control from the seller to the buyer: the buyer customizes the product or service without the participation or even the approval of the vendor, cf., the recent NY Times article on the relationship between  Nike and sneakerheads who customize its sneakers. (See also my collection of mass innovation links.)

The most WS-* related example that comes to mind is Greasemonkey: "a platform for running scripts that inject new functionality into web interfaces. If you're a UI designer, this might frighten you. What it means is that any kid with a bright idea and a knack for DHTML can create a new interface for your site, and it will probably be better than yours. (There's a lot of bright kids out there in the world.) Why should you get paid when the bright kids will do your job better for free? The key to survival will be going meta: design for the bright kids. Create a flexible, modular set of APIs and a well-documented example UI or two that shows how they are used. Learn from Amazon and release your grip on the end-user experience. But developments like Greasemonkey disrupt more than just job descriptions: they disrupt business models too. For example, I will never see a Google AdSense ad again, thanks to a handy Greasemonkey script." [Greasemonkey Stole Your Job] Greasemonkey enables anyone to "reprogram" Firefox to filter and transform any and all web interactions ON THE CLIENT SIDE. Now the "look and feel" of a site in no longer in the hands of the site owner, but in the hands of the browser owner or any intermediary.

BTW, my fellow blogger Tom Murphy has a nice link to Long Tail thinking applied to specifically to software.

Mass amateurization

The issue of Mass Amateurization came up in a client discussion. Thought I'd pass along the links and thoughts I'd collected so far. Sorry for the endnotes, but I wrote it for ASCII email.

Here's Clay Shirky's blog posting that (seems to have) first articulated the concept.[1] He had this to say about the amateurization of travel planning:

Mass amateurization is the web's normal pattern. Travelocity doesn't make everyone a travel agent. It undermines the value of being travel agent at all, by fixing the inefficiencies travel agents are paid to overcome one booking at a time. Weblogs fix the inefficiencies traditional publishers are paid to overcome one book at a time, and in a world where publishing is that efficient, it is no longer an activity worth paying for.

Tom Coates then expanded the concept to "(Weblogs and) The Mass Amateurisation of (Nearly) Everything..."[2] For example, he states:

But it's not just publishing or journalism that are going through a process of mass amateurisation at the moment. In fact over the last fifteen years or so pretty much all media creation has started to be deprofessionalised. We only have to look around us to see that this is the case - as individually created media content that originated on the internet has started to infect mass media. Hard-rocking poorly-animated kittens that once roamed e-mail newsletters (http://www.b3ta.com) are now showing up in adverts and credit-sequences, pop-songs written on home computers are reaching the top of the charts, weblog commentators in Iraq are getting columns in the national and international newspapers, music is being hybridised and spliced in the home for competitions on national radio stations. The whole of the mainstream media has started to look towards an undercurrent of individual amateur creation because of the creativity that's bubbling up from this previously unknown swathe of humanity. Mass-amateurisation is EVERYWHERE.

And Ted Leung correctly applies the same concept to open source[3]:

Tom Coates notes that just about everything is becoming amateurised. I think that there are parallels with open source. ... I wish that we could find better terminology. After all, the software running 64% of the web servers on the Internet was written by "amateurs".

Perhaps a better word is semiprofessional: everyone becomes semiprofessional across several professions.

A different perspective on the same phenomenon goes by various names: "hacks"[4], "home hacking"[5][6], and "consumer hacking."[7] As the editor of the O'Reilly "Hacks" series explains[8]:

What happens if you expose the rich mountain of Google data to hackers via a programmatic interface (the Google Web API)? How do you turn a store-front like Amazon's into a syndicated e-commerce engine? (Take a gander at the Amazon Associates program for the answer.)

Think about it. eBay has turned legions into amateur merchants. 40% of eBay's listing come through its Web services APIs[9], of which about 20% are initiated by 3rd parties.[10] Amazon's APIs tell a similar story.[11] The same thing is happening with advertising. Google's AdSense has turned everyone's personal web sites into ad revenue generating machines.[12] All you have to do is insert a sliver of simple HTML boilerplate into your page design (and free up some page real estate), and whenever that page is displayed, Google will automagically post ads that are directly relevant to the content on the page!. For a case study in the airline biz, check out SeatGuru.com. It a favorite of mine because it lets you see the seating configuration for all aircraft models across the major airlines! No more first or last rows! Google even uses the site as a case study.[13]

This ability for consumers to customize their software-driven devices and appliances and even cars is what accounts for the popularity of ring tones ($3 billion business), skinning, and car hacking.

The phenomenon has even been written up in the Wall Street Journal.[14] A related phenomenon, user exchanges, where users exchange their extensions or add ons, has been around for a long time.[15] And here's this month's Communications of the ACM with a special issue on "End User Development" aka "Do it yourself" (DIY) development. [16]

Note, in some ways this mass amateurization trend is nothing new. Note that all managers became amateur "secretaries" when word processing made it possible for everyone to do his or her own typing. Did it eliminate secretaries? No. They went on to do more complex things. It did put a big dent in typing pools though. <grin>

[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16]

Update (2008-09-16): I originally misspelled Clay's name as "Clay Sharky"!

User Innovation.

Given my belief that it is the role of the developer-user that is essential to "open development" (which I will discuss later), I was pleased to come across the following MIT web site: userinnovation:

Empirical research is finding that users rather than manufacturers are the actual developers of many or most new products and services - and that they are a major locus of innovative activity in the economy. This finding opens up new questions and avenues for exploration in fields ranging from economics to management of technology to organizational behaviour to marketing research. Examples are patterns in innovation by users, characteristics of innovating users, design of a user-centered innovation process, economics of a distributed innovation process that includes users as innovators, and social welfare implications of innovations by users. [Emphasis added]

I find this view to fit my own experience extremely well. It is often users of a business application that see its limitations and are inspired to build a new application that better fits the business they came from.

I just started the paper "Profiting from Voluntary Information Spillovers: How Users Benefit by Freely Revealing Their Innovations".

(Historical) Analysis-Driven Innovation

An interesting question is the degree to which sustaining and disruptive innovation are based on or driven by analysis of data regarding the system to be improved. Certainly, one must have some idea of the limitations of the current system in order to improve it, thus data collection and analysis seem central to at least sustaining innovation. This is an interesting interpretation of George Santayana's famous dictum: "Those who cannot remember the past are condemned to repeat it." Put another way: "Those who do not collect and analyze information about the past behavior of a system cannot improve it." But this begs the question of how evolution improves a system apparently without such analysis. Certainly, random mutation, which entails no analysis, can "improve" one member of a species. But is the diffusion of such an improvement dependent on some process akin to historical analysis. Something to ponder.