In the last decade or so with Salesforce.com leading the charge SaaS has made deep inroads into every area of commercial business software. Starting with Sales applications then moving into other edge applications like Collaboration, Project Management, Document Management. In the last couple of years even core business processes like Human Capital Management (SuccessFactors) and financial management(Intacct) have been not out of bounds. While private sector has tremendously benefited from the move towards SaaS, Government agencies have been a mere spectator.

Late last year, I was working on a deal to sell our SaaS software to federal government. Being a SaaS company, naturally we were in a quandary. Up until then we had stuck to the core SaaS edict – i.e, maintain a single code base and all customers hosted on a multi-tenancy based deployment. Despite all the challenges we ran into from technology, architecture and operational issues, we had persisted. There were times when we debated on the question of  segregating customers into Small, Medium, Large multi-tenant instances. But we resisted and persisted. We invested large amounts of time and resource required to put out all the fires/challenges, make the requisite scalability related improvements and kept going with a single instance.

But this deal with the government was different. It was a large multi-million dollar deal which was tough to walk away from. What with the financial meltdown upon us and the prospect of a bleak 2009 being forecast.

As we had imagined, the federal government agency required their own instance and a on-premise installation at that. Considering the information they were going to manage in our product, I could see why it made sense for them host it and not co-mingle (their words) their data in a publicly accessible internet based application.

The deal we were trying to secure was with one particular agency and the usage was going to be limited to that agency. We had an elaborate RFP process that ran for more than couple of months – many many spreadsheets to fill with information and multiple demos to the primary contractor and in-house staff.

But with all the recent focus/news on Federal IT, federal CIO/CTO nominations, Recovery.gov and the talk about government agencies better leveraging technologies, I could not help but think of how SaaS would be the PERFECT model for deploying applications within the government. Various agencies can form tenants of the single instance and derive the inherent benefits. While there could be numerous other benefits here are 4 clear ones I could see federal government agencies could gain from by having their own SaaS deployment.

Master Data Management
As with the multiple business units in a large conglomerates, different federal agencies share common information across multiple agencies. Real Estate Properties, Approved Vendors, Approved Items, Locations, Technology Sourcing and the list can go on. With a multi-tenant SaaS model, all these master information entities and the related transaction can be managed in a single database, with appropriate access controls. This would eliminate all the redundant integration and data replication needs between different agencies and it could serve as a master data repository. All the reporting needs can be met from this single repository for a single agency and rolled up across all agencies.

Provisioning and Identity Management

While in recent times, government agencies have increasingly adopted Identity Management solutions, they still manage the identities in disparate directories. An internal on-demand solution hosted by a central IT agency under the Federal CIO can effectively streamline the identity management needs across agencies and serve as the provisioning clearinghouse for all the applications. If and when a agency employee transfers across agencies, it would merely be a change in access control as opposed to the entire provisioning work done across both the agencies (to revoke and grant access).

Collaboration

A single multi-tenant collaboration solution would not only standardize the way processes are followed across agencies, it will allow them to leverage best practices across agencies. I would put Project Management, Document Management, Communication under this bucket.

IT Infrastructure and Operations

Having a single instance would eliminate the need for redundant infrastructure needs for backup, recovery, redundancy infrastructure (for fail-over), hardware, software licenses, security assessments. All the upgrades, quality tests, user acceptance can all be conducted under a single installation.

All the management applications needed for governance i.e., change management, configuration management will also need to be done once.

Last but not least, the resources required to manage multiple implementations of software across agencies can now be deployed to perform incremental IT needs.

Who else would benefit from this?

SaaS Technology Vendors: Government sector has been off limits due to the resistance of government agencies to use any software outside their premise. With a dedicated instance hosted for government agencies or a hosted version on their premise (hardware), now the 70B+ spend is a new market segment SaaS vendors can go after.

Prime Contractor: You should strategize with a SaaS vendor to become the reseller of their SaaS offering with a government flavor. You can be a turnkey operator to manage hosting, provide managed services for provisioning, upgrades, custom integrations. Also being knowledgeable of the government processes, government contractors can now turn their knowledge into best practices for agencies.

What should a SaaS vendor be prepared for?

Brace for discussions that will question the very premise of your business model. While NIST comes up with the standards for SaaS security and performance, each RFP will be onerous to say the least. The numbers will be large. Government does not understand the monthly subscription business. They throw money once and buy things they want and as is their wont and would look to customize the application. It will take some time before they digest the fact that they are buying usage and not custom application capabilities as in the past.

Be prepared to hear the following

1. “Government does not want to store its data outside their firewall.” This should not come as a surprise to you considering all the critical data they seem to store. So to counter this you have three options
   • Create a hosted instance or an appliance on government network and you manage it just like your commercial offering. This might mean you need to have dedicated resource managing that instance and in some cases they will need security clearance. So factor that in your quote.
   • Host the application with database managed inside the government network. This entirely depends on how your Multi-tenancy architecture or product architecture is designed.
   • Let government host and support a copy of your product. You provide updates. (this has caveats based on 2 below)
2. Government would like to customize the product to their need. This customization could be anything for changing the application flow to building extensions in the form new UI+ Data capture or security model changes. To accomplish this they would need access to the source code or you exposing all the underpinnings of your application in the form of a SDK or API. Government is big on SOA so have your SOA story ready.  I would strongly urge you to push back on any request for source code. If you are working with a prime contractor, chances are they might be the ones perpetuating this need for source code more than the government. SIs make their living by customizations and long implementation cycles so it is their DNA. Eventually you might have to succumb and agree to part with your source – part of doing business with Uncle Sam.
3. Source Code and Who owns it: Extending the point from 2, if you do part with your source code, get your legal to draft verbiage around who, where and how the source code can be used and what if any, attributions you need out of the code changes they make. Also highlight the fact that if they make changes to the core product, they will do that at the risk of precluding themselves from getting further updates from you. At a minimum they will require a source code escrow.
4. Accreditation with government standards like FISMA, NIST.
5. Location specific storage: If you manage to convince government to use a hosted instance owned by you, then you will run into requirements like storage being done within the boundaries United States.
6. Preferred Customer pricing

SaaS is based on the premise that deals come in short sales cycles. A government deal is a anti-thesis to that – long drawn out and expensive. If you have gone through a similar process, shoot me an email, I would love to compare notes with you.