Aaren Quiambao

Welcome to Coding Over Cocktails, a podcast by Toro Cloud. Here we talk about digital transformation, application integration, low code, application, development, data management, and business process automation. Catch some expert insights as we sit down with industry leaders who share tips on how enterprises can take on the challenge of digital transformation. Take a seat. Join us for a round. Here are your hosts, Kevin Montalbo and Toro Cloud, CEO and founder David Brown.

Kevin Montalbo

All right. Welcome to episode 37 of the Coding Over Cocktails podcast. My name is Kevin Montalbo joining us from Sydney Australia is to cloud co and founder David Brown. Hey, David.

David Brown

Hi, Kevin.

Kevin Montalbo

All right. And let me introduce our guest for this episode throughout his career in software development. Our guest has helped in automating highly scalable core workflows at global companies including t-mobile, Lufthansa and Zalando. He has also contributed to various open source workflow engines. He is the co-founder and chief technologist of Kunda, an open source software company, reinventing workflow automation. He also co-authored real life BPMN, a popular book about workflow modeling and automation. His latest book, Practical Process Automation came out just March of this year and we'll be talking about it today. Ladies and gentlemen, joining us for a round of cocktails is Bernd Ruecker. Hi, Bernd, welcome to coding over cocktails.

Bernd Ruecker

Hi, Karen. Thanks for having me.

David Brown

It's our pleasure. So I guess we should start by defining process automation. So maybe you can give us a nice definition of process automation.

Bernd Ruecker

I'm not sure if I can give a nice definition. So I mean process automation is a pretty broad topic in general. It means you want to automate typically the control of some kind of process or I would at least limit it to some kind of business process in this, in this conversation. But this is still a very big field. So we can use very different means to automate processes. It can be it can be something like RPA, we probably talk about that later on robotic process automation. It can be something very low code, it can be software development. And there are a lot of areas in software development to automate processes very different ways So in general, it's very important because we need to automate much more nowadays for, for a lot of reasons and digital transformation to be more agile, to be more efficient, to be yeah, just more compliant with certain processes and so on and so forth. There are a lot of reasons for automating But the ways we can do that are really there are a lot of them and that also makes the topic so overloaded and sometimes so complicated to talk about it.

David Brown

And I guess that's why you came up with the title of having Practical process automation is because there are so many of them.

Bernd Ruecker

Actually not. So let me try to clarify that. So I do that in the forward of the book. So II, I try to sort out the market a little bit and I focus on one, let's say segment of the process automation market, which is what I call developer friendly process automation. And I could even narrow that down to develop a friendly process automation by using technology like a brick. And that's kind of what I'm looking at in the book. I tried to make that clear in the subtitle of the book . Right. And that's what I'm looking at. II, I call it practical because it's basically rooted in all, all the real life experiences I did with a lot of companies, customers over the last, yeah, almost 15 years. That's why I call it practical. I'm not so much in just thinking about theory and concepts. I always want to know. Ok. What are the customers are doing? What are the real life problems there? I stumble upon every day and that's why I call it practical.

David Brown

And do you go through case studies in the book of real Life use cases?

Bernd Ruecker

In a way? Yes, I mean, you probably know that so very often you, you have an NDA, you can openly talk about the most interesting problems or the failure stories, which are normally the ones you can learn from most So it's, it's normally not easy to disclose use cases. So, what I do in the book, I relate it to, let's say relatively real life cases. Like also I'm looking at order fulfillment or customer on boarding or certain processes, certain scenarios we see at every customer and I we in the learnings I did at the customers very concretely without naming them without making it a concrete case study. But I think that works relatively well. So far I could get good feedback for that. And then I also tried to be consistent in the example, not to switch it in every chapter because that's normally a bit annoying as a reader.

David Brown

And on what makes a process complex is it, is it the steps within a process and the decision making within those steps? Is it transaction volume? Is it infrastructure and technology? What, what part of it?

Bernd Ruecker

