In this blog, I want to begin to explore and share with you the lessons that we have learned over many years of delivering system integrations for our UK Local Authority clients. Abavus has a well-established pedigree in the delivery of a digital transformation cloud platform, known as My Council Services, for Local Government.
As the My Council Services platform has continued to develop and broaden its range of capabilities, the delivery of secure, system to system integrations has become a staple delivery of most implementation projects.
System to system integrations are important elements of a project because, when done well, they enable the Local Authority to maximise the opportunities for process automation and efficiency realisation.
This blog introduces the topic and classifies the primary types of integrations. To get into more specific detail, I would encourage readers to visit the Abavus website and download the more comprehensive white paper on the same subject.
From the early days of Abavus, offering solutions based on a native mobile app, to today being a full cloud solution provider, Abavus has always taken an open approach to integrating with third-party systems. The My Council Services platform has been engineered to integrate with any third-party solution enabling a seamless and effective end-to-end digital solution.
We have now completed hundreds of individual integrations from the relatively simple payment integration through to the most complex multiple flow integrations involving sensitive financial and personally identifiable data.
Any integration will have its degree of complexity and challenges, what follows introduces the main purposes and types of integrations:
Types of integration:
We will introduce the main types of integration and for those who wish to read more, you are welcome to download our detailed White Paper that expands on the methodology and approach of integration that we use at Abavus.
Delivering and designing an integration for UK local authorities. The three types of integrations:-
- A synchronisation
- A lookup
- An output
All three of these characteristics can be present in a single integration (which of course will add to the overall complexity). As a starting point, it makes sense to define the three classifications listed above.
Synchronisation
Most local authority systems will have the concept of a case, a worksheet, a job ticket or a service request. This is generally an issue or something that needs to be dealt with. This may be resolved by the Local Authority’s own staff or by an outsourced contractor.
You can refer to any of these items i.e. a case, a job ticket or a service request as a ‘container entity’. Each of these container entities will hold information that is relevant to the service request or case such as the submitter’s details, location information, notes, and status flags. The relevant and required data fields included in each container entity will need to be securely shared with and accurately mapped to the corresponding fields in the recipient database system.
Synchronisation integrations help improve the Council’s data management, support the creation of seamless digital processes and support the creation of a consistent and federated data infrastructure.
Lookups
It is not unusual for UK Local Authorities to hold data in separate databases that are not connected with the wider information architecture of the organisation. These can be thought of as data silos. This could be a spreadsheet (although we would advise against using spreadsheets as long term data storage solutions – just ask the UK COVID-19 Track and Trace system run by Serco), it could be an isolated departmental Access database, SQL Server database or any other ‘flavour’ of database technology.
Just because the data held in these isolated locations that are separate from the wider information management set up, it does not mean that it is not useful and valuable. These data silos often include current address records, financial data, information about an asset or personal data that needs to be referenced for other processes.
To aid a process flow, sometimes it will be necessary to validate data provided or retrieve data to enhance or verify the process. It is not uncommon to need to do this with data held in a data silo. For example, cross-checking via a lookup to separate database that an applicant is not already making a claim or that an asset has already been reported as faulty.
Lookups will normally be a real-time when an integration is happening at the same time when a customer or user enters information and waits until a response is returned.
Lookups can make digital self-service processes more efficient and easier for a customer to navigate, by reducing the need to re-enter information that the Council already holds about a person for example; they can be extremely useful and often make the difference between a really good user experience versus a sub-optimal one.
Output
The most commonly occurring example of an integration that would be classified as ‘output’ is a payment integration i.e. the software systems that Councils utilise to collect online payment such as CivicaPay, Worldpay or Capita ePayment.
There are other examples of output type integrations, for example, when integrating to a document generation system, or notification processes such as email or SMS. As the name suggests the object of this type of integration is to produce an output that typically concludes a process or at least concludes an element of a process (the successful completion of a payment, the production of an official document, badge or permit or the send and delivery of an electronic communication).
It is not at all unusual for an integration to involve more than one or all three of these methods described above. Like the facets of an integration multiply, so does the complexity.
When I approach any integration, I have a clear documented approach and methodology which is essential if you want to avoid risks and pitfalls.
