"The role of the developers are kind of shifting towards, I would say the hard problems...which are not that easily solvable by low code."

Ben and Andrew open the show by discussing the emergence of the DeepSeek AI model, Google's shakeup of the SEO landscape, and speculate on whether or not we're seeing the death of free APIs.

Then, Ben sits down with Bernd Ruecker, Co-Founder and Chief Technologist at Camunda, to explore how low code solutions are changing the game for developers. They discuss how these tools allow developers to focus on more complex challenges, and delve into the importance of understanding when to leverage low code versus custom solutions, and the evolving role of developers in a world increasingly driven by automation.

Finally, do us a favor and fill out the Dev Interrupted listener survey! You'll be our best friend forever :-)

Show Notes

Transcript

Ben Lloyd Pearson: 0:00

Hey, Andrew, have you ever woken up in the morning and thought to yourself, I would love to get out of bed today and help Dev Interrupted make content?

Andrew Zigler: 0:10

Well Ben, I think that most days, when I wake up.

Ben Lloyd Pearson: 0:14

Yeah, well, that's great. Uh, but I also want to give our audience that opportunity. Uh, and we'll get to that in just a moment, but you've probably noticed some changes that are happening here at Dev Interrupted, you know, our goal really is just to provide the best coverage of topics that matter the most to our audience. And to that end, we've launched a new survey. To gather feedback from you, our listeners. We want to know what an ideal Dev Interrupted looks like for you. And this will help us make the best content and let you influence the roadmap. But there's one extra bonus that I'm going to let Andrew share with everyone.

Andrew Zigler: 0:53

That's right. There's a little bit more to this too, as part of adjusting our content to make sure that we hit all the marks you want to see. We want to invite you to share your opinions on topics like developer productivity, developer experience, adopting and scaling AI. And this becomes a chance to join the conversation with us and engineering leaders that join us on this podcast about the challenges facing software engineering teams in 2025. for listening. The survey that Ben alluded to includes a section for you to indicate that interest, but even if not, we still want to hear from you. Uh, we still want to know your opinion on Dev Interrupted. It's only going to take a minute to complete, so please check out the link in the show notes, and thanks in advance for sharing your opinion with us.

Ben Lloyd Pearson: 1:40

Thanks, Andrew. And for our listeners out there, I'm Ben Lloyd Pearson and I'm joined today by my co host, Andrew Ziegler.

Andrew Zigler: 1:47

Yeah, of course, It's always great to be here, excited to dig into today's topics. What's top of mind for you?

Ben Lloyd Pearson: 1:54

Yeah. So, you know, I feel like we're probably not going to get us through a single episode this season without Mentioning AI at least once,

Andrew Zigler: 2:02

Too true.

Ben Lloyd Pearson: 2:03

so, you know, the, the stories that have been catching my attention lately have been, you know, it seems like we're going through another round of major investments into AI infrastructure. So. You know, there's the one that made a lot of news was this new Stargate project where, OpenAI has come together with a few companies to, invest half a trillion dollars over four years. but we also have stories of, like, Google investing a billion dollars into Anthropic. Microsoft. A few weeks ago announced an$80 billion investment into their AI data centers in 2025. and then Meta invested as part of the Databricks Series J, which is an AI startup. it wasn't disclosed how much meta specifically invested, but it was a 10 billion round overall. So somewhere under that amount. The AI hype cycle is clearly not over. And it seems like what's really beginning to emerge is that the U. S. and China are the only two major world powers that are aggressively investing in AI infrastructure right now.

Andrew Zigler: 3:05

And more specifically, they're investing in controlling and creating the AI chips. Because that infrastructure is useless without the chips they're built to support. And so we're going to see these world powers controlling that AI dominance by controlling the creation and production of that technology.

Ben Lloyd Pearson: 3:22

Yeah. It's like who can build the most hardware and then, you know, Put the most like electricity behind it to train their models, you know, but it's almost, you know, what it almost feels like to me is, is like, there's a bit of like an arms race that's emerging here that reminds me a lot of like the Manhattan project, the space race, and in both of those situations, previously, the, you know, the U S was the first nation to really reach the heights of success for both of those. challenges and it put the country in a place to dominate. So, I mean, if like, when I put it in that framing, like it really puts things into perspective about what's happening.

Andrew Zigler: 3:57