It's typically a mixture of all of them. So it's first of all, it's kind of the number of steps. I find that in one of the most important things to look at. First, Do I look at like one or two steps? Only then I'm not really looking at what I call process automation. That's more task automation. I want to automate a single task in a certain scenario But if I have a lot of tasks in a sequence and probably go left or right for under certain circumstances, then this is free process automation. And then I can look at like the number of steps which normally relates to how many, for example, different it systems. I have to integrate how many different teams I have to send tasks to how many teams I have to interact to basically specify the process or roll it out. I might have to look at the size of the organization, the technical environment I integrate with, of course, the volume I want to run over that it's a very different thing if I run one process a day or if I run a million per second or whatever. So these are all aspects that count into the complexity of a process. Yeah.

David Brown

And when we talk about say, for example, API design and implementation, we have a methodology called API first where we get stakeholders in a room and we collaborate on the design and we iterate through the design with those stakeholders before any implementation. Do you recommend a sort of similar process with UML diagrams and that sort of thing sort of with the stakeholders to define the process upfront before any implementation?

Bernd Ruecker

Yeah. So if we look at process automation and VFL engines, there is something called B PM N which I find super interesting business process model and notation. It's an iso standard for defining these processes. So I wouldn't go for uml you could probably do that but B PM N is much more advanced in in how we can express processes. And one of the one of the big features of BPMN is that you can execute these models directly. There's not no weird translation, no code generation. It's simply it's defined how a workflow engine has to execute that model. And that gives you a lot of power also for the early phases because normally of course, you start with a very often drawing on the white board discussing certain requirements, probably drawing a first model. But then you can go into exploration very quickly. 

You can deploy that on a real engine and then probably you don't automate all the service task you want to automate later on. But you do what's called a user task. So you, you open up a form for the user instead in the first step, So you can click through a process model and say, OK, this now opens a form that would normally not happen because now it's automatically whatever is sent to sales force and so on and so forth. But it allows you to discuss certain requirements with business stakeholders which normally don't think in abstract models, they think in, in forms and screens and tasks and what happens next. And this allows you to get into that, that integration of understanding the process automating it step by step improving it very quickly. And that's a super, actually super powerful concept. We've seen that working quite often.

David Brown

Yeah, I understand. And what about the developers themselves? Do they require any specific skill set to implement process automation?

Bernd Ruecker

It's, I mean, it's kind of what I the struggle I also have in the book So if you look at that topic specifically, it depends very much on the tooling you use and I try to in the book, I try to be as tool independent as possible. I mean, I co-founded a plus automation vendor. So you can't always be 100% independent but I try to and for, for this question, it's the same problem. So you have to look at the specific to links and there is a big variety of these to link if I look at workflow engines and what I call developer friendly workflow engines Then the idea is to bring this methodology and that technology into the normal world of the developer. So it means that it can still write code in the programming language. You, you normally write it, you can write test cases as you normally write it, you can use continuous integration, continuous deployment. Like you normally do, you put it in your version control and that's the virtual engine is not an alien in that, in that regard. And then if you succeed with that and there are a couple of tools which are really good at that, then it's, it's not much you have to learn as a developer. Yeah, you basically have to learn probably that language like BPMN. 

You of course have to understand what's the workflow and what does it do for me? What's the API in order to use it? But just as an example, I'm doing these trainings for Riley also as a compliment to the book, it's a three hours training. So we don't have much time and we do a live lab and the attendees automate their first process including a service task, writing some code in roughly 20 to 25 minutes. And if they have coding experiences, it's not a big deal. Actually, the, the, the big complexity is normally, then the next step like, hey, what's the real api how, how do I integrate that? What, what are all the parameters? How do I do the data flow in the process? That's not so much a technical problem of how do I use a work flow into it? It's more like if you have a complex problem to solve, it's, it's, I mean, it's complex.

David Brown

Well, you did dedicate an entire chapter of your book to autonomy, Boundaries and Isolation. How, what tell us about these concepts and how they influence how we automate the.

Bernd Ruecker

So maybe I can give you a bit of the background story, why this ended up as a complete chapter in the book. And actually the next chapter is also rooted in the, in the same story. So if we look back in history, like let's say 10 years back there was, there were these ideas of B PM and so on, that was pretty hard, like 1015 years back and BPM for business process management and so on for service oriented architecture. And the idea was that we build services in the so layer and then we basically plucked them together in a process on the BPM layer. That was kind of the architecture. You always saw the pictures you saw It was always compared to LEGO, we had that LEGO building breaks the services and then you just build the process and that didn't work too well in a lot of companies for a couple of reasons But the, the big reasons which were basically all the same were OK. The tooling was not really good at the time, it was totally not developer friendly, it was very, very unhandy, but that, that was the one side, but the other side, architecture wise was that you distributed in a way ownership. 

