Is there a fit for SaaS in the government?
Given all the economic and government policy hoopla, it’s no surprise that some are tackling the issue of if and how SaaS can impact government IT. Clearly, government adopting SaaS has significant benefits with a dose of security related fears, but overall, I see the government leveraging SaaS as a net win. One thing that interests me more, however, isn’t so much whether government can benefit from consuming external SaaS applications like Salesforce.com, but instead, whether opportunities exist for government to leverage SaaS architecture for internal, “home brew” applications.
Let’s use the U.S. government as a discussion point. In 2005, the federal government was a sprawling institution of 3.3 million civil servant and military personnel with 10 million other works that were direct government contracts and “grant workers,” for a total direct and indirect workforce of 14.6 million people! Clearly, we haven’t included state and local government in this mix, but I think you get the picture; the numbers are staggering. These millions of employees leverage software every day. For many scenarios, generally available SaaS offerings like Salesforce.com will fill many needs, but the government ecosystem also requires a massive number of niche applications to help in very specific tasks. For example, consider managing parking tickets or traffic violations. Generally speaking, custom software would be used for this task. The internal market for niche applications is just as staggering as the raw employment numbers.
So how does SaaS play into all of this? Let’s consider much of internal government IT functions at this point. If some municipality needs a software package to manage traffic violations, it either (a) writes it or (b) contracts a consultant to write it and then runs that software on some server it owns or leases. The municipality next door has a similar need and pursues a similar path. You can extrapolate this process to many different municipalities, each with their own on-premises solution. The fact of the matter is, many will have the same or extraordinarily similar requirements when it comes to their traffic violation systems. What you end up with is a generally unnecessary gross over allocation of resources. Each municipality is maintaining infrastructure and code on its own, resulting in pressure on the IT budget, inefficiency in terms of delivery and maintenance, and general headaches.
These niche applications are completly warranted in terms of functional need, but can SaaS help with the delivery and save the government time, money and effort? Absolutely! SaaS is often overlooked as an intra-enterprise (i.e. private cloud) deployment model. For example, considering the common functional overlap for our traffic violation app, as well as the lack of strategic value associated with hosting the app themselves, municipalities would benefit from “banding together” or relying on a super-scope governmental body (think the county or state governments in the U.S.) and having the application written once and delivered as a service to each municipality. Furthermore, this model could be extrapolated to a number of applications, allowing the centralized management and delivery of applications, as well as governmental standardization. This would create huge savings for the government, allow for an unbelievably flexible sharing and deployment model, and get rid of waste. I’m excited to see SaaS architectures materialize within organizations as a viable model that changes the way these organizations write and consumer internal software.
What’s your opinion? Is SaaS only beneficial to the government from a consumption point of view, or is the
idea of leveraging the delivery model on a “private cloud” for internal applications equally (if not more) powerful?

(1 votes, average: 4 out of 5)



I do think there is a role for SaaS in the government. I think properly written SaaS applications scale better, deploy easier, and are more lower TCO whether its for the government or the private sector.
I might be slightly biased though…