Public Sector · Integrations
Integration of public information systems and registries.
A new system fits into the existing landscape instead of duplicating it.
When public bodies bring us in
- you're preparing a tender and need a supplier
- the project needs several disciplines at once
- an existing system needs extending or connecting
- a procedure needs digitalising from application to decision
- long-term support after handover is required
What this means for the contracting authority
- Traceability for every step of the procedure.
- Documentation that matches the tender requirements.
- One accountable partner even with several vendors.
- Acceptance testing against pre-agreed criteria.
- Support and development after handover.
Problem → solution
Connecting to existing systems and registries
Public projects almost always connect to other systems: registries, the document system, the authentication system, accounting, or a system operated by another body. For each connection it has to be decided who owns the data, how often it moves, what happens on failure and how the transfer can be evidenced.
- access to the external system's test environment
- interface documentation or a contact at the vendor
- agreement on transfer frequency and volume
- error handling and ownership of failed records
- an audit trail of transfers
- what happens when the interface version changes
Evidencing a transfer
In public systems it is not enough that a transfer works; it has to be possible to prove it happened. So we record what was transferred, when, from which source, with what outcome and who handled the failures. Those records are part of the audit trail, not of the developers' logs.
Connecting to existing systems is often the longest part
Technically an integration is rarely hard. Everything around it is: getting access, getting documentation, arranging a test environment and getting a reply from the system's operator, who is not a party to the contract.
So we plan that part first and do not place it at the end of the schedule.
- who operates the system we connect to
- whether a test environment exists and who approves access
- what interface documentation exists
- what happens when the other system does not respond
- who is notified when an exchange fails
One source of truth for each piece of data
When two systems hold the same data and both may change it, sooner or later a difference appears that cannot be resolved automatically. So for each piece of data one system is designated authoritative.
How we run a public project
Requirements
Tender and technical requirements are translated into a delivery plan with milestones and responsibilities.
Project management
One contact, regular progress reporting and subcontractor coordination in one place.
Quality and security
Test scenarios, a security review and compliance with the client's requirements before acceptance.
Documentation
Technical and user documentation, instructions and training material.
Acceptance and SLA
Acceptance testing, handover and support with agreed response times.
Related work
FAQ
Do you help prepare tender documentation?
We can contribute to the technical part and clarifications, within public procurement rules.
Who manages the subcontractors?
We do. The client has one contact and one progress report.
What does post-handover support include?
Agreed response times, defect resolution and enhancements as agreed.
Related solutions
Sounds like your project?
Send us the project description, your existing system, the tender documents or the event date.