Roger Berkley - Monday, 6 July 2020.
Will robots also dribble on a basketball court?
Disclaimer: this article appears to be triggering some Business Process Management professionals into thinking that the article suggests that Robotic Process Automation Systems (RPAS) are made to replace Business Process Management Systems (BPMS). It's important for me to note at the outset, that this article refers to Business Process Management (BPM) and describes the modelling notations used within a group of both BPMS and RPAS. As a BPM professional and a user of both BPMS and RPAS, I'd like to point out my assertion that BPMS and RPAS are not replacements of each other and that they both fall under the umbrella of BPM technologies. Read at your own discretion :)
The mid-2020 poll made in a Linkedin post by Jignesh Khakhriya.
Important note: the poll is still open and the results are subject to change. The poll will possibly be always open as it is a LinkedIn post with emoji-based voting. Yes, it is not statistically representative or anything. But this is also just a journey of admiration post.
The poll results show that the more popular RPA software in use among developers are model-driven process automation like UiPath and Blue Prism. More so than textual process automation like Automation Anywhere and other platforms.
Let's go a bit back in time and explore this from a contextual perspective.
BPM research groups have long studied processes mathematically, textually (programming), and visually (programming). Meanwhile, the BPM professional community has for long discovered, modeled, simulated, designed, developed, and deployed business processes primarily visually.
The visual practice of the BPM community is performed with various standard public process notations and sometimes with vendor-specific or organization-specific ones. This continues to be the case in almost all Business Process Management Systems and in most Robotic Process Automation Systems.
The limitations of concurrency in object-oriented programming have led to some early textual process-oriented programming languages in 1992. These early languages first introduced applied means to programmatically represent concurrency at process runtime.
The 1992 process-oriented programming languages were a breakthrough, as they syntactically separated actor-object concerns and enabled the Actor Model in BPM. This allowed asynchronous communication and control structures - as patterns of passing messages among actors. And that made representing and executing concurrency in processes much easier and more useful than representing the same in object-oriented programming languages.
Examples of these early textual languages which are based on PM-Graphs:
And the textual ones which are based on π-calculus:
The year 1992 was a turning point for BPM as the domain started to move away from Turing-complete imperative languages towards λ-calculus-based functional languages and π-calculus-based process-oriented languages. You can see this document for a brief on the rationale behind that shift from Turing to λ and π calculus. Then you can take a look at some of the first values, patterns, and processes in textual Pict.
From that early textual process-oriented programming foundation in 1992, nearly all process notations until today in 2020 have had visual constructs aligned with their mathematical and textual base (whether XML, XSD, XSLT or other).
I'm not trying to say that representing processes in textual Pict or another concurrency-enabled programming language is wrong, because it's not. What I'm saying is that the visual extension of the textual foundation essentially makes the language that much more accessible, usable, useful, and comprehensible to a wider audience among both technical and business users.
Let's see how that visual extension looked like in the last 20 years or so.
A quick roundup of some of the visual paradigms of BPM since the late 1990s to 2020.
This article is not meant to be a complete journey in the history of process models in BPM, but only a quick and brief one. There are many other process-oriented programming languages, standards, and visual notations in the same time period from 1992 until today, here's another one:
Readers who are interested in the prior model eras until 1990 can check this article and navigate from Carl Adam Petri and his Petri Nets of 1939 (formalized 1966) to the modern day. Petri Nets have been monumental in setting bipartite graph cyclical-logic and token-based transition logic in modern BPM and other computer science.
Scholarpedia reports that Carl Adam Petri invented Petri Nets at the age of 13.
Here's a two-token transition logic in a Petri Net:
Similar and more sophisticated transition logic is present in all modern BPMS and RPAS, both the textual and visual ones. Similar logic also applies to valid BPMN 2.0.2 process models.
One major limitation of the textual only automation platforms is that they completely miss that visual element which is at the core of process thinking. It's true that one picture is worth a thousand words, what if that picture is the blueprint to your automated digital business? How much would it be worth?
I'm completely surprised that you're still reading this article, so I can only try and surprise you with this Petri Net from 2010 which depicts the behaviour process of a ball-dribbling physical robot. Petri Nets are proving useful to modern Roboticists 71 years after they were first invented.
I hope you enjoyed reading this and looking at some historic and modern visuals of BPM.
External contents in this article are linked to their sources, I tried to keep this error free as much as possible, in case you find any errors, let me know to correct.
Any copyrighted material in this article are used via the Copyright Disclaimer under Section 107 of the copyright act 1976, allowance is made for fair use for purpose such as criticism, comment, news reporting, scholarship, and research.
This content was first published via Linkedin Pulse.