Enabling government Web services
Jim Willis, the chief geek in the Rhode Island Secretary of State's office, has a vision for government data:
It is simply unacceptable at this point in history that a citizen can use web services to track the movies he is renting, the weather around his house, and the books he's recently purchased but cannot as easily monitor data regarding the quality of his drinking water, legislation or regulations that will directly impact his work or personal life, what contracts are currently available to bid on for his state, or what crimes have recently occurred on his street.
The quote from an announcement of a new service from Rhode Island called GovTracker. GovTracker provides RESTful access to public information in Rhode Island. Now, mind you, this is just a start, specifically the data that the Secretary of State is responsible for including Board/Commission Memberships, Corporations, Elections, Lobbyist Registration, Rules and Regulations, and State Directories. The service includes a large collection of methods for querying these data sources, collectively or separately. By default the data is returned as an RSS feed.
When I was Utah's CIO, I published a set of principles, which I called the Web Services Manifesto, that I believed every government agency ought to follow whenever they build a Web application. I also wrote a longer white paper on the idea entitled "Enabling Web Services" (PDF). The idea was to liberate data from its silos at minimum expense. I still believe its possible to do and would yield significant benefits.
Still, as easy as this would be from a technical perspective, there are significant hurdles. To see why, let's return to the GovTracker story.
The announcement was covered by Government Technology magazine, whose tag line is "Solutions for state and local government in the information age." To show you how far we are from what Jim has done in Rhode Island being universally adopted by cities and states the second paragraph reads:
A Web service is a mechanism that allows separate software applications to share data over a network. The Internet is such a network. Web services can enable a high degree of interoperability. With Web services, different software applications can share data despite being on different operating systems, platform environments, and written in different programming languages.
When your audience is government technologists and you feel obligated to describe what a Web service is in 2005, you know you're in trouble.
This remains a big problem. Many government technologists, particularly the older ones in management positions, are stuck in a world that so far removed from Web services that it's difficult for them to catch the vision. However, having worked inside government IT, I'm confident that this will change in time.
Maybe more important is for legislatures to catch the vision. Now, I don't expect them to start demanding RSS and SOAP, but I do think they can be educated to ask for, and fund, more holistic approaches to putting data on the Web. Right now, government Web applications are mostly limited to spot solutions, but some public officials, like Matthew Brown, the Rhode Island Sec. of State, with the help of technologists like Jim Willis, are seeing the benefits of putting data on the Web wholesale.