The way Mark Schwartz describes IT projects in the federal government would probably make CIOs in Treasury Board and other parts of the Canadian public sector cringe. Although there are some obvious differences between our two countries, the bureaucratic barriers to innovation in IT sound like they cross borders pretty well.
“Our typical process is, we realize a need, then we wait until we can assemble a whole bunch of needs and call it a program,” said Schwartz, CIO of U.S. Citizen and Immigration Services (Department of Homeland Security), speaking at a Government, Education and Nonprofits Symposium hosted by Amazon Web Services two months ago. “The next step is acquisition oversight. It means we write about 105 long documents that no one ever reads and we put them in a filing cabinet.”
According to Schwartz, this approach tends to greatly lengthen what he called the moment of “mission need” to “deployment of a capability” far longer than is good for the organization.
“It’s on the order of years to decades. And I mean that literally; that’s not a joke,” he said. “Some of the requirements have been sitting there for 12 years. “I don’t think that’s acceptable.”
Watch the full clip below, or scroll down to hear Schwartz’s proposed solution.
The alternative, Schwartz suggested, is Continuous Delivery, a software engineering approach in which teams keep producing valuable software in short cycles and ensure that the software can be reliably released at any time. This is how he described it in practice:
- Take one requirement or a small batch of needs within the organization.
- Assign the requirements to the required number of Agile teams (who may be working under contract) to develop code,
- Use Continuous Integration to integrate code into a shared repository to get the work into production via a public cloud.
Citizen and Immigration Services has projects like this that now regularly deploys updates multiple times per day, while others deploy one or two times per week. He said the results are more secure and easier to patch. Beyond the technology, however, he suggested Continuous Delivery could be a way to stimulate more innovation from a wider group within the public service.
“If you ask around and talk to government people, you’ll find they have a lot of great ideas . . . but don’t feel empowered to do anything,” he said. “The public cloud and Continuous Delivery system can make the cost of an experiment so small.”
It would be exciting to hear from Canadian government officials who embrace a similar style of innovation using Continuous Delivery, especially since the arrival of more local data centres may make the public cloud a more viable option.