[Intelink-U mirror]

I’ve had a “lightbulb moment” about the problem with the acquisition of IT systems in the Defense Department. The flash was so blinding that several of my co-workers have now filed for disability benefits.

Like most blinding-flashes-of-the-obvious, the insight was that the question was wrong.

Let me lead up to it: Beth McGrath (the DoD Deputy Chief Management Officer) famously testified to Congress:

Our current approach to implementing IT systems takes too long, costs too much, and often fails to deliver the performance improvements we seek. On average, it takes 81 months in DoD from when an IT program is first funded, to when it is fielded. Given the rapid state of improvement in the IT field, this means that we are delivering systems that are outdated before we ever turn them on. In contrast, the iPhone took two years from concept to delivery. It is clear that we need a different approach.

DoD personnel are completely fascinated by, and oriented towards, buying systems. Here’s the problem: in today’s world, most IT systems exist to implement a service.  There are not even words in our government lexicon for this; it is hard to even ask the right questions. A “system” is just a tool. It exists to make some task easier or possible. Operating an IT system is often complicated; it requires specialized expertise and there’s more to providing a service than is immediately apparent.  By itself, the operation of an IT system could be a service, but really it’s the mission function that the system enables that is the actual service being provided. “Running ATAAPS” (Automated Time and Attendance Production System) is a service, but it’s not running the software application that matters – the real service is timecard processing and reporting.

Sometimes IT systems are acquired as tools for users, just like buying a HMMWV, but most of the time, a government IT system is just the backend implementation of a information service.

Here’s an example:  MediaWiki is a “software application”.   If I take MediaWiki, and I install it on a server, and connect it to a database, I have a “system”.   There is a 146-person not-for-profit organization called the Wikimedia Foundation that runs a service called “Wikipedia“, which is a global, knowledge management service.  Providing this service involves putting MediaWiki on a server (many, actually) and administering the system.  It also involves securing the system against cyber attack, updating the servers, updating the application software, writing documentation and training materials, managing the user community, collecting metrics, analyzing metrics, fund-raising, replicating SANs, curating content, buying new servers, strategy formulation, disposing of old servers, policy development, integrating load-balancers, optimizing cache servers, failing-over to backup systems, resolving disputes, and notifying users of planned outages, trademark and copyright enforcement, trademark and copyright infringement defense, conference organizing, advertising, and holy-cow-does-it-ever-stop?!

If you hired a DAWIA-certified Level 3 acquisition professional as the PM for a Enterprise Service, he or she would be trained in program management, requirement analysis, cost-estimation, contracting, test & evaluation, systems engineering, etc.  He-or-she would not necessarily be trained in any of the operational things it takes to provide an enterprise service (see list above.)

Lest you think this is too far afield from the world of Government, let me point out that Intelink operates MediaWiki on Unclassified, Secret and Top-Secret networks as an award-winning service-of-common-concern called “Intellipedia“.  Operating Intellipedia requires pretty much all the same activities as running Wikipedia.

Aside: The Defense Acquisition System (i.e. DoDI 5000.02) has specific policy on the Acquisition of Services (Enclosure 9), but that doesn’t begin to address the gap between “acquiring a service”, and “providing a service”.

There is a vast chasm between “buying a system”, and “providing a service”.  The first step for acquiring an IT system should be: determining whose mission is it to provide that service?  If there are only have vague answers to this, then the proponents should stop; right at step one, and figure out the DOTxLPF (i.e. the non-material) parts of the solution first.  Does the Doctrine allow this mission function to be performed as a service, and if so, what Organization has the responsibility to provide it?  Do they have the Training, Leadership, Personnel and Facilities to provide the service?

I have some painful and instructive examples to illustrate this, but this post is already too long, so I’ll write about those separately.

[followup 1][followup 2][followup 3]