Lt. Gen. Sorenson, Army CIO, at Web 2.0 Summit
I didn’t make it to the Web 2.0 Summit in San Francisco in November last year so I didn’t get to see Army CIO Gen Sorenson present this Higher Order Bit talk in person. However, I thought it was cool that the Army made the agenda and luckily someone posted the video. I finally got a chance to go through it. If you didn’t see the talk, or don’t have the 20’ish minutes to watch it now, here’s a rough summary:
– Because of security and related concerns, it takes a very long time for the Army to take advantage of new generations of technology. We tend to deploy it widely about the time it’s becoming obsolete.
– However, we are now beginning to take some advantage of Web 2.0 technologies in, for example, Stryker Brigade collaboration, battle command information sharing, and command and control.
I don’t think that slow technology adoption is caused by fundamental first principles, so I don’t think it has to remain true. But that’s a long discussion for another time. In this post I’d like to focus on Army Battle Command, Web 2.0 and Gen Sorenson’s connecting the two. Specifically I’d like to talk about lost opportunity and how the same technologies can constitute a generative platform in one setting and window dressing on a temple to determinism in another.
The lost opportunity I’m thinking of isn’t whether Army Battle Command is Web 2.0 enough or not. It’s that enterprises tend to see web technologies as an add on to whatever they already have. Plus, they tend to focus on specific technologies rather than the combination of technology, process and policy that make a collection of technologies viable as a generative platform. “Let’s add some Web 2.0 to this system; we’ll use REST instead of SOAP.” But the fundamental question that the web answers isn’t whether REST is better than SOAP, but whether emergence is more likely to create innovation than enterprise planning, and the answer to that question is yes.
General Sorenson says in the video that “CPOF brings in Web 2.0 capability, chat, video, etc…” and then comments on “graphics, chat, use of tools…” and stuff like that to reinforce the idea that Command Post of the Future (CPOF) and the Battle Command suite it is part of has Web 2.0 attributes. Like many enterprise technologists, General Sorenson appears to be focusing on rich user experience and collaboration as the attributes that give CPOF a Web 2.0 imprimatur. While that’s not unexpected, I think it leaves most of the benefits on the table and untapped.
Putting aside for the moment that CPOF isn’t primarily delivered through a browser, a first step toward webness, the reality is that CPOF and other systems like it neither leverage accessible platforms nor contribute to them. It is a standalone (though distributed) computing system with gee whiz collaboration and VoIP. And while it offers some enterprise-style data services, it has none of the features of a generative platform. If I’m in the field I can’t readily extend it or build on it to solve different problems, modify its proprietary underpinnings to suit my local needs, or quickly incorporate its information into other applications. If an important aspect of Web 2.0 is enabling the long tail, then this isn’t Web 2.0.
I should say, this isn’t a post about web 2.0 semantics. However, it’s important to understand that the web’s power derives from its evolution as a platform. Otherwise it’s hard to see what is being missed by the military’s IT enterprise (and many other large enterprises).
From the beginning the web has been generative. It wasn’t CompuServe. With some basic skills you could add to it, change it, extend it, etc. Jonathan Zittrain, in his excellent book The Future of the Internet – and How to Stop It, reflects on why the Internet has experienced such explosive innovation. He argues that it’s the powerful combination of user-programmable personal computers, ubiquitous networking with the IP protocol, and open platforms. Today, the emergence of open source infrastructure, ubiquitous and cheap hosting for LAMP-based sites, open API’s, and the intentional harnessing of crowd wisdom has ushered in the web 2.0 era. It’s an era of high-velocity low-cost idea trying that leverages the web itself as the platform for building world changing ideas and businesses.
The Internet hosts innovation like it does because it is an unconstrained complex system where complex patterns can grow out of easy to assemble simple things. Simple things are not only permitted, but they are encouraged, facilitated, and often can be funded with a credit card.
I’ve subscribed to the notion of Gall’s Law for longer than I knew it was a law:
“A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.”
The upshot of Gall’s law isn’t directly stated, but it’s important. To get complex things, you have to be able to do simple things. It turns out that enabling simple things is what the web as a platform does exceptionally well and that enterprise systems like Army Battle Command don’t do well at all. In fact, the DoD enterprise tends to prohibit simple things through an unintended combination of policy, practice, acquisition rules, and organizational inertia.
In an environment that does permit or encourage simple things, many of them will go nowhere, but without those failures, complex successful things are impossible. So, if you want your enterprise to be innovative like the web, you have to resist the Soviet urge to five year plan everything, and instead make at least some room to facilitate emergence. If you agree, then the goal of your planning should be to plan the development of infrastructure, policy, and practices that support the emergence of things you haven’t thought of yet.
A while back I met Carlos Castillo and Paul Lin through this blog. I had written a post touching on some similar themes to this one and they commented about their experiences developing systems while in the Army. Later we got together and they told me the story of a system that they built, against all odds, while they were deployed with the California National Guard to Iraq. Called Combat Operations Interactive Network (COIN), it was a simple but very effective set of web applications that streamlined operational administrivia for the soldiers in their unit. Things like crew and equipment manifests for patrols, the status of routes, etc. Stuff that until then was being done in Excel spreadsheets and lots of running back and forth with USB thumb drives.
It was a great story of how, with sheer determination, two guys in the field took on layers of bureaucracy and after six months got a single Linux box authorized on the secure network. Then, using skills they brought with them from their civilian careers, they launched COIN within days.
The really interesting thing from my perspective was that once that box was on the network, it’s value as a generative node was obvious and they rapidly extended COIN to scratch all kinds of other itches. People were lining up to ask for enhancements and new apps. Simple as it was, it had become a platform, and it was valuable in ways that the CompuServe-like Battle Command couldn’t be. Within a short time elements of COIN were being used in General Petraeus’ daily situation briefings and it had become a fixture in command centers across the theater.
If one Linux box can enable that much emergent innovation, imagine what java-scripting (or Ruby wielding) sergeants could do with EC2, some simple application and mapping frameworks, and a lightweight REST-based API strategy implemented across the rest of the Army’s Battle Command suite.
I went to the Pentagon with Carlos and Paul and had the opportunity to introduce them to General Sorenson through members of his staff. It was great to see them get recognition for what they had achieved. Most people in their shoes would have faced that mighty bureaucracy and fled the field. However, today COIN is languishing because they’ve rotated home. Once again they are struggling with the bureaucracy to get back over there and further extend and maintain it.
I was thinking about all this as I watched General Sorenson’s video. I’d love to see the Army push less for the development of specific end solutions like CPOF and work instead to build general infrastructure to support emergent innovation. Traditional requirements documents are low band pass filters at best. They are too time and distance displaced from users, but emergent processes close to the problem can achieve high-fidelity solutions quickly. To take advantage of this Army Battle Command should expand its mission to build platform components and content API’s and consider themselves one part enterprise system, one part platform, and one part edge development facilitator.
The over-arching goal would be to bring, train, and develop more Carlos’ and Paul’s in forward-deployed units and then make sure they have what they need to innovate rapidly and in situ. I would expect to see a flurry of simple but valuable things emerge. Some of them might just grow up to be the next really important big complex thing. Plus, just think how cool it would be to have an enterprise metric called “number of serendipitous emergent solutions per brigade.”