Are Shared Services in The Procurement Mix?

At first glance, it seems that the value of a shared service environment for the federal government would be obvious. The process involves taking existing information technology (IT) capabilities and, through the judicious application of Service-Oriented Architecture (SOA), allowing those capabilities to be reused across departments and agencies.

Many people share that SOA vision within the federal government, especially the Federal Enterprise Architecture Program Management Office (FEAPMO)at the Office of Management and Budget (OMB).

The FEA represents the Holy Grail for efficient and cost-effective government procurement of information technology across the civilian, military, and intel-ligence communities, affecting both business and
mission systems.

Despite the need for a cross-platform, why isn't there a mad rush of integrators to create shared services and for contracting officers to require shared services as part of contract performance? Various reasons contribute to this lack of integration. To provide one solution, government programs can establish incentives to create an environment more favorable to the shared services vision.

Currently, the shared service cupboard is essentially bare. Overall, no open catalog of shared services can be reused across departments, agencies, and lines-of-business. This condition exists, even though civilian, military, and intelligence agencies all have initiatives to foster shared and reusable services.
The FEAPMO vision is to create "line-of-business consolidation" across the government to end the redundancy and waste created by duplicative payroll, human resources, and accounting systems.

The DoD Force Transformation initiative requires that major combat information and weapons systems make data and behavior available in a shared fashion as discoverable and consumable resources on the Global Information Grid (GIG), rather than perpetuating stovepipe systems.

In addition, the U.S. intel-ligence community has a mandate to share intelligence information across agencies, with the goal of helping our nation avert another terrorist strike. President George W. Bush has even issued Executive Order 13356 to promote information sharing.

Yet, why have these efforts failed to produce the expected inventory of shared services? The answer relates to system integrators (SIs), who generally have little or no incentive to build and deploy shared services.

Weighing Shared Services

When contemplating why federal SIs seem reluctant to fill the shared service cupboard to the brim, a number of basic questions surface.

First, why would someone want to use or consume a shared service? While this question might seem trivial to address, considerable doubt surrounds the motivation and ability of departments within government agencies to use shared services, especially in the world of government procurement.

One exception involves directives from the Secretary of Defense, which emphasize interoperability and agility as the foundation for the future of U.S. armed forces.

Secondly, why would someone want to create a service that is published and shared via a shared services infrastructure, such as Network Centric Enterprise Services (NCES)? Again, this question may sound elementary, but a serious one nonetheless.

The question at hand becomes: What is the incentive to either produce or consume a shared service? In reply, it is difficult to find a compelling reason why anyone would take advantage of a shared services
infrastructure, given the current way that business is conducted between government entities and the integrator community.

To provide solutions, each side of the question can be addressed separately, followed by a sample case that illustrates how a shared services incentive system might work.

For instance, consider the case of an existing capability. The next step is to service-enable that capability in a standards-based fashion (such as, using Web services), and then make the capability available for use as Government Furnished Equipment (GFE) or a Government Off-The-Shelf (GOTS) product by other programs. In all likelihood, an integrator will develop this service.

However, during service development, a primary business of integrators is to "trade dollars for hours." Integrators generate invoices paid by the government for hours spent by highly qualified technical personnel to create systems that satisfy the program's requirements. Integrators have traditionally resisted acquiring Commercial Off-The-Shelf (COTS) software and systems.

In practice, integrators purchase COTS or use GOTS only when they find it impossible to justify building it themselves. Also, a critical part of their business model is to leverage past performance on a program in order to acquire new development contracts, where they gain the opportunity to build nearly the same capability over, and over, again.

This phenomenon surrounding business models begs the question: If the capability integrators just
built as part of a traditionally operated contract vehicle is now generic, service-enabled, and generally available as a GOTS product to the entire government community, then what incentive does the integrator have to build it?

The integrator usually seeks to leverage that direct experience and charge "dollars for hours" to build the same service for someone else.

Expanding on Motivations

Various factors influence business models of public corporations operating in a shared services world.
Without being accused of touting a conspiracy theory, one could imagine a situation whereby integrators would go out of their way to build a service that was incapable of being used in a generic fashion within a shared services infrastructure, even if this compatibility requirement was part of the contract performance.

When considering service development, one might ask: Don't most businesses actually seek out opportunities to derive a better margin from a "repeatable" effort?

On the other hand, wouldn't any company try to protect its current business model? We cannot underestimate the tendency for a major integrator to be motivated by these realities.

