Back in 2001, when open source software was still young, then-CEO of Microsoft Steve Ballmer declared it to be “a cancer that attaches itself in an intellectual property sense to everything it touches.”

The little Linux kernel that caused all that angst with a handful of part-time tinkerers has now exploded into a universe of open source software (or OSS) built upon millions of person-hours worth of contributions. Ironically, Microsoft is one of today’s biggest champions of Linux, and the enterprise-scale adoption of OSS in general, having contributed its own ubiquitously used VS Code IDE.

Until recently, most open source tools seemed to live nearer to the ‘roots’ of the software supply chain, making core operating systems, infrastructure automation and development tools more accessible and reusable for technical users. OSS was the domain of geeks constantly building and improving projects, not of business professionals using the application functionality itself.

Perhaps the myth that systems of process and systems of record contained the types of proprietary workflows and sensitive data that couldn’t be entrusted to a loosely-organized free-for-all of individual open source enthusiasts held OSS back from the business automation space.

That objection is now falling away, as the event horizon of open source efforts is starting to reach the frontiers of the RPA, IA (intelligent automation) and low-code market spaces. What is causing such rapid growth in contributions to this space, and what impact will the advance of OSS make on automation in the near future?

Shifting work away from proprietary systems

Businesses constantly demand transformative new application functionality – but inevitably, this requires overcoming the inertia of existing proprietary systems, along with deep programming and integration labor. Any company with a history has already accumulated multiple layers of technology for handling business processes and data, from core monolithic systems to SaaS platforms.

The idea of screenware automation is nothing new, but dedicated RPA tools appeared on the scene in the mid-2010s at just the right time. As most companies sought to scale up their agility for designing and executing on business processes at cloud scale, the ability to have ‘extra sets of hands’ to quickly repeat manual work across multiple application interfaces and disparate services became popular.

This first generation of RPA vendors had a key shortcoming – they offered closed systems, so once processes were captured, they could only be run within the vendor’s proprietary work automation servers as well. Furthermore, editing the captured processes to allow dynamic behavior often required ‘ripping off the cover’ and doing difficult customization work – making changing processes even more difficult.

Well-established open source projects like Linux and Kafka and Ansible are great mature projects, but to get involved in improving them now, coding skills and an understanding of internal data structures, system architectures, networking, security and the like would be required. Now open source tooling is starting to bridge the skills gap and bring automation into the fold.

Software testing provides a great entry point for newer participants, because it isn't about coding, it’s about doing. Testing executes a series of human and machine actions, and validates results. So why not put that concept to real work as a repeatable automation framework? Robot Framework is an interesting open test automation project that planted the seeds for the next generation of automation.

Robot Framework uses the Python language, which makes its resulting code quite human readable. The simplicity of how properties are declared and the abstraction of real work processes as code brings Robocorp’s RPA project down to a skill level that is as easily approachable for new community members, as it is highly productive for experienced developers.

As many as 30 million individuals have contributed an incalculable amount of time toward open source projects that are now in production around the world – a 2019 paper estimated the current value of OSS at more than $118 billion.

Technically, any vendor could throw an install on npm, and a bit of their code on GitHub with a code of conduct and call it an open source project, but the real success of a project is defined by the level of engagement and variety of perspectives that arise within its community.

An activated community will spontaneously collaborate – sharing tips, problems, demos and work product in forums, newsgroups, media channels, Stack Overflow and git repos. No vendor should act as the single source of truth anymore.

The community of one automation project like Robot Framework can also generate synergies with other OSS products, with fascinating results for delivering on the promise of RPA.

Take for instance this cool story from Robocorp’s Jani Palsamäki pulling together several open automation tools to instrument a React front-end, or this video where “RPA Jargon Buster” Tolani Jaiye-Tikolo and her architect friend Devashish demonstrate a license plate reading app built over the weekend using open source test automation, machine learning and OCR tooling.

Google had to introduce Kubernetes – simply because there was no other way for this tech titan to overcome the near-total primacy of AWS in cloud computing by itself. [Honeypot posted a great documentary about it here.] 

By contributing their internal container orchestration tech to the entire development world and inviting global collaboration, they were able to usher in industry-wide adoption of an open-source cloud-native architecture far faster–and more sustainably–than they could have ever done using a proprietary approach.

