John Rymer (00:08)
everybody. Welcome to the latest episode of Lowdown on Low Code. We are going to do a little bit of an experiment in this episode. We hope to start a conversation about applications in a low code world and how to think about that. What's different? What might be the same? And we're hoping to just start a conversation and then
And then have that conversation be the beginning of research that we will do and conversations we will have with you going forward. Speaking of which, if you find Lowdown on Low Code valuable, particularly this episode, please like us on YouTube or your favorite distribution service and share with your friends. We are...
We are part of a community and we are all trying to learn. So if we all continue the conversation, that's likely to happen. So with that, I'll introduce myself. I'm going to be the moderator today. My name's John Rymer and I worked as an analyst at Forrester Research for 17 years, total of 25 years as an analyst in various other places. And towards the end of my time as an analyst,
before I retired. I did research on low code, like 100%. And actually, myself and Clay Richardson, a colleague and a friend, coined the term. I retired about three years ago, but I missed it, so I'm back. So I'd like to introduce my guests today. Francis, tell us about yourself.
Francis Carden (02:06)
Hi everybody, this is my first podcast with Analysis .Tech on the lowdown on low code. Appreciate being here. My background is I've been 40 plus years in application software development and legacy rejuvenation, which includes everything from what used to be called 3GLs to 4GLs that became low code, no code.
So it's one thing if anybody out there knows me, you know I'm absolutely passionate about low code and have been for many, many decades. And if there's ever a time for low code, it's now. So I started a couple of companies, one was RPA, which obviously is not what this topic is about. Although of course that often gets brought up within the DPA world. So I've often had to convince the likes of John and Andy and Rob in the past as a vendor.
that our products are the best and the bee's knees since I spread. So I don't have to do that anymore because I'm now an analyst with analysis .tech and I'm excited to be here.
John Rymer (03:06)
Thanks, Francis... Andy.
Andrew Bartels (03:08)
Well, I've been a co - have been still am a colleague of John's. I had 24 years at First Giga and then at Forrester. I though come not so much from the low code side as from the package application side. That was what I was primary. One of the major things I was covering at Forrester was the package apps that companies use for their buy side operations as well as new.
trends in the market, sizing the market, all those other broad economic forces that impact it. But that's the background I come from. And part of a little bit of this discussion today is gonna be the packaged apps versus the low -code, discussion choice selection issues.
John Rymer (03:54)
Andy, you're under, you're selling yourself for Forrester Research. Andy Bartels, Andrew Bartels, formerly, was our chief economist. So not only did he hold down a portfolio of product research, but he also did all of our forecasting. So we're thrilled that you're here, because I can't do that stuff. Anyway, Andy, thanks for teeing it up. Let's first...
Andrew Bartels (04:16)
Anyway.
Francis Carden (04:18)
Each to his own.
John Rymer (04:23)
start this conversation by looking at the buy decision in a build versus buy dichotomy. Software as a service, SaaS products like Salesforce have become the primary basis for the buy decision, but these products are very different from the buy decisions of the past.
where you had on -premise software. First, one thing is they embrace low code as a way of customizing and configuring. But there are other dimensions of this as well, including the financial assumptions you make. So Andy, maybe you could kick us off on the financial angle on that. What's the best way to think about these products?
Andrew Bartels (05:21)
Well, the application world, the package application world, whether we're talking about old licensed software or, as you correctly note, the new SaaS versions of that, are essentially you're acquiring an asset that you are going to use to automate and improve various processes that you have. As I mentioned, I focused a lot on the buy side processes, procurement sourcing and so forth. The issue with these is twofold.
One is to correctly note, John, today you are not buying these and you have direct control over it as you have it licensed software. You're renting access to that. And part of that access is one of, if you need to make adaptations, how do you do that? One way is the vendor provides configuration options. You get to choose those. Another approach is vendor provides a development environment where you can build extensions off of it.
But those costs, and you have to think about the cost of those. And of course, you're continually paying subscription fees, whether it's paying for the basic application or paying for access to the environment that you're dealing with. And we're building custom extensions, or not, I'm sorry, we're building configurations. Those configurations hopefully persist, but there's always the risk that the next upgrade of it, they have to be redone.
So you have an ongoing cost of these applications that you have to just be dealing with. Unlike license software where you can't after a while just stop paying license fees, actually even stop paying maintenance and just run with it because you own it, you're on the hook forever for these as long as you use them. You stop paying, you lose access to it. But it's the operating cost, which really is the thing you have to be mindful of, especially if you're dealing with
development of joining apps or configurations or things of that kind on the development platform, how do you maintain those, how do you keep those integrated? So in general, the best approach for these applications is for the most generic, most common process that you have. You want to try as much as possible to minimize the configurations or the extensions you do within those environments because of the lock -in.
So one of the things you want to think about is if we have to build extensions, can we do it in alternative environments where you have more control and less cost associated with that? In many cases, the issue is you do need to build extensions because these are designed, again, for the most generic applications for the most common industries. And so in many industries, you don't find that availability. And so the extensions, or the configurations, the customizations,
become critical if you're going to operate in the industry in which you find yourself sitting. So that's the basic parameters around packaged applications. Make a lot of sense for the most generic applications. Do make sense if you want to do minimal extensions of it. But if there's anything more specific, you may want to look beyond the application for ways of achieving that functionality. And that's where low -code comes in.
John Rymer (08:31)
So Francis, we've talked and you've written some about this notion that SaaS is good for generic processes. In fact, you actually believe that a lot of the processes that companies employ are interchangeable, right? I mean,
Francis Carden (08:55)
Yep. Yeah, I mean, it is, this is an interesting topic because we're talking about the history of computerization again, right? You know, so it used to be, let's build it. And so there was no maintenance costs or subscription costs. You'd build it all internally. You put a team together and you'd build the hell out of all these manual processes that went before we had computers. And then we had decades of, you know,
Does it run on this piece of hardware? Now hardware's got cheaper. Could we move it to someone else's? Is there a better operating system? Is there a better language with more skills? So we went through that. And then of course we had package software, which is like, yep, you buy it off the shelf and then you configure and you customize it. And then we moved to SaaS. And to be honest, some of the SaaS applications today are potentially even built in low code, right? They're built to be adaptable. What I like to call configurable.
versus customizable. Customizable implies lots more code debt, lots more wrapping everything and doing all that kind of stuff. Whereas if it's customizable, you need it to work in a different language, you need to add a different set of business rules. I think a lot of low code is being inherited now by a lot of these SaaS applications, which themselves could also be classed as packaged, right? And then the other aspect to this is just how different do these processes need to be today?
You know, banks weren't so different in the old days. Insurance wasn't so different between one car insurer and another or healthcare insurer and another, but computerization is when it first started, it gave us this implication that, well, we're unique. Our process for onboarding a new customer is different to that bank's onboarding a new customer. It's like, but it was the technology that drove that differentiation because you couldn't, you know, one bank wouldn't share its code of another bank integration. Yes, you know, credit cards have to, companies have to.
transfer of monies between themselves and their banks have to transfer monies between themselves. But it weren't that long ago when I moved to America, probably 20 years ago, I actually had to write out a fax so they could fax the money. Why? Because the banks didn't talk to each other even then. But I do think we're entering an era, and I know there's a lot of people that agree and disagree with this, where I don't think the majority of my processes need me to hire an entire IT team, an entire development team, just because I think my process is different to someone else.
What I want is IT to have my back. I want the ability to customize it to be able to clarify my differentiation to win more customers and provide better customer support, etc. So I think it's kind of morphing and merging together here, right? Does it really matter? I don't really want to build it. I think building today is just, you know, my passion for low code is who the hell wants to write code today, right? Who wants to build their own application? So it's not now a choice of
John Rymer (11:24)
Mm -hmm.
Francis Carden (11:37)
It's a choice of SaaS or low code, but low code can be SaaS. So I think it's all back down to processes will be similar. The advantages of low code technology running on SaaS platforms, because let's be honest, almost everything is as a service platform now, right? We pay a subscription in perpetuity, but for that privilege, we don't have to have a massive IT team supporting all the infrastructure underneath. We can let IT go do what they're really good at.
Andrew Bartels (11:48)
you
Thank you.
Francis Carden (12:03)
which is to protect our business, put the governance and security and all of the things that matter at the heart of our running our enterprise. And then the software is becoming much more, I'm not gonna say laissez faire, because it's actually a key part of how we interoperate. And then of course there's a difference between generic applications like productivity apps and enterprise apps. And for enterprise apps, the future cannot be to write them in code. It has to be low code.
Andrew Bartels (12:21)
you
John Rymer (12:30)
I'm hearing a bit of a caution.
Andrew Bartels (12:31)
I'm sorry, can I pick up on one of his points? So, yeah. To the point of having your own versus common code. In a lot of industries, it makes sense for all the parties to utilize similar software because they got to interact together. And...
John Rymer (12:35)
course.
Francis Carden (12:36)
Go John. sorry, Andy, go.
Andrew Bartels (12:57)
That's one of the vulnerabilities of a lot of packaged applications is they've written generically. So how are you going to get your industry to work on the same thing? The vendor may do it, but you may have to figure out how to work together on this. And to Francis' point, back when I worked at American Express, before I became an analyst, one of the issues we had in our essay world is that in our engagements with service establishments, the MX did things differently.
we engaged with our service around, they said, no, you become a pain in the neck then. We want you to do the same way that our non -amex merchants do. So that notion of finding commonality and then finding a common platform or code base, you can do it. The challenge is package apps may not do that. You have to go low code, but you're going to do it in a community way where all of you are utilizing a similar set of
extensions in order to unproper together. And so it's not just thinking of your own company, it's thinking of the interactions you have often with competitors to figure out ways of utilizing similar code to work together.
John Rymer (14:09)
Right. I am hearing, hold on Francis, I am hearing, we're going to come back to this in a little while because what I am hearing is a note of caution from both of you about how much customization you actually do. Do you do it in the SaaS platform? Do you do it externally? What are the pluses? We're going to come to this. We're going to come to this in a little bit.
Francis Carden (14:09)
Yeah, and low code doesn't imply...
Andrew Bartels (14:15)
Okay.
John Rymer (14:38)
I'm going to, now do some shameless self promotion for analysis .tech. the, the producer of this podcast, a little low down on low code. we are a firm devoted to, low code, advancing low code journeys. We are low code all the time, all low code all the time. This is what we do. And, our, our goal is to.
help customers advance their journeys to achieve more and fuller benefits. And we are very eager to engage with you if you are to learn more about your journey and to help others through our research and through our community efforts. So end of shameless self -promotion. Let's continue the conversation.
Guys with low code making, with low code products, making custom development so much faster and so much less expensive really, and opening it up to so many other people within the enterprise. Have we really, do we really need to take another look at the build versus buy decision? And is build, is low code now advantaging?
build over by. Francis, let's start with you.
Francis Carden (16:09)
Well, but yeah, so I think you've answered it almost by definition. Build in low code. It's not, it's building code or building low code. And there are vendors out there that are building in low code that sell those solutions as packaged solutions that can be configured. Because the opposite of all of this is, well, do we want to go build something in code?
Hire a bunch of developers, 500 or 1 ,000 or 100, doesn't really matter. We hire all the developers, great intentions to build the best application in the world that three years later maybe gets rushed to the finishing line because it never gets finished on time. And then every time business then want an enhancement or a feature or want something done, IT like, well, listen, this is the way we built it. You shouldn't have told me that back then. It wasn't built for customizing or configuring. So it's hard.
Andrew Bartels (16:45)
Yeah.
Francis Carden (16:59)
and roll forward 10 years later, you've now got this plethora, monolithic set of sprawl I like to use, a sprawl of code that's so hard to manage and maintain. Whereas if you build an application from scratch in low code or you buy a platform that's configurable, it never needs to be upgraded, which is the Achilles' heel of all software. Five, 10 years out, you're going, okay, we're gonna have to upgrade it. Well, that's a three -year process.
What you need three years from now might not be what you planned. The definition of the way software should be built, enterprise applications should be built today, should not be like the past. The past will strangle you. We're going to cover this subject, the total cost of ownership, which I think very few people have a handle on. And it's astronomical how out of control the total cost of ownership is. But you have clear visibility if you re -
think the way you build or create even applications that run in the enterprise that keep the lights on. Everything from the simple apps to the monolithic ones. These can be built in low code. They can be configured for life. And we just end this era of computerization and move into the digital revolution or the digital transformation era. That's what I think.
John Rymer (18:17)
When you say, when you say, I think the, I think the contract or the, the comparison you're doing was simple apps versus complex enterprise apps. Those are in scope for low code. I would just.
Francis Carden (18:30)
complex or simple, I think the very idea is that you just reimagine what an app is. You build it, you don't write it, you create it, you don't write it, you don't code it, you don't have this legacy debt ever again. I'd love to see the term legacy disappear from the terminology in enterprise IT. It's unnecessary. Maybe for systems engineering, you've got a lot of that or there's a lot of baggage and you can't change that. So I'm not talking about systems engineering where that requires the brightest minds.
some really, really clever people. But for enterprise applications, the future is not the past. And I don't care if it's a complex. I mean, a lot of simple apps now, let's be honest, they're off the shelf. You know, you're not going to go buy, build your own zoom app. You're not going to build your own chat application or, or, you know, co -pilots or all these things. I mean, but if you build on a platform that has a future, that's going to take you to the next generation of hardware, the next generation of quantum, the next generation of gen AI, you don't need an IT team.
that builds it for you, you have an organization, a low -code platform that's floating all boats at the same time. And if they're providing solutions to 10 ,000 clients and one of those clients has a great idea that goes into their platform, the other 9 ,999 clients get it the following week or month or in the near term.
John Rymer (19:47)
Yep. Andy, do you think there's a, do you think, you know, just looking at the economics of it, that there's a rebalancing or rethinking of build versus buy that low code enables?
Andrew Bartels (20:00)
Well, there is certainly a rebalancing in the sense that there are some things that you've already bought and your business is built around them. And so you might not make that decision today, but you have it. It performs a certain function. Changing it is so the process change, organizational change, the data link changes so big it's not worth doing that.
But it's around, it's the newer stuff. Or it's the changing of things that you need to do to adapt to new realities. New regulations come along, new environments come along, COVID comes along, everybody has to work differently, you have to adapt to those. So I think Francis is correct that anything new that you're looking at, it makes much more sense to in fact build it. Or alternatively, and this is the part I was trying to make,
find somebody else who's in your industry who's already built it that you can leverage and take advantage of using theirs because guess what? You both need to do the same thing. You both benefit if you can take advantage of that. So, you know, there are many industries that are highly cooperative. Government, for example. There's no reason that the state of Georgia does something that the state of New York can't utilize that because there's no competition between them. So that's in a sense communal aspect of development.
is a key opportunity. And it comes back to the point I made earlier. So much of software was not industry focused. It was generic. And yet so much of what happens in each industry is differentiated. So looking for the commonalities, look at the word community that you can draw upon that goes beyond yours that does involve building, but building in a way that's collaborative and cooperative is one of the ways you can get
beyond the trap of the legacy system that you bought five years ago, whether it's Salesforce or anything else. And more and more isolate that, more and more limit that, and shift over time your new stuff to new environments. I think that's where I would agree with Francis.
John Rymer (22:15)
I like your use of the word community and that idea certainly would reduce risk because it's more likely your systems are gonna be embracing best practices and not just the best you can do to figure out the best practices. It sounds like it's a, I like that idea, yeah.
Francis Carden (22:38)
Well, I don't know the number, John, I don't know the number, but I'd like to think it's 85 to 95%. But whether you think it's 75 or 55, the percentage that all businesses in the same industry need can be the same. It's high. So if you've got a, I don't know what the number is 10 ,000 banks in the US or whatever it is, but you know, numbers of banks versus I don't know, let's pick a number 500.
They don't all have to be different for the majority of the business. They did in the old days because IT forced you to go and choose your own hardware, your software, your operating system, your da da da da, right? The rest is history. And maybe if you were lucky, you know, they always say, if you were the first bank to build an app and then you were the second one, you'd go hire the people from the first, you would then just improve on it. But all you've got is more and more legacy code to support and the cost and the debt of supporting that. It's just unnecessary today, but it wasn't possible. But we should pat ourselves on the back.
the same time, right? For the last 40 years, it wasn't possible to do this. This idea of sharing, collaborating, co -offering didn't really, it just didn't lend itself. But today, IT should not be in the business in competing with another IT department because they can build an enterprise application better than the other. It's just a waste of money, waste of resource. Let's focus on the innovation of these banks, insurance companies, where innovation matters and it's not in code, not anymore.
John Rymer (24:01)
Yeah. Thank you. I'm going to, let's move on. I'm going to introduce a word, a term, that is really hot, really hot topic. these days, the term is orchestration and it is very much a part of the low code landscape. The idea being that you can use software to, orchestrate almost like a conductor conducting an orchestra. a series of tasks.
processes, interactions in order to automate an operational process. And this is a really hot topic because automating operations gets you a tremendous amount of, can get you, can get an enterprise a tremendous amount of differentiation in its marketplace as well as efficiency and all the other good things. It sounds, it sounds to me like the, like in thinking about apps,
SAS gives us a really good option for the commodities in our world to automate the commodities in our world. And low code then gives us a great opportunity to do the orchestration because that's always going to be unique, right? We're always going to be looking for differentiation there. Am I, as Rob?
Koplowitz, our friend and colleague might say, am I smoking the curtains?
Francis Carden (25:36)
Do you want to go Andy first? I've got a very strong opinion on this too, but no surprise.
Andrew Bartels (25:38)
I'm sure you do, Francis. If we go back to the metaphor of orchestra, which is an orchestra obviously consists of a wide variety of instruments playing a wide variety, well hopefully not a wide variety of notes, but different strands of notes. And the conductor is involved in orchestrating that to come up with consistent whole. Orchestration I think is a good metaphor.
question is one of who actually does it and how does it get done? Is it a task that gets handled by software itself in a kind of AI type way and certain elements of that are a particular step in the process that needs to go here, got it, okay, you map the exceptions and the routing and things of that kind. But it's also has a very strong human element of determining when and where do we utilize this.
And this is sort of the key themes which I'm most conscious of is utilizing software not to eliminate people, but to help people. And a lot of the process we still have are very people -centric processes. And it's the interaction between the system and the people, or the people, person A and person B, or person A and system B, where the orchestration comes into it. And again, keeping that metaphor of the different instruments in the orchestra, it's that differentiation, it's that,
bringing together all of these modularities, the modalities of the people and the technologies and the systems to bring it together. There's a critical need for it. How that gets done is another question, and France probably will tackle that.
Francis Carden (27:19)
For sure. So I, if there's, number one passion is low code. Number two passion is orchestration, right? Workflow, orchestration, whatever you want to call it. And people have different definitions. I am so strong now on this because of the era of technology that we're in makes this possible. If you don't know where your work is, you are not providing a good service to whether that's a customer internally or externally. You know, and this has happened to me many, many times, you know,
You've got examples where, well, we didn't get back to the client or you've had to file something twice. People are turning to things like process mining, task mining, or process understanding, or whatever it is. And that's because they're frustrated that these disjointed, disconnected, discombobulated even systems were never designed to talk to each other. And the poor human, the end user has to be the orchestrator. So actually what you have is...
sorry, the conductor, you have 10 ,000 conductors trying to conduct these different systems and different processes and different tasks because they have that freedom and luxury. And even then after it's done, nobody knows what you did. Nobody knows how John did it versus Jane did it versus Jillian did it. And so they turn to these mind tools trying to find, well, there are a thousand different ways we can do this process. There shouldn't be a thousand different ways to do the process. You do need variations for sure. You do need human interaction. So my push
to low code and all the vendors is you have to orchestrate your work. I don't care good, bad and ugly work. I don't care if you've got 6 ,000 systems or a hundred systems. You need to be orchestrating the work so that whoever does it, there's an audit trail, clear audit trail. I don't even like the term audit because it implies technology. No, what happened to this process? Whether it lasts 20 minutes because it's in a call center to upgrade my phone or if it lasts two years because I'm trying to cash in a pension.
If we have full visibility to what went on, even through the bad times in our systems, then that process orchestration gives us the ability to have visibility to the good stuff, how well it's done, how badly it's done. It spots automation opportunities. It spots application elimination opportunities. And it really puts us all, every enterprise on the path to true transformation. And today I'm afraid, ladies and gentlemen, there's very few people.
They play or pretend they have orchestration or workflow, but it's as fragmented as, like I said, John does it this way, Jane does it that, and even know how the other does it. And I say enough orchestration, bring it on.
Andrew Bartels (29:51)
One of the things which attracts me to low code is that it changes the dynamic between users and the technology. The old model is that a consultant or someone, an engineer would go and talk with someone, try to understand what's going there, and then figure out a way of building technology to do that. And obviously, any time you do that, you have the old issue of a telephone message. What the user wants gets lost in the building. Low code...
narrows that gap and allows users to directly identify and test what they want and eliminates that gap between what the user wants and what the builder has created. And that is eviscible.
Francis Carden (30:23)
Yes.
And you get the visibility. And you get the visibility. Absolutely. Out of the box. You don't even have to buy orchestration. You just get it.
Andrew Bartels (30:40)
Right, exactly, and enables the end user to become the orchestrator rather than trying to get the guys in IT to be the orchestrator, which sometimes works, sometimes doesn't, but has all these error messages that arise around doing that. Anyway, but I think that notion of the end user being empowered now to become the orchestrator of the processes that impact them, that's one of the real benefits of low code.
John Rymer (31:07)
Francis, to your point, if you really want to know how things are done, you don't go to IT and you don't go to managers typically, the top level managers. You go to the people at the coalface and they'll tell you how things are really done and all the work around.
Andrew Bartels (31:22)
Exactly.
Francis Carden (31:24)
Right, but you don't need to. But even then you get such variation. It's like what's been happening for decades is we go there, we do time and motion studies, we do business process management, we try to figure it all out. And then we come back with, well, we can't even deal with this. We don't even know where to start. But the future of applications in the low code environment means everything's just orchestrated. And you find out, it's like, well, why do you do this? You don't find out like you shouldn't do it. It's like it's happening.
John Rymer (31:40)
Right. Right.
Francis Carden (31:53)
Let's prevent it because in those workflow engines in low code, you can actually force a path. You can force a route and better still using AI, GenAI today on the orchestrated work, you can predict what's going to happen before it happens. So you know, look, we're seeing 30 % of these cases that are going through this work. If this is missing in the first stage, we know 90 % of the times it's going to miss an SLA. We can predict it and route the work to a different set of experts.
to make sure we never miss an SLA. You can't do that if it's all over the shop. And the future of software is not for processes to be all over the shop.
John Rymer (32:27)
Sorry.
And I would add to what you're saying, the future of software is very deep business involvement in the creation of these orchestrated.
Francis Carden (32:40)
I don't even know if it's right to say involvement, John. I think they take over. We don't need IT to build applications anymore. We need to make sure we're secure and governed, but we don't need them to build and create applications. We needed them to code them, but if we don't code anymore, then we, I'm sorry, but we don't need IT to help with what is actually fairly simple. It used to be hard, but it's not anymore.
Andrew Bartels (32:43)
What?
John Rymer (32:45)
I was.
Thank you, Francis. I'm always one to sort of soft pedal it a little bit. And I love the fact that you're working with us now, because you just come right out and say it. So listen, guys. Thank you.
Francis Carden (33:10)
Me? What about the tagline? The cab line is for analysis .tech is all to make the shit out of it. So, you know, I think we're all aligned.
John Rymer (33:20)
Yes, absolutely. Guys, thanks so much for indulging us and indulging our sort of experiment here. I think it was a good start. There's lots more to explore. Francis, you teed up TCO. Very much look forward to what you guys are able to do, the research you guys will do on that. For everyone who's still here watching,
We'd love to continue this conversation. The best way to do that is to go to analysis .tech. We have a form to talk with us, to send us your thoughts. Help us with this research. Help us understand what this topic means to you and what you need in the way of research. This is what we're about. So thanks very much for listening. Guys, thanks again for your thoughts and your expertise. And everyone have a good day.
Francis Carden (34:00)
Please do, yes.
Happy July 4th. See you, John.
Andrew Bartels (34:16)
Love it.
Francis Carden (34:19)
Thanks Andy.