How Technology Almost Lost the War, but Should Do Better
It was cool that ETech ventured into unexpected territory this year with Noah Shachtman's presentation on technology’s failure in Iraq. The talk was derived from his provocatively titled Wired article "How Technology Almost Lost the War: In Iraq, the Critical Networks are Social - not Electronic". In it he takes shots at the military’s infatuation with the bright shiny objects that support the big fight while missing the day-to-day realities of counter insurgency operations; a reality that revolves around people.
Leaving aside for the moment the fact that using technology to win the big fight gives one the luxury of discussing failures in the subsequent counter insurgency phase, Shachtman argues that the military's “Network-Centric” technology is the wrong tool for the counter insurgency job. Systems like Command Post of the Future (CPOF) are cool, but in this phase of conflict, they are like bringing an iPhone to a knife fight.
I can’t disagree, but I think the reasons are as much about a monoculture focused too long on the Fulda Gap as they are about technology's bells and whistles. But that’s a conversation for another day (and venue). An interesting question might be the one he doesn’t ask, what kinds of technology might help now in the midst of a counterinsurgency and how can we get them faster?
Released just before Shachtman’s talk, MIT’s Technology Review magazine covered DARPA’s Tactical Ground Reporting System (sorry, registration required), or TIGRnet. Where CPOF was designed for commanders fighting conventional battles, TIGRnet is for the patrolling sergeant and lieutenant fighting in a counter insurgency. While CPOF supports conventional ideas of command and control, TIGRnet gives troops on the ground new tools to share information horizontally (which might make it an accidentally subversive culture virus).
TIGRnet is interesting because it was built from scratch for the counter insurgency environment. This is no small thing in a one-size-fits all Army. However, it’s disappointing because it has been so long in the making.
Both CPOF and TIGRnet are cool compared to anything previously fielded, but in another context they would be trivial. Because what magic they have is focused on making up for poorly provisioned networks, it’s hard to get excited about them. If you’ve used Google Earth, Skype, and a wiki you wouldn’t be impressed. If you’ve used Google Earth, Skype, and a wiki through a 4.8 kbps modem, you might be.
It’s telling that both store similar data but there is no mention that they are connected. Neither offers simple and readily accessible API’s to the broader community or is designed as though it will part of an ecosystem.
So, I’ll leave it to Shachtman to talk about why the Army has the wrong tools from a cultural point of view. I want to talk about how it gets them and why they evolve so slowly to meet a changing mission.
Defense technology evolves in a world choked by systems engineering and onerous testing and certification; an approach designed during the industrial age to eliminate risk before you start bending metal. It sucks at thinking about risk/reward or dealing with urgency. That’s why, in two years longer than we were in WWII, we’ve delivered TIGRnet - essentially a replicating database with a map on top - and little else to the patrolling foot soldier. For five years new units have been showing up in Iraq with little more than a three ring binder left behind by the last guys to help them understand the social, political, or economic context of their new area of operations.
Jonathan Zittrain, in his excellent piece Saving the Internet, talks about the tradeoffs between security and generativity. I would love to see things like TIGRnet evolve in an environment with the generative attributes Zittrain describes, but defense technology lives at the other end of that spectrum. What the military needs is an Internet and stack that lets them have their cake and eat it too. Secure but generative. Five years is just too long to wait for a simple application; no matter how secure it is.
When Noah looks at CPOF (and presumably TIGRnet) he sees a military focused on the wrong stuff. When I look at them I also see missed opportunity for the technology to evolve so that it could be useful now instead of in some later conflict.
Instead of one problem = one application, I want a set of services and components that collectively add up to a generative environment for building stuff quickly. An infrastructure designed with agility as a requirement and with provisions for permanent beta. A Command and Control Platform as a Service - think Force.com wrapped around a map - with a vibrant ecosystem of component developers where Ajax scripting sergeants can take “parts off the shelf” and build their own new pieces of TIGRnet while their boots are still dusty. As if CPOF and TIGRnet were just two applications in a Command and Control Facebook platform.
In 1942 we focused our advantage of the time, industrial power, and built great quantites of all kinds of things to end that war in three and a half years. Nowadays we’re great at other stuff. We know how to do this. But through a combination of industrial age thinking and our government’s inability to engage us, our troops are fighting with last year’s tools, designed for a different war. We can do better.
tags: defense, emerging tech, etech, network-centric, platform plays
| comments: 12
| Sphere It
submit: 
0 TrackBacks
TrackBack URL for this entry: http://blogs.oreilly.com/cgi-bin/mt/mt-t.cgi/6395
Comments: 12
Jim, I agree with an open standards policy for DOD software, and so apparently do the Armed Services, at least according to the research that I've read on it, but with all due respect, I think Noah's point is the more pressing one. The solution to a successful COIN strategy human-centric rather than net-centric, particularly in the work of Human Terrain Mapping teams. More emphasis needs to be placed in cross-cultural awareness and how to overcome ethnocentric thinking and less on the next new Web 2.0 tweak.
Steve, thanks for your comment. I should have thought to mention CIDNE, but honestly it doesn't do much to alleviate my main concern that this is not a "generative" environment for software development. The fact that there is a third application independently working the same problem space really serves to reinforce my main point, we're not building reusable platforms, we're building point solutions.
In the defense space Conway's law can be paraphrased to say that "system architecture follows contract architecture" and so three independent contracts are resulting in three independent too-slowly-delivered tools. The fact that CIDNE exposes web services is nice, but delivers it with a line of business application integration mindset. I'd like to see Conway's law harnessed to build reusable and open stack / platform so that CPOF, TIGR, and CIDNE could all be built for a lot less money faster. I'm really talking about harnessing open product platform thinking in the DoD.
Jeff, thanks for your comment. You are absolutely right, a human-centric strategy is key. My comments are a bit orthogonal but I think they do connect. After a year in theater each unit has gained understanding of at least some of the human context through blood and sweat. But even the most COIN-enlightened units take all that understanding with them when they leave; most can't even be reached by a simple email once they board the plane home. One thing that is needed is a much better way to capture and transition that institutional memory for the new units coming in, and I believe more rapidly developed technology can help with that.
Jim, thanks for a good discussion. I'd like to point you to a great "Lessons Learned" article in this month's Military Review "Human Terrain Mapping" by Jack Marr (LTC USA), et al. Here's a snippet:
"As the U.S. Army continues to examine the human-terrain mapping aspect of counterinsurgency warfare, TF Dragon Soldiers would offer a caveat based on their experience: do not rely solely on a computerized, automated solution to HTMTM or on the creation of a singular special-staff section to provide human-terrain insight. From what TF Dragon learned, a unit would best benefit from going out and collecting this information initially on its own, or, if it inherits such information from a previous unit, by developing a process to continuously reassess that information."
Marr and his officers point out the many benefits of working among the populace of a given area to collect the HTM data that they need; benefits which have to be re-earned by each new company that rotates into the area.
I guess the bottom line in this debate is to find a middle path that provides optimum collection and storage technology with an insistence on human interaction with the population to confirm and/or adjust the data previously collected.
Hi, I am very familiar with all of these systems and the environment in Iraq. I used them all and helped introduce TIGR in theater.
TIGR could not and would not have been developed anywhere except at DARPA. The need was unperceived by the big Army, no $ or doctrine. The CIDNE comment is misleading - CIDNE isn't an Army system either, precisely because the Army is still figuring out what to do for information flow.
-- DOD software ends up with poor interfaces for all the reasons stated in the posts. However, this is changing. Too slowly, but it is changing. First, there are programs like TIGR that are built entirely on Web services and standard databases. Secondly, there is a (ponderous) attempt to create a Common Operating Environment that is services-based.
These systems take a while to develop for a lot of reasons:
-- a war zone is no place for experimentation or roll-your-own. Lives depend, every day, on critical functions. Development through beta testing is necessarily something that has to occur prior to fielding.
-- it is the gov. Contracts must be let, the Army must OK, the logistics of staging to theater, training of civilian personnel, etc, take time
-- TIGR and its counterparts are classified systems. There are security hurdles and approvals that aren't encountered in more normal environments.
Now as to the systems: TIGR operates precisely to provide the lowest-level soldiers with an information tool. Other systems overlap - CPOF, CIDNE - but are built for a war fighting model that is primarily kinetic and focused on more or less conventional warfare.
TIGR operates at the lowest level, a level that is not even addressed by doctrine or the acquisition system. It uncovered a capability gap that desperately needed to be plugged and plugged it. It is designed for company, platoon, and section leaders, those that are actually leading the fight in Iraq. It is disruptive: traditional C2 models are stood on their heads, and higher echelons become supporting elements in the fight. The information flow that counts is horizontal - patrol leader to patrol leader.
TIGR means this level, the level of most importance in the fight, can capture, organize and display information that was essentially lost before - reporting to a commander helps the commander but not the patrol leader. TIGR is multimedia-rich and operates over severely disadvantaged networks. You have to see the networks to really understand, but I have never seen a good analogy here.
CPOF is primarily a collaborative planning tool for commanders - battalion and above. Good tool, heavily used, but not easy to use, relatively bandwidth intensive, multi-media poor and not a good choice for patrol leaders.
CIDNE began life as a data aggregator, so that kinetic actions throughout theater could be viewed by, well, folks that are interested in kinetic actions throughout the theater. Those folks generally reside at division and above. CIDNE has been exposed on the Web, but being Web-based does not mean that it is a sort of universal tool.
I suppose my analogy would be Google Earth, Net Meeting and Bloomberg. Each might be on the Web, but nobody in their right mind would advocate making them one.
So, we're moving as fast as possible, the people aren't dumb and understand that information sharing is critical to the fight. However, our "human systems" cannot change on a dime. Cultural change in an organization takes time, whether it is IBM or the US Army. I am actually amazed at how aggressively the war fighters adopt things that help and ignore things that don't. Maybe we should think about that - the users vote with their feet, every day.
Sam, thanks for your comments and insights. While I agree with you that today there are lots of reasons why software development and delivery happens more slowly in this domain, I don't think there is anything fundamental that says it has to stay that way. The biggest barrier is that our belief systems say it has to be that way.
Not every system is a fire control system and no one will die if TIGR goes down for a day. The data it is sharing wasn't shared at all before. Yet its development, test, and certification cycles are not unlike those of a fire control system hooked to an MLRS. That doesn't make sense to me.
We can provide horizontally available stacks and platforms combined with parallelized processes for development, testing and certification that make it a lot easier and faster to deliver these kinds of things in a much more granular, iterative, and user-responsive way. But first we have to believe we can.
A key challenge which TIGR addresses is operation over challenged military networks - Jim mentions this issue, but the the original comment on CIDNE seems to miss this critical point entirely. The edge of the military network where the warfighter operates, by its nature, needs to be wireless and mobile, without fixed infrastructure - and provide connectivity to whatever location is necessary. The further forward, the harder the problems become. This fundamentally influences the design of military software for tactical use. TIGR is specifically designed for use in the wild by small units, while tools such as CPOF and CIDNE are targeted at headquarters and operations centers that have better connectivity. TIGR is designed around a web services interface specifically to enable the sort of services and components evolution the author describes. Third party analysis applications are being developed for TIGR using these interfaces, and automated inter-application communication is under way with others (e.g., CIDNE). TIGR is able to import and export data to CPOF, Analysts Notebook, Google KML, and MS Office products - and interfaces with other organizations and applications are planned. There is movement in the right direction, but the fundamental edge network challenges remain.
I understand the point that you are making from the standpoint of development and deployment, but it's not just a question of belief that a change in approach is possible.
I don't work on the DoD side of things, but I've got a reasonable amount of experience in managing civilian sector projects, and the rigor - or at least the linearity - of the contracting and development processes is a result of the road being littered with the remnants of systems that didn't work for federal agencies, built under a time and materials approach.
Furthermore, the government doesn't have much recourse when contracts go wrong - if there's no criminal component to failure, contractor liability is limited to the value of the contract. That's why there are so many interim stages of software projects - whether it's T&M or fixed price, tying waypoint checks to SDLC lifecycle stages is a way of preventing issues from spiraling out of control.
So, while you are entirely right that software development and deployment could be completed in a more agile fashion, it's not just a change in thinking about software architecture that's needed, it's a change in managing outside contracts that will speed up delivery without also leaving the gov't at risk for going back to spending vast sums to get nothing. This is not a trivial change.
@ Colin: Yep. You are right on, it's more about contracts than it is about technology and the one thing that DFARS and associated contracting approaches don't seem to understand is scale. $100M and $1M contracts go through basically the same process. Things like TIGR and CIDNE are more "web" than "enterprise" in terms of technology and more "departmental" than "enterprise" in terms of scope and risk. Different flavor and scale should mean different approach.
Jim,
When exactly was the last time you developed software in a war zone as these guys are forced to do every day?
I wrote a lot of code during my tour in Iraq/Kuwait (up to May 08). Our battalion were the first "edge" to receive approval for a handful of Linux boxes on "the" network. We developed our own web interfaces for CIDNE data in addition to web apps for mission tracking/logistics and widgets for situational awareness.
Jim's right about our tools being mainly for TOCs, as our troops are frequently on different networks.
"Sam, thanks for your comments and insights. While I agree with you that today there are lots of reasons why software development and delivery happens more slowly in this domain, I don't think there is anything fundamental that says it has to stay that way. The biggest barrier is that our belief systems say it has to be that way."
Can't agree with you more. One critical system we developed took a couple weeks from concept/fielding to mass usage. Sorry to be so vague, but they're still in use in Iraq today. I think a main problem is there aren't many (any) soldiers assigned as software developers in the active army. Most (all) developers are contractors. Contracts don't happen fast and new ideas don't get out into the battlefield fast enough because of that. There's really no "open development environment" to speak of. It's more like, here's Microsoft Office and a web browser, deal with it.
CPOF... most units use it as "stickies on a map" in a PowerPoint kind of way for briefings. I don't people using its full potential... maybe a web version would be more useful.
Post A Comment:
STAY CONNECTED
RECENT COMMENTS
- Paul on How Technology Almost Lost the War, but Should Do Better: I wrote a lot of code d...
- Sam D on How Technology Almost Lost the War, but Should Do Better: Jim, When exactl...
- Jim Stogdill on How Technology Almost Lost the War, but Should Do Better: @ Colin: Yep. You are ...
- Colin on How Technology Almost Lost the War, but Should Do Better: I understand the point ...
- Joe Evans on How Technology Almost Lost the War, but Should Do Better: A key challenge which T...
- Jim Stogdill on How Technology Almost Lost the War, but Should Do Better: Sam, thanks for your co...
- Sam Earp on How Technology Almost Lost the War, but Should Do Better: Hi, I am very familiar ...
- Jeff Carr on How Technology Almost Lost the War, but Should Do Better: Jim, thanks for a good ...
- Jim Stogdill on How Technology Almost Lost the War, but Should Do Better: Jeff, thanks for your c...
- Jim Stogdill on How Technology Almost Lost the War, but Should Do Better: Steve, thanks for your ...
RADAR TOPICS
Steve L [03.22.08 07:12 PM]
Agree that 5-years to develop an application is to long. Also think that having DARPA develop an operational system is wrong. There is an operational system, developed in short order and on the ground in Iraq that is supporting COIN. The Application is called Coalition Information Dissemination Net-centric Environment (CIDNE). It was designed and developed to capture and correlate data and then make that information and its relationships available to other systems, such as CPOF. The interfaces to other systems are via Web Services. The majority of CIDNE development, maintenance, and training is done in the Iraqi Theater of Operations (ITO) with a reach-back development team in Hampton, Virginia. As a web application, CIDNE is available to users on SIPRNET and CENTRIXS without installation of client software. CIDNE does for the entire AOR what TIGR does for a battalion. It was rapidly developed at a much lower cost. The CIDNE development team just doesn’t have the contacts within the media to get articles written about it in MIT Technology Review.