And it really shows why the next few years even can be so critical. It's still early days. There's something new every day when we wake up in this kind of development. And while it reminds us now looking back on things like the space race and the Manhattan Project, you know, those projects themselves are even completely different from each other and a world full of unknowns and uncertainties every single day. And I think that's the reality of what we're currently experiencing. for example, the recent Chinese model DeepSeek R1, which uses pure reinforcement learning, is able to match OpenAI's O1 power at 95 percent less of the cost. And so what that tells us is there's no moats yet. In the world of AI, no one is secure in terms of developing the next leading thing.

Ben Lloyd Pearson: 4:44

I mean, it's really hard to shake the feeling that there are just massive changes around the corner. I kind of feel like 2025 is going to be the year that we really start to see massively disruptive outcomes from that. I really feel like 2026 then becomes like the winter for AI where investments are just going to evaporate. Like you can't invest this kind of money into core infrastructure like this and not expect significant payouts on the other end.

Andrew Zigler: 5:14

And speaking of this kind of massive disruptive outcomes from AI, in the last week, the world of SEO was turned upside down by changes from Google in an attempt to protect its market share from AI. This was an interesting story that I learned about in Perhaps if you're in close communication with your company's marketing team, you've heard about this too. but there were many changes from Google's end in the last week that resulted in temporary data blackouts on SEO tools, and things that actually connect to Google to understand page rankings. for example, Shea Harrell, the senior director of SimilarWeb. Shared a statement saying that Google implemented significant changes to how its systems handled automated interactions, and it required JavaScript to be enabled for search queries. And what happened is it took about five days for most of those tools to start working again, which, if you're working at a company that's buying and investing in ad space and lives and dies by the world of SEO, that's an extremely stressful time. And I see this as a play from Google to protect its dominance in the world of search, which is slowly getting eaten away by technology like AI. For the first time since 2015, Google's global market share has dropped below 90%. And we know that at this stage, LLMs, when they're scraping websites and collecting content, they're largely not executing JavaScript. So this seems like a short term change to shake off the scrapers and give Google a little more time to protect its search supremacy. Wow.

Ben Lloyd Pearson: 6:42

for a couple of months now that search is dead, you know, and it's, it's a little hyperbolic because obviously, you know, even myself, I still use it, on basically a daily basis, but I also am starting to wonder, like, could we be witnessing, witnessing the death of APIs that provide free access to data? So, you know, Twitter, Reddit, they've already, made their APIs more restrictive, specifically, you know, I, I know Reddit, it was specifically because of AI training concerns, but I imagine Twitter had similar concerns as well. And I've started to wonder, like, is Stack Overflow the next one, you know, they, they still provide. Public data dumps, but, how long is that going to happen? Particularly considering that they now have a partnership with open AI. And, you know, personally, I really love how like these GPT interfaces provide a search that, that really does a good job at connecting disparate points between, multiple resources. and honestly, that's probably been the single feature in these tools that have accelerated my workflows more than anything else. But, you know, there's still so many bugs to iron out with this. I personally experienced this pretty recently where, I'm not going to share the term I was searching for, but it was a very basic term. Search for like, what is meditation as an example, like that's not too dissimilar from what I was searching. And the result that I got from Google's AI was, it basically focused in on this really toxic version meditation and tried to convince me that I might have a mental disorder for asking, asking it to find this word. It blew my mind, but then it got even more shocking when I asked somebody close to me. To do the exact same search. And the response was almost exact opposite. It gave a very like clinical approach that was grounded in practical advice. And it went even as far to encourage this person to reinforce people who were engaging in meditation. Like I couldn't believe how. It was shocking, honestly, how different those responses were. And, you know, you mentioned DeepSeek earlier. They've been kind of a hot entrant onto this market. you know, one of the issues with them is they actively censor anything that goes against like the Chinese Communist Party directives. and really every single LLM has censorship capabilities like that built into it, because that's fundamentally how they're designed to, to make decisions. You know, if you want to see what happens when these controls aren't in place, go look at what happened with Tay tweets. Uh, I think back in 2016 or something, where it just went off the rails and said just extraordinarily like hateful and terrible things in relatively short order, So, you know, now more than ever, I feel like the algorithm that feeds you information is becoming more important than it ever has been, even if it's always been important. And Google is a really great example of what I think is going to happen to a lot of companies, like traditional conventional things that we've all normalized over the last. You know, one or two decades are now having the, the, the paradigm just completely disrupted, you know? So I think every, every company, every leader should be thinking about this challenge and if it's going to impact them in a similar way

Andrew Zigler: 9:56

