August 1, 2011 By Brian Heaton
Before a permanent change in systems development can happen, analysts agree that the budget cycle and procurement system, particularly that of the federal government, need to change. Specifically government agencies need the flexibility to employ technological changes as they occur, which runs counter to the federal budget cycle that’s essentially a three-year look ahead.
Di Maio said while changing the status quo in the procurement process is likely a difficult transition, it was crucial in order for government IT departments to add value in mission-specific areas, rather than spending resources on infrastructure. “There has to be greater scrutiny in approving spending, more effective portfolio management to prioritize requirements, and ways to promote and enforce reuse and cooperation,” he said.
“The federal budget … is a much longer cycle than the pace of innovation and technology,” White said. “How do we improve and evolve the procurement process … to maintain the control, but also to reflect the fact that I have to be able to move in small increments more frequently?”
In addition, state laws, regulations and state leaders’ overall mindset may need to evolve to accept the new model of consolidated IT implementations and shared systems instead of proprietary ones, according to Michigan’s Behen.
“Some of the states have different rules, and we need to get through that as quickly as we can,” he said. “But let me be frank, there’s [also] some control issues. Some say, ‘I have it in my state; my state does it best,’ but the current climate is turning more toward not having that kind of barrier.”
Fletcher had similar thoughts, adding that business-minded folks in government need to change their tune. He explained that if a state went to the federal government and said it was building a Medicaid Management Information System (MMIS) from scratch, the feds would kick in 90 percent of the cost. But if you want to adapt an existing system and combine it to serve as an MMIS, the federal government won’t contribute nearly as much money.
This is one of the issues the federal IT officials are aiming to change.
“The problem [the federal CTO and CIO] are experiencing is that they have to get the [U.S. Department of Health and Human Services] to relax those rules and understand that or incentivize the states to do things differently,” Fletcher said. “You have to get the business folks [on board].”
Another hurdle to reusable applications and shared systems is data security. For states to embrace the open data trend, it will require a higher level of comfort and trust in putting what some may view as sensitive information in the cloud for developers to access.
Behen said that education about the cloud and data privacy help remove the hesitation of some local and state governments to get on board with open source development and collaboration.
“A lot of people don’t understand that the stuff they are doing every day on the Internet is in the cloud,” Behen said. “I challenge … governments that data isn’t all that sensitive. We’re too conservative about that, and we need to challenge conventional wisdom on this stuff.”
Despite the roadblocks, the more application-centered and multistate approach has spurred quite a bit of activity among state and local governments in the past couple of years.
Utah has a few irons in the fire. The state consolidated its data centers and virtualized all of its servers, resulting in a 25 percent savings in operating costs. Then Utah opened its state data center to other government, offering to host data and applications for cities, counties and other local agencies.
Fletcher said the state is hosting data for three school districts and a university hospital, but negotiations are under way with six local governments to provide services.
“We are offering services to them to host their data at cloud rates,” he explained. “It’s cheap storage, cheap processing, and we host all of their applications so they don’t have to have a data center or servers.”
Additionally Fletcher said Utah was considering the most feasible way to acquire a new MMIS. He explained that although the optimal scenario would be a regional approach where multiple states use one system, it’s much more difficult than it sounds. An MMIS pulls data from many areas from a state’s data stores, which complicates joint usage and increases the customization and cost such a system would require.
Though still interested in the regional approach, Utah is looking to take parts from other states’ MMIS models.
“We’ve got great discussions [going] with Washington, South Dakota, Michigan and Maine,” Fletcher said. “Each of those states are in a different evolutionary point [with their system development], so we want to get the most mature and reliable one out of each of those states so we can adapt it.”
Michigan is in the infancy stage of partnering with the federal government on a consumer financial protection bureau. If developed, the bureau would be a cloud-based solution that would work with attorneys general to catalog and route complaints and issues to the appropriate personnel.
The idea was one of many collaborations Behen and his staff discussed with Chopra at a meeting earlier this year. Another proposal dealt with Michigan taking part in a health insurance exchange committee.
Although Behen stressed that the two sides had just exchanged points of contact on the cloud-based bureau, he was confident that once it starts to develop, all states could join the program.
“We’re still trying to connect with Aneesh’s team to finalize what [the consumer financial protection bureau] will look like, but if you think about it, all attorneys general across the country are doing the same thing, but probably are using different systems to track that stuff,” Behen said. “So it only makes sense to do it [as a multistate initiative].”
Cities are also getting into a more modern IT approach. Various municipalities are transitioning to cloud-based e-mail and operating under the infrastructure as a service model, and some are bringing in outside personnel to develop apps that can be used by all government entities.
Code for America, a nonprofit that pairs Web developers and cities to create Web apps for citizens, has projects under way in Seattle, Boston, Philadelphia and Washington, D.C. The difference from a typical contractor situation, according to Jennifer Pahlka, founder and executive director of Code for America, is that applications are built without an endgame in mind.
“Government contracts normally require that you know all the functions an application will have and every feature on the front end,” Pahlka said. “But if you look at the platforms developed that had great success in the consumer world, that isn’t how they’ve developed. They’ve started small and evolved to be what people want them to be.”
In Philadelphia and Seattle, Code for America development teams have created platforms to let citizens start initiatives and connect with the city government to solve problems. But unlike conventional app development, anyone can contribute or take the code as it’s being developed. Pahlka also cited Code for America’s contract with the U.S.
Department of Labor as a good example of a new approach to app development. The nonprofit helped devise a jobs database for U.S. veterans instead of building a $40 million one from scratch.
“Our contract is one-one hundredth of that amount,” Pahlka said. “We can build something that helps veterans get jobs, but … we can use [APIs] from Monster.com and other job sites. For us, it’s a success story because we think it is a much better use of taxpayer dollars.”
You may use or reference this story with attribution and a link to