Building a Business Integration Platform with Robotic Process Automation

Introduction

Thanks to the advent of more powerful computing, pervasive networking, and commoditization of technology infrastructure, there has been a renewed focus on automation along the concept of business processes rather than basic operational automation. A discipline known as Business Process Management has evolved, usually supported by Workflow and Rule Engine tools from vendors. The Workflow Management Coalition defines BPM (Business Process Management as thus:

“Business process management (BPM) is a discipline involving any combination of modeling, automation, execution, control, measurement and optimization of business activity flows, in support of enterprise goals, spanning systems, employees, customers and partners within and beyond the enterprise boundaries.”

Typically, BPM implementations have been the domain of large enterprises with the resources to implement automation via top-down methodologies and with the deep pockets needed to procure the various BPM products available from vendors and the consulting services associated with their use.

The options for smaller companies have been more limited. This document discusses an approach that leverages traditional service-oriented architecture principles with emerging robotic process automation (RPA) technologies to enable a Business Integration Platform (BIP) capable of supporting business process management automation in your company. The use of RPA provides more immediate value by allowing migration on a functionality basis via a series of agile-based sprints or on a segmented basis (e.g by department, by region).

The business integration platform discussed here focuses on flexibility and functionality at a relative low cost and can be a valuable component in the technology toolbox of options when deciding how to best implement business automation solutions in your environment. Because you won’t need to immediately amortize heavy upfront BPM investments the RPA based technique discussed here will better enable bottom-up value delivery (better known as the proverbial “low hanging fruit”), while avoiding riskier and more complex “Big-Bang” implementations. 

The Concept of Services

The Service Oriented Architecture (SOA) deals with the ability to ask a system to do something without having to tell it how to do it. Think about it. When you go to a restaurant and order a dish from the menu, you are implicitly applying SOA principles. The actual SOA inventor is unknown, but most assuredly he was some lazy bum trying his best to avoid work and pass on his responsibilities to others. Perhaps he was a merchant asking a scribe to log a transaction, or a king requesting a priest to plead his case to the gods, or a man of commerce paying someone to carry his produce. Agriculture, war, religion, the construction of temples and edifices; all the core activities we associate with modern human endeavors, are the results of someone doing another’s bidding along the concepts we now refer to as services.

In computer terms, SOA is about simplifying the business process automation by relying on the availability of service interfaces from various systems. More recently, SOA has benefited from the use of service integration platforms known as ESB (Enterprise Service Bus) that help in the orchestration and use of those services. As such, ESB is an optional component, best used in complex SOA environments. However, as the diagram below suggests, the actual business flow represented by an Application is the component that ultimately decides which services need to be called and when. In this scenario, the actual business flows are orchestrated outside the scope of SOA.

This model works well as long as you have the resources or applications capable of exposing functionality via service interfaces. But oftentimes, the problem is that you have to deal with legacy applications or vendor solutions that do not offer these interfaces.

The traditional approach of overcoming the lack of native interfaces is to write wrapper-interfaces that expose specific application business logic as a service. In the diagram below, System B has been provided with a wrapper module that exposes some of its functionality as a service.

The problem with this approach is that the wrapper code needs to be able to interface with the legacy application, while implementing business logic that, if hard-coded, can be difficult to maintain. Additionally, this type of coding requires specialized development skills not often available to small to medium-size companies. What to do then?

Enter Robotic Process Automation

Robotic Process Automation (RPA) is part of the recent growth of tools capable of providing services able to replace manual labor by leveraging improved system interfaces standards and machine learning advances. RPA tools provide sophisticated scripting interfaces and comprehensive integration to various computer platforms to enable them to simulate on any given computer system the work human beings perform. As a result, RPA is now widely being used for various purposes such as data entry automation, test automation, automated diagnostics and repair agents and, most importantly for the purposes of this article, workflow process automation.

Consider the typical RPA use case below: Sales agents fill-in work orders on paper forms which they then fax or scan to email to a central office. There, workers proceed to enter the orders into the system for processing (A). An ideal automation approach would be to develop an App service to allow entering the purchase order directly into the system to begin with (B). However, this direct access to the service approach is not always possible either for technical or commercial reasons. The feasible alternative is to use an RPA robot to “automate” the PO entry by having the computer emulate the employees’ work (C).

While there is no doubt that RPA can be used to integrate systems lacking service-oriented interfaces, the view that they can simply be used as a wrapper would be like using an expensive Apple laptop as a hammer. Use of RPA opens up the possibility to further elevate the system integration capabilities to provide actual business services. What is needed is a paradigm that better leverages the powerful capabilities RPA offers to solve the business automation problem.

From Application Services to Business Services

The beauty of thinking in terms of services is that you can avoid getting bogged down by how the service is provided. The manner in which the service is provided should be, in the end, immaterial to the person or entity requesting the service. What matters is having a well-defined interface for the service. If you order a meal in a language that is not understood by the waiter, then you can be assured the request either won’t be met or that you will be served a dish full of proteins and fats of unknown origins (something like this actually happened to me while in Hong Kong, after erroneously assuming I had ordered chicken!)

The next question is how precise and detailed should the request be? Say, you are seated in a fancy restaurant hoping to enjoy a nice gourmet meal. The waiter shows up with the menu, but instead of a list of entrees and appetizers, you are confronted with a catalogue of recipes. You order Tuna Tartare as an appetizer. The waiter stares at you with a bewildered expression. “Pardon?” he asks. “I’d like a Tuna Tartare,” you insist. He doesn’t understand, and it finally hits you, he’s expecting you to guide him through every single step of the recipe! “Heck,” you think, this must be some kind of novelty gimmick (think Kramer’s make-your-own-pizza idea in a classic Seinfeld episode), and so you begin the painstaking process of giving the instructions to prepare the dish:

“Get 3 ? pounds of very fresh tuna. Dice the tuna into 1/4-inch cubes and place it in a large bowl.” The waiter scribbles furiously. “Got this part, sir, I’ll be right back!” he says as he dashes to the kitchen to begin preparing your order. After he returns, you continue: “Mix 1 ? cups of olive oil, 5 lime zests grated and 1 cup of freshly squeezed lime juice.” He runs back to the kitchen before you get a chance to tell him to also add wasabi, soy sauce, hot red pepper sauce, salt, and pepper to the bowl. . .

You get the idea. 

This approach to SOA is nowadays known as Microservices, and the idea is that by defining very finely grained interfaces, you are able to easily change your recipe and even scale the resources offering each service in a more flexible manner. Need more salt? No problem! The diagram below shows a number of microservices being utilized by an application booking a particular airline flight.

There are different ways to ask for services, and microservices is a popular way to do it. However, one of the issues with the concept of microservices is that trying to offer wrappers for each of them can be computationally expensive. Using RPA scripts which tend to also be top-heavy in terms of set-up and computation to wrap microservices is also out of the question. Instead, we need to think in terms of Business Services:

A business service represents a unit of work that a non-technical person can understand as providing a valuable stand-alone capability. 

The premise of the Business Services approach is that, in general, it is better to start with fewer, coarser services and then move on to less coarse services on a need by need basis. In other words, it’s better to err on the side of being coarse than to immediately expose services that are too granular. It’s ultimately all about using common sense. In our restaurant example, you simply order the dish and leave it to the chef to figure out how to prepare it.

Until recently, the main objection to coarse services, which when you think about it are more closely related to business-level services, was that  they make you dependent on the complex logic behind the interface. If you didn’t like the flavor of the dish, tough luck, you got get what your ordered and that was it.

However, it is possible to use Robotic Process Automation to implement a coarse business interface while preserving the flexibility needed to change the business process behind it. Imagine that as you order a dish from the menu, you also hand the kitchen staff the recipe they should follow to cook your meal. The recipe stays in the kitchen and is followed by the chef. Think of this kitchen recipe as an RPA script that can be changed should you wish to improve the flavor of the dish.

This level of granularity is more akin the way we request business services from humans. We present our needs at a high level. When we ask, “Book me a flight”, we provide only the destination and the date, but we assume that the travel agent is expected to follow the company’s pre-written rules and procedures as well as our preferences.

When implementing business services, you are not using RPA simply to develop a “wrapper” interface on top of a system lacking a service interface, but instead you are adding an entire new integration layer on top of the traditional SOA bus. Because this new integration layer handles “coarse” business-level interfaces, using what perhaps can be described as robotic-bus, we refer to it is as a Business Integration Platform (BIP). The difference between BIP and the more traditional, vendor dependent, BPM approach is that we are now using RPA to services these requests.

There are several reasons why it makes sense to integrate RPA capabilities with SOA in this manner instead of simply using RPA as a wrapper:

• The use of BIP does not preclude use of microservices when needed, but the view of services can now include sophisticated embedded workflows, scripted by the RPA tool.
• Using RPA simply to wrap a microservice would be too expensive in terms of computer resources.
• Using RPA with BIP eliminates the need to create dedicated system wrappers. Instead, we leverage the workflow process creation capabilities offered by the RPA vendor to our advantage, so as to reduce dedicated programming work.
• ·The BIP drives the need for a business process framework that accommodates the various limitations and characteristics of RPA solutions. For example, RPA vendors may charge extra licenses per robotic instance, and if we were to use several robots concurrently our licensing costs could quickly escalate. A BIP framework allows serial usage of the RPA system. Additional capabilities offered by the BIP would be the ability to schedule, prioritize, and log the various business processes.

The following diagram offers a view of this type of BIP environment. Just as SOA relies on ESB services to facilitate ad-hoc and flexible use of application services, the BIP can benefit from a business integration framework that normalizes and orchestrates the manner in which RPA is used to offer business-level services.

The Business Integration Framework

Just as SOA abstracts the use of services, the BIP framework abstracts the use of RPA, while meshing the system with the underlying service-oriented environment. Perhaps the best analogy for a business flow that can be replicated by the BIP is the Department of Motor Vehicles flow when applying for a license renewal (let’s set aside any horror stories you may have against DMVs for the moment!). You first go to the reception, where you express your request to renew your license. After the reception clerk checks to see you have the necessary papers, she gives you a number. After your number is called, you are dispatched to the appropriate service window. This window functions as a gateway for your request by collecting your documents and then sending them to the appropriate backroom office for processing. The application is processed. As part of the process, you may be asked to provide additional information (your picture, for example), and an outcome will be generated. The backend process, may call other services of their own (e.g. checking your background info, validating you have no outstanding tickets, etc.), but eventually there may be a new license issued or not. Throughout, there is a level of journaling and tracking taking place.

The BIP has essentially the same elements:

• Reception. This is the main entry to business service requests. It parses and validates the requests and delivers them to the dispatcher/scheduler.
• Dispatcher/Scheduler. Depending on the nature of the request, it assigns a priority and places it in a service queue. Remember that one of the main objectives of the BIP is to serialize the use of RPA in order to more effectively use RPA services.
• Gateway. The business service request can be processed by a service or by a robot. The Gateway component ensures that the appropriate protocols and argument mapping takes place to ensure the desired process takes place.
• Process. This is the actual service processing flow. It can be a number of things: A specific RPA Robot or a call to a SOA Service. If the process requires manual intervention, it will trigger an appropriate call to action via email or some other notification. The expectation is that the manual response will be injected back to the platform via the reception area. It should be noted that one of the BIP’s key attributes is that its functioning is sessionless (it does not keep the state of a transaction), and that it is designed to operate asynchronously. Any process correlation, if needed, is expected to take place via the use of correlation tokens embedded in the transaction.
• Journaling. The framework enables a holistic tracking of the business flow, as well as the centralization of data elements as determined by the business process.

Conclusions

The business integration approach discussed here is suitable for the following cases:

• The systems in your company are highly heterogeneous. In other words, there is a diversity of best-of-breed systems that do not offer out-of-the box integration or that lack appropriate or standard service-oriented interfaces.
• The workloads do not demand high performance transaction processing. The BIP approach discussed here should not be viewed as capable of handling high transaction levels. Instead, the focus is on providing increased flexibility via the use of scriptable robots, even at the cost of throughput.
• The company does not have lots of development resources that could justify ad-hoc wrapping interface programming.
• There is a desire to gradually increase automation without resorting to “big bang” automation deployments. The BIP architecture discussed here allows for the gradual addition of automation robots within the framework.
• Even if your company is very large, this approach can be used to automate at a departmental level.

Use of RPA does indeed offer a new powerful tool that, if leveraged deliberately, can deliver significant more value than traditional SOA approaches and that practically matches the capabilities of more expensive BPM products. Using RPA in this manner requires the implementation of an integration framework that best accommodates the characteristics of this type of tool. I hope this document has demonstrated that there is ample opportunity to combine the SOA and RPA models in synergistic ways that provide innovative business value.