Government’s problems aren’t off-the-shelf, so why would their solutions be?

The public sector’s continuing desire to minimize its investment in custom software is a laudable goal. There’s certainly no shortage of failed or failing software projects in government one could point to illustrate the inherent risks of ground-up development of software solutions. However, the pendulum in many organizations may have swung too far towards off-the-shelf solutions; straight past the real answer of platform standardization. The reality is government organizations have, in many cases, fairly unique requirements for which there really is no suitable off-the-shelf solution.

One of the arguments frequently circulated for off-the-shelf software is that they embody best practices and the implementing organization should change its processes to match the way the software was written to work, rather than the other way around. On its face, this seems like a pretty compelling argument, but ultimately requires one to ignore the ground truth of government requirements: They’re often dictated, not developed. Requirements stem from a wide range of regulations, policies and guidance related to what an agency must do and what information it must capture. In addition, an agency must possess the ability to address an ongoing stream of ad-hoc information requirements from Congress, OMB, GAO, the Inspector General, and agency leadership which often drives a set of information and technical needs that represent a wholesale change from the private sector.

Another common argument that is often made for off-the-shelf solutions is that when it comes to information and process management, ‘data is data’. But off-the-shelf in most cases doesn’t enable one to readily configure a solution’s data elements, add more elements, determine where they should lie in the user interface, and what actions to trigger when a user hits the ‘submit’ or ‘save’ button. These customizations often represent requirements around and beyond simply managing a piece of data.

The most common argument however, is the cost, risk, and track record of custom developed systems. True, if one reviews OMB 300 submissions it won’t take long to find investment levels in what would seem straightforward solutions that make one gasp – such as one agency’s public comment system. However, determining that an agency could simply use an off-the-shelf solution to meet the same requirements is often also wrong. Off-the-shelf solutions, when applied in government, have a tendency to address 100% of the mental objectives but only 20-50% of the actual functional, information, and security requirements.

In most situations, application and database platform standardization represents the best approach for reducing implementation risk, achieving desired efficiencies in development and operation, and addressing requirements that simply can’t be ignored. With a set of platform standards associated with content and data management, workflow, reporting, and user interface for example, an organization can readily leverage common infrastructure, resource skills, and authoritative information sources. Additionally, the organization maintains the ability to customize and configure these components while minimizing many of the common pitfalls associated with pure custom development, such as lengthy delivery schedules, poorly written or buggy code, limited or no APIs, and shallow technical documentation.

Frequently, the best way for an organization to get the best of both worlds is to embrace platforms upon which they can create and customize function and problem-specific capabilities. As federal leaders continue to move towards shared and cloud-based solutions and environments, they should look closely at the concept of Platform as a Service (PaaS) providers as more strategic architecture components over a plethora of specific cloud-based solutions.