Integration assessment
The inventory, the ownership map and the data-definition gaps, for an estate or for the systems a specific programme touches. Short, and it changes what most buyers thought the problem was.
The integration practice
System integration in Saudi Arabia
Every enterprise runs systems that were bought at different times from different vendors to solve different problems, and the work of making them behave like one organisation never appears on any of their invoices. This practice is that work.
In short
Making the systems you already own behave like one organisation
Interkey integrates enterprise systems for organisations in Saudi Arabia: the ERP with the operational systems, the operational systems with each other, and all of them with the legacy applications that were supposed to be retired years ago and still hold the data everyone needs. The work is interfaces, data flows, identity, and the discipline of cutting over without a weekend nobody wants to repeat.
It sits between two neighbouring practices and is neither. Building a system that does not yet exist is software development. Governing the interfaces once they exist — who may call them, at what rate, in which version — is API management. Integration is the part in the middle: getting a system that was never designed to share its data to do so reliably, and getting the organisation to agree what the data means on the way through.
Inside the Interkey group, the same capability across the wider GCC is delivered by RAMA Technologies, from Dubai and Riyadh. Saudi engagements run through Interkey in Riyadh; an engagement that crosses the Gulf is routed to the team whose geography fits.
Patterns
The five ways two systems can be connected, and when each is correct
Every interface in an estate ends up as one of these. The useful part is the proportions: an estate that is all point-to-point has grown rather than been designed, and one that routes everything through one middleware layer has bought a single point of failure with a licence attached.
| Pattern | What it means | When it is the right call |
|---|---|---|
| Leave them disconnected | The two systems keep separate records, and a person or a report reconciles them | When the data crosses rarely, the reconciliation is cheap, and the alternative is an interface with an owner nobody will fund. An honest integration inventory has this row in it. |
| Point to point | One interface, built for these two systems and nothing else | Two systems, one flow, one owner, unlikely to multiply. Fast and cheap. The failure is the twentieth one, when nobody can draw the diagram any more. |
| File and batch | Scheduled extracts moved and loaded on a timetable | Unfashionable and frequently correct: for reconciliation, reporting and anything that does not need to be current within the hour. Simple to operate and simple to replay after a failure. |
| API layer | Each system exposes a defined interface; consumers call it through a governed gateway | The default for anything with more than one consumer or any external party. It is also where the API practice takes over once the interfaces exist. |
| Event streaming | Systems publish changes as they happen; anything that cares subscribes | Where several systems need the same change promptly and the source must not know who is listening. Powerful, and it moves complexity into ordering, replay and schema evolution, which then have to be owned. |
The real problem
Every interface that fails has the same root cause
An interface nobody owns is an outage on a timer
Integration projects rarely fail on technology. They fail eighteen months later, when the vendor on one side changes a field, the interface silently starts dropping records, and the discovery is made by the finance team at month-end. At that point nobody is sure who built the interface, which side is responsible for it, or where its documentation went.
So the first deliverable of an integration engagement is not code. It is an inventory of every interface with a named owner, a named consumer, a statement of what the data means on each side, and the person who is told when either side plans a change. Most estates have never had this document. Producing it usually finds interfaces nobody knew were running, and a few that have not worked for some time without anyone noticing, which is itself a finding worth the engagement.
The second deliverable is a definition of the data. Two systems can exchange a “customer” for years while meaning different things by it, and the integration works perfectly while producing figures that never reconcile. The mapping between the two meanings is the intellectual work, and it is done with the business owners of the systems rather than around them.
The order
How an integration programme runs without a big bang
Each step is only safe once the one before it holds. The programmes that go wrong compress the first two into a kickoff meeting and discover them again at cutover.
-
Inventory and ownership
Every interface that exists, every one that is needed, an owner and a consumer per row, and the meaning of the data on each side agreed with the people who use it.
-
Contract per interface
What is sent, in which shape, how often, what happens on failure, and who is told before either side changes. Written and agreed before a line is built, because it is the thing the build is tested against.
-
Build and test against the contract
Each interface built to its contract and tested with real data shapes, including the malformed ones the source system actually produces. Arabic text, mixed-script fields and legacy encodings are tested here, not found in production.
-
Cut over incrementally
One interface, one flow, run in parallel with whatever it replaces until the two agree, then switched. No weekend in which everything moves at once, because that weekend has never once gone to plan.
-
Operate and watch
Every interface monitored for volume, failure and staleness, alerting the owner rather than a shared mailbox, with the inventory kept current as the estate changes. This is where the observability practice and this one meet.
Scope
How the work is usually shaped
Four shapes, in the order they normally happen. Each can be the last one.
Programme integration
The integration workstream of a larger change: a new ERP, a new operational platform, a merger of two estates. Contracts, build, parallel run and cutover, alongside whichever vendor is delivering the new system.
Legacy interface replacement
Taking the interfaces that hold the estate together and nobody dares touch, documenting what they actually do, and rebuilding them on something a current engineer can maintain, one at a time, with a parallel run each.
Operation
The interface estate monitored and maintained as a platform, with a named owner per interface and the inventory kept true, from Riyadh, as a managed service where wanted.
The Saudi layer
What is specific to this market
Three things change the shape of integration work here.
Government and sector platforms are integration targets with their own rules. Saudi organisations increasingly have to exchange data with national and sector platforms on those platforms’ terms: their formats, their credentials, their timetables. Each such obligation is an interface with an external owner, and it belongs in the same inventory under the same discipline, or it becomes the one nobody can explain when the platform changes its specification.
Arabic is a data-quality requirement, not a display setting. Names, addresses and identifiers arrive in Arabic, in transliteration, and in both at once, from systems that store them differently. Matching a record across two systems is the hard part of most integrations here, and it is tested against real local data during the build rather than discovered as a reconciliation gap.
Residency decides where the middle runs. Any integration layer that holds data in flight — a queue, a staging table, a transformation service — is a place the data lives, and its location is answered by the data classification before it is answered by convenience. The same rule the cloud practice applies to workloads applies to the pipes between them.
Definition of done
What finished actually looks like
Each of these is either true or not, and each can be checked by someone who was not involved:
- There is one inventory of interfaces, every row has a named owner and a named consumer, and a new interface cannot go live without joining it
- Every interface has a written contract, and the build was tested against it with real data shapes, Arabic included
- Every cutover ran in parallel with what it replaced until the two agreed, and the switch date and its evidence are recorded
- Every interface is monitored for volume, failure and staleness, and the alert reaches its owner rather than a shared mailbox
- The meaning of every shared entity is defined once and agreed by the business owners on both sides
- A vendor on either side changing a field is told whom to notify, and that person exists
- The interfaces nobody dared touch have been documented, and the ones still needed have an owner and a replacement plan
Questions
Questions buyers actually ask
Common question
Do you work with the vendor delivering our new system, or instead of them?
Alongside them, on the part they are least interested in. A vendor implementing a new platform is accountable for that platform; the interfaces to everything else are usually a line item called “integration” with a day rate against it. Interkey takes that workstream: the inventory, the contracts, the build on the side the vendor does not own, and the parallel run. The vendor stays accountable for their system, and someone is finally accountable for the joins.
Common question
Do you use an integration platform or middleware product?
When the estate justifies one, and not before. Middleware is a good answer for an estate with many interfaces that share transformations and need one place to be operated; it is a poor answer for six interfaces that would have been cheaper point to point. The pattern table above is the actual decision, taken per interface, and the product follows from the proportions rather than the other way round.
Common question
Our legacy system has no API. Can it still be integrated?
Almost always: through its database, its files, its screens or its message queue, in roughly that order of preference. Each has a cost in fragility that the contract makes explicit. What matters more than the mechanism is that the interface is documented, owned and monitored, because a legacy interface that works silently for years is the one that fails silently too.
Common question
How is this different from software development?
Software development builds the system. Integration connects it to the ones that already exist. The practices share engineers and standards in Riyadh, and a programme often needs both, but they are estimated, staffed and accepted differently: a build is accepted against requirements, an integration against a parallel run that reconciles. The software page covers the build side.
Common question
Where does the group’s UAE company fit?
RAMA Technologies is the Interkey group’s integration arm across the wider GCC, from Dubai and Riyadh. A Saudi engagement is delivered by Interkey; one that spans the Gulf is routed to RAMA. Start with either and the group routes it.
From the insights library
The neighbouring decisions
Practice
API management
Governing the interfaces once they exist: who may call them, at what rate, and how versions are retired.
PracticeCustom software development
When the system that needs connecting does not exist yet, or the one that exists is the thing to replace.
Productiblync data integration
Interkey’s own product for the data-movement half of an integration, where the flow is records rather than requests.
Explore related solutions
Next step
Start with the interfaces you cannot draw
Describe the systems that have to agree, which one is changing, and what breaks today when they disagree. The inventory conversation starts there.
Or directly
+966-11-2180999 info@interkey.com.saTawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia