Our CTO Luke Morgan discusses interoperability, a hot topic in policing, in a piece originally written for techUK.
Interoperability between IT systems in policing has become a hot topic for several reasons, reflecting the evolving nature of law enforcement, technology, and the challenges faced by modern societies. Not least of all, is that today all crime has a digital element, criminals have weaponised technology.
An absence of interoperability in organisational terms or between disparate IT systems and solutions will if not addressed lead to failures in policing’s ability to solve crime, protect the public and fail to uphold the Peelian principles upon which policing in the UK is based.
The challenge of interoperability and doing more with data cannot be restricted to only designing systems which acquire and analyse information. The issue must be addressed in an organisational context. Melvin Conway, back in the 60’s had enshrined his thoughts in what is now known as Conway’s Law: “Organizations, who design systems, are constrained to produce designs which are copies of the communication structures of these organizations”
When investing in interoperability, it must be analysed in tandem with scrutinizing the organisational topology and communications flow. Budgets and organisational politics aside, the biggest gains to be made is when you are acting on both dimensions. The urgency for greater systems interoperability could be seen as the symptom whilst tired organisational structures and process are a potential cause.
There are three focal interoperability types to consider and corresponding organisational activity. The following is a lightweight framework and application recommendations to use whenever you are exploring the three types for use between 3rd party or internal systems.
The 3 Types of Interoperability
1. Communicate – System to system communication is data exchange through well-defined interchange formats. Small and more frequent broadcasts are key.
Embrace
- Open exchange formats; JSON, XML, Protobuf etc.
- Industry defined semantic schemas such as NPCC POLE data standards.
Avoid
- Proprietary formats from a single vendor.
- Chatty APIs or large data payloads.
Organisational Activity
Flatten. Explore ways to encourage high value communications; close, lateral and semi-formal. Flatten hierarchies even virtual ones.
2. Integrate – Capability exchange. Specialist capabilities often have value in a wider context. The ability to consume or inject certain portions of this capability can be invaluable, otherwise multiple panes of glass will continue to be the norm.
Embrace:
- Well defined APIs.
- Componentised control libraries.
Avoid:
- Application monoliths.
- Hub and spoke models where a vendor insist, they are the hub.
Organisational Activity
Combine. Handover, requests for specialists and context switching are all forms of waste. Multi-disciplinary teams are excellent antidotes to this. Even when combining is based on a transient activity.
3. Orchestrate – Essentially workflow coordination. Polices, governance, business process management are all examples of upstream and downstream activity between distinct and specialist functions.
Embrace:
- No / low code and out of the box orchestration vendors.
- Decreasing cycle time of the workflow or time to decision.
Avoid:
- Complicated state transitions. Remodel the decision matrix or process workflow.
- Scenarios where the cost of orchestration is greater than the cost of the applications you are orchestrating.
Organisational Activity
Decouple. If the automation is performed efficiently and effectively, the organisational functions can focus on more valuable activities. Where some form of automatic orchestration is unavailable, tedious, error prone manual processes and communications ensue.
