Solution
Integration and Middleware
An architecture where links between systems do not scatter through the application.
18 functions4 module groups4 integrations
Integration usually gets added as needs arise; a few years later nobody knows which service is called from where, and changing one provider opens half the system. In our setup every outward link is gathered into one module. The rest of the application does not know those services exist, so when a provider changes, one place changes.
Scope and modules18
01
Connection layer
- Single entry point, service contracts and versioning
- Retry, timeout and circuit-breaker behaviour
- Queueing and deferred processing
- Full request/response logging and error tracking
- Provider swaps handled in one place
02
Enterprise systems
- Logo, Netsis, Mikro, SAP and bespoke ERP connections
- Journal entry export to accounting packages
- Single sign-on via Active Directory / LDAP
- Database-level reads from legacy systems
03
Statutory and financial
- E-invoice, e-archive, e-waybill and e-ledger providers
- Bank statement import and bulk payment files
- Payment gateways, providers and instalment rules
- Exchange rate services
04
Operational services
- Courier and carrier services
- SMS, email and push notification providers
- Mapping, address and routing services
- Marketplaces and e-commerce platforms
- AI model providers, behind one service layer
What it connects to04
- REST, SOAP, GraphQL and file-based transfer (SFTP, CSV, XML)
- Webhooks and event-driven triggers
- Message queues for asynchronous processing
- Scheduled batch transfer
Signs you need this system05
- 01The same data is keyed into two systems
- 02When a service changes, you do not know how many places in the code will open
- 03Integration failures surface as customer complaints
- 04You learn in the morning whether the overnight transfer ran
- 05A provider contract is ending and nobody can cost the exit
Decisions to make upfront03
- 01What does the other system’s API actually give you?
- Documentation and real behaviour are often different. We measure integration feasibility during the technical assessment and define an alternative transfer method for whatever the API cannot do.
- 02Which way does data flow, and which side tells the truth?
- Every field needs exactly one owner. Designs where two systems can update the same field inevitably produce conflicts and lost data.
- 03Real time or batch?
- Real time is not always better and can overload the other system. We decide field by field: stock live, statements hourly, journal entries daily.
Sectors we have delivered in02
Frequently asked02
- Will you take integration work on its own?
- Yes. Keep your existing systems and have us build the links between them. Even then we start with a feasibility study.
- How do we know if an integration breaks?
- Monitoring is in scope: alerts fire when the failure threshold is crossed, every request and response is logged, and failed jobs can be retried.
Let’s scope it together.
We do not quote a fixed price for undefined scope. We review your existing system and processes on site, then deliver the roadmap and a fixed-price proposal.