I completely agree. And by the way, for our listeners, for those of you that are not already following us on Substack, everything that we've discussed today is in the Substack newsletter. So be sure to check it out and subscribe and us for more details on these topics. Continuing to the topic at hand today, I want to start by setting the stage a bit. Engineers have commonly treated applications and tools like low code design like the beginner's lane of software development. But what if the real power move is knowing when to step into that lane? Here's the thing about low code. It's not beneath developers, but a force multipliers for rituals like automation. And after the break, today's guest, Bernd Ruecker of Camunda, will talk about low code and other automation workflows, and how they fit into an engineer's day to day.

Ben Lloyd Pearson: 10:54

Join LinearB and Luca Rossi of refactoring. fm for a workshop to learn the three key traits shared by highly successful engineering teams. This workshop uncovers a wealth of insights about how to make your engineering organization more successful. You'll learn how to take practical steps to ensure engineering is well regarded among leadership and non technical stakeholders. Your engineers are satisfied with their development practices and to more consistently ship and deliver. Projects on time, check the show notes to RSVP your spot in tomorrow's workshop, and we'll see you there. Hey everyone, I'm your host, Ben Lloyd Pearson, Director of Developer Experience here at LinearB, and I'm delighted today to be joined by Bernd Ruecker Co Founder and Chief Technologist at Camunda Bernd, thank you so much for coming on the podcast today.

Bernd Ruecker: 11:44

Thanks for having me, Ben. I'm delighted.

Ben Lloyd Pearson: 11:47

today, I want to spend some time just talking about something that seems to be like pretty core to your professional experience, and that's process automation. You know, you founded a company that is sort of centered around this concept. So, you know, before we dive too deep into it, because, you know, we have an audience that comes from all different types of backgrounds, many of them are probably not super familiar with what process automation is. Maybe if you could just give us from your perspective, like just an overview of what. Yeah,

Bernd Ruecker: 12:17

I always like to do examples. we could pick basically an industry. Um, at the moment I'm working with a lot of banks. So let's, let's just use something from there. For example, the bank account opening process. So if you want to open up a bank account, you. Basically, you go to the website of your bank, probably enter some data, and then you move through a process where a lot of things have to happen in a certain sequence, like probably you have to identify yourself, then there are checks on the bank side, like a fraud check and a trust check, and know your customer, compliance checks, sanctions checks, whatever, until you're done. At some point in time, hopefully get a bank account. So the bank account must be opened. An account number must be generated. Probably you get a new credit card, whatever. So there are a lot of steps that have to happen A lot of banks, like other industries as well, try to automate as much as possible. They try to digitize those processes. They, of course, want to move away from pen and paper and so on and so forth. And then process automation. And I find that really important. And it took me a couple of years actually to understand that a lot of confusion comes from not understanding that. For me, process automation, consists of two parts. One is what I call process orchestration. So basically the coordination of what steps have to happen. And the other is task automation. So basically not having all the tasks done by humans, and, probably automating them with, tasks. Programming, Microservices, probably calling the right API or whatever. And the combination then is process automation. And you can do it, basically in two different flavors if you want to. very often they come together, but you could do process orchestration only if you like. Then that would mean That you, for example, model the process saying there are a couple of steps I have to do. And then I use a workflow orchestration engine to run that model instances of that saying, okay, the first thing I have to do is fraud check. and then if you just use orchestration, you would push that to a task list. Of a human saying, Hey, you have to do fraud check now for this customer. Then the human does that basically talks back to you. And then the workflow engine or the orchestration engine knows what happens next, and that's the orchestration piece. And you could do task automation only, which basically means you get an incoming new bank account opening request, and then you program a small piece of code that whatever, grabs that email, grabs the data, does the front end, write something to a database, then you probably automate the task without looking at the, the orchestration piece, the overall process. And process automation basically is, Bit of both. And where I'm focused on a lot is the orchestrated part. Basically getting, getting order into all the chaos of things that happen.

Ben Lloyd Pearson: 15:00

and I also work on a product that is really focused on workflow automation type stuff. and I think, you know, one of the big points that I always make about this is like, automation is not only a way to speed up your workflows because you're, you know, as you said, removing like that pen to paper sort of Component of, things, but it also standardizes. So it's like you're being more consistent while also moving more efficiently, you know? So it's like, there's sort of two benefits to

Bernd Ruecker: 15:25

100%. So we typically even put that into three or four different buckets, depending on, how we talk about that. The one is the, Operational efficiency, that basically means you're basically can operate cheaper, probably, or, or also faster. then we have, the whole thing about, compliance and risk management. So you basically reduce the error rates basically, or the bias in the process and, and make it repeatable.

