Here’s the punchline: Enterprises should prepare to add Robotic Process Automation (RPA) tools to their existing 3-tier Integration Architecture Standards.
But there are some caveats and learnings that should be incorporated into your strategy that we will talk about.
Let’s allay one of the common concerns that most Enterprise Architects have, and rightfully so….RPA will not fully replace APIs, or SOA, or MicroServices, or <insert favorite integration pattern here>. Fully engineered, and architecturally elegant integration stacks are valuable and should not be dismantled at the hand of robots. In fact, robots can and should leverage APIs where available in order to take advantage of API performance and enterprise security. This approach can actually shorten RPA development and testing time, resulting in a faster deployment with a trusted connection.
As an example, during the Covid-19 PPP loan process, there were several cases of robots being deployed to expedite loan form submissions. Rather than using the APIs, the robots were built (as commonly the case) to mimic the human entry from the UI/frontend. The problem was that the robot speed and volume swamped the loan processing systems since the UI was not engineered to handle that type of concurrent volume. Robots were banned from using the Small Business Association (SBA) UI forms and had to be re-written to connect via the published APIs. We can carry that lesson into the enterprise. RPA for form entry is still extremely valuable, but it needs to be correctly planned to ensure the volume and concurrency issues are mitigated so we avoid a fire-fight.
We’ve established a strong “pro” for the APIs above, pretty easy case. But let’s also acknowledge that APIs usefulness ends when the target data does not live in a “system” or some sort of structured database. Often with enterprise projects, the integration of several data sources is critical to the deployment success and business case. Even as some of the data lives on desktops, in documents, or spreadsheets; many workarounds have been implemented over the years to get that last piece of data into a system so the project can continue. Processes are re-engineered and potentially new screens, or even entire systems are built to handle the rogue data that is so essential. Since RPA can access unstructured or semi-structured data, robots can bridge this common gap without causing process disruption or needing to customize systems. A key point of value is that robots are non-invasive. This is another lesson that can be carried into Integration Architecture planning. Integration Governance teams (COEs, etc.) should be adding RPA to the toolkit and establishing approved patterns for gathering data outside of systems and databases. This becomes especially important as robots expand into the citizen developer communities.
Additional value from RPA can be extended to integrations with 3rd party or “closed” APIs that cannot be easily changed. Robots can provide the missing piece if the API is partially usable but needs additional data to complete the puzzle. Countless hours have been spent trying to work-around closed APIs that can now be solved quickly and effectively with RPA. Understand that RPA can be used as a stop-gap until the 3rd party vendor updates their API, or with hardening and enhanced security, the Robot may become the permanent solution.
As we continue on the path of understanding the duality of APIs living peacefully with RPA, we need to address the elephant in the room related to IT priorities and manpower to solve ALL the integration requirements with full-blown APIs. In the perfect world of Enterprise Architecture, the reference architecture would be executed with reusable services, likely microservices that are cataloged and automatically discoverable. The reality is that IT budgets and manpower will be applied to the most critical projects, leaving some systems without the aforementioned attention. Adding RPA into the enterprise toolkit allows projects to proceed without the cost/delay of API construction since we are using less invasive RPA tools. RPA can fast-track valuable projects that may have been shelved because of manpower/cost constraints. If engineered correctly, the RPA framework will deliver the project and realize ROI faster while still maintaining your architectural rigor and security.
Lastly, business rules tend to be added/changed in waves as systems and their respective integrations age. What started as an excellent plan to have the data integrity logic live in the UI, the business processing logic live in the middle tier, and the target system own the master data will inevitably morph to a hybrid over time as additional systems and rules are applied. One can make the argument that the real cost of the project lies in the final business rule amalgamation that has been in production for years…please, don’t make any hasty changes! An obvious but often overlooked RPA feature lies with the ability to pick-out data at any of the points (UI, Middle, or master system). As the business logic becomes complicated, APIs become complicated because they are so embedded with their respective systems. Enter RPA that can take advantage of existing investments in logic and APIs, with minimally invasive approaches to integrating additional systems (internal or external) or retrieving data already filtered through multiple layers of business rules.
As RPA tools continue to advance, with more AI and ML native capabilities, the reality of Robots intelligently being applied to the Enterprise Architecture reference model is here. We discuss RPA governance here, as it’s a critical part of realizing value and minimizing risk. At Optezo, we want to remove the barrier for getting RPA up and running in your environment with our “As a service” model, leaving the enterprise time to focus on the next valuable automation rather than the infrastructure, licenses, and maintenance of Robots. Since the business case (and ROI) begins at project inception, we feel that that our service model accelerates the deployment of your robots so value happens from day-1 rather than the old models of purchasing licenses, cloud/servers, infrastructure, setup, etc. In addition to starting faster, we start with a short-list of candidate processes extracted from our 300+ process catalog. Stop process engineering and begin your Robot Automation journey today. Let’s Talk today!