Much of the value of open source comes from its ability to harden systems over time, thanks to thousands of practitioners encountering and working around any critical issues that arise in production.

Enterprise customers often prefer OSS because it mitigates vendor lock-in and de-risks investments in the processes they build atop it, as the most successful projects are more likely to continue to receive community support and improve the future utility of each program or workflow that is added.

There’s no guarantee an open source project will remain relevant forever, but it is extremely unlikely a useful one will be abandoned. Compare that to the end-of-support notifications and abandonment we have all experienced from vendors.

When an OSS project like Robot Framework is incubated by a foundation, that means it is being battle-hardened through code reviews, experimentation, refinement and real-world stress testing. The community of practitioners and vendors can then combine that project with other automation and orchestration tools to make it an essential part of a Gen2 RPA solution.

No matter who you work for, or what digital process you are designing and automating, letting your development teams get involved with OSS at any level is now a key recruitment and retention factor in the war for talent.

Attend an open source forum like KubeCon for cloud-native computing, or the upcoming Robocon for Robot Framework practitioners, and you will find an unparalleled level of sharing and genuine camaraderie going on.

After all, the most enjoyable part of success in reaching your own intelligent automation goals may well be realized by helping others succeed in this new, open world.

Open source: Bringing joy to the intelligent automation and low-code world

Do you need RPA bots or DPA platforms? Do you need to modernize your BPM with AI decision intelligence, build low-code apps, or make your automated testing frameworks more process-aware?

Enterprises face a buzzsaw of buzzwords when entering this forest of process automation options. Leading analyst firms have identified several unique technology spaces relating to the automation of business processes, but the lines between them become blurrier every day.

Looking at the amount of investment and sales hype happening in process automation, along with the analyst, consulting and platform vendor activity of segmenting so many products into arbitrary markets, it’s not hard to see why all this jockeying for position is happening. There’s a lot of money to be made in prescribing innovative solutions to fit such complex problems. 

Clearly, any business must become more agile, responsive and efficient in every operational aspect of fulfilling customer demand in order to face down competitive pressures. 

Every business process consists of many tasks, where automation would benefit the business if the work happened faster and used less resources to complete. And every automation approach must execute these tasks in a way that maintains context and respects the business goals of the process.

Therefore, I’d like to posit a way to see both the trees of automation, and the forest of process complexity at the same time.

xPA (where x means ‘Any’ process automation, or even eXtreme process automation, if that’s your style) is not another software market segment. 

xPA is the practice of understanding and codifying commonalities between all process automation tools and the enterprise’s application estate, in order to produce more reusable process automation assets.

Whereas RPA bots or some test automation scripts might operate against a web or application UI, and DPA might broker human requests and system-to-system processes against API services, xPA is not defined by its automation interface or the venue it operates in. The more application and service stops a given business or system process must make, the more relevant xPA becomes.

xPA can be informed by any combination of inputs:

Human input/intervention, whether defining, guiding or responding to the automation.

Invocation, how do you call the automation into existence, how do you end the automation, and what person or system can make such requests.

Process, a captured or codified procedure or set of steps to execute.

Branching, how to define alternate processes -- it’s a lot more complicated than a set of if-then statements that might have been stored in existing process silos.

Integration, defining the infrastructure for hosting or running the automation agent or workload, whether as a service or locally, and declaring how it communicates with other services.

Feedback, monitoring for status conditions and metrics gathered to continuously improve the process automation system, and help humans make better decisions.

These seem like rather generic inputs, but that’s intentional. While a specific business process definition and data within workloads may remain part of the intellectual property of a company and its customers, xPA automation itself should be open and understandable, making xPA inherently portable and reusable across interfaces and application silos.

Going back in time, xPA has many ancestors that contribute the best of their process automation lineage and capabilities to this practice. [If you were to try and make an acronym out of them, it would be ‘RPATAIADPALCNCBPM,’ which isn’t nearly as catchy as xPA.]

RPA. Robotic process automation often employs semi-autonomous ‘bots’ to replay the actions of human users on a web or application interface. RPA is a hot, high-growth space and extremely useful for imitating manual work. While dynamism is being introduced to leading tools, the rote nature of some captured tests can lead to brittle bots and excess maintenance work if back-end changes affect the presentation layer.

