System of record, warehouse, iPaaS, RPA: what each one is for

The same problem gets four different answers depending on who is in the room. Somebody cannot get a straight answer about what a job cost, and the proposal that comes back is a warehouse, or an integration layer, or a bot that reads the screen, or a new system of record to replace the old one.

All four are real categories that do real work. They are also not substitutes for each other, and most of the disappointment comes from buying one to do another one's job.

A system of record owns the truth about something

It is the system where a business object legitimately lives: the ERP for the transaction, the HR system for the employee, the document system for the signed contract. Its defining property is authority. When two systems disagree, this is the one that is right by definition.

What it is good at is being trusted, controlled and auditable. What it is not good at is holding anything outside its own domain, which is why an operational question that spans four of them has no single place to be asked.

A data warehouse copies data out so it can be analysed

It takes data from the systems of record, reshapes it for querying, and answers questions across sources that no single source could answer. Modern versions do this at impressive scale and speed.

Its defining property is that it is a copy, and downstream. That is a strength for analysis and a hard limit everywhere else: a warehouse can tell you what happened, and it cannot change what happens next. Writing back into the operational system is outside what it is for.

An integration platform moves data between systems

It connects A to B: when this happens here, do that there. Mature platforms handle authentication, retries, scheduling and monitoring, and they turn a hundred bespoke scripts into something a team can actually operate.

Its defining property is that it moves data without holding an opinion about what the data means. Two departments that disagree about what "complete" means still disagree after integration; the disagreement now just propagates faster and in both directions.

RPA drives the screens of systems that offer no other way in

Robotic process automation operates the user interface the way a person would: open the screen, fill the fields, click the button. It exists because a great deal of valuable software has no usable interface for programs, and it is often the only option that gets a result this quarter.

Its defining property is that it depends on the layout rather than on a contract. A field that moves is an outage, and the failure is silent until somebody notices the numbers stopped arriving. It buys access without buying stability.

The four side by side

The question none of the four answers

Take an ordinary operational question. What did this job cost, who approved the change that made it cost that, which document governs it, and where does it stand today.

Each of the four holds part of an answer. The systems of record hold the pieces, in four different vocabularies. The warehouse can assemble a view of the pieces after the fact. The integration platform can move them. RPA can type them somewhere else. None of them holds the thing the question is actually about, because that object exists across all of them and belongs to none.

This is also why adding a fifth tool of the same kind rarely helps, and why the first four were each bought in good faith by somebody solving a genuine problem.

Why this became urgent rather than merely annoying

People are good at absorbing this gap. They ask a colleague, check a second screen, and reconcile in their heads without ever calling it work. Software cannot, which is why the arrival of agents turns a tolerable inconvenience into a blocker.

The distance between those two numbers is not a distance in model quality. It is the distance between a tool one team can use and a capability the organization can run on, and that second thing needs something to run on.

Informatica sells data management software, so this is a vendor-commissioned survey of a population with a professional interest in the answer. It is quoted because the sample and date are stated and because it agrees with the independent Gartner finding on AI-ready data, not on its own.

How to tell which one you actually need

• If the answer exists in one system and people cannot get at it, you have a reporting problem and a warehouse is the right shape.
• If the same fact has to exist in two systems and does not, you have an integration problem.
• If a system genuinely offers no programmatic way in and will not for years, RPA is a legitimate stopgap. Budget for it breaking.
• If the object the business earns from lives across four systems and none of them can answer for it as one thing, none of the four classes above is the shape of the answer, and buying another one will not change that.

The last case is the one this company was built for, and what the resulting structure looks like is on the model.