The same record, in four places, disagreeing.
Making bought and built systems agree: who owns each record, what happens when copies differ, and how a failure gets noticed by you rather than by a customer. The engineering is the easy half.
What you leave with
- A one-page map of your systems, the records they share and where the copies disagree
- The first integration worth fixing, and whether to build it, buy a platform or retire a system
- A view on your integration platform (WSO2, MuleSoft, AWS, Azure or Google Cloud services, or none) and what it should and should not do
With a senior architect, not a salesperson. Sixty minutes, no cost, no obligation.
Most integration failures are a decision nobody made.
Two systems hold the same customer and disagree. The question that decides everything is not which protocol to use; it is which one is right, who says so, and what happens to the other one. Teams that answer that first tend to build integrations once. Teams that start with the API tend to build them repeatedly.
One owner per record
For every piece of shared data, one system is the source and the rest follow. Written down, agreed by the people whose work depends on it, and enforced in the design rather than in a convention.
A rule for disagreement
What happens when the copies differ: which wins, who is told, and what a person has to approve. This is the part that gets skipped, and it is the part that produces the Monday-morning spreadsheet.
Failure that is visible
Something will be down, out of order or rejected. The design decides whether you hear about it from your monitoring or from a customer.
Chosen from what the systems support and what the business needs, not from fashion.
Real time
Where somebody is waiting: a booking, a payment, a login. Synchronous, with timeouts and fallbacks designed rather than left to chance.
Events
Where the systems should not wait for each other. A change is published once, anything interested reacts, and a system that was down catches up rather than missing it.
Batch and files
Still the right answer for overnight reconciliation and for platforms with no API worth using. Done properly it is reliable, cheap and easy to audit.
Agent-ready capabilities
When an AI assistant has to act on your systems, the same work needs a manifest, permissions and a receipt for every action. That is the API and MCP side of this.
API and MCP workEAI, SOA, APIs and now AI agents. Most estates still run all four.
Each generation of integration was built for a different caller: a central team, a shared contract, a developer reading documentation, and now an AI agent that finds and combines services at run time. Most of the old patterns survive. We work with the platform you already have, whether that is WSO2, MuleSoft, IBM, Kong, or the integration services on AWS, Azure or Google Cloud, or with no platform at all.
EAI
Hub-and-spoke brokers and a central mapping team. Reliable for a few stable systems, slow once every change has to go through the hub.
SOA and the service bus
Shared contracts and an enterprise service bus. Sound principles; the bus tends to collect logic nobody else can change.
Service-oriented architectureAPI platforms
REST described by OpenAPI, events, and a gateway in front. Built for a developer who reads the documentation once and writes the client.
API and MCP workAgent-native
Capabilities an AI agent can discover, call within set rules, and account for with a receipt. Layered on top of what you run, not instead of it.
Read the researchWhere getting integration wrong costs most.
Higher education
Student records, learning platforms, identity, finance, library and timetabling kept in step: Ellucian Banner, Tribal SITS, PeopleSoft Campus Solutions, Workday Student, Moodle, Canvas and the standards between them.
Higher education integrationPayments and fintech
Ledger, card processor, fraud, KYC and sanctions agreeing about one customer, under ISO 20022, PSD2 and DORA, with evidence a supervisor can read.
Read the researchYour own business tools
HR, time tracking, projects, quotes, invoices and payroll. Sometimes the answer is not to integrate them at all, but to run them in one place.
See NexcubatorOne student, eight systems, one truth.
A university runs a student record system, a learning platform, identity, finance, library, timetabling, accommodation and the CRM that recruited the student, and each keeps its own copy of the student. Integration is usually nightly files, connectors that fail quietly, retries that risk a duplicate fee, and a morning mismatch report fixed by hand. Universities ask for two things: one login for every student and lecturer, and the same student, module, grade and fee in every system, at the same time.
Student records
Ellucian Banner, Tribal SITS, Oracle PeopleSoft Campus Solutions and Workday Student: the system of record for enrolment, modules, grades and progression.
Learning platforms
Moodle, Canvas, Blackboard Learn and Brightspace, connected through LTI 1.3 and OneRoster rather than bespoke connectors where the platforms support them.
Identity
Microsoft Entra ID, Shibboleth and eduGAIN federation, Okta, and SCIM provisioning: one login, and access that ends when it should.
Finance and HR
Unit4, Oracle Fusion and Workday: fees, sponsorship, payroll and the staff record, kept in step with what the registry says.
Library, timetabling, accommodation
Ex Libris Alma, CELCAT, Scientia and StarRez: the systems students notice first when a record is missing.
Admissions and CRM
Salesforce Education Cloud and Dynamics 365: the applicant becomes the student without being typed in again.
Keep the login. Keep the gateway. Change what sits behind them.
Directory and nightly files
One directory pushed into every system overnight, and the morning mismatch report. It works, a day late, and every new system means another connector.
Federation and an integration platform
One login through Shibboleth, eduGAIN or Entra ID, and changes announced once through an integration platform such as WSO2, MuleSoft, or the integration services on AWS, Azure or Google Cloud, or an API gateway. Seconds instead of a day, but every change queues behind one team.
One definition of student
Each system wrapped as a capability with the rules it cannot break and a receipt for every call, all held to one definition of student owned by the Registrar. The missing library account gets fixed; the duplicate fee goes to a person.
Read the researchThe decisions first, then the build.
Map
The systems, the shared records and where each one currently comes from. Nearly every estate has at least one surprise here.
Decide
Ownership, direction of travel and the rules for conflict, agreed with the business rather than assumed by engineering.
Build
The integration itself, with retries, alerting and a way to replay what failed. One flow end to end before the rest, so the pattern is proven cheaply.
Operate
Monitoring, a runbook and the handover. You should be able to answer “did it run last night?” without calling us.
What we integrate, and how
Bought and built systems, old and new, from file transfers to AI agents. The same discipline applies whatever sits in the middle.
Enterprise and SaaS systems
ERP, CRM, HR, finance and line-of-business platforms, including Salesforce, Dynamics 365, Workday, Unit4, Oracle, Zoho and the internal system everyone depends on.
Higher education
Student records, learning platforms and identity: Ellucian Banner, Tribal SITS, Workday Student, Moodle and Canvas, through LTI 1.3, OneRoster and SCIM.
Payments and regulated data
Ledgers, card processors, fraud and KYC services agreeing about one customer, with the audit trail ISO 20022, PSD2 and DORA work expects.
Integration platforms
WSO2, MuleSoft, AWS EventBridge and Step Functions, Azure Integration Services, Google Cloud Pub/Sub and Apigee, Kafka, IBM MQ and Kong: we work with what you have.
Data in step
Change data capture, event streams and reconciliation jobs, with a rule for every disagreement and an alert before a customer notices.
Agent-ready interfaces
MCP servers and capability descriptions so AI assistants can act on your systems within set permissions, with a receipt for every action.
Sound familiar?
- The same customer, student or supplier looks different in two systems
- A nightly job fails and nobody finds out until someone complains
- Every change to one system breaks an integration nobody remembered
- Your service bus or iPaaS has become the place business logic goes to hide
- An AI pilot is waiting on data that lives in five places
A small, senior team that stays accountable.
- Architect-led. Every engagement is led by a senior architect who stays accountable for the decisions, from the first hour to the handover.
- Over twenty years of building and integrating software. Enterprise integration, cloud platforms, product delivery and now AI agents, across sectors where systems cannot fail.
- Independent and vendor-neutral. AWS, Azure and Google Cloud, and whatever platforms you already run. We recommend what fits, including doing less.
- Research, applied. The patterns we use are published openly on The Software Lens and applied by our R&D Wing, so you can read the reasoning before you hire us.
- We run what we recommend. We build our own product, Nexcubator, on the same architecture we design for clients.
- You own everything. Your repository, your cloud account and your documentation from the first week. Based in Ireland, working across the EU and beyond.
Questions we get asked
How is this different from your API work?▼
The same engagement seen from two ends. This page is the estate-level decision: which systems hold what, and how they stay in step. The API and integration page covers the interfaces themselves, including REST, SOAP, events, files and the MCP layer an AI agent needs.
Should we use an integration platform, or build it?▼
It depends on how many flows you have and who will maintain them. A platform earns its licence when there are many simple, similar flows and a team that will keep using it. It becomes expensive when the logic is particular to you, because the hard part ends up written in a tool only one person understands.
What if the systems have no usable API?▼
It happens more than vendors admit. Scheduled file exchange, database-level extraction with the owner’s agreement, or a thin service in front of the old system are all legitimate answers, and each one can be made reliable and auditable when it is designed rather than improvised.
Do you integrate Ellucian Banner, SITS, Moodle and Canvas?▼
Yes, through the interfaces and standards those systems publish: their APIs, LTI 1.3, OneRoster, SCIM and campus federation. We are independent rather than a vendor partner, which is useful when the right answer is a different product, or no new product at all.
Do we have to replace our student record system?▼
No. It stays the system of record. The work is in front of it and between it and everything else: clear ownership of each record, connections that report their own failures, and old connectors retired one at a time.
Is there a case for not integrating at all?▼
Yes, and it is worth saying out loud. When the same work crosses four systems because you bought four systems, connecting them is a permanent cost. Sometimes the better answer is fewer systems, and we would rather tell you that than sell you the glue.
One free hour. No pitch, no obligation.
Bring the problem you are stuck on: an integration that keeps breaking, a cloud bill nobody can explain, an AI project that is all demo and no product, or a platform you are about to invest in. You will leave with a straight answer and a written summary, whether or not you ever work with us.
- Architecture and integration review
- AI feasibility: what will actually work, and what will not
- AWS, Azure and Google Cloud cost and design
- Business process audit and ISO readiness
- Technical due diligence before you invest or acquire
Sometimes the answer is not to integrate at all.
Every integration is a seam that somebody has to keep working. Where the sprawl itself is the problem, replacing it can cost less than wiring it together, which is why we built Nexcubator, one platform for the whole business, with nothing in between to break.
See what one platform looks like