Today’s state and local governments are striving to digitally transform their processes and systems to break down silos, improve interagency collaboration and communication, and delight their citizens with access to streamlined and automated services. But public agencies and institutions have been running their own siloed legacy information systems for decades, making it difficult to automate and streamline processes. Citizens often need to visit multiple systems or government agencies to get all the required documentation for an application or fulfill a request.
The same can happen when private institutions need to interact with the government and when separate government agencies need to interact with each other.
Governments have been trying to solve this silo problem for many years using a variety of different approaches, including point-to-point integration techniques and data warehousing technologies. But there are many problems with these approaches, such as needing to centralize all the data in a single place, brittle hard-wired connections, and organizational friction.
The advent of Application Programming Interfaces (APIs), microservices, and the ability to flexibly aggregate and orchestrate them are finally enabling digital transformation in state and local governments. Through modern architectures and APIs, data doesn’t need to be stored in a central repository, and the government agencies can continue to operate and control their own systems and databases. APIs are simply adapters that expose data and application functionality from internal systems in a way that is easy for other systems and users to access – with security and monitoring. API platforms allow these APIs to be flexibly accessed, orchestrated, monitored, throttled, and so on, to meet the wide-ranging needs of government agencies and their constituents. APIs can be deployed close to each legacy system, and since each agency remains in full control of their processes, data, legacy applications, and APIs, this new approach aligns perfectly with the organizational structure and culture.
But not all API Platforms are the same. Here we present the 10 key features to look for in an ideal API Platform.
The 10 Key Features of an Ideal API Platform
- Connectors
Besides exposing “RESTful” services, the API platform needs to provide a variety of other connectors in order to support legacy systems that can’t implement modern interoperability technologies. The most common connectors are: File/FTP, SOAP, Language Bindings for Java, .NET, Python and C, TCP/IP, HTTP/HTTPS, support for processing XML, Fixed Length, CSV and JSON payloads. - OpenAPI Specification (OAS)
APIs must be built using a schema first approach. Schemas must be OAS compliant and published on a portal for developers from other agencies to search. Developers should be able to see the API’s documentation with example of its usage. - Business Monitoring and Distributed System Monitoring
Mechanisms for monitoring the API platforms deployed on each agency. Business metrics such as metering of service usage and monitoring of SLAs are essential. Preventive monitoring of the individual API platform system deployments on each agency in terms of disk space, memory, CPU usage, health of the API platform and system alerts must also be considered. - Developer Portal
The API Platform must provide an API Developer Portal so that agencies can easily search and find APIs for their use cases, learn about them and understand how to get access to them. - Data Caching, Replication, Queueing and Horizontal Scalability of Pure Services
Cache and/or replicate the data from the legacy system and serve requests from other agencies from this copy of the data instead. Allow the queueing of incoming data from other agencies, and to throttle or schedule requests to be pushed into the local legacy application. It must also allow for the horizontal scalability of Pure Services. - Data Encryption
Strong data encryption must be applied to all the logs, tables and data structures that hold sensitive information. The encryption key must only be required when the API platform is started. - High Availability Through the Use of Service Replicas
The replica makes sure that all the code and data is always safe on another box. Such replica must be maintained by the API platform software without relying on shared infrastructure or single point of failure (sharing the same SAN). Such architecture is also known as “shared nothing” and allows the service to be deployed on commodity hardware on-premises or in the cloud. - Data Transformation
Mechanisms to visually build transformations between different data representations, data structures and to apply lookup tables to map custom codes to the reference data defined by the regulatory framework - Business Process Orchestration and Business Rules
Allow the designing and execution of Business Processes that are essential for orchestrating work that may involve many API calls, triggering data transformations, complex decision-making using conditions and business rules, human workflow and alerts. - Dealing with Exceptions and Providing Forensic Information
Provide mechanisms for sending alerts to humans, provide human workflows to support processes that need human intervention and store all data exchanged for a certain period of time for forensic analysis. This data must be easily searchable by data range, API and its contents (i.e.: find API call that happened on such and such date and time that included this SSN).
About InterSystems
Established in 1978, InterSystems is the leading provider of data technology for critical data-driven applications. Its cloud-first data platforms solve interoperability, speed, and scalability problems for organizations and government agencies around the globe. InterSystems is committed to excellence through its award-winning, 24×7 support for customers and partners in more than 80 countries. Privately held and headquartered in Cambridge, Massachusetts, InterSystems has 25 offices worldwide. For more information, please visit InterSystems.com or email
info@InterSystems.com.