nmedia/Shutterstock.com

How to Apply Government as a Platform to Different Classes of Systems

Integrating various systems of record, engagement and insight can pay big dividends in delivering public services more effectively.

When looking at how enterprise IT continues to evolve, it is increasingly common to refer to different types of “systems of…”.  Writer Geoffrey Moore got the ball rolling with his 2011 use of the term “systems of engagement” (SOE) and “systems of record” (SOR); IBM has recently added to it with “systems of insight” (SOI), referring to the range of purely analytics tools that exist, from dashboards to optimization tools to cognitive computing. 

Government as a Platform (GaaP) provides a framework for integrating these to improve the delivery of public services.

Definitions and Examples

The table below briefly defines each category with some examples:

Category

Characteristics

Examples

Systems of Record

(SOR)

  • Traditional transaction processing systems – often “back office” systems
  • Reference systems
  • Databases
  • Often mainframe based
  • Billing and tax collection
  • ERP, personnel management
  • Citizen record
  • Asset management
  • GIS base maps

Systems of Engagement (SOE)

  • Add value to data from systems of record – enable new modes of interaction
  • Enable data collection for systems of record
  • Often web or mobile enabled
  • “311” and other “my city” apps
  • “My Social Services”
  • Field collection of asset repair data
  • Consumption analysis provided with water or energy bills
  • Open data and reporting

Systems of Insight (SOI)

  • Add value to data from systems of record – enable new levels of optimization
  • Dashboards
  • Data-mining
  • Models, simulations
  • Cognitive computing
  • Traffic pattern analysis
  • Revenue stability and trends
  • Fraud detection
  • Crime pattern management
  • “Sentiment analysis”
  • Water pressure optimization

 (Note: It is possible to speak of a fourth category, systems of control - SOC - covering SCADA systems, PLCs, sensors and the like, but these are not the primary focus of GaaP.)

The key to these categories is that they interact.  They are not mutually exclusive, meaning the same GIS may function as the SOR in identifying where assets are located, but also power an SOE that allows repairs to be recorded or the public to see which traffic lights are broken after a storm. Another example is that a cognitive computing application may both perform analysis (SOI) and provide a natural language interface for the public as an SOE.

As the table hints, the categories add value to one another. When an SOR is implemented, it usually enables certain process improvements, but once these are implemented, the benefits pool is usually exhausted and the process is just in operation mode. The SOR continues to enable the process to operate, but it does not (by itself) enable that process to improve further, unless it is subsequently modified in some way, usually a slow and labor-intensive process. An SOE, however, can add value to that system of record. For example, in enabling asset data collection at the point of repair to improve  data capture or in providing new ways for citizens to access or interact with data about them and their properties.

Moreover, SOE are often quick and relatively simple to build. Similarly, an SOI can enable new policies or responses based on an improved understanding of trends “on the ground.” For example, where new policing patterns are implemented in response to crime patterns identified from data held in the crime database (SOR) or where sentiment analysis allows crowdsourcing of data from SMS and Twitter (SOE) about wildfires and whether evacuation routes are working.

Implications for GaaP

So how does all this affect GaaP? The three classes of systems together allow public agencies to run existing processes and execute basic operations (SOR); improve their interaction with the public and support for their workforce (SOE); and identify new insights that allow new service offerings to be developed or optimized (SOI).  With its hybrid cloud enablement, integration and espousal of APIs, GaaP can be thought of as the “connective tissue” between the three classes of systems. More specifically:

  • The hybrid element of cloud in GaaP enables the SOR/SOE pairings that Geoffrey Moore originally wrote about: SOE are often built and operated on the public cloud for speed and cost reasons, but then securely interfaced with legacy SOR that may be too difficult to move from their legacy processors or that may have compliance requirements that dictate a private cloud. Alternatively, a government entity may publish open data from its systems of record with an API that allows citizens to create new apps and new uses for that data.
  • As a special case, GaaP may enable SOR combinations that add value; for example, where client records in multiple SOR are looked up together to create a 360-degree view of the client. This might then allow services to be bundled together to meet more complex needs that the individual may have.
  • GaaP enables SOI by again providing the conduit for the required data from SOR or, as with sentiment analysis, from Twitter or SMS feeds from SOE. It may provide APIs for analytic modules to make a generation of insights and optimization of processes easier and faster to achieve, and it may also provide computing resources from other clouds to enable especially intensive analytic workloads to run.  GaaP also allows insights to be distributed, either within the government or to the mobile devices and browsers (SOE) of the public consumer.
  • GaaP enables SOE in two ways.  First, it is stated to provide the conduits to and from SOR and SOI as required; and second, it enables access to suites of APIs that can allow SOE capabilities to be constructed rapidly and cheaply.
  • Finally, a common challenge for public agencies is the need to modernize legacy systems in order to deliver full online availability of government services. GaaP provides a means for abstracting and encapsulating legacy systems with APIs that can be called by SOE. Going one step further, one can build “micro-services” in the GaaP platform and serve these to users by the APIs. Now it becomes possible to apply what is commonly known as the “strangler pattern” to legacy SOR: incrementally phasing them out by replacing their rules and logic with new micro-services in the GaaP. The benefit is that public agencies can avoid costly, risky, big-bang legacy system replacement projects and instead opt for a more gradual approach—one that has been successfully used in banking, insurance and transportation over the past 20 years.

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 nmedia/Shutterstock.com)

NEXT STORY: The Art of Ignoring Things