Imagine yourself as a senior official within one of the dozens of departments in the DoD. You care deeply about your organization’s mission, and you’re always looking for ways to improve its performance. One day, you’re told that a web application custom-built for your organization runs on outdated technology and will be obsolete in two years. You request funding to rebuild the application with newer technology, the funding is approved, and the 18-month development project begins. A few months later, someone approaches you from a different organization about building an application similar to yours. Because your organizations work with overlapping information, this person suggests that you collaborate on building a single application that serves both, thus expanding the information-sharing community and increasing internal transparency.
It sounds like a nice idea, but it would delay your progress while the requirements are developed for the new, combined application. Even worse, replacing your current effort to collaborate on another means you would lose your current funding, as it was specifically approved for the project in its original form. You would be forced to reapply for funding for the new, combined project and risk being declined. Your dilemma: continue on your path, guaranteeing your organization continued access to the application it knows, or agree to collaborate with another organization, incur delays, and risk your funding for the sake of experimenting with the idea of a larger information-sharing community. What would you do?
The Pentagon official who is the basis for this story very quickly opted to stick with his original plan. I approached him about combining efforts. He was committed in the abstract to exploring “synergies,” but outright merging our efforts would have been too costly and risky for him. This kind of tragedy of the anticommons happens everywhere, all the time. While it’s ideal for everyone to adopt a common framework that ensures shared standards, it’s usually too difficult and costly for any one group in an organization to take on the challenge of creating it. On the occasion when one tries, the minor network effects of an infant framework are typically not compelling enough for other organizations to be willing to make the necessary changes and sacrifices to join. It’s difficult, then, for a standard to ever take off.
The core problem is the fact that DoD organizations are responsible for their own IT solutions. Many of them have their own, internal IT teams. When authority is fragmented, solutions are fragmented. Most organizational decision makers don’t even think to consider a solution that could expand its reach beyond their niche. It’s beyond their scope. They’re not IT product managers looking to increase market share. They fund IT projects that support their particular mission.
As a result, the DoD is riddled with one-off applications. It’s analogous to commerce before mass production. If every county designed and manufactured its own brand of vehicle we’d have a lot of trouble driving between counties: some places would put the driver on the right, others on the left; city cars would be go-carts that top out at 40 mph; rural vehicles wouldn’t bother with turn signals or door locks.
In the same vein, government’s custom applications cannot communicate with one another, making them counterproductive information silos that reduce transparency. I might research the test plan for a helicopter prototype within one application and never know about additional information within another application. On the other hand, many applications store copies of the same underlying data, but these copies are not linked. When the helicopter’s cost estimate changes, for instance, each application’s data set must be independently updated. Inevitably, some data sets are not updated, meaning that an analyst will run into different cost figures for the same helicopter within different applications. Sometimes meetings devolve into determining whose data is correct rather than discussing the significance of the data.
The variety of unique needs among the DoD’s many organizations makes any standardization effort fundamentally difficult, but in some cases even easy opportunities for consolidation are lost. My organization developed its own collaborative calendar even though many other DoD organizations already use some form of public calendar. Multiple instances of meetings are passed back and forth across one or more systems, some up-to-date and others not. A meeting might have only a partial attendee list in one system and simply not exist in another. This fragmentation makes meeting management more tiresome and opaque than it should be. A universal calendar framework would enable consistent transparency into what meetings are being held and who’s attending them.
The lack of IT standards is a recognized problem in DoD and throughout government. Countless consolidation efforts have been unraveled by institutional inertia, the politics of agreeing on a standard, and the inherent difficulty of standardizing complex data sets. As a result, my experience with government IT has been a bit like looking through a kaleidoscope, where each organization has added its own, uniquely colored shard. Through this kind of lens, a piece of information may be inaccurate, lack context, or simply be invisible. It’s an unreliable kind of transparency.