Test automation. At its heart, a test is really just a script for invoking an intended process and gathering results. It’s no wonder that much of the intellectual property we know in xPA comes from advanced automated testing tools and continuous testing disciplines. 

Testing happens at the UI layer, as well as invoking services through APIs and back-end integration processes and simulating real-world conditions and data for testing. Test automation is built into xPA because the business needs to ‘cause the cause’ within the software process to validate success or find failures. Ideally this happens as early as possible.

IA. Intelligent automation uses AI-like features for understanding work inputs and data, and reactively reassembling tasks and workflows on the fly, to reduce the need for human-attended automation. While a promising growth area for augmenting the capabilities of any flavor of process automation there’s still a lot of research to be done in this arena.

DPA. Digital process automation offered the next step beyond BPM in that it could possibly conduct process and data mining of more distributed processes that cross multiple services and invoke complex business processes at messaging and API layers, as well as some UI functionality, usually from a shared central application or SaaS. 

Low-code or no-code. Low-code is a huge technology category with its own galaxy of vendors –that of ‘app builders’ which non-engineering citizen developers can intuitively leverage their business expertise and leverage easy integration hooks to other systems to create applications. While not pure automation, the ability to create an application that replaces costly development and manual work is certainly a relevant contribution.

BPM. Business process management has evolved for decades, but BPM systems are still commonly thought of as a centralized repository and process engines for procedural workflows which other applications could reference to get instructions or next steps.

Even unrelated fields like cybersecurity and authorization play some part in this dance of xPA -- so that the process wherever it runs inherits the appropriate permissions to ensure the automation workloads are operating safely.

There’s a big difference between process and automation. A process should be a differentiated aspect of how a business functions, whereas automation is simply the means by which that business function is scaled to run anywhere it is needed. Automation doesn’t need to be proprietary at all. 

Technical debt is an IT management measure of the cost of repairing and refactoring old code and obsolete applications, and it has a parallel in process debt. Any process automation that takes more effort to repair than its utility value represents process debt and becomes a great candidate for an xPA transformation effort.

Don’t worry though. With so many options for process automation productively employed within enterprises, there’s no reason to pursue a ‘rip and replace’ strategy to ‘do xPA.’ Since xPA is a practice and not a tool, adoption means taking the time to rethink automation artifacts as resilient automation assets going forward.

xPA: Clearing confusion through any-process-automation

When a hot new business technology comes along, we see exuberant market size predictions from analysts, accompanied by heady ROI claims from vendors attempting to increase their valuation by driving customer adoption past early stages.

Despite the repeated cycle of hype, every generation sees a handful of solutions that justifiably achieve phenomenal results in the steepness of their initial adoption curve. 

Take for instance virtualization, and a few years later, containerization. Both arrived on the scene and quite abruptly proliferated through enterprises, replacing conventional servers and later, consuming VMs -- while offering an initial burst of infrastructure cost reduction and utility that couldn’t be passed up.

RPA (Robotic process automation) is a more recent phenomenon in the same vein. When the first generation of RPA tools came on the scene, they gained traction by capturing human-to-system manual work as replayable automated tasks handled by bots. 

Since virtually every information worker could use a set of extra hands to offload non-value-add tasks and typing, quick ROI was easy to identify. The RPA software market took off like wildfire in the mid-2010s, as initial vendors in the space envisioned a combined digital and human workforce pulling together in every office.

RPA can trace its lineage to many other categories of business process automation, testing, and task management tools used over the last decades. But with its first appearance still a recent memory, by any account RPA is considered one of the hottest tech growth markets going right now.

What could stop RPA’s unending ticker-tape parade of ever-increasing value, given such amazing early results? What could bend this exponential growth curve into a logarithmic one?

For starters, let’s look at who actually bought RPA. In most enterprises, the CIO or a similar IT executive role will lead a group making any significant technology purchasing decisions. While digital demands on the business drive annual IT budget increases, usually every dollar of that budget will already be allocated against cost controls to meet requirements with planned development, support and infrastructure costs.

Initial RPA vendors struck an impressive early vein of customers with business managers and practitioners who just wanted to take clicks off the clock and get more work done. Unlike early adopters in other spaces, these buyers did not want to think about software or coding at all. 

