Can RPA Be the Bridge Between Two Speeds of IT?
- November 30, 2017
- 1 Comments
Recently, we posted a blog with a video of a bot enabling “swivel chair” integration (https://www.bp-3.com/swivel-chair-doesnt-work/). I wanted to take this topic a bit deeper and discuss the broader business case for using bots for integration and also tackle some of the misconceptions we’ve heard in regard to this practice.
We Need the App Yesterday
It’s been a couple years since we started hearing the phrase “bi-modal IT”, but the gist of it was that traditional IT organizations are too encumbered with keeping the lights on in addition to other critical system changes (backlogs) to meet the velocity demands of the business. This gave rise to a framework that would allow smaller teams to rapidly iterate and ship digital products and applications independently of their legacy IT counterparts. This hasn’t changed; in fact, the velocity needed to effectively compete in many industries has substantially increased over the last 36 months. While these digital SWAT teams have shown their effectiveness, we’ve noticed that their ability to deliver value is correlated with their ability to integrate with legacy systems.
So All We Need Are People to Build the APIs?
Not quite. While I mentioned the correlation, there is more to the story. There are three pillars that define “ability to integrate”:
- Delivery Timeline
- Shifting Organizational Goals
I’m going to break down each of these to demonstrate the challenges.
Delivery timeline is affected by several intertwining factors, including staff availability, integration complexity, and project prioritization. Here are a few scenarios that you may be familiar with:
- We have the staff available, but the integration is so complex that we need to involve the vendor or it’s going to take an astronomical amount of time to build the necessary APIs.
- We don’t have any developers available that have the necessary knowledge to write the integrations.
- We don’t have any time until next XYZ because our backlog is packed.
As you can see, all of these will have varying degrees of impact on the delivery timeline. It’s difficult to plan and deliver an MVP around these types of issues, and many times integration capability will be scrapped entirely and deferred to “manual processing”.
Integration costs can be substantial, and can arise from numerous things such as cost recapture through interdepartmental transactions, consultant fees, or even paying the software vendor for the necessary changes. In fact, “Gartner predicts that through 2018, 90 percent of organizations will lack a postmodern application integration strategy and execution ability, resulting in integration disorder, greater complexity and cost.”1
Shifting Organizational Goals
The focus of the smaller, agile teams is building the minimum viable product (MVP) to address a specific business goal or challenge. The goal of the MVP is to show value, but given that these projects should be quick and dirty they’re prone to disruption themselves by reorgs and a shifting focus to new initiatives or new bottom line impacts. This can be frustrating for traditional IT. In the event that they’re halfway through, or even done with, an integration there is now a possibility that it is throw away code and wasted capital.
Bridge the Gap
So as you can see, we have a lot of competing roles, responsibilities, and priorities. Traditional IT wants to create good (low technical debt, reusable), stable software. The innovation teams want to quickly deliver and measure value from a project. How do we enable both teams?
One answer, of course, is Robotic Process Automation (RPA). In the next sections I’m going to address common arguments people make against using bots and indicate why those arguments are misleading. By the end, you will have a better understanding of why bots should be in your company’s arsenal for digital business operations.
We’re Already Building/Should be building An API
Agree! Bots are NOT a final solution to any integration problem. They do, however, solve a few very important issues:
- The specifications can be developed and validated prior to the integration being written. It is costly to have to continuously change your consuming application because the integration development itself was rushed and there are bugs that are identified by the consumer. More importantly, data requirements are dynamic in nature and can change drastically as the business begins to use the application. Adding additional fields or data elements to an integration can extend timelines, add cost, and frustrate developers. The bot just has one more field to find and retrieve.
- Integration via bot can help validate (show ROI on) the business case quicker, allowing the team to pivot away from projects that didn’t actually show the savings that were expected (and prevent costly stop & go distractions for the traditional IT teams).
It’s Just Screen Scraping
While some bots do use “screen scraping” software, modern bot vendors have actually built frameworks around native API access through DLLs and app consumption. This reduces the risk in the event that the UI itself is modified. There is, of course, some risk in the event that an application is changed (not unlike other risks in every integration scenario), which is why modern bot frameworks also include robust exception handling that hooks in nicely to process software for manual processing.
Many people wonder how they can prevent a bot integration from becoming the “final solution”. They effectively want to answer the question, “How do we engage IT so that the actual integration is in place in the event that our MVP needs to scale?” This is a question that we’re helping a lot of customers with as part of their RPA deployment initiatives. We would love for you to reach out so that we can have a more detailed conversation around your use case and how we can help bridge the gap.