Wayne Ariola, General Manager of Tricentis RPA, recently joined Mitch Ashley on DevOps Chats to introduce the DevOps and testing community to the red-hot opportunity in RPA.
Wayne and Mitch explore how RPA intersects with DevOps tools, processes and teams, as well as how RPA benefits from the experiences gained in the DevOps community.
The following are two excerpts from the discussion: the first covers the intersection of DevOps and RPA, and the second covers the intersection of test automation and RPA. The complete transcript is available at DevOps.com.
RPA and DevOps
Ashley: I know RPA, robotics process automation is the hot thing. How do you define RPA?
Ariola: It is definitely on fire. In fact, I have a slide that I use in presentations that I compared DevOps to RPA. And the DevOps folks, it looks like there’s a bunch of people dancing, but then I show a picture of RPA and it looks like a rave—you know, a big, huge party at a rave with lasers and lights and a whole crowd thumping to the music.
And that’s really what’s happening right now. I mean, the RPA world and the RPA market is just on fire, and it’s a bit crazy. But the reason why it’s a bit crazy is that the ROI associated with deploying automation or what is defined as RPA automation is really high. You get immediate value out of it, so it’s kind of like this—especially if you talk to CIOs, you know, they’re saying that it’s the no-brainer of today’s world.
But this is, I mean, the DevOps folks are no stranger to this, right? So, we did, we went through this when we kinda went through the whole DevOps motion beginning with build automation, right?
Ashley: Right, yeah.
Ariola: You know, we took a breath and we said, “Hey, this build process is manually painful and it’s difficult and it’s arduous.” And, you know, once we got through the initial thing around the automating build, you know, the imagination associated with what could be automated then exploded, you know, and then you got into the DevOps motion, right?
And I would say it’s a perfect parallel. RPA is doing exactly the same thing. It’s taking these preliminary type of motions associated with manual processes and automating them.
Ashley: Well, you know, in a way, the way I think about it, Wayne, is, you know, to step back for a minute, the best developers I’ve worked with in my career have always been the laziest, and that’s a compliment.
Ashley: Meaning, they write the least amount of code, the automate everything—they don’t want to do that manual stuff, right?
Ariola: Yes. So true.
Ashley: They want to spend time on the things they enjoy working on. So, you know, in the DevOps world, of course, we’re big on automating things and maybe all of it isn’t automated, but it’s taking that same kind of, “Let’s take those things we don’t need to do manually and we really can automate it and look across IT, across business process automation—you know, the whole organization.”
Ashley: That’s probably why it’s hot, because it’s not only in IT, but it can affect other parts of the business. So, I’m going to lay claim to RPA’s roots being in DevOps. Now, you can tell me I’m totally wrong, but I won’t—
Ariola: No, absolutely not, given the audience I’m speaking to. I agree.
Ariola: I totally agree. But it’s true, though—I mean, think about this, Mitch. Let’s unpack that just for two seconds, right? So, take the idea of that developer who’s lazy, right, and the fact that—what are you doing? And if you would, say, ask the person what they’re doing at any point in their day, it’s like, “You know what, I’m writing a script to do X, Y, Z because I’m so sick of provisioning this particular application to this environment,” whatever it might be, right?
So, their knowledge base and their understanding of how to construct a script gave, especially in the DevOps world or the Dev world, these guys a leg up in terms of producing this automation to eliminate manual tasks.
Ashley: They’re the most productive, yeah.
Ariola: Yeah, exactly, and make that the most productive. But RPA is really trying to—and I hate to even use this word, but it’s the best way to describe it succinctly, is democratizing that, right? It’s giving people who are not as talented as your laziest developer the ability to actually create the automation to get rid of the mundane or manual tasks that are slowing them down, right?
Ariola: So, I mean, even by—Mitch, even by definition, you know, RPA is defined as a technology that predominantly leverages a combination of maybe UI and API or surface level features and applications to create more automated, routine, predictable data transcription or enablement work, right? So, automation work or executable work.
So, if you think about it, it’s a technology that sits on top of—a superstructure that sits on top of apps that allows you to do things more proactively across applications. So, making sure that a manual task to transpose data, to move data, to initiate something, to do data entry is eliminated by the automation itself, which is really cool.
Ashley: You know, I think of it as, an analogy would be just like sysadmins write scripts, right, to do things that automate it.
Ariola: Yes, yes.
Ashley: This is for other IT folks, but also can be end users, right, that automate filling out forms on online screens or doing some processing of “load this data into a spreadsheet, export it out to here, send it to here.”
Ariola: Yep, yep.
Ashley: Now, why do all that stuff by hand? Here’s an easy tool.
RPA and Test Automation
Ashley: Talk a little bit about why it made sense for Tricentis to expand from automating testing to more generally providing an RPA solution.
Ariola: Yeah. So, thank you for asking that, because I do happen to get that question quite often. A real differentiator in the marketplace is that Tricentis RPA features model-based automation technology.
Ariola: And most of what you’re going to see today out there from RPA vendors are scripted technologies or technologies that use image-based controls to understand screens. And the script-based technologies and this image stuff, by the way, is the prime reason why software test automation has been so difficult. Because scripts fail.
Ashley: Yeah, I was just going to say. [Laughter]
Ariola: Yeah, they’re brittle. They basically are hard to update. It’s hard to maintain. You know, it’s the old adage of keeping in sync with the code base and, you know, RPA is highly susceptible to changing UIs. And this is where we shine.
Our model- based automation takes a much, much more technical approach. So, where most of the vendors out there, if not all of them, interrogate a UI from a screen perspective, we actually interrogate the implementation.
Ariola: And we understand the UI from its more technical implementation perspective. So, if you take SFDC or if you take SAP or you take ServiceNow or any of these big, large vendors, the complexity of the UI even through a browser is pretty significant. So, the fact that we actually interrogate it at a technical level to build an abstracted model gives us the ability to deliver real, resilient automation.
Universally, in our platform, you cannot script. If you wanted to script, you’re going have to go somewhere else, because you can’t script, because our automation is model-based. So, everything that we’re doing is actually produced from technical observations of the application itself. And then we allow you to put those observations or components that you discover—reuse them as LEGO blocks, right, and put them into different flows.
So, the good thing is that, when the UIs that are part of the automation change, (a) if you have to make a technical change, you only make it in one spot, and that change propagates throughout all instances or all bots that are using that automation, and (2) because we actually do a highly resilient technical implementation, you know, we self-heal our technology or our bots in roughly 80 percent of the change cases.
So, this is why we’re successful and still are successful in software testing, and this is why we decided to bring this to RPA, because it faces the exact same challenges.
Ashley: Well, it’s almost a knowledge-based approach, thinking about it as a model oriented solution. If you go back to screen scraping days, you have the brute force “this vector is where the information you’re testing is at.” With model based, it’s more of a canonical based approach, which is a defined way of determining what the information is and then you can detect when it’s changed.
Ashley: Now you have some reference model to pull from. It makes a lot more sense now. You can put logic based or flow based logic into an automation process rather than having to script it into everything as manual. I think that’s what you’re saying.
Ashley: Do I have it right, here?
Ariola: You have it 100 percent correct. So, it also gives us a broader reach within the organization as well. So, you don’t have to rely on the highly technical skills to actually produce the automation or, even more importantly, maintain the automation that’s required by your business.
Ashley: So, does this open up different people that you’re selling to in the organization? Are you still selling through the DevOps test organization in IT and you kind of expand what other places you can apply your RPA technology? Are you now calling on business units, end users, other application areas? What’s that mean for your business?
Ariola: So, whoever has the problem, we certainly want to talk to about assisting them to solve it. You know, within the DevOps space, there’s a lot of conversation about maintaining the scripts that are automating everything around my infrastructure is painful, right? So, there’s conversations that are even in that horizontal area. However, you know, the skill set that’s mostly in that domain is highly technical, so, you know, there’s a lot of preferred—a lot of preference to actual scripting there. But within the line of business, there’s certainly a lot of conversation going on, and that broadens the conversation.
But believe it or not, you know, when you’re talking about tests and test automation, although we do think of it as kind of a Dev test in motion, when you look at what Tricentis does, which is more end to end testing and protecting the end user journey because we cross applications, we have a lot of conversations with the business analysts. We have a lot of conversations with the line of business.