Oil and Water: Incentive System for Government Programs and Systems Integrators

When contemplating the technologies and usage models for something like NCES, one has to consider two things. Firstly, why would someone want to utilize or consume a shared service? Where this seems almost a silly question on the surface, in the world of government procurement practice and specifically in the realm of DoD program management practices, there is some doubt and some explanation as to why many might not want to use shared services. We’ll ignore for the moment that the express goals and directives from the Secretary of Defense clearly declare Interoperability, Agility, Visibility and Transformation as a the tenets and mechanisms for the future US forces and their capabilities. Secondly, why would someone want to create a service that is then published and shared via a shared services infrastructure? Again, this seems a silly question, but a serious on nonetheless. The question at hand is: What is the incentive to either produce or consume a service? This author cannot find a compelling reason why anyone would take advantage of a shared services infrastructure given the current way business is done between the government and System Integrators. We’ll take each side of the question separately and we’ll construct a use-case that will illustrate how a shared services incentive system might work.

We’ll start with the case of taking an existing capability, standards-based service-enabling it (e.g. with WebServices) and then registering it to be used as GFE or GOTS by other programs. In all likelihood, this service will be developed by one of many Systems Integration firms that do business with the government. A primary aspect of their business model is to leverage past performance on a program in order to acquire new development contracts where they basically get to build nearly the same thing yet again. Which begs the question: If the capability they just built as part of some traditionally operated contract vehicle is now generic, service-enabled and generally available as GOTS to the rest of the DoD (or even the entire government) then what incentive does a System Integrator have to build it if they are unable to leverage that direct experience and charge dollars for hours to build a very similar service for someone else? It’s a long-winded question to be sure, but one that needs to be addressed in the business model for a shared services world. This author could imagine the situation where System Integrators would go out of their way to make sure that they did not build a service that was capable of being used in a generic fashion on a shared services infrastructure. It would help them protect their current business model.

Now imagine the same scenario with a slight twist. Imagine that once this fictional System Integrator built this fictional service and that service was registered as a shared service via NCES. Now, this service is then consumed by a number of other applications and programs providing greater efficiencies in time and cost. But, imagine that the System Integrator that originally built the service now receives continued revenue based on the usage of that service. This assumes that somehow there are mechanisms in place to allow a charge model for consumers of shared services. It is beyond the scope of this document to delve into the subject of how the government might craft such a “charge for the usage of shared services” model for the service consumers. Further imagine that that revenue gained from the consumers also benefited the original PEO that commissioned the shared service in the first place.

The question of why a program would use a shared service is somewhat more complicated. It largely revolves around trust and control. If a C2, ISR or perhaps even a weapon fire control system utilizes some shared service to perform a critical task, it places an enormous amount of trust in that service, the infrastructure that provisions that service and the people that built it. It is not trite to say that many lives, soldier and civilian, young and old, are in harms way and at high risk with some of these systems. The financial and budgetary reasons why a shared service might need to be used are not nearly compelling enough for the PM of a C2 application to utilize some shared service.

The most common and compelling reason why an application or program would want to utilize a shared service is because they cannot get the information otherwise. Examples of this include intelligence information, logistics information, as well as troop and equipment readiness data. What makes a shared services infrastructure such a compelling value proposition then is two fold. Firstly, the PM for this consuming application does not have to go out to each of the data sources and individually negotiate the details of how the integration between the two systems will operate. All they have to do is negotiate and encode the SLA and QoS with NCES. Secondly, there is a certain level of distrust between the consumer and the producer of information as there is no prior indication that the producer of the service will be able to deliver to the level of quality that is demanded by the consumer, and for very good reason as was discussed earlier; the service producer is not necessarily an expert nor has all of the appropriate infrastructure on hand to satisfy the consumer. This is where the NCES shared services infrastructure is strategically important. NCES should be able provide the appropriate level of assurance and trust that services it brokers will be able to satisfy the consumers SLAs and if they do not, then NCES should have the appropriate detection, governance and recourse in place to help the consuming application complete its mission.

This type of incentive system is a critical success factor. The ability to provide trust, adjudication, consistency and the appropriate business model will accomplish far above and beyond what any technology base, standards or set of products can provide.