Ben Lloyd Pearson: 15:51

great analysis of process automation. So let's talk a little bit more broadly speaking about what this category itself looks like, because. depending on the challenges that you're trying to solve, the requirements you face as an organization, particularly in compliance, you're probably facing like a lot of different competing philosophies around how to solve these challenges. So like, walk me through like how you would, break down the use cases within this category and how they fit into the different philosophies.

Bernd Ruecker: 16:19

It's actually a good segue to, answer the last category of the last question, because that's, a lot of things are around customer experience, nowadays. Like, how quickly can you do things, don't get anything lost. I think we all know that from a customer perspective. You ordered something, you never received it. You, my last time I opened up a bank account with a, with a actually big German bank. It took like, Six weeks, and I called in two times, I think. So there you get lost between certain cracks. And that's a really bad experience. And especially if you now look at how you implement those processes behind the scenes, it's sometimes understandable why that happens. I mean, the obvious thing is you don't implement, or you don't look or focus on the end to end process at all. That basically means it's kind of a chaos ping pong. you might do that chaos ping pong more automated. Like nowadays, I'm not sure if you heard about RPA, Robotic Process Automation. That was quite a hype, I would say, five or six years ago. So the idea was instead of a human entering data in a user interface, We use a bot doing that, so the human doesn't have to do that. But the problem with that is it looks at the task automation part. It doesn't look at the overall process. So it's still, chaos underneath. we had a good use case. I love that with, Deutsche Telekom and they, they, had a lot of human work. Then they introduced a, massive amount of bots. And then they ended up with what they called a SpaghettiBot. Um, integration. And then they started to understand that it's a bit like, the shit in, shit out idea. you have to basically understand your process first, then you have to know how you want to automate the process and then you can go about that. So you have spaghetti bots, which doesn't help you. So you want to want to understand the process layer. And actually, there are a couple of other technologies out there, which go in a different. problem for me, event driven architectures is one of those, technologies, or let's say architectural styles, very often combined with microservices, where the idea was, we can have all those microservices. They emit events like, Hey, somebody opened a bank account we cleared fraud for, for certain things. And then we have other microservices reacting to those events. And the same problem, now you start to automate the process. Yes, you start to automate the task, but you don't understand the process level anymore. Why does certain thing happen in a certain sequence? so these are typical problems then you get if you don't have that orchestration layer on a separate field

Ben Lloyd Pearson: 18:53

know, and I really like how you open this with focusing on like the customer experience, like thinking about how that process goes all the way to like very end user that is impacted by it, I'm very much a subscriber to like Tom Peters thriving on chaos where the rapidness in which you respond to customers you know? And a customer can be internal as well. It can be internal, external, whoever it is. but using automation to be, to having that, having that full-fledged process that can just respond more quickly to the customer

Bernd Ruecker: 19:22

and one part of that, and you can put it in the customer experience box, but you could also put it in the, business agility box. So we see a lot of change nowadays, uh, change in the way that the customer interacts with the organization, websites, couple of years back now it's chatbots or whatever it is tomorrow. and we also see a lot of changes in the business model. So there is a lot of coming in order to, to make that happen. And to, on the one hand, make the customer still happy, and on the other end, also keep the company in business, you have to be able to adjust and to change those processes. And the first step is always to understand that. If you have this big bowl of spaghetti integrations, or bots, or AI agents, if you're super modern, or, event, controlled microservices, it's super hard to understand what's going on. And if you want to change something, that's a big, big problem, actually. And that's where process orchestration starts where you say, okay, let's extract that process. Let's understand it and let's control it on a, let's say on a separate layer. That's it. like that. Extracted from the spaghetti, and then you start understanding. it I'm not so much love talking about layers because sometimes people then think like the Process Orchestrator is like a big, huge, monolithic thing above everything else, which is not

Ben Lloyd Pearson: 20:43

oh, oh, you know, the system architecture models, like, stuff like that.

Bernd Ruecker: 20:46

Yeah. you can still, find a good architecture. You can still go with microservice. For example, you can have one microservice owning the bank account opening, for example. Then also owning that, that process and still use a process orchestrator and a visual model. to make that, visible, understandable and changeable.

Ben Lloyd Pearson: 21:07

So I think you've done a great job explaining this and convincing our audience that you've clearly thought about this for quite a long time. what's your unique, take on this? You know, obviously you started a company that, Communda that is focused on this problem. So what's the unique take that you believe you've brought to the table?

