Government as a Platform: Putting the Pieces Together
The building blocks of GaaP are based on eight capability patterns.
This is the final article in a series that examines case studies and model architecture for government as a platform, or GaaP.
Government as a Platform is both a consumer and provider of services. As such, it is encased in an API layer that is able to consume services and data from a variety of sources, deliver shared services to agencies, and provide services to third parties.
The interlocking building blocks to support GaaP can be based on eight capability patterns:
Exchange. The exchange pattern provides interoperability among agencies and between agencies, external services and data sources; in GaaP, the exchange pattern is implemented as a shared system of interaction.
Federate. The federate pattern is a special instance of the exchange pattern and highlights that GaaP is not a standalone system. Instead, it is an overlay on existing data and services, which must integrate with (rather than replace or duplicate) existing standards and services frameworks. While GaaP can provide a shared security access framework for a group of government agencies, it may also simply leverage one that is already in place, using open standards.
Coordinate. Coordination and joined-up government rely on the exchange pattern, which allows the exchange of standardized data among government agencies, is supported by data exchange protocols, and depends on the availability of appropriate business application services and workflows that allow agencies to come together and form multi-disciplinary teams; therefore, the GaaP must contain at least one shared system of coordination (SSoC).
Engage. The engage pattern delivers government services to constituents in a unified and consistent manner across channels and agencies; it adheres to the “no wrong door” principle. Previously, it may have been sufficient to have a single, multi-purpose portal, but with the widespread use of mobile devices, the engage pattern unifies Web, mobile devices, call centers, instant messaging, and video conferencing and leverages the exchange pattern to connect channels to the coordinate pattern.
Share. The share pattern comes into play when GaaP is used to deliver shared services to government agencies, irrespective of whether these services are of a business or technical nature. Examples of shared business services include accounting, finance, human resources or procurement services, while examples of shared technical services include application management, mobile access, analytics, or connectivity services, to name a few. By definition, GaaP will run on shared infrastructure, suitable for cloud.
Compose. The compose pattern allows external service providers and other government agencies to build new services on top of the ones delivered by individual agencies. The objective is to provide a single platform that makes it possible to combine services from across a group of agencies into new services; as a result, the compose pattern relies on the exchange pattern and potentially on the coordinate and share patterns.
Guide. The guide pattern is a set of analytical capabilities that provide a shared view of agency data as well as data on individual constituents, including an individual’s identity across government systems and programs. To comply with security and privacy laws within specific jurisdictions, GaaP will often provide a shared consent management capability as part of the share pattern where users may consent to having agencies share their data. The guide pattern may also be used to provide such tools as cognitive “chat bots” through the engage pattern.
Protect. The protect pattern is focused on the protection and privacy of data stored in GaaP data stores, and typically is shared among many government agencies and departments. Examples include: life event management data; meta data that is used for agencies to coordinate efforts and exchange case information; demographic data that represents a single view of the citizen or business; personalization data; and rules data for targeting purposes and to determine eligibility. GaaP is not just API rich but also data rich, and its shared data must be protected according to applicable security and privacy legislation.
The patterns can be organized into a simple organizing model for GaaP:
Although we haven’t discussed it in detail, the protect pattern can itself be a shared service. Since GaaP promotes a unified protect pattern, it can deliver shared security services to agencies that participate in the GaaP and be used to regulate the use of agencies’ external services from cloud-based platform and software providers.
GaaP can be implemented in a variety of ways, but there is a natural sequence to how things can be organized. A high-level view of GaaP is best expressed through the eight capability patterns but also one that can be broken into a series of interlocking architectural building blocks, all of which are present today. The main challenge is not technical, but rather, political and organizational. GaaP is able to provide tangential value to agencies and their constituents—if there is political will behind it, there will be tangential, political return.
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.