We are debating whether to build expensive API connectors for our 15-year-old mainframe or just use RPA to scrape the screens. RPA is faster to deploy, but APIs are more stable. How do we calculate the long-term Total Cost of Ownership (TCO) including bot maintenance vs. the high upfront cost of custom software development? I need a clear framework to present to my CTO next week.
3 answers
Have you considered the security implications? Scrapers often need higher permission levels than a scoped API key would require on a database.
This is the classic "Speed vs. Stability" trade-off. For legacy mainframes where an API might cost $100k and 6 months to develop, RPA is the clear "Tactical" winner. However, you must factor in "Technical Debt." If the mainframe UI changes once a year, your bot maintenance might cost $10k annually. A good TCO framework looks at the 3-year horizon. If (RPA Dev + 3 Years Maintenance) < (API Dev Cost), then RPA is the way to go. Usually, we recommend a "Strangler Pattern": use RPA today to get the immediate ROI, while slowly building out APIs for the most critical, high-volume data paths over the next two years.
RPA is great for "Swivel Chair" tasks where you are moving data between multiple apps that don't have a common API bridge.
Absolutely, Barbara. RPA shines in those "inter-system" gaps where traditional integration is either impossible or prohibitively expensive.
Thomas, that is a major point in our debate. Our security team hates screen scraping because the bot essentially needs "User" access to the terminal. We are trying to mitigate this by using a "CyberArk" vault to manage the bot's credentials and session recording for every bot run. However, the CTO still leans toward APIs because of the "Least Privilege" principle. We’re currently doing a POC (Proof of Concept) on one legacy screen to see if the bot can operate with restricted permissions before we make the final call on the TCO.