US Digital Services

The newest thing, a legacy of the rush to fix the Obamacare website, is the US Digital Services.

Digital services' role "will stop when we get you to minimally viable project," Kruger said. The team can help define user needs, build in analytics, wireframe the user experience, deploy and test alpha and beta versions, and generally tune and refine a service to ensure it can serve the intended purpose. "When we're happy with that, we'll hand it back to the business unit, and they'll own it -- to maintain it, to make improvements over time."

"We're not going to be here forever," he said. It is up to the business unit to plan for ongoing maintenance and support, and "from the beginning, we're going to have that conversation."

I think there are some downsides to this idea, or at least there would have been in the old days of COBOL.  One downside was the difficulty of understanding what's going on and making changes to the code.  That was at least one rationale for all the documents produced in the old "waterfall" software development process: users and systems analysts were supposed to produce a lot of documents at different levels of understanding (data, system flow, etc.) which would then enable their successors to understand what was going on.  My own feeling/guess is that what happened when these documents were produced was the people involved learned the process by writing documents, so there was a reasonable base of understanding among enough people to be able to handle people retiring, etc.