Courtesy of Camunda's Bernd Rücker, below is a transcript of his speaking session on 'Practical Process Automation' to Build a Thriving Enterprise that took place at Digital Process Automation Live.
Practical Process Automation
Modern IT architecture needs to create connected business solutions out of individual components that are decoupled and independent by design. It needs to include people as well as legacy systems but still automate processes to a high degree. And all architecture choices will influence the business agility and innovation capabilities of the whole organization.
In this talk, I will discuss process automation as a centerpiece to solve these challenges and enable successful digitalization. I will dive into different ways to automate processes and share some real-life stories which will give you some guidance for your own process automation endeavor. I will present a developer-friendly way to automate processes and look into the journey to introduce this in your own organization.
From Germany, today, and thank you so much!
Burn, Rucker for being here with us.
And, burn is the co-founder and Chief Technologist, ..., Gordon is a software developer at heart who has been innovating process automation, and deploying, deploying it in highly, scalable and agile environments of industry leaders such as ...! Stanza, IMG, and Atlassian contribute to various open source workflow engines for more than 15 years.
Barn is the co-founder and Chief Technologists of Commander and Open Source Software Company. That is re-inventing process automation. His work focuses on new process automation paradigms that fit into more modern architectures around distributed systems, microservices, domain-driven design, event-driven architecture, and reactive systems. Burn. Thank you so much for sharing your expertise with us today. We're very excited about your presentation.
Thanks very much for the introduction.
Can everybody see my screen? I think Denver? Yes, Awesome. Great, yeah. Thanks for having me.
Thanks for joining today's talk, I want to talk about Yeah. Practical process automation.
It's kind of a wide field but and I think you're sales already to give you some context and I think it's not a big surprise nowadays, I mean, we live in the age of digitalization.
I love this article, Why, why all companies Fear by death by Amazon, and that can have different angles. So, one could be, like, probably, Amazon puts you out of business directly or they're competing with you, or some fintech, or ensure tech, or whatever is competing with your business. But also, on the other side, these companies are setting the bar for customer expectations.
And these expectations are rising because of what, like companies like Amazon can deliver.
Yeah, and that's, that's, That basically affects everybody of us.
I, I love this, The survey a customer told us about, it wasn't an insurance company in Germany, in this case. And they did a customer satisfaction survey. They do that every year, and then they basically look at the numbers and how they develop. And they looked at that. And it was 2018, so even quite a while back, so it must have tracked traumatically and decreased since then, I don't know.
But they looked at all of these numbers and saw KB, satisfaction with the speed of claim settlements like trapped and traumatically in a way. So they looked at, like, OK, what's the speed of processing of claims settlements? It wasn't nearly constant. So they're not getting any slower, but the customer expectations have risen. And that means the, Yeah, the satisfaction.
Yes, yeah, much worse. With the same speed of claims settlements. And that's a problem they have to deal with.
I was sitting together, it was ... with a CIO of a German insurance company during lunch.
And he basically told me, OK, DevOps, very humble, I liked that actually. But he also said, We don't know what really build the tomorrow. I don't have a magic crystal ball.
I can't foresee the future, but what I know is that there will be change and then there will be big changes coming up. And whenever we see them coming, whenever we really anticipate what's happening, then we have to be in a position to be able to move quickly.
Right? And this is my job to bring us there, to bring us into that position, to be, to move quickly, And that's about agility.
And that's, I think, what is all about nowadays? And we had that agile movement, like agile development, For example, software development. Like, 10 years, 15 years back, that was a huge thing. So, we understood a lot of these practices by now as an industry. But now, it's really about business agility, like probably introducing complete new business models, changing the way we're working traumatically from today to tomorrow, and that's about business agility and that's super important. I also look like to up the, like Forrester report, for example.
They published in November, 2020, so it's pretty recent and they, they were saying also like because of the pandemic, now the metric for success isn't cost efficiency or even business agility, it's velocity.
And that I find that interesting, the speed of business transformation is the most critical metric for every company.
OK, I put that a little bit out of context, but I find that super important.
So, business agility and the speed of doing things, the velocity of changes.
If you look at velocity, I totally love the following book. It's called Accelerate. You probably know that it's not a it's not super hidden, but I am. I always find it surprising. How many people have never heard of that book? I loved it. I can totally recommend that.
It's what they did.
These folks riding accelerate.
And they basically survey, or, yeah, they study a lot of different companies around the planet around different industries, really a huge size. So you sample size companies, how they do software development.
What's the practices, certain things they do, and they don't do, and they also look at the success of the company overall.
And then they publish their learnings from back, but in a very scientific way. It's not like, hey, we asked 20 random CIOs, what they think, it's really, really, very scientific. That's what I like about that. So, we can use that to really try conclusions with a very good foundation.
And if you're not into reading the book, I can also understand that time is limited.
I can recommend to read the report. So, from the methodology, what they describe in the book, they try and you know numbers every year, and then they publish that FTE so-called State of DevOps report.
So there was one in twenty 18, and you see there, they're normally sponsored, which also means they are available for free as a PDF. So, you can just Google for it. Get it.
And they are published, like with the latest numbers, normally, every year. So there's even a State of DevOps report 2020 for Excel if you want the latest.
If you look in these reports, I just drew a couple off, Couple of insights.
one of the thing I've found, very interesting, because that's why it matters, is that they found that high performing organizations were consistently twice as likely to exceed these goals, which are profitability, market share, and productivity as low performers. So, in my words, it really matters.
It makes a huge difference if I'm, if I can be twice as successful, Alright? But what is the difference between high performing, low performing organizations?
So, when you look at that, they basically look at the software development practices. They have in-house, and they're basically saying, OK, lead performance.
Half, 46 times more frequent code deployments, And I'm coming back to that, What that means in a second, it basically means there, the elite performance pushing every commit to production, immediately continuous delivery there, to 2555 times faster, from commit to deploy, so it's really fast. They have lower failure rates because of that, normally, because they have more smaller commits, and they're pushing them to production very, very quickly, which leads to less failures. And if they have a tailor, they can recover fast because everybody knows updates. So there are a lot of these things are Interconnect, so that are impressive numbers. That's what, I'm trying to get it. And just to give you an idea, I don't want to walk you through the details, but to give you an idea of what that means, deployment frequency for Elite performance are on demand. So really commit, deploy multiple times per day.
The time for change is less than one hour.
And I know organizations that, that take months to deploy change, and that's normally here between one month and six month.
That's not totally uncommon.
Then you're on the low performers, and so on and so forth. You can read that yourself, just trying to get at that. This is really important.
And what they also find, and I like this, because I was discussing that vary very regularly with bigger organizations.
Because Gardner coined the term of that bimodal IT where they basically said, OK, you must have different speeds, different velocities in your company, because you have these, like big ERP like systems, which, which keeps all the records, and they, they must be stable, so you move slowly.
And then you have these, like small, iterative things for new innovative products or business models or processes around that.
And that can evolve quickly.
And what that book found is that this is nonsense, if you, if you go for a process for the development process that gives you, um, the speed and the continuous delivery, you get both to get the speed.
But also stability because all the numbers before.
So, this is kind of the way you should aim for as an organization. If you look at software development, I'm looking at what that has to do with process automation in a second.
And industry doesn't matter. Also found that interesting, because I hear that sometimes RBR in this industry, we don't do to this were to whatever for continuous delivery.
No, they're not shortcut. So, and for me, process automation is one of the core enablers of digitalization, business agility, and velocity.
And I think today, I don't have to talk about the benefits of process automation, right. So, what we just talked about, business agility, time to value, efficiency, customer experience, it's improving, you can scale everything and so on and so forth. So there are a lot of these benefits. I don't have to talk about them today, here, I think.
But what I want to talk about is how do I get that into, into my company, into my undertaking, because the reality is actually heat sometimes pretty frightening. So on the one side, you have all these organizational challenge. It's like, whatever your organization is look like. It's kinda there. You can't ignore that. For process automation. Projects, you have Legacy, You have a lot of IT systems.
Most companies, I know have really old legacy systems that needs to work in order for the business to continue and they can't replace that, like, immediately big bang, but they have to gracefully move away from that. You have, at the same time, an increasing number of IT components or applications.
I mean, almost daily new stuff is popping up that you need to add up to and at the same time, and this might come back to that later on, because this is very interesting. At the same time, do you have a limitation of resources, developers, for example? So, we would need much more developers in order to get process automation, right? But they're just not on the market.
At the moment, they're not that, Not enough people knowing bad, which we could could bring into the job, OK, So this is kinda the relay realities, so the question is like, how, how can we succeed with process automation in this environment?
And, I thought about that for quite a quite a bit, And, I, I, did something, or I developed something, I call the process automation, where I want, I want to walk you through this a little bit because, that, with the customers, I discussed that, that gives them a bit of orientation, how to maneuver in this environment. And, what are the big decisions you normally, always make in the very beginning?
Do you buy something, or do you build something yourself? So I talked about software development in the beginning.
Do I really have to do software development or kind of access buy a standard software? Which does everything.
And that's a very valid question.
And I mean, one of the important things here, it's not a surprise, and it's not very innovative but it's important is, can you differentiate by using standards?
We have a lot of telecommunication companies as customers besides insurance, banking and stuff.
We also have a lot of telecommunication companies, and they all use these operating software for the networks, and most of them use kind of the same software. And that's why I love this story. And that's from AT&T, quite awhile back in the 19 seventies. They had kind of a monopoly on long distance call in the U S long distance calls at that point in time were really, really expensive.
So you thought twice before doing a long distance call. It's not like today, it wasn't really expensive.
And AT&T had competitor, called MCI.
And what they did, they thought off a new business model of saying, Hey, we can have a circle of friends and family, you can define that.
And you can make calls to that circle, only these persons for local local.
For the price of local coal spacing, that was kind of the idea.
Now, AT&T, and that's what's interesting, part of that story, AT&T, tried to stop that legally didn't work, and then they couldn't compete with that, Why? Because they're software.
Their operating software couldn't handle that business model.
There's there's a bit of more documentation on the web available as well and that mean men because they have this kind of standard software plays they can probably can't support that process which would be needed in order to to beat competition.
That was a huge, huge lose for them on the other and that's kind of by personnel thing at the moment because I'm or family is involved in a lot of these. Yeah, ecofriendly shops or economic shops, and if you look at a lot of these shops which are evolving today, what they do is they bill, they sell very specific items.
Right? Very. Whatever they are.
You probably know that better than me, but there are a lot of specific characters of these articles.
But the shop itself, it's totally on. You'll have a shop off the shelf. The order fulfillment processes are standard. So you're not innovating via the process, but you're innovating by the product you're off.
That's fine, I mean, it's just means you have to know what you're having in front of you in order to decide.
And these are the, for me, the first, job access are these process automation map.
So one could be, do I want to, or do I need a standard process like the order fulfillment in these shops?
Or, does it have to be very unique? I have a couple of other examples later on, something like, hey, I have this, whatever customer onboarding process, and I need to talk to these 20 degrees C systems, which are very unique. For my situation. That's a very different thing. And at the same time, you have to decide if you want to innovate via the process, so can you live with it with a standard process? Because it's fine. You don't innovate by process, or should the process be the part where you really need innovation, in order to get in front of competition. For example, our insurance is using, like telematics, for example, that that was, I mean, starts to get more normal. But it's still pretty innovative, and it changes a lot of the business processes operate.
And now, the interesting part is, if you have these kind of map, you can basically rate your processes, and then you have sweet spots. So, for example, if you're, if you're in that corner and saying, Hey, I have a standard process. I don't want to innovate.
You buy software.
If you're more, on the right hand, upper corner here. Say, I need a very unique process, and order, and I want to innovate with a process. Then you need something very tailor made.
And then you're in the realm of building, OK? And that's important to keep in mind. There is no one size fits all. There's not a buying, it's always better than building, or the other way around. You have to understand what you have in front of you to basically decide for that solution.
As you can see, there are a couple of more access and there are pretty interesting, so I wanna walk you through that, and I think this was kind of the warming up. I was kind of the easy part. one thing, and I find that particularly into interesting at the moment, is the scope.
What do you want to automate?
Do you want to automate one task, or do you want to automate a real process?
And I give you an example of where I want to walk you through that, and that's kind of the classical, because there's a lot of misunderstanding in that axis, at the moment, in the market.
So let me walk you through one example.
It's again telecommunication, I'm sorry for being a bit telco here today. But this is a technician off the German telecom company, doctor Telecom.
And if they do something, hard wiring with the lines, what they do, what they have to do afterwards is they have to check if the line is working.
And it was, When did they start that product, 20 16, 2017.
So a couple of years back, actually, the way of doing that was they had to call an inbound colleague saying, OK, this is the number I want to tag ozone.
And, then, the, they involve colleague enter data, and the legacy system, the legacy system, by tech, presented the result on you're done.
In order to do that, to technician had to wait.
And in line for 3 to 5 minutes, before somebody was available, like, on average. That's pretty low.
So, overall, this, this task was, that's what was relatively slow.
It took a long time, and if you extrapolate that for all the technicians all over Germany, that's quite quite a lot of time based it. So, it was also very expensive. Not only this guy has to wait, and these persons also need to be there. It was pretty annoying for everybody.
So it was far from being a good process, a good task, what they did.
That's what you all to know about, robotic process automation. I mean, should say, also mentioned RPA in the beginning. It's, it's kind of a hot topic. And I think you're most probably familiar with that. If not, this is my one. Slide explanation for RPA. It's kind of the Microsoft Excel or Microsoft Office Macro Recorder. That's what a lot of people know, right. You click on record, and then you can click around and the record, I records that, I can replay that later on. To automate simple things. It's ..., so it's a bit more powerful than that, because he can steer any application you lie by its front end. And then we get these kind of flows, which, then, can automate this interaction with a user interface. That's kind of the idea of RPA. Very often, the history of RPA tools is around automating tests based on user interface, OK? This is RPA.
And they use that in order to automate the entering on the Legacy system.
And then the technician has portal, and an app, basically on his smartphone, doing something, getting back the result immediately. So that was a big win for everybody, that was a great project, very successful prototype to telecom. So that's a good application of RPA.
But that's interesting.
And I link the talk on one of the next slides because they did a full talk at the common knock on about the whole project and their journey, because now, that was a successful project. But then a couple of problems started, and why is that? The first, and I don't want to go into details about that today, was kind of a governance problem, because this was driven by, by basically the business, other business department started doing stuff as well. It was not well co-ordinated. It was not clear who operate at the stop. And they ended up with, I think seven different RPA plat firms and they had a lot of issues. So it was not easy to govern. That was about the problem.
But the second problem, and that's what I want to talk about today, is, they were mixing tasks and process automation, mixing things up. And I want to explain that with an example. I blocked about that quite a while back.
There's the link, a typical RPA flow, looks a little bit like this.
Hey, open this application, go into that field, enter something there, press that button, and so on and so forth. And at some point in time, it might say, OK, now, open another application, to enter the same data there, for example.
So, what it basically does, it mixes a lot of the UI interaction for one task, like entering data into the CRM system, with all the UI interaction for another task, which might be create the order in the ERP system.
And if this is all mixed up, you can't see the forest for the trees anymore. So you should separate that. You should look at the process, automation layer, what's like the sequence of activities or tasks and how to automate a single task. And that's a very different thing.
And it has different requirements. And that's important, too, to separate.
Just keeping in the example of op or staying in the example of Deutsche Telekom, they kind of did that, exactly that journey.
So they started very manual, that was a technician calling.
And then they basically automated part of that by RPA, but they ended up in what they call spaghetti bot automation.
And then just then they started to extract the process layer, say, OK, we need to orchestration above these RPA bots in order to separate the both concepts. And what they are currently at is a lot of replacing bots with real API calls because APIs are much less brittle than bots.
Right? So, it gets a much more stable solution.
The barrier, if you want to look into that, that's what I meant. I link to the blog post, and there's the recording link, so you can look into everything they talked about yourself.
So, I find this very important different, So, do you look at task automation or PaaS automation? And if you look at low code tools, for example, you have the same thing, if you look at things like, say, pure.
They typically automate one, task one thing, but not the process.
Nice, the next axis I have in here, it's the process complexity.
So you might have very simple processes where it just integrate. That's a one system.
But another, this sometimes might even simply be task automation can be very simple, but it can be very complex, very involve a lot of different legacy applications. But a lot of different APIs, probably involving different teams, different development teams to take part are different users to be notified via hospice or whatever. So that can be a big variety of complexity.
I added scale as a separate access.
It's sometimes interwoven with complexity, but it might be that I just have one team solving a very local pain for them.
Right? Or it can be a big scale.
Which means, again, I involve a lot of applications, people, or I have a large volume of instance.
It's like, I'm doing order fulfillment, and I have millions of artists to date.
That could also scale.
And the last one is the product setup. Also, this can be a wide variety.
So you could, you could have a now talk product, we have this pain, we need to solve it now, but, now, we don't care how good we solve it. We just need to solve it now. All. We have something which is temporary. We need to do that data. We need to fix that data, like now one time, then we throw everything away. That's a very different thing than setting up a project and saying, OK, I'm developing a process solution for the next 5 to 10 years.
All right, or we have customers running a complete department for certain process automation products.
So that's a big variety of things.
And now what you can do, that's the exercise you should actually, if you want to automate a process, you can rate that on this map. So with a technician example earlier on the telecom technician, it's relatively unique.
It's doesn't have to be very innovative, I mean, unless you count using the smartphone as innovative, which might be true for some companies, it's not too complex. It's not a huge scale. Its Task Automation Board, and its process automation RPA might be fine.
And it's somewhere in the middle.
And by the way, this is my gut feeling, I, this is nothing, I designed together with telecom. That's the disclaimer I want to make here. But then I can easily show it here. So that's my gut feel.
I have other examples, and if I looked through official case studies from us from kimono, that's pretty cool. Because I can quote them here.
But I start doing this exercise with a lot of different customers. And it's very interesting, actually, to have this discussion.
So, in this case, **** Zana that says west insurance company, they wanted to sell insurance directly online within two days, which is kind of an innovative process.
Like people are coming to the web portal, identify themself and do everything online. This is not how they traditionally labor needed paper to send around and so on and so forth. So, it's relatively unique because they have to integrate a lot of their own legacy system. So it's nothing they can just buy. A software will automatically Burke it's relatively innovate if that's what I mean, it's not the diff the standard that people do that themselves online. It's not too complicated thought, the huge scale, but it's definitely a process and a plant plant setup.
And to get a bit more on the other end of the scale, one other customer from ours, in Germany, at Zalando, they are pretty active in Europe, they are kind of the Amazon for cloth in Europe, and they do order fulfillment with, come on.
So they have these 145 million annual online orders processed.
They have, for example, runtime requirements, because they need to be very, very quick and responses to the customer, like below 300 milliseconds, for example, And there, they use also come on that. So if you look at that order fulfillment process, for example, It's it's pretty much on the This acts of the spectrum, so it's very unique for a lot of reasons what they do in the art of perfume and you can simply by that in a shops up there.
It's not super innovative, but they do a couple of things which are really innovative for for order fulfillment.
It's Not super complex, but relatively complex, but it's on a big scale. It's definitely a process. And they have their own department running.
That's where this is located in a way.
And now, you can do the same exercise for the process you automate. And that's important thing. It's not a company wide decision. Hey, we want to be on that side of the of the map. No, you have to look at that one process you want to automate, and then you, you have to understand where it fits. And of course, there is some fuzziness involved. But you do normally can can spot the area where you're looking at. And then you typically have sweet spots.
All right. And the animation seems to be proper.
So, we already talked about commercial off the shelf software.
You simply buy, or, you build something. If you build something, this is how it can read it. And then you can decide between local, that's pretty high at the moment, or what we called pro code. So, or I prefer to term developer friendly, too.
Like, on this or that. And that's an important decision you have to make And it has to fit the process. You're looking at. That's important.
And the difference is really that on the one side of that spectrum, you give developers tools that they can easily automate processes. And I come back to that in a second. Or in the other end of the spectrum, you give business people, the local tooling or ought to do something themselves. And both my work, but it's a very different strategy added, really depends on where you're looking at. So if you have these kinds of processes, Lowcock might be a really good choice.
If you're on that side of the spectrum, it might not work at all.
Coming back to something in a second.
I wanted to give you one slide, which I find interesting in that context, and I should say already on the introduction, I do.
I normally do, at that point, but now already delivered some content, but just that, you know, my personal opinion nation about the topic, I'm I'm Super, and to the ..., about developer friendly tools. I'm developer my heart, I have.
Yeah, degree, and what was it called, software technology.
And I've worked on different open source projects, different workflow engines, open source workflow engines over the last 15 years, so that's kind of where I'm coming from. And my co-founder come, one evidential. Results available, we are delivering that developer friendly tooling.
And they're pretty successful with it. That's the short summary of that, of that slide.
And, I mean, you can have a look at that yourself.
As you can see, we're we're targeting a lot of different use cases for different industries. That's what I also said in the beginning. It's not industry specific, but it can also, in a way, see, we're on that spectrum.
I just had on the map where normally working so, we're more on the on the ride part of it with onboarding loan origination or whatever. Risk Management, Fraud Detection, we have payments stuff.
So, you can read that.
And if I only, well, sorry, if I only use one slide for explaining what developer friendly is, I normally use this one. So, you probably design a process model, which then give to a workflow engine, which can execute instances of that. Hey, somebody booked a ticket, let's go through this, reserve seats and so on, so forth.
And in order to make that work, what you do, for example, in our platform, is then you provide additional code source code programming in the language you like. This case, it's Java, Spring Boot, and Commander Cloud, but it could also be whatever node JS, Python, c-sharp, whatever.
For example, to provide a rest endpoint, which then kicks off that process.
Right, Or you provide a bit of glue code.
How generating tickets for, in, here, you call a rest endpoint. And the cool thing is, you're using exactly the tooling. The developers are always using, so you can can leverage that experience, you can use the normal way of testing the solutions, you can use, the normal way of CI CD, like continuous delivery, that's kind of the link back to the accelerate book.
So, you can use all these practices for getting vela velocity for, for getting this very successful IT practices.
Also, for process automation, with this kind of approach, and I totally believe in that.
I'm a huge fan, and we're seeing that it works for with it, with a lot of customers. Thanks.
That's developer friendly tool, and that's why we are saying we can automate any process anywhere to some extent. I love explaining that a little bit, at least.
And, I mean, with this approach, I can do everything. I can even integrate.
You're very, very legacy system, because if you can go into programming code, you can do everything.
You're not limited by what we have foresee.
That's why we can make the bold statement.
But still, you need to look at where you want to be in that spectrum. So normally, most of our customers are somewhere, somewhere here, because there, it really makes a difference to use this kind of developer friendly tools. It makes it important to have the velocity. It's probably not so important if you're on that end, or low code might work on that, and, I mean, you can still do stuff with kimono.
But that's kind of the idea.
And then, if you think back up velocity and the accelerator, one thing I, I think you have to keep in mind as that if you, basically, if you apply the wrong kind of tooling for the wrong kind of process, you're really screwed.
So just with the accelerate book in mind, if you and that's what I see a lot of companies are currently trying.
If they apply low code for these problems on the right end of the spectrum, most often, because their limit, there are not enough developers for them.
This can't be successful.
I mean, first of all, you don't reach these practices, like in the Accelerate book.
And the second is it's it's kind of a downward spiral, because it normally means you're developers, the developers to have, they're frustrated by these tools. And this will normally make the good developers leave, and you're not able to attract good developers anymore.
And that's kind of a really bad thing. So if you're on that side, you really have to invest in developers. And do you have to mean that, they smell it?
If she's like, Yeah, yeah, yeah, no, no, we, you can code, but we do local, and that's kind of a strategy.
And I find that important to keep in mind.
So, two things, to be yourself, in this context, and I saw both.
So the first is, RPA is not kind of a magic magic wand where I can, like, automate any process.
for me, RPA, robotic task automation, in a way, it can automate one task if the system doesn't have an API. It's very important for process automation, but it's not a silver bullet.
Be aware of that. People like, if you know these risks, that's what better. At the same time, just. Because there are these pro code tools, doesn't mean you have to apply for everything. And then get very, very technical logically.
So, you have to find their place in the map, apply the right to links. And last comment on that.
And then, of course, these categories are not as easy. As I describe them, they also overlap. So, for example, like if you look at come on over here, in the digital process automation space, we're also having capabilities to understand processes that are not automated on our engine.
We're also have capability to orchestrate robots RPA tools are buying into software to, basically, yeah, trying to get into the DPA space. And so on and so forth. And the same for mining tools there are getting into the execution viewer, for example, We're getting into the understanding part. So, there's some overlap.
So, keeps or stays complicated.
If you want to get started, I wrote that lovely book.
Um, if you, if you're interested in the developer friendly approach, then this might be a good start as it goes into that approach, with a more technical.
technical lens onto that. There are also examples, if you want to run something. It also talks about orchestrating RPA if you're interested in that, and so on. So, I'll pause.
Thank you very much.
See, do we have questions?
Well, listen, nobody's sleeping like that, right now, Barry, and I can guarantee you, is, how many is making the connection here?
This is a fantastic, Thank you so much, You did such and such a great job of setting the stage for that, That no one size does not fit all, when it comes to the Solutions Center. And I think you did a really good job at showing the different dimensions of, on the decision making, for buy versus develop.
And the, and the, and then, the rationale behind each one of those segments. Very, very useful.
We got lots of comments about that, so we want to thank you for, for, for guiding everybody through them, that there was, we, I can tell you, that based on the questions that I've been seeing here, there's going to be, we're gonna need a follow up session. That we're gonna focus specifically on low code tools for business people.
That got a lot of attention because there is a there is a bit of a promise of a low code or no code tools for business people. But the reality quite often is not there either. I think the developers sometimes are overestimating the ability that business people have of using a low code or no code tools. So, can you talk a little bit about that?
What does the stage of development for a low code tools, for business people versus the developers?
It's interesting that you say like this, because I would have phrased it the other way round. I think developers, as far as I see, are not really believing in low code for business there. They're not.
There are at least for these, that's what I'm trying to to get at for these more complex processes.
So the story, I see, and that's happening at a lot of customers. It's typically always the same. It's like, OK, we buy this low code or no code tooling.
Because we, Yeah, we have normally limited resources in IT or whatever the business doesn't talk to, the IT are there. There are a lot of these reasons which are around. We don't get access to the right resources. So we buy low code so we can do it ourselves. And for simpler process. That might work. Then you still end up with a governance problem. We also saw with Deutsche Telekom. But that might be something you can handle it for a simple process. But if you, if you look at more complex scenarios, that simply doesn't work.
You have to integrate a system which is not easily into Gradle. You have to. I mean, you probably just have to call some API, which is not supported. You have to do this. And that we're normally a business person simply can't do it, which makes sense.
I mean, that's why there looking into the business, not they're not developers. And that means normally these tools are then handed over to IT, or some developers are like fetched into the project. Like, hey, can you, can you solve that for us? Can you do that, and then developers are normally for them. This kind of tool is alien.
You can't use any of the practices. They know they can't do normal programming. They have to do some, whatever your script language, they can't do testing, they can't do deployment in the way they know they probably can't do the security in the way. They normally do it. So there are a lot of problems they have.
So they normally kind of hate these tools, it's not always the case, but normally that's kind of the case. And then you're in a situation where you're really stuck Like the business conduit. The IT hates it and that's not a not not a recipe for success.
So, scenarios, where Local can work is, I think, if you, if you have the right process for it, if you have something which, is very simple, which is just local to a department, for example.
All these, I mean, what we did with Microsoft Access, 10 or 20 years back, a lot of, like, local solutions, that solve the problem. I mean, also within kimono.
We have solutions with our table and CPR and these kinds of things, berks yes, for certain things, but not for these more complex or end to end processes, and that's why I find it so important to understand what you're looking at and then like getting at the right solution.
And you did a fantastic job driving that point about where the right application sets and then that, that was very, very helpful. And you And your answer just emphasizes the importance of knowing where you are in that in that spectrum that that's very helpful. Just out of curiosity does come on to develop low code, no code type of tools as well. Or you work more just on the developer side. So for us, it's developer friendly, It's pro code there is That's what I meant. There's some fuzziness in the middle. So, for example, of what we do.
Think marketing tries that crazy, and we call it smart, low code. It basically says we're pro code base for the developer. But we're trying to make it easy for the developers sometimes. So we have convenience features making it easier. Or we have customers doing just RPA orchestration, for example. And there we have, certain elements were, this person could click together things without real development.
So that that moves the bit into the locally direction. But it's always still open.
So if you hit a, if you hit a limitation, you can always have a hook, and you can do development if you'd like.
So for us, it's making things a little bit easier, but they're definitely still on the pro side.
That's, that's fantastic. We are running out of time here, so I wanna make sure that people know where to go. Where's the best place? You've mentioned a few different references. Where's the best place for a lot of the people who are asking questions about this protocol applications? Where's the best place for them to go learn more to connect with experts who can guide further than what we did yesterday?
I mean, what I can always recommend as kind of, if I, if I select one, go to place, it would be coming up forum. It's very technical to some extent, But it can ask everything, and we have people looking at it so they can still distributed. That's definitely some one place where it can go, so go to the web page and you will find your way there.
Of course, you can always also reach out to me on whatever, LinkedIn and Twitter, I'm sure you will find me in the Intranet.
Wonderful burn. Thank you so much for sharing your expertise insights, a masterclass on the, on the, on the topic, on behalf of our global community, we're grateful to have you here sharing that expertise with us.
Thank you, sir.
Thank you and have a great day.
Ladies and gentlemen, that was Burdened Rock or from Commander, with a real masterclass on the decision of developed versus buying, and in a very structure, reveal of how we should approach that decision making, and the, and what's available today to help us be successful. Especially as we look at the Pro Code level that, that he discussed with us. Wonderful presentation. And we're going to build on that now, at the top of the hour. When we come back, we're gonna bring to global leaders that will discuss intelligent automation as a transformation agent. We're going to have, hey, my Gandhi, who is the CEO of Latent Bridge, and Joined. Joining Heart will be Robert Scott. He's the head of market service for Commerce Bank.
And they're going to discuss global, intelligent automation and how it's being done as a transformation agent for their organizations. So, we'll be taking a break now. We'll see you all back at the top of the hour. Thank you.
Co-founder & Chief Technologist,
I am a software developer at heart who has been innovating process automation deployed in highly scalable and agile environments of industry leaders such as T-Mobile, Lufthansa, ING, and Atlassian. I contributed to various open-source workflow engines for more than 15 years and I'm the Co-Founder and Chief Technologist of Camunda – an open-source software company reinventing process automation.
I am the author of "Practical Process Automation" and co-author of "Real-Life BPMN". Additionally, I am a regular speaker at conferences around the world and a frequent contributor to several technology publications. I focus on new process automation paradigms that fit into modern architectures around distributed systems, microservices, domain-driven design, event-driven architecture, and reactive systems.
September 07-09, 2021
October 12-14, 2021
June 22, 2021
11:00AM - 12:00PM ET
July 06, 2021
11:00AM - 12:00PM ET
Watch On-Demand Recording - Access all sessions from progressive thought leaders free of charge from our industry leading virtual conferences.Watch On-Demand Recordings For Free
Courtesy of DC Government's Ernest Chrappah, below is a transcript of his speaking session on 'Going Digital To Enhance The Customer Experience' to ...
Courtesy of PMO Global Alliance's Harris Apostolopoulos, below is a transcript of his speaking session on 'Digital Transformation: The Game Changer ...
Courtesy of 's Anu Senan, below is a transcript of his speaking session on '' to Build a Thriving Enterprise that took place at Enterprise ...