So normally, if you implemented some business requirement, you had to adjust the process and you had to adjust at least one service. And that meant you have to walk around asking different teams, different people. Hey, can we coordinate on the deployment? How can we, how can we get that feature life? And it normally even was organized like, hey, there is this B PM team, let's go to the B PM folks. They have to help us with that. And this didn't really work well. And that's a lot of these learnings also led to these microservices ideas where, where you looked into, hey, let's build that one business capability. It does something meaningful for me and then you have that one team caring about all aspects and probably even run it and having these B PM layer doesn't, doesn't fit in there because that's kind you distribute the business logic into the microservice and, and a process. And there were a lot of discussions about that and I had hundreds of them with different people in like especially three or four years back. And that's, this led me to write all these thoughts down in a couple of talks and then in the book and describing how you can bring that together, how that can go hand in hand. And it's, it's actually very simple, but it's important to, to understand that. 

So if you implement a business process, if you automate a business process, that's typically a business capability, I mean, you do order fulfillment. So that's business capability, you do whatever new bank account, opening business capability. So you, you, you implement that as a microservice if you think in microservice is at least and then that you use certain process automation technologies like a work flow engine, for example, it's an implementation detail. So on an architectural slide, the difference would be it's not a layer on top, it's kind of within the microservice box. And that sounds like a small change, but it's actually a huge change in terms of how you think about that. And this is how I described the chapter going a lot into these questions for example, isolation means now the microservice team can fully decide how to automate that process. They might hard code it, they might use a workflow engine, a workflow engine B or whatever It's basically their decision for the important thing is from the outside. You don't see that you have an API where you say, hey, kick off the order fulfillment for example. And then this works and that's an important mind shift. We saw happening over the last years and it works actually very well.

David Brown

What triggered this mind shift? Was it microservices themselves? And these domain specific boundaries of microservices which kicked off that thought process.

Bernd Ruecker

I if I look at it from the pro automation perspective, yes, that was definitely the microservice movement. I mean, you could then ask what triggered the microservices move plan because that was kind of the initial thing. And I, I think there were a lot of these problems we had with so a and not distributing ownership, right, and not distributing or, or not assigning that to the right teams and, and having an organization that doesn't really fit to how we implement software. And that was kind of the initial trigger. Yeah.

David Brown

Let's talk about robotic process automation. You mentioned it at the, at the beginning and I think there is some confusion about the boundaries between workflows and process automation, business process automation and now robotic process automation is it just another new, an acronym that the technology industry loves to, you know, create? Is it something that we've been doing all the time or is it something different?

Bernd Ruecker

It's RPA is an interesting topic , you have to love and hate it at the same time I think. So there is one thing that, for the name, for example, we can probably come back to that later. I think the name is a big problem and it's not very accurate to what it does. And that makes it more like sounding like a hype thing. But if you look at what RPA does, it basically means that you, that you use some, some technology to steer user interfaces automatically. And this allows you to automate things by clicking around, like the computer, clicks around themselves. And this is very powerful in a way that it can easily automate things you did manually before. And if you do these kind of products, normally, what you get is a very instant return. OK? I save labor, I save money pretty quickly. And that makes it so great. Actually, that makes it a big success and we see a lot of customers applying it in first products, seeing the return and then start to invest more and more. So that's, that's the, let's say the, the, the good side of, of RPA and there are a lot of good things around RPA like, especially if you, for example, have a legacy systems that doesn't provide API SRPA can help because then it can integrate that in automation. But there's also a big risk and I think that's not transparent enough for a lot of people are not. 

