Before anything is integrated, four things have to be agreed: what systems talk to each other, what data moves between them, what the shared concepts are, and where the risk areas lie. Without that, the developer builds exactly what they think you meant.
Integration pre-analysis is the cheapest place to have those arguments. It reduces risk on both sides of the table: the client knows what they are ordering, and the supplier knows what they are promising. From there the same description can go to a developer, into a tender, or into delivery with us.
The description is written so that it can be handed to any developer. If you would like the same person who wrote the description to build it as well, that is one of the ways to work together too.
How data moves between systems and processes, with classification and sensitivity tagging (PII, retention, owner).
OpenAPI 3.x contracts, authentication, error scenarios, quotas, versioning.
What has to be true for the interface to work — and what happens if it is not.
Source and target fields, with transformation rules and whether each field is mandatory.
All deliverables are handed over in editable formats.
An integration is the place where data leaves the protection of one system and arrives in another. That is why the mapping comes with data classification and sensitivity tagging: what counts as personal data, how long it is kept, who owns it, who has access, and what is logged. These are part of the interface description, not a separate security chapter at the end.
In delivery the same idea is added as a way of working: authentication and permissions from the start, secrets kept out of the code, and behaviour in error situations described and logged so that afterwards you can tell what happened.
The founding analyst has 13+ years of practice with systems, data models and system-to-system interfaces in banking, telecom, IT consulting and logistics. Qualification: BCS Foundation Certificate in Business Analysis. Working languages Estonian and English.
The closest public example of what our integration-analysis conclusions look like is our e-invoicing article: it works through exactly that job — what applies, what is promised, where the promise and the actual data flow part ways, and what to do about it.
We write in Estonian first. The pieces below have not been translated yet and open in Estonian.
Each of these is a starting point; we settle its scope in conversation and fix it in a written offer. The steps can be taken separately, or one after another in a logical sequence.
A fixed-scope written deliverable, produced before development or a tender. It answers the question of what has to move, where to, and under which rules.
What it includes:
The technical description of a single interface, at a level that lets you build from it and accept against it. Works for internal development and as an annex to a tender alike.
What it includes:
From the description to a working interface, and on to handover. The same analyst-developer does the work from start to finish, so the description and the build do not drift apart.
What it includes:
A look at what already moves in your organisation today. Suits you when interfaces have accumulated over the years and nobody holds the whole picture any more.
What it includes:
Write down which systems you have and what moves between them by hand today. We talk the scope through and send a written offer. We reply within one working day, and the first discussion is free.
