Breathing New Life Into Shared Services

This article is the third in a series that examines case studies and model architecture for GaaP (government-as-a-platform).

Government-as-a-Platform (GaaP) is an expression of how technology trends such as cloud computing and API based software can enable more flexible, responsive and efficient government. One benefit of GaaP is that agencies can move away from their traditional towered approach to managing information technology and instead leverage shared and composable services offered from a universal platform.

Shared services is not a new concept — it has been used by various government consortia for years. But in many cases they have become synonymous with centralization, slow application development processes driven by conflicts over requirements, and grumbling about the costs of legacy infrastructure used to support shared services. GaaP is a more decentralized concept and seems likely to breathe new life into shared services, in two ways.

First, more applications will be built from composable services, reducing delays and encouraging out-of-the-box code. Disputes over requirements are therefore relegated to the margin, and participants in the shared services consortium can weigh their own need for modifications. Second, virtualization and cloud technologies will reduce costs by using the infrastructure more efficiently and centralizing systems administration and support tasks. GaaP will also make pricing fully transparent. Agencies will see what they get for their money and will be in much greater control of what they’re spending.

By making it easier for governments, or agencies to share platforms, GaaP shared services promises to enable the collaboration and data sharing needed to achieve “joined-up government.”

The idea of sharing services applies at several levels, ranging from infrastructure as a service (IaaS) to application sharing, or software as a service (SaaS), to cross-agency consolidation of functions and streamlining processes across various lines of business. Examples include CalCloud, an IaaS platform open to all public entities in California; Denmark’s NemID, a shared and unified login service for citizens across all public agencies; and GOV.UK, a shared web portal for all government entities offering over 400 shared services that have collectively saved about $750 million. Sometimes, shared services are becoming part of the national infrastructure, much like highway systems, rail systems, ports, bridges and telecommunications. The national social information exchange in Belgium’s Crossroads Bank, for example, provides secure interoperability for hundreds of social service organizations, and Estonia’s X-ROAD middleware infrastructure integrates government agencies, banks and telecom companies.

In thinking about a GaaP-enabled approach to shared services, a number of considerations apply:

Governance: With large shared services initiatives, it may be desirable to create a separate entity as Canada, for example, has done with Shared Services Canada. This organization may, of course, use existing government computing platforms if they are suitable. It may or may not be for-profit.

Scope: In some cases it is reasonable to expect a shared service to provide all the required functionality – processing for simple licenses like dog tags, for example. In other cases, and especially for mission critical activities, it may be desirable for a shared service to focus on the core functionality rather than responding to all customer needs and becoming so large and complex that it starts looking like a legacy application once again. Each user agency could provide additional functions to meet their own unique requirements.

Platform: The GaaP concept spans public and private (and hybrid) clouds and, where required, legacy non-cloud infrastructures. This is important. Some of the services that agencies might want to share are best suited for the private or hybrid cloud, and others for a public approach. An example of the former might be a shared content management system that underpins the case flow of multiple agencies; and examples of the latter would be e-government portal or e-payment gateway services. Most GaaP services can be made to appear as cloud services to participating agencies irrespective of whether they are run in a private or public cloud or in traditional IT data centers.

Segregation: Shared infrastructures, sensitive or regulated data — including run-time and archived data — must be properly segregated from unauthorized users. Security solutions offer capabilities to help protect cloud-based customer information and intellectual property from both external and internal threats. These solutions help prevent unauthorized changes to sensitive cloud-based data by privileged users.

Standards: In many cases, governments may be using a range of legacy systems and technical standards that are difficult to replace. But many of the newer collaborative or interoperable services that GaaP users will want to access can be based on newer and perhaps open standards. GaaP will need to strike a balance between already accepted technical standards and product choices and these newer standards. The goal is to encourage standardization and reduce the need for opting out of the delivery model. The approach to GaaP must be vendor- and product-agnostic and be able to interact with external “anything as a service” (XaaS) offerings or with internal shared services.

Catalog: If public or private sector organizations are to reuse services created on or supplied from the shared services platform, these need to be catalogued and their metadata made accessible to enable users to link and deploy them. The catalog may also need to include a shared library of event-based policy rules that are relevant to government’s ability to serve citizens. The catalog app itself becomes the core of a shared service arrangement.

Composability: One issue with older, monolithic applications is their sheer scope invites debate and disagreement over functionality, and another is that data is “locked in” and hard to share. GaaP shared services allows these legacy applications to be broken apart into reusable modules, or services,   accessible to multiple lines of businesses.

Transition: Depending upon the significance and complexity of a shared service, there may be a need for extensive investment in transition management, documentation, leadership and training.

GaaP offers the flexibility, responsiveness and efficiency to breathe new life into the concept of shared services for government. While there are certainly issues to be considered, agencies can now reap the benefits without losing control over their own systems and processes. Through GaaP, shared services’ time may finally have come.

Peter Williams is chief technology officer for Big Green Innovations at IBM, where Jan Gravesen is client technical leader for California and Trinette Brownhill is information architect for Government Industry.

(Image via Lightspring/Shutterstock.com)