This first wave of RPA wasn’t discoverable as ‘rogue IT’ because it supplanted the need for IT in some regards. Vendors could circumvent the technology-led procurement process, and sell directly to end users who could start productively equipping themselves with bots, without needing engineering help. 

An individual employee could start small and buy a personal bot, a manager could expense some bots for the team and evangelize the new time-saving utility with co-workers. 

First-gen RPA generated quick wins that easily offset the initial cost of ownership, but as usage increases, license and support costs could proliferate throughout an organization for quite a while before coming to the attention of IT.

Bots almost immediately eliminated hours of valueless toil for many employees, generating an immediate one-time productivity boost and paying for themselves. 

As for what happens next, I’ve noticed a discouraging ceiling inhibiting further improvement when talking to Gen1 RPA adopters. The bots are inherently procedural in nature, especially when recorded and replayed from on-screen user steps. They become flaky and throw errors when confronted by unexpected changes or data payloads appearing on the screen.

Of course, it may be possible to go into one or more of the bot’s steps, and set alternative paths if the automation stops for some reason. This kind of error handling didn’t usually come standard, of course. One customer said as much as 25% of their RPA integration labor was devoted to coding error handling routines.

Better page the IT support desk and ask for development help -- the very thing we were trying to avoid in the first place. Or, call a consultant who’d be happy to continue maintaining the RPA bots you already have at premium rates!

Even if you can afford expert support, there’s an even flakier problem at play here: scalability. Many early RPA tools were never architected to handle today’s far more complex service-based and microservices workflows that can span hundreds of unique steps, and they reach a breaking point.

Companies confronted with this problem can wait around for a patch to resolve the rework and scale issues. Or, perhaps wait for the vendor of the old on-prem RPA to push customers onto their new SaaS edition (or ‘cloud’ edition) to at least have access to the latest updated version of the software.

Many customers felt burned when the utilization of their first RPA vendor dropped, and they made ‘lateral leaps’ to similar vendors who promised better support or modernization of a feature they wanted most, for instance, integrations to their specific CRM or incident management tools. 

The next best RPA may offer more current patches and incremental improvements, but factoring in bot refactoring and switching costs, it’s not really raising the ceiling from this ever-flattening value curve.

RPA is young, even in tech years. So how can we already be dealing with technical and process debt in this area, and what can we hope the next generation of RPA can do about it?

Stop layering on. RPA’s productivity can become limited by the scale of its own adoption. As more procedural bots are added and used, more effort is required to code adaptation and error handling into the bots. Break out of the temptation to keep adding more layers of automation to fix existing automation.

Go beyond screenware. In today’s modern, distributed application environments, while users might experience functionality at the UI layer, by far most business logic and data is dynamic and called via APIs through cloud-based services and data sources.

A next-generation RPA approach should be able to automate not just human-to-machine interaction, but the machine-to-machine applications happening behind the scenes via APIs and REST calls. Gen2 automation encodes both human and system interactions in parallel, resulting in far less brittleness to change.

Seek out higher utilization. Since a Gen2 RPA solution expresses multi-system interactions in the natural language of computer code, the resulting automations, whether captured or coded, are more easily componentized for reuse and recombination into more complex business processes in multi-tenant environments.

Track the utilization levels of RPA assets like you would any other critical assets within your repository and live application estate. Prioritize the early retirement and replacement of existing Gen1 assets with Gen2 RPA based on demand, as measured by current usage levels and service requests.

It’s time for RPA to live up to its full potential.

Distributed organizations are leaning on their digital backbones more than ever to support every aspect of business. When RPA automation assets are brittle, it can compromise confidence in nearly every functional aspect of a business, from employee enablement to customer services.

Gen2 RPA approaches should allow the enterprise to refactor and replace rote task-oriented bots with context-sensitive automation code that is both understandable by humans, yet speaks the language of our systems.

Blog

Robocorp offers its clients the ability to build, scale, deploy, and maintain their robot workforce.

All posts by Jason English, Intellyx

Open source: Bringing joy to the intelligent automation and low-code world

xPA: Clearing confusion through any-process-automation

The challenge of uptake: What’s limiting RPA’s full potential?

products

solutions

developers

digital workers

resources

company