Bernd Ruecker: 21:23

when I started the company, basically we were a consulting company. And we were focused around the whole, back then it was named business process management. So basically business processes, and we were working with a lot of different clients actually, using different kinds of software that range from these, back then it was, um, BPM suites like IBM or others, or very, let's say low tech open source stacks sometimes. what we understand after a while is that there's a lot of value in these process models and executable processes, but the software is really, really a problem that we have out there. Either too monolithic, too complex, too hard to work with for a developer. Or the open source ones were too low tech, basically. They didn't have a, not even a visual editor or a visual model probably you had to code a lot of things around that. So, um, not very productive. And from that experience, we said, okay, this is how we think, Such a process orchestrator should look like. And one of the key elements there, I mean, besides the obvious things, you have a visual workflow model. You can execute that directly. We're using BPMN as a standard, which is quite adopted worldwide. That's the obvious things. but then we made it, what we call developer friendly, and very open in the architecture so you can plug that into any kind of technology you like. I mean, they're rooted in Java, so Java is sometimes a bit easier, but we also have clients in the NET world or nowadays Python gets more and more important so You can hook that into, the architecture used there, into the, um, CI, CD pipelines. So basically the software engineering approach you're doing, and also hooking it into whatever you have like SSO and so on and so forth. So it's very easy to integrate that into your software development, approach and not the other way around, because what we see with a lot of. Those, orchestration vendors, they vary off much more rooted in low code. Which has more the vibes of, we don't want to have the developers anymore. We want to do that with the business people only. And then we just can do that magically out of the box. And that was not working. That's what we saw back then, especially not for complex processes. And we had the exact opposite approach saying, okay, there's value in all those models, but let's take it to the developer world and make it accessible there. And then probably add some layers of low code if people want

Ben Lloyd Pearson: 23:50

as someone who used to be a software developer, I've encountered this, this like low code versus like software development like conundrum many times. and from my experience, I think most, most developers have A reaction that ranges from, eye rolls and groans to like outright hostility, depending on like the

Bernd Ruecker: 24:09

I think that's accurate. Yeah.

Ben Lloyd Pearson: 24:11

Yeah. So let's just start at like a high level. So if you're a company that is trying to figure out when to deploy low code versus actually having your software developers focus on it, on like building something custom, like at a high level, how do you break down where you draw that line?

Bernd Ruecker: 24:27

first of all, to acknowledge that I'm on the same page actually. And when we started the company and when we moved into being a product vendor, 10 years ago, then it was. Exactly that, but true as there, it shouldn't be always low code just because you want to use BPMN, for example, to automate workflows. the thing that changed over time now, is that it's not such a binary decision anymore. Back then it was you were either a business person and you want to use low code or you were a developer and you wanted to write java.. Um, but nowadays we have also in the roles of the people, we have a much more diverse set of people that range from really senior developers or whatever, super spring guru, for example, to probably very junior developers or people that are more in, for example, data models and they can do a bit of Python or, or so on and so forth. We have business people that also understand some bits and pieces of coding. We have AI assisted coding that people with a bit of technical understanding can probably use. So it opens up a big variety of people actually. And so it's not so much about, Low code or not low code. For me, the important thing is to understand that you also have to build very different solutions in the organization. So that can range from super complex. So we typically use those, kind of access, like complexity, criticality, value to the business. And in complexity, you can then find a lot of things like, for example, uh, how often does that process run? It's a very different thing if you do. something once a day, or if you run it a million times per second. So we have customers doing that, which needs, of course, if it breaks, it's a, it's a different, order of magnitude, the problem, or how many different systems, or we like to call them endpoints are involved, different types of systems. This is a bit of just calling up some SaaS services, or do I have my bespoke, AS 400 host system and seller, which I have to talk to. So all these kinds of things matter. And then you get kind of a range where you say, okay, my use case is here. For example, I have a core bank account opening process that runs whatever a couple of thousand times per day. If I get in trouble, it's really a problem. I have compliance requirements. So it's basically It's important to get it right. I want to use, I want to get to a certain quality. And then you use things from software engineering, because that's what we know in software engineering, how to do high quality software. We want to write tests, automated tests, for example, and pipelines and so on and so forth. but at the same time, you will have use cases on the other end where say, in banking, one of the examples I often use is the, bank account, bank, um, transfer limit. Change, which you can do in your online banking. Say, I want to set that to from 5, 000 to 10, 000. And there's a small workflow running behind that because you do a couple of checks and verifications and probably even a manual approval, depending on certain rules, but it's not very complex. And honestly, if, if that goes out, the normally the impact is also not that big. So you might apply different quality requirements. around that process. And that means probably you can, you can get to a higher degree of low code, for example.

