Robot Process Automation (RPA) has become a hot topic in the Digital Transformation space. The industry is still coming to grips with the possibilities offered by the technology. The robot in this context, is a virtual representation of a human who performs highly repetitive tasks that involves minimal or almost no human intervention. This enables businesses to automate activities that are performed by people freeing up human capital to focus on applying their expertise on higher value activities.
RPA software is able to process large amounts of data efficiently given the right amount of training. Once most of the edge cases have been established, system’s can achieve high levels of consistency . Automation processes can be tweaked easily to keep in sync with business demands.
One consistent question that comes up with customers relates to the choice of technology for integrating different systems for automated data capture/transfer. Traditionally, transferring data between systems has involved some sort of batch mechanisms or integration using API’s. I will focus on the various factors that affect this choice and some frequent issues associated with such efforts.
Integrating Applications using API
Enterprise systems rarely exist in vacuum. They work with and depend on a large ecosystem of supporting systems that exchange data. Core applications can have many services in production that have customers inside and outside the enterprise. When a system requires new data from an external source, managed secure file transfer or API are the usual suspects available for integration. These time tested approaches have served well over the years and will continue to do so. Let’s look at what’s involved to get data from external systems:
- Enterprise IT sanctions budget for said effort
- Project team is setup
- Requirements meetings with enterprise team and data vendor
- API Integration development
- Integration tests and acceptance
- Rollout to production
- Maintain integration service in prod: new API releases, bug fixes etc
Integrating Applications using RPA
With the advent of newer toolsets in the market like RPA, enterprise architects now have an easier option to achieve the integration goal in certain circumstances. RPA is not and will never be the number one solution for this problem, but given the right conditions, it can have one of the quickest solutions to complete data transfer. So, what are some examples where RPA will be a better solution than API integration?
- No Native API or integrations from the provider application
- Available integrations not suitable for use
- Resources to build the integration not readily available
The data transfer requirement process is already identified. If the data source is available in the form of a desktop/web application, RPA is the better candidate for solving this problem. Let’s look at what’s involved to achieve the same using RPA:
- Document RPA process for data transfer.
- Any qualified in-house developer designs and tests the process locally.
- Migrate the bot to acceptance using RPA toolset product of choice
- Integration test.
- Rollout to production.
- Much simpler and quicker tweaks to stabilize the bot process.
Available RPA tools in the enterprise software catalog should help an architect determine if it is a better and more cost effective approach. The following factors should be considered when evaluating their integration approach:
- Does using available API have a recurring cost. For eg, a fixed cost per call or a subscription model. Are there any license costs associated with these services?
- Does the IT department have resources available for developing and maintaining this new interface. What will it be the ongoing costs associated with this effort?
- API interface is workable or it needs more work on the provider side? Requesting custom changes. Is more work required on the consumer side to accept the api results
- Is direct integration with backend database being considered? I’ve seen cases where features like Oracle materialized views are used to access other system databases, usually within an enterprise. This approach is dependant on deep knowledge of the systems involved and seems to veer towards key person dependencies
- Production Support associated with this new effort. Is it better for support teams to monitor results vs application users enable themselves.
While there is no doubt that system to system integration is usually the best approach, certain requirements can help tilt the decision in favor of RPA. Users can help manage their own RPA processes and develop their own reporting and feedback.
In conclusion, RPA is not the first choice for application integration use cases. But for certain niche use cases, RPA can have the best ROI by far. The enterprise architects should be able to identify RPA use cases rather easily given their role in the overall scheme of things. All you need to do is believe that RPA will work in your integrations.