Robotic Process Automation
What we build when integration is not available.
Read moreComparison
RPA vs system integration
Should we automate the screen, or connect the systems properly?
Both approaches solve the same visible problem: information sits in one system and needs to be in another, and right now a person is moving it. They solve it in fundamentally different ways, and the cheaper one to build is usually the more expensive one to keep running.
RPA drives the user interface — it opens the screens a person would open and types what a person would type. Integration connects the systems underneath, so data moves directly with no screen involved.
Side by side
| Â | Robotic process automation | System integration |
|---|---|---|
| What it depends on | The screen layout staying the same | An interface the system deliberately exposes |
| Cost to build | Lower — no changes needed to either system | Higher — needs cooperation from both sides |
| Cost to keep running | Higher — breaks when either system is updated | Lower — interfaces are versioned and change rarely |
| Speed | As fast as a person clicking, roughly | Effectively instant |
| Volume it handles | Good for batches overnight | Handles real-time and high volume |
| When the vendor changes something | It stops. Someone has to fix it. | Usually unaffected, and warned in advance |
| Time to first working version | Weeks | Longer, and depends on the other party |
When each one is right
Choose robotic process automation if
- The system has no interface and the vendor will not build one
- It is a regulator's portal or a bank site you will never get access to
- You need something working in weeks, not next quarter
- The process runs in batches overnight rather than in real time
- You want to prove the automation is worth doing before committing further
Choose system integration if
- Both systems expose an interface, or can be made to
- The data needs to move in real time rather than overnight
- Volume is high enough that speed matters
- This will be load-bearing for years and you want it stable
- You control both systems, which makes this straightforwardly the better answer
Our answer
What we would tell you
If a real integration is possible, build the integration. It costs more up front and less every year after, and it does not wake anyone up when a vendor ships a redesign.
Use RPA where that door is genuinely closed — and be clear with yourself that it is closed, rather than that opening it is inconvenient. A robot built because nobody wanted to have a difficult conversation with a vendor becomes a permanent maintenance cost.
A reasonable middle path: use RPA to prove the process is worth automating and to buy time, while the integration is negotiated and built. That is a deliberate decision with an end date, not a default.
Related
Where to next
Application Development & Maintenance
Where a proper integration or replacement gets built.
Read moreGlossary
Plain definitions of API, integration, legacy system, and the rest.
Read more