Ben Lloyd Pearson: 27:51

it's almost like the developers are like commandos or people with superpowers that the things that you don't need an expert to focus on solving the challenge, Tends to be like, the type of thing that, you can hand off to process automation. So like from your perspective, like what, what is the role of the software developer in this

Bernd Ruecker: 28:13

I like this question because that's probably something I forgot in the last answer is, the quality you want to get to the complexity, critical use cases, whatever. Um, but at the same time, we see more and more that the teams that build solutions. are getting much more cross functional. So we have more business people in there. We have developers in there. and what we see is that the role of the developers are kind of shifting towards, the hard problems, which are not that easily solvable by low code, for example, if we keep with that example, the core banking system has a very weird API. It's not just a well documented open API compliant REST API. It's something super weird. where you might need a developer actually to integrate it because that's the most efficient thing you can do. We write a bit of code to integrate it. And then, what it can do is have those developers do that. And then probably they end up with providing certain, connectors to the outer world where you say, okay, and I now leverage those in when I stitch together my business processes. Um, and that might be again. Probably done by somebody which, or who is not that technical, who can't write code in that language, but doesn't have to because they understand, the overall flow of the process. They understand the data flow complex enough, but a different kind of thinking, a different kind of personality behind that. Maybe you're using behavior driven testing where you also abstracted that, where you say, okay, somebody is writing these fixtures and somebody writes the tests, which is not that technical. So it's, it's the same idea over and over again, basically pushing certain very, very technical tasks to more developer and to people so that other roles can basically participate in building solutions.

Ben Lloyd Pearson: 30:01

Yeah. And, and really what you're describing is this like world where there's this growing diversity of. people who can build things, right? so in a world where like, let's say, it's years in the future and everyone is adopting, these types of, development workflows. how do developers like still stay relevant in this world?

Bernd Ruecker: 30:21

I mean, first of all, that's kind of the, I think the overall disclaimer. nobody really knows how development will look like in five or 10 years from now. I mean, I'm looking at how quickly certain things evolve at the moment, and change, makes it hard to predict. At the same time, what I find most important at the moment is really It's a mindset thing. It's exactly what he said. It's still, if I talk to people saying, okay, there's a visual model, we actually go like, oh, a visual model. That's kind of these model trim nonsense that never worked 10 years ago, 20 years ago, whatever. we don't, I still hear that. Oh no, we don't like graphical models for no good reason. We don't like XML for no good reason. So there are all these perceptions. and I find that a big problem. I think actually as a developer. I should start to understand what low code is, what are good use cases for low code, but what are probably also limitations of low code. And what I said early on, there are extension points or customizable, areas in the whole low code game. So then I can position myself properly and say, okay, I'm in that world. I don't want to write the next integration of something which I can just track and drop in low code. That doesn't make sense. That doesn't make me more valuable. That doesn't make my job more interesting, but I probably have a lot of hard problems still to solve, and then I can plug in with these other things. Just be open for that and embrace it to the extent that it makes sense. And then probably also enable others. I'm using that, is for me, mostly a mindset shift. And I find that important to acknowledge from a developer point of view, because otherwise we will end up with. What we see in a lot of organizations, which is more like, Oh, the IT is too slow. The developers are not understanding our requirements. business has to move because that's a reality. They can't just stand still, do nothing. So they, they start to, to buy local tools for themselves and try it for themselves. And everybody that saw that happening, Knows that that doesn't go well because that bypasses everything, all quality controls, all compliant controls, all governance, everything. and that's kind of a malicious cycle because then people see that and say, Oh, local, see that doesn't work. it's horrible. Then business and IT are drifting further apart instead of basically getting together. And that's a huge missed opportunity because especially visual models, they help communicate those different, different people and doing it right helps getting cross functional teams together.

Ben Lloyd Pearson: 32:59

Yeah. You know, and I think deep down, like developers don't want to be the ones who are just constantly intaking an endless list of. Tickets to produce new connectors and minor updates to like interfaces, I think most developers, particularly as they progress further in their career, like they want to be focused more on like the bigger problems and the deeper challenges that nobody else can solve. So let's maybe talk about some first steps then. So if an organization wanted to start thinking about this as a solution for their company, what would you recommend is the way to start integrating this into their software delivery workflow?