And they just don't have it front of their head because these, these, these integrations on your eyes, they're, they're typically very brittle. That's the one problem we see happening. So if you whatever, if you just update a browser version, sometimes things break if you update operating if versions update. So they are normally need a lot of maintenance on a, on a very fine grained level That's one thing probably. But what I find the actually the biggest issue was RPA and now I come back to the name and sorry for doing such a long sentence around that. But if you say robotic process, robotic process automation, people think about processes and this is not what RPA does. The idea of RPA is from my perspective, task automation. They automate a single task like, hey, enter this customer in this system or, or do this And then it's, it's still in a way a process because you have multiple steps to do that. Hey, go in this field, go there, click there, do this But it's not really a process in, in what I call a business process. So it's not a multi step. And if you then start to apply RPA for these real business processes, then it normally gets a mess because you start to mix granularity of clicking around in a UI and like the bigger steps in a, in a business process And yeah, and, and, and this gets really really problematic over time. We have a super story which we can even refer to which I love with Deutsche Telekom, for example. And there's a whole recording of talks and slides available so you can dive into that. And, they also started with RPA with a, with a small use case task automation for and basically line diagnosis, a technician does that he had to call in before. Now he could use a phone and the bot basically steers your eye instead of human. And that was a big success. And then they started to move into RPA and they ended up with I think 3000 bots. 

They had millions of bot transactions, saving a lot of money with that. So it was kind of a big success, but then they ended up doing bigger processes and they understood that this is not maintainable anymore that they can't really understand the processes. They get a lot of spaghetti integration They had a lot of issues with that. So then they integrate, then they did something which I think is the right thing to do. Then they separated the, the bot layer, the task automation from the pro automation layer. So they, they, they added a brick line which basically orchestrated certain bots and then they pulled up the real process on the, on that process orchestration layer. And then they called out for the bots whenever their task, whenever it's turned for their, their task. And that was actually a big success. And now they, they have this architecture for, for all bot orchestrations. And this also allows, and I find that important aspect of RPA, this also then allows to replace bots with real API calls whenever possible because the business process itself doesn't really change what's in that one box does change you no longer use a bot but an API and they do that. And for that was not Deutsche Telecom. I think it was RBS who called RP a technical dept. So every bot is a technical depth because they, they basically say it's brittle. So we have to think about yeah, basically the strategy to remove it later on and then you can easily do that. 

David Brown

Yeah, it's interesting that they defined it as technical debt that's, that's taking, I mean, most people would be just starting to embrace RPA and they're so far down the track. They're saying actually this, we can now considering this technical debt, can you elaborate on that a bit further?

Bernd Ruecker

Yeah, I think as I said, it's actually a little bit of both sides and I know that technical depth is a term for that is pretty it always leads to discussions, but the idea is really OK, you can easily apply it you can do it but it's not a really long term solution, especially because of the brits of, of these parts. If you have a real API integration, that's much more stable, you can much easier to test that again. All the good software development practices, we know we can easily apply to API integration but not to a bot and that makes it at least a risk

David Brown

I understand. So basically RP is like a, almost like a workaround that we're, we, we're doing UI manipulation or we're, we're scraping a PDF file or a website because there is no API available. If there was, we would make a direct API and do it properly in the first place.

Bernd Ruecker

There's a second flavor to that. So even if the API is available and that's very often the bigger problem, you don't have the right people to do a proper integration, you don't have software developers or you do, you have them, but they have other priorities and that's what we see a lot. And I think this is the biggest risk we have there because then you can, I mean, on the good side, you can automate something even if you don't have these people at hand. If you, if you use RPA, that's cool , but in the long run that gets very risky. For example, Telecom does that. They , very often because I also asked them, hey, if you do all these RPA stuff, doesn't, I hate you. It's like, I mean, they, they probably get all the, the problems with that and they said, no, no, we even , we even,, fostered our communication because now if we, if we want to do an integration, we talk to each other and they say, OK, we, we can do that. There's an api no problem, but we don't have time now, we can do that in whatever a year from now. Why don't you do an RPA board in, in between? So they even propose that as a temporary solution. And if you apply that for, for, for this kind of thinking , I think then it's, then it's fine, you just have to manage that risk. And of course, the risk is that you don't replace it in a year. 

David Brown

But this is what you refer to as a short term painkiller RP, being a short term painkiller, short term solution before we can get to where we want to be with this task which is a proper api implementation of the-

Bernd Ruecker

Yeah, exactly. And we always painkillers have the risk that you don't feel the pain anymore. 

