Shared Services and Exit Strategies

“Life is pain, Highness. Whoever tells you differently is selling
something.”
– Man in Black, “Princess Bride”

If you’ve been following my work the last year, you know that I’ve been
thinking about the different kinds of friction that plague an IT shop. Vendor lock-in, cloud lock-in, data lock-in, the cult of the product, and technical debt all conspire to keep us away from options that could improve our work. Over that time, the idea has started to resolve into the general notion of an exit strategy.

The idea is that if we spent as much time evaluating the exit strategy as we did evaluating the entry costs of a particular technology, we’d be able to avoid the worst of these lock-in traps. Unfortunately, exit costs are grossly undervalued under the current contracting rules.

Imagine how excited I was to see the CIO Council’s “Shared Services Implementation Guide“, which was released last week, spend paragraph after paragraph on the topic. You would think I was excited about the CIO Council’s mention of open source, open standards, and interoperability – and I am. The mere mention of open source and open standards in official guidance was once a lightning rod for controversy, but it’s presented here in a pragmatic, utterly non-controversial way. Both open source and open standards are simply tools that make it easier for agencies to provide and receive shared services.

But it’s their talk of exit strategies that really captures my imagination. The elegance of the notion, and how it can draw out some of the real benefits of openness and collaboration, is a great way to demonstrate the value of open source without sounding like an ideologue.

Specifically, here’s my paraphrase of the more interesting exit strategy
guidance the CIO Council provided:

Put someone in charge.

Dan Risacher has written about this a number of times. An appalling number
of systems in government have no party that’s directly responsible for customer satisfaction, the vendor relationship, or both. Relying on contractual obligations alone is a terrible idea: you’re not buying a product, you’re outsourcing a business function. Making a party directly responsible for the proper delivery of services is a great idea.

This recommendation is great for open source, too, because open source’s
greatest enemy is complacency. If there’s no incentive to improve services,
there’s no incentive to seek out better and cheaper alternatives.

Make sure you own everything.

Secure as many rights as possible to the work you’ve paid for. If you don’t, the contractor building or providing your system will have a functional monopoly, which naturally increases your transition costs. Government-purpose or unlimited rights, though, give you option to share, collaborate, and compete technology. Naturally, that makes for a larger ecosystem, more providers, and more options. You can read a lot more about this in the DOD Open Source FAQ.

This is the personal mission of My friend John Scott. It drives him crazy when he sees the government pay millions of dollars for software to be developed, just to watch the vendor resell all that government-funded technology to another agency. Ensuring government rights to the systems it paid for is a great first step towards solving this problem.

Keep an inventory of your assets.

Almost as bad as not owning the technology you paid for is paying for technology you can’t find. Far too much technology, especially software, ends up on a DVD in a filing cabinet in a program office, and not up in software repositories where it can be made useful by other programs. The Air Force actually runs a software museum to this end. forge.mil, and the products like CollabNet and Github can all help make this government-funded work more discoverable by other agencies looking to solve the same problem.

Secure the data at rest and in motion. Delete correctly.

One you have an accurate inventory of your assets, you want to make sure your incumbent can securely and swiftly move that data to a new provider. If they can’t, all the safeguards and open standards in the world won’t help you.

The cost of transition should be borne by the incumbent.

This is the most important item. I don’t think I’m responsible for it, but it’s a pet project of mine. The true cost of services, which should include the opportunity costs, is distorted when vendors provide low up-front costs and then force you to pay through the nose to leave. In order to truly understand an incumbent’s cost, you have to put them on the hook for your transition. Instead of making any new entrant pay to move all your data and retrain your folks, unnecessarily raising the bar for cheaper alternatives or new approaches, make the incumbent pay for it. That puts all the incentives in the right place.

You’ll notice that nothing about this guidance on exit strategies is necessarily specific to shared services. That’s because the economics of an exit strategy are the same, however a service might be delivered. Everyone needs interoperability, lower costs, and more competition in their IT systems.

Transitions, like life itself, can be painful. There’s no way to guarantee painless exits, but we can stop pretending that those exits will never happen. By putting these rules in place, we can make them much easier and make ourselves much more available to newer, better options as they arise.