In addition, since most large SIs are public corporations, officers who run these companies have a fiduciary responsibility to their stockholders. Moving to a "shared services" model in government contracting would constitute a significant change to their businesses, and the investors in these businesses would question this decision.

The "bottom line" is that large system integrators are not about to change their business models just because government officials think that shared services are a good idea.

Instead, the SIs should be offered something in return for giving up an important part of a highly lucrative business model that has been proven over a very long time.

Exploring a Test Case

For example, imagine a scenario where an integrator would be financially motivated to create a shared service. This service might be developed for a government customer, but its use might have a slight twist. Suppose this service is consumed by a number of other programs yielding substantially greater efficiencies for those programs. In addition, these savings, whether in time or money, would be measurable.

Finally, imagine that the SI firm which originally built the shared service now receives a continued revenue stream based on the usage of that service. Of course, just a portion of the savings would be forwarded to the integrator. For the sake of discussion, this cash flow will be called, "operations and management revenue."

Next, the SI firm that builds the service is responsible and paid to keep the service running. This condition assumes, of course, that mechanisms are in place to allow for chargeback or a fee-for-service model assessed to consumers of the shared services. Users would undoubtedly agree to pay for the service, because it saved them money, time, or both.

Although it is beyond the scope of this article to delve into how government agencies might craft a model to support "chargeback for the use of shared services" by consumers, public entities have dealt with this situation in the past.

Further imagine that the revenue gained also benefited the original Program Executive Office (PEO) that initially commissioned the shared service.

We can thus create a "budget sharing" model between government programs. This model could do wonders to advance the cause of the OMB and the FEAPMO.

The question of why a program would use a shared service offered by another program is somewhat more complex. Factors largely revolve around trust and control.

If a Command and Control (C2), Intelligence Surveillance Reconnaissance (ISR), or a fire control system for a weapon uses a shared service to perform critical tasks, the buyer and user place an enormous amount of trust in that service. This trust is directed to the IT infrastructure that enables the service, as well as those who build and harness the technology.

The importance of some systems created cannot be underestimated, since these systems may place the lives of many soldiers and civilians in harm's way.

Thus, the financial and budgetary reasons of why a shared service might need to be used are not nearly compelling enough for the program manager of a C2 application to justify using a shared service.

The problem of risk management around consuming shared services is extremely difficult and needs to be addressed further.

Changes Required

Before the sharing of services and information between programs and agencies becomes commonplace, a long road lies ahead.

Currently, shared services are enacted on a limited scale mainly because critical information necessary for some programs is unavailable by any other means. In this case, the infrastructure to enable "live" data connections between and among programs doesn't yet exist on a large enough scale.

Beyond the scalability and infrastructure improvements, a significant problem relates to the way
government agencies conduct the acquisition process.

For instance, the government buys technology similar to the way it buys trucks and bombs. As a result, current government fee-for-service mechanisms don't lend themselves to widespread chargeback policies for the use of shared assets.

To make government dollars stretch further, we can begin providing mechanisms for sharing budget dollars between programs that promote the use of shared services.

Otherwise, there is no way that government officials can have the foresight to budget various programs appropriately and allocate budget funds to a particular program for perhaps five years in a service sharing environment.

We require a more dynamic and fluid inter-organizational economic model. Furthermore, the government acquisition process needs to provide new compensation models for system integrators who are willing to sacrifice a traditional view of their business for the sake of sharing and efficiency.

Overall, the real challenge centers on addressing modifications necessary in the Federal Acquisition Regulations, as well as the Defense Procurement and Acquisition Policy. These changes require political will and an appreciation for the evolution of technology in Congress.

Modifications to acquisition policies will involve politics that will make the formation of the Department of Defense in 1947 and the Department of Homeland Security in 2002 seem trivial by comparison.

About the Author

Jeff Simpson is a federal architect at BEA Government Systems, Inc., where he handles Service-Oriented Architecture (SOA) projects. Simpson is responsible for developing SOAs that include next-generation application and data integration architectures. Before joining BEA, he was involved in several start-up companies near Washington, DC, in lead architect and director of engineering roles. Prior to these positions, Simpson spent 10 years as an independent consultant in Object-Oriented systems and architectures, directing projects at many Fortune 1000 companies, such as Texas Instruments, Boeing, Time Warner, and US Airways. He has been building distributed object systems since 1986, and he specializes in object databases and component-based service architectures.