Why SaaS should scare government IT managers

The scares of Halloween 2012 are well past now, but there’s still time for agency IT teams to hear one more tale of technological terror.  For government IT workers, there are few words more spine-tingling than an agency CIO demanding the implementation of a software-as-a-service (SaaS) solution.  Agency IT professionals are hard to frighten, faced as they are with the looming “fiscal cliff” and years of budget cuts, but the dangers inherent in SaaS are enough to turn even the most hardened systems administrator’s hair white.

What’s so scary about the big bad SaaS monster?  And is it something that IT teams should bar the proverbial door against, or do they need to face their fears and deal with SaaS warts and all?

Before delving into the SaaS Pit of Fear, first consider why agency CIOs are so interested in the technology, at least from a consideration (if not implementation) standpoint.  The primary purported benefit of SaaS is cost savings, as expensive and time-consuming custom application development is not needed to deliver the same functionality.  There is also the perception that SaaS is “cloud,” and everyone knows how important buzzwords can be higher up the chain of command.

For IT professionals, however, these benefits are fleeting at best, leaving agency IT teams with a mess of epic proportions to handle on their own. From loss of control and poor integration with existing systems to the potential impact on government IT jobs, the downsides to IT of SaaS are far more detrimental than any short-term cost-savings or “cloud readiness” could be.

Technological terrors

The biggest fear agency IT teams have with SaaS is the impact it could have on their careers.  At a simplistic level, SaaS is essentially outsourcing the running of an application to a third party, which makes much of a traditional government IT worker’s job irrelevant.  There are arguments that SaaS simply makes government systems administrators and other IT pros more “efficient,” but the fact remains that in order to realize the full cost savings of SaaS, cuts almost certainly must be made.

The outsourcing of an application’s lifecycle does much more than just cut federal jobs – it also greatly decreases the level of visibility into a given application.  For most agency applications, end users see only the front end, while the actual “tubes and wires” of an application are overseen and maintained by the IT staff.  With SaaS, only the vendor sees the back end, effectively holding end users and IT staff hostage when it comes to troubleshooting application issues.

SaaS’ promise of lower costs and enhanced “cloud-based” flexibility also do not stand up to close examination.  While initial implementation costs might be lower, what if a feature must be tailored to meet the needs of a specific agency? Or if organizational goals change, requiring a different set of criteria from the SaaS application?  This is where exorbitant change fees come into play – the first hit of SaaS might be free, but to actually customize the technology to meet agency goals, budgets will almost assuredly be broken.

From a flexibility standpoint, the vast majority of SaaS applications are a case study in vendor lock-in.  Once data enters a SaaS solution, there is no easy way to retrieve it. Essentially, any new project started outside the existing SaaS technology will begin at square one, which means major costs in terms of hours to months of lost man-hours for development and integration teams.

SaaS also is a challenge from an integration standpoint.  Because agency IT teams cannot see behind the curtain, they are essentially attempting to integrate an SaaS application with existing systems wearing a blindfold. Obviously, this can cause all sorts of additional problems, from corrupted data to massive network downtime.

Facing fear itself – working with SaaS

If agency IT teams have no choice but to face their fears, they need to understand the key metric behind forcing SaaS to work for their agency: uptime.  Because SaaS solutions are effectively hosted services, almost any government-focused SaaS technology will include a service level agreement (SLA) for a specific amount of uptime.  It’s vital that IT teams monitor the end user experience to ensure that this SLA is met, as it is likely the only way any of the SaaS perceived cost-savings can be achieved.

Moreover, SaaS works only if monitored correctly, and since IT teams have access only to the front end of the application, they must do everything they can to act as watch dogs for the user experience.  If monitoring lapses and downtime occurs, systems administrators will get the heat, not the SaaS vendor – unfair, yes, but a harsh reality of the SaaS world.

Scary story, happier ending

When the notion of SaaS and, by default, cloud computing are brought up in agency technology discussions, IT teams should be quick to point out not only the limitations of SaaS, but also alternatives to it.  These could include other members of the everything-as-a-service family such as platform- as-a-service and infrastructure-as-a-service, both of which provide greater visibility into the application layer, or even an agency-owned private or hybrid cloud.

Thanks to the government’s push for greater IT efficiencies, federal private clouds are no longer wishful thinking.  The Defense Information Systems Agency’s private cloud efforts are moving forward, while FedRAMP also is poised to turn even more federal cloud computing possibilities into realities.  When it comes to SaaS, the cloud isn’t the problem – it’s the service.

No matter the cloud-based solution selected by an agency (and the cloud is no longer just an option, but an inevitability), federal IT teams need to be ready to manage and monitor operations, potentially with limited visibility across layers.  By utilizing best practices and emerging tools in network management and encouraging agency CIOs and other decision-makers to select “IT-friendly” cloud solutions, IT teams can put an end to scary monsters, whether in the server closet or on the network.