Bernd Ruecker: 33:37

So the, the way what we typically do is, I mean, you are always, working pain driven, where you say, okay, I probably have a pain in this process here, like bank account opening, if we keep the example or whatever. And you have to do something there because compliance is a good example. So we had, for example, before Russia, so there were a lot of changes in compliance regulations. Um, you need to implement them quickly or, T plus one currently is also an initiative. You have to settle, trades quicker. So you have to do something. there's an active pane and that are good projects because then you can solve something. And instead of them trying to, implement that within the spaghetti, we extract the process from it, orchestrate that, try to keep, I would say as much systems as possible untouched in the first step. But very often you have to cut ends off hardwired integrations between them under the hood. So it's not always super easy, but then you start extracting it, running it, and then you keep going. And the more you do there, the more you transform the whole architecture towards being more, More business capability and process driven. And technology wise, I would say it's, that's the easier part then. That means you have to settle for a platform. you probably have to implement your first process depending on what that is. You might have to, use existing connectors or write a bit of integration code, writing some test cases, deployed like you did before, probably, install a cross orchestration platform beforehand. So that's typically not the big showstopper.

Ben Lloyd Pearson: 35:14

would you almost say that it's like, like as a first step, like pain points that have a lot of Yeah. If the problem is more about connecting multiple services or people or teams versus like trying to solve like a discrete challenge, do you think that's like a good way to break it down too?

Bernd Ruecker: 35:38

I would say so, yeah, because typically if you look at end to end processes, they touch on different systems and different parts of the organizations. That makes them complex and that's where cross orchestration can help. We also see it applied sometimes, layer B below that, which we call integration flows typically. So you probably just want to do for one task, you need to talk to whatever three microservices in the right sequence because they generate an ID. I need that for generating that document, whatever. of course not that transformational. pretty hard to tell a value story based on that. So, it might be a good start and might also be a good, proof that technology works and then it can master the technology in a way and understand what it takes, like skills and roles and so on and so forth. But, overall I would focus more on these, bigger end to end processes, yeah, touching on a lot of systems and

Ben Lloyd Pearson: 36:30

Yeah. So we've already talked about a little bit about how, developer perceptions can be a challenge for some organizations looking to adopt these tools. So what are some other, initial challenges that a software engineering leader might face when they start integrating these low code solutions into their workflows.

Bernd Ruecker: 36:49

I would say the perception thing is the biggest. It's like, if people don't want to use it, it's always hard to get it in. So, you have to make people understand what it's really like, and that might even differ from tool to tool. So, I would go in a POC mode. doing kind of a proof, doing a small project. Same happens, by the way, also to the business side. Sometimes they have very, very unrealistic expectations because it's local. It's so easy. It should be super fast. for me, that's, um, that's the biggest showstopper. And the other one, probably, we touched on that in the beginning is that the market is also, Not super easy to understand. So there are a lot of different tools, different categories, markets are always shifting. so it's like evaluating the right tool on the one hand and sketching your architecture you want to get to is not always super easy. I would say that.

Ben Lloyd Pearson: 37:49

Yeah, probably makes education and training like pretty critical then as a part of this.

Bernd Ruecker: 37:53

I would differentiate two phases there. The first is like really understanding where you want to get to as an organization. Very often these are. where you have senior architect, involved. And that's the, I think the harder part, understanding which kind of tool we want to use. How do we want to use that? How do we use that here at our organization? And then there's the second part where you probably want to get that into the field more and use that more. And that's where training comes in a lot. but that's probably the easier part because then you can lean on material the vendor has, But still still a challenge. Yes, of course.

Ben Lloyd Pearson: 38:27

one of the challenges with this is make sure you hire. the right people to work in this type of environment. So, how does introducing low code into an organization, like change the roles and responsibilities? Like, does it require different skill sets or is it just simply more about rethinking workflows with existing skill sets?

Bernd Ruecker: 38:48