David Brown

So, yeah, interesting. You've been doing this for as you say, around 15 years or so and, and you've obviously seen a bunch of evolution in, in, in the vendors and the process and microservices and the, the way you architect business processes, like you're saying, through autonomy, boundaries and isolation where, how, how do you see it continuing to evolve? Where are we at now? And where are we moving towards in the future? Do you think?

Bernd Ruecker

So I can, I mean a couple of things again, if you look on the on the higher level of process automation, I think we see these different also categories of tools not melting together. I wouldn't say that but getting closer together. So we currently, we have RPA, they also extend in their execution capabilities for for automating processes There's process mining, that's a pretty hot topic as well currently. So if you have implemented processes which are not in, in, in a work flow, in a, in a, in a process automation tool, we still get some visibility and understanding these processes. And we have these forester called CPA digital process automation. That's kind of the category of these work engine tools where we are also located and we extend our intelligence as well as the integration to RPA. So there these are the big three categories and somewhere in the middle there, there are some use cases melting. And I, I think this all has just started. So we're seeing a lot of adoption of these tools. 

So I would assume for the next 5 to 10 years, we, we simply see people doing it. So there, I don't expect to much big disruptive ideas here, to be honest, I mean, we had a couple of them, but overall, we simply have to do it. That's my feeling Of course, on on the level down there, there is a lot of innovation and disruption happening. So for example, most of the tools are now also provided as a cloud service. That's a big change. Now you have cloud services for providing process automation for providing the analysis. So it's much easier to apply them. And we can do it on a very different scale, for example. So we have use cases now where we look into payments, for example, or trading. So so high volume low latency use cases which we never could tackle with these kind of technologies 10 years back. So you can apply to much more use cases nowadays. So there's a lot of this kind of innovation happening So my expectation is that we simply also see it much more over the next 5 to 10 years.

David Brown

Yeah, and I'm guessing technology is going to push the boundaries. Whilst the process itself doesn't change things like edge computing and internet of things, devices and stuff being incorporated within business processes and workflows is going to make sure that the tool sets and vendors have to be able to incorporate these technologies within their, within their own state to accommodate a business process. But under the underlying business process itself really is is not changing significantly. As you said that it's really now about that digital transformation that everyone's going through and for the next 5 to 10 years is just going to go through the motions of starting to, to digitize. 

Bernd Ruecker

Yeah, I would agree. I, I can, I can double down probably on what he said with the, with the it stuff. So what I'm also seeing is there, there are even a lot of new news case emerging in that sense, like having a lot of events getting insights out of the events and that leads to a lot of like automated processes where you have to rec and stuff So there, there are a lot of things happening, but despite that, it's exactly like you said, we, we simply have to, to digitalize a lot of things. 

David Brown

Now, Bernd, very interesting to talk to you, where can our listeners follow you on social media and, and stay in touch with what you're writing and doing.

Bernd Ruecker

So, the easiest is always either to follow me on Twitter or on linkedin. I mean, these are typical sources, not a big surprise, it's Bernd Ruecker. So , if you don't know how to write that you probably make a hint in the podcast, but it's a Bernd Ruecker, and that handle is typically used everywhere, github, linkedin, Twitter and so on so forth.

David Brown

Great. And your book, Practical Process Automation is available at amazon.com, I'm assuming Riley. 

Bernd Ruecker

There is even if you go to the to the home page, maybe that's easier to, to remember it's process automation book.com. You can even get a currently a free PDF copy that's sponsored. So for the next, I don't remember exactly six months or so,

David Brown

Bernd. Thanks very much for your time today. It was very interesting to have you on the program.

Bernd Ruecker

Thanks David.

Kevin Montalbo

All right. That's a wrap for this episode of coding over cocktails to our listeners. What did you think of this episode? Let us know in the comments section from the podcast platform. You're listening to. Also, please visit our website at www.torocloud.com for a transcript of this episode as well as our blogs and our products. We're also on social media, Facebook, LinkedIn, Youtube, Twitter and Instagram, talk to us there because we listen, just look for Toro Cloud on behalf of the team here at Toro Cloud. Thank you very much. For listening to us today. This has been Kevin Montalbo for coding over cocktails. Cheers.