I would say it's not necessarily completely new roles. that's why, for example, we are so behind that developer friendly approach that open architecture is a every year. Normal developer should be able to use that, probably learn a bit of BPMN, probably learn certain APIs, but then you can implement a workflow process. so that doesn't necessarily require new skills. at the same time, one role that gets much more crucial in such a setting as the whole, business analysis is probably that's the best term for it. you have to have somebody who really, understands the process or gets the understanding from various people and distills proper process model from it that is executable later on. And that's not an easy task because you have to really sort it out. You really understand it. You have to talk to a lot of people. You still have to be very correct about expressing it and probably look into, into data flow of things. Like where does that data come from? What data do I need in order to call that system? And how do I know that? so that's not easy. And honestly, we see very different roles filling that in, in customer projects. Sometimes developers do that. Sometimes we have separate business analysts. Sometimes it's kind of a collaborative exercise. but my point is, which I'm trying to make here is that you have to do that anyway, even if you do it like in a traditional programming setting, you have to understand the requirements. Just then very often it's, it's hidden in a ton of requirements documents and nobody, nobody, What we really see is that it's not consistent and the process forces you to get it on a consistent level and to sort out certain problems very early on, in the whole process. And we see regularly that this takes a little bit of more time in a, in a, in a early stage of the product. project, but it always pays off in the end, because you. You get where you want to get and you solve certain problems on a level when you not even have written code yet. but it's not super simple, honestly. so I see a lot of people struggling with that, It's more like, brain capacity to really dive into how the process should work, talk to all the business stakeholders, understand certain things and drive a proper process from that.

Ben Lloyd Pearson: 41:09

So I've got one more question for you, and I think it's one that comes up whenever someone is evaluating a tool like this, particularly people from engineering backgrounds, you know, they want to know, like, is this going to impact the quality of the things that we produce? Is it going to be secure? is it going to comply with all of the things that we're required to comply with, like very standard set of, of like, can we actually trust that this is going to perform for us? And, you know, conventional software engineering, like we've built all these tools that help us validate that, like, CICD services, static analysis, you know, the list goes on. So if, when you're adopting low code, is it just a matter of applying like those tools to ensure that you're, Using these local tools in a safe way, or is there more to, ensuring you're maintaining quality standards?

Bernd Ruecker: 42:00

I would answer twofold actually. the first part of the answer is yes, you should simply, use the tools you already know. writing test cases is something you should keep doing. just because it's low code doesn't mean you should not test it. so yes, you should do all of those things. And, um, depending on what that is, especially if you look at, security, for example, that's a can of worms, which is not always, course, super simple, um, to look in like which data is going into the process, which data doesn't, does the, like Process platform, is that using, is that you SaaS, for example, then I might have to look into the vendor, what they provide, or do I run that myself? And so there are questions, of course, that need to be answered. Most customers, we have to do that centrally once for the whole organization. So there's a economy of scale thing. So, as soon as you have, Sorted that out once, it's working for the whole organization. but that's kind of the normal problem you would have anyway. I mean, if you're hard coded, again, it doesn't win that much. You still have to think of where does the data live? And, is that secure and, so on and so forth. Do I write tests? I would say, yes, the typical, typical tools at play at, and the other part of the answer is, and that's probably what low code triggers sometimes is that I find it also important to note or to acknowledge that not all processes require the same level of, quality There are these high critical, high complex processes at the core of the company that. require high quality standards. Yes. But then there are a long tail of very simple processes, which might not need that. And then probably it's, it's, it's also okay to run without a test case. For example, the important thing is to make a very conscious decision and What we see with our customers at the moment is that if you, if you can establish the same, I'd say the same platform for both use cases, you can easily, grow into, let's say, also more complex use cases from the one side. So you probably start with a very simple process where you say, Oh, we don't need any testing. And then you see that you add certain things, or it gets relevant for compliance or whatever, then you can start doing that. Because it's not a completely different technology, which probably doesn't work if you use a very, very low code, low code only tool. so yeah, where I'm trying to get at is there is this range of use cases again, and you have to understand where this use case you want to implement sit and then decide on the, the right approach of that.

Ben Lloyd Pearson: 44:34

I want to be respectful of your time. So thank you so much for joining me today. Bernd It's been wonderful to have you on the show. where can our audience keep up with you if they want to follow your work?

Bernd Ruecker: 44:45

usual places you can of course find me on LinkedIn, can connect to me on LinkedIn. Always happy to discuss certain things. the Camunda website might be a good place also to get started. We have a big community there as well. We have get started guides. We have an on conference, the Camundacon. Coming to New York probably before this is, aired. So the next one will be in Europe and Amsterdam in May. a lot of local events. I'm a hundred percent sure you will be able to find me on the internet.

Ben Lloyd Pearson: 45:12

Wonderful. Thanks for listening, everyone. We'll see you next week.

Bernd Ruecker: 45:17

Thanks for having me.