Embracing SaaS to Reduce Technical Debt – Sune Engsig, Leapwork

This is Textron tv. Hey guys, thanks for the throw. We're here with Sunne Enzi, who's vice president of product Development for LEAP Work, and we're talking about technical debt and the fact that it is just a killer for innovation.

Sune, welcome to the show. Thank you. Thanks for having me.

Technical debt has been with us since time began, or since the first time anybody built anything. And my question to you is, I mean, in some cases it's not all a bad thing. It's probably a necessary evil on some level, but it seems like we have a deficit now that's just killing us.

So what's to be done about this? I mean, how do I kind of find some way to manage this in a way that doesn't suck up all my time for creating and building something new and interesting? Um, well, I guess the, the answer to that question is, is, uh, is an old one and well known.

It's just, you know, make sure that you test everything and that it works, and then, you know, you're good. Uh, and obviously then we're, we can you, you could start that completely separate conversation on, you know, Hey, let's do test automation, but obviously that would put us in, in that particular spot. Uh, jokes aside, getting back to, to the, to the answer, um, technical debt.

I, I completely agree with your starting point. You know, yes, a, it's been here forever, and B it's not necessarily a bad thing. Uh, but I, you know, the clients that we're talking to, and when we're talking about tech debt and when they, when they experience the pain, two rough categories I'd highlight in this one, the software vendor who is, uh, who's on a track of, uh, you know, evolving his product, uh, making the next great capability available for the customer base only to experience that.

That said, customer base is, uh, too busy, uh, taking in the new and great features, uh, because they, they can't, uh, for whatever reason, they don't have the time, they don't have the ability to prioritize it right now, blah, blah, blah. And, you know, one release will do fine. Okay, we'll, we'll manage that, but all of a sudden this guy finds himself maintaining X number of versions of this software, which he, he needs to support, he needs to keep it alive.

He has customers running on it. He hasn't successfully enforced that regime, uh, to sort of go, Hey, guys, uh, you, you need to run on the same version of the software or else, right? Uh, so if you look at the Microsoft's, uh, and if you look at the sales forces of the world, they're trying to do this, um, with, with varying degrees of, of success.

Um, Microsoft, I think being extremely loyal to, to their customer base in terms of understanding where they're coming from on one hand. And then on the other hand, of course, uh, for Dynamics 365 f and o in particular, you know, driving these, uh, these mandatory quality updates, um, uh, every month, which, you know, you, there's no way around 'em, you, you gotta take 'em. Uh, so, so, and obviously, so, so that's working on that, I'm, you know, I'll bet you that that's just the first step on their path going from quality updates to, you know, wave updates, proper updates, and say, you take this now or leave me forever, sort of thing.

But, and so, so from a Microsoft perspective or from from that vendor perspective, technical depth is a, is is that mix of keeping my costs at bay. Uh, if, you know, the more versions I need to maintain, uh, the more work I have to do, uh, employing more people, the less space resource time, money, uh, I have to focus on the new cool stuff that I wanna bring into the hands of my clients. Uh, for a fact.

We know this is one of the strong motivators for Microsoft. Uh, as you may know, they've chosen us as, as a strategic partner for their Dynamics 365 testing. Um, and, you know, it's, it's, it's a win-win situation from their perspective.

I just mentioned their motivation, but obviously that goes on the client side as well, right? So being stuck on, on whatever version to to, to, uh, due to other priorities, which is the world and the reality for clients out there that, you know, business first, right? Um, so that would shade number one.

Sorry, shade number two, of course, if you're just the, uh, if you're just the consumer of software, if you are, uh, just, uh, primarily you're not, not building stuff yourself, but utilizing it. Um, and then maybe you have your integration layers of stuff, and then all of a sudden you're finding yourself, uh, running on, on older versions of things because, uh, the, the business requests of things that they want to do exceeds your capacity. And all of a sudden you find yourself in a situation where your layers deep in, in complexity that is, uh, that is, uh, you know, among other things written by or driven by, uh, you know, different versions of software that you didn't have the time to upgrade or didn't, you know, you didn't have a business urgency strong enough to do that mandatory upgrade to some version of some given framework.

And all of a sudden features are, are timing out. Uh, so, so, you know, it has different shapes, shapes and sizes and, and faces for the client's perspective, I would believe. Do you think that there's an awareness of technical debt and the whole notion of consuming more SaaS applications and cloud applications to reduce it?

Or is there just some vague sense of, you know, I'm experiencing something that's akin to a back pain, but I've come to learn how to live with it and I'm not quite, you know, willing to go get, you know, yeah. Here to help me out? Yeah, for sure.

Uh, I, it's a great analogy, and I guess a lot of people out there are going around with back pains and they're living with it. Uh, and then occasionally, uh, you have that is, uh, nerve that freaks out on you, and all of a sudden you can't get out of bed. So you have that as well, right?

Mm-hmm. Um, I think those, uh, absolutely. And it's, it's not as if, and I think in an important point, you know, companies don't wake up in their morning and say, Hey, let's build some technical debt, right?

That's, you know, that's not how it works. Um, so it's just something that comes in complex and, uh, infrastructure system landscapes where there are not just one or two, three systems, but you know, hundreds if not thousands, uh, they've, they've got their work cut out for them. And at any given time, if it ain't broken, don't fix it.

You know, that rings true in, in, in it as well. And then all of a sudden you find yourself running on some really old cold, and before, you know, at one point you find yourself inhibited from that fact, right? And that's when it starts to get painful.

Are we overly addicted to running our own infrastructure still? I mean, despite the rise of the cloud, most workloads are still running in an on-premises environment. Somebody's out there, is hugging a server somewhere.

I mean, are, are we doing that just outta habit or what's their motivation? I think, uh, from our experience, the clients that we are talking to, so, so obviously, uh, that conversation SaaS versus, uh, on-prem, um, you have, I I, I experienced very few organizations, uh, at least if they're more than a decade old, uh, where they go, Hmm, I wonder if I should choose SaaS just for the hell of it. Uh, you know, if you are, if you're a new organization, uh, you know, founding today, you know, you're probably gonna be all SaaS.

'cause you know, it's the, it's the natural thing to do. If you are a company with some miles on you, um, and obviously if, especially if you're in a certain sector like B F Ss, I, or, uh, you know, pharma, whatever it is, then the asset of the data that you have, not only have they a value for you, but they're also a point of interest for, from author's perspective, uh, et et cetera, et cetera. Just to give you an example, uh, obviously from Europe, so, so we are subject to the GDP D P R thing, which means that in some conversations, it's not really an option for a company to just move stuff into the cloud.

Um, and, and that has, that has different degrees as well. If you're a Swiss bank, you're not allowed to have a data center outside Switzerland, and the data that you have are not allowed to leave Switzerland, then all of a sudden that conversation of, should I go SAS becomes a different conversation, right? You might as well run it at home.

Well, if that's the case, uh, and just theoretically speaking, do we need to change the tax laws to say, Hey, we're gonna let you write off all that infrastructure running on premise because the government's making you run it. I think those tax laws are already in place. I think the choices from the most organizations, right, is, uh, you know, the, the most heard argument I get from when I talk to SaaS teams, you know, um, when we, when we talk about our on-prem offering or we talk about the SaaS one, uh, the, the first response I'll get, especially, especially from the smaller teams, right?

This is, Hey, I don't wanna run a server room. I don't care. I mean, it's, it's, the cost is one side of things, but it's also the type of organization that you have.

Um, I think most of organizations today, you know, we've gotten past the point where they thought, where they thought that SASS is just, you know, painless it, uh, always up and running. They, they understand that by now, but at least they're rid of all the electricians and technicians and AC guys and, you know, God knows what that they also needed to employ to, to run a data center of their own, right? So, so, um, I, in my impression at least, it's more a question on, on that.

And then, um, I I, I'd even argue a lot of the organizations have also now found out by now that it ain't cheaper necessarily. So, um, well, There's an argument about costs when it comes to all this. 'cause some folks say there are certain classes or workloads that when running in the cloud or long running, they wind up being more expensive than that is on premise.

So how does one actually sort out the math here? That's a good question. Um, and, and it's, it's not a, you know, the math is not a time slash snapshot thing, right?

'cause you've already made an investment in the past, plus you've decommissioned stock at home. So make, you know, if you were to wake up one morning and discover that your, your SaaS ambition actually turned out to be more expensive than you had planned for, right? Then the song costs kind of hit you double.

'cause then you need to reinvest in and spin up the, the seller again, right? Um, I, I don't have that answer really. Um, but, but as you mentioned, uh, some companies out there are, are, are sort of thinking again now with, with a strategy, uh, either half or all the way there into SaaS, uh, discovering that it, it wasn't as cheap as they thought it'd be.

So don't I kind of paint myself into a corner where I'm supporting both classes of systems, whether they're a cloud and on-premise, and I'm absorbing the cost of managing them both. So my total cost of it actually goes up no matter what I do. Yeah, you could argue that.

Um, and I, I've, most of the organizations I meet at least are hybrid. So they have, they have both. Um, but again, it's not exclusively a cost perspective.

Obviously, the, the benefits of running in SaaS, and obviously we don't need to go through them here, that's not the point. But, you know, the, the flexibility of sass, the ability to have a dynamic stance to, to the resources that you have available. Uh, and then you might wake up and find them running a bit more than you, that you figured, or they need more capacity or whatever it is.

But still, you have that unique ability to, to go with the flow running in SaaS, right? Compared to, uh, building up this, this farm of iron in, in your cellar. So, um, again, it's, in my my perspective, it's, it's a cost.

Um, and, and most organizations are, you know, taking it, uh, with, with a, with a, with open eyes understanding that this is part of, of running their business. And, uh, when they're running hybrid, they're continuously toggling thing back and forth. Um, I certainly do sense that it's not a clearest picture as it was just, you know, five or six years ago.

So most companies are, yeah, we have a SaaS strategy, but it's not unconditional. Are developers forcing this issue? It seems to me that they just wanna write code, and the ones that I talked to just wanna be done with writing code as fast as possible.

So they don't really wanna have a conversation about on-premise infrastructure and how much resources they have. They kind of like the flexibility of the cloud and what they would consider infinite resources that may or may not be free in their minds, but, you know, are they the ones that turning around and saying, Hey, I just wanna use low code tools and I'm gonna build this app and I'm going home by five. Yeah.

Um, I think they did that when we were on-prem as well, actually. So, um, I, I don't know. Actually it's a good question is, is the, is that latitude towards the resources that I can just seamlessly, uh, exploit, is that driving the, the, uh, that mindset in, in, in a more or less tangible way?

That's a super question. Very relevant. Um, we see a lot of other trends, you know, where we see tools emerging that affect the way that developers work, or anyone else for that matter.

I'm not talking about chat, G B T, I'm, I'm just talking about plain all ordinary tools that makes people work more efficiently, but also, um, you know, creating, uh, maybe more slobbish code if, if you're a developer, right? But it, it certainly moves faster. But then what's the price in the other end?

That's a good question. Are the business folks also kind of forcing this conversation around this whole digital business transformation? Because it seems like they look at what a Google or a Microsoft can do, and then they look at their guys and say, how come you can't build that?

Of course, you know, the difference being they have thousands of engineers and most companies have a few administrators in a handful of developers, but that notwithstanding they're being asked to do something, you know, cool and amazing. So yeah, the only way to get there is to reduce the technical debt, or what's your thought process here? I think that particular question more dives into, uh, the nature of, you know, the operation that they're having.

As you say, you know, if, if I'm in a, in a perfectly ordinary company and I'm looking at Amazon, I'm looking at Google or whoever it is who seemingly, uh, you know, are capable of pushing out new stuff, uh, every day, uh, and hey, gee, I'd like, I'd like to be able to do that as well. Um, I think that's more, you know, that's where we venture into the, you could say the traditional conversation, at least from my perspective, talking about qa, talking about testing, uh, talking about, um, you know, the method with which, uh, I deliver my software and the, the efficiency with which I do it. You know, have I successfully switched entirely to Agile?

Um, have my testing followed suit? Uh, a lot of the organizations work in Agile today. Yes, the developers have, have gone all, uh, gone all in, they're utilizing the most advanced tools, and they, they've automated the pipeline and then they hit this brick wall, which is called manual testing.

Um, and, and so do not really utilize the speed of Agile because they still need to test for a couple of months before they can do any releasing. And then, you know, so, so a conventional con, uh, or conversation, uh, more in the, you know, traditional transformation agenda and say, Hey guys, we need to change the way that you do things. And then it's really not that important if stuff is running either here or there.

Um, it's more of a, it's more of a methodology. It's more of a way of work and how you organize. Um, and obviously from our, from our perspective, have you automated your testing yet?

So what's your best advice to folks? Because technical debt doesn't go away, unlike financial debt. If I accrue too much of it, I just declare bankruptcy and start over again.

So, you know, how do I like, deal with technical debt and, and live with it? Um, well, I, I, you know, I got a, I should probably not, you know, call this customer by a name, but, um, I think one of what they did, which, which was in an inspiration to me, was that they, when they decided to invest full on, on test automation, one of their drivers were, you know, one of the, the metrics and the goals that they set for themselves was that they were able to, um, to painlessly and seamlessly adopt to, uh, to the SaaS solution of choice, which happened to be Dynamics 365. Um, and obviously bearing in mind, uh, when we're, when, when they're testing Dynamics 365, or for that matter, any other SaaS solution, you know, they're not testing the vanilla addition of it, right?

They're testing the implementation of it in their environment. So what happens when the new source code or the new version of the application hits my environment? You know, what happens with my integrations?

What happens with all of the associated activities that I have running on top of this? Is it still working? And they've made the choice to say, we need to be on top of these things.

We cannot accept that this strategic agenda we have, that we, we want to get bigger. Uh, we have an m and a, uh, strategy, which needs, which requires us to have, uh, you know, we, we, we don't, we can't afford to have the noise in, in, in, in the engine room. Uh, so, so they verbalized how technical depth for them, how that looked like, which type of problem it drove for them and, and what they wanted to get rid of.

So they may have other types of technical debt, which they've identified, and they said, we, we can live with that, that's fine, but these particular strategic pillars needs to work. Um, and they identified that one of the problems they had related to that was the ability to, to run on software that, that did what it was expected to do. Um, and so, so, so that was one of their drivers to, to focus on why are we automating tests?

Well, it is to target these initiatives. Um, so, so, uh, so having it, you know, not just talking about technical depth as something that you do reactively, which is, I would argue the case in, in many organizations, going back to your analogy on the, on the back pain, um, one morning, I can't get out of bed, I should probably go see a doctor. Um, it, it's the same here, right?

Identify what are the drivers and what do they need in order to, to take my company in that direction? And then whatever it takes to, to make sure that they run. Um, so again, it's, it's, the technical depth is the, is the symptom, right?

So, so what, what is it that you're gonna focus on? All right, folks, well, you heard it here. If you're spending 80% of your time trying to keep the IT environment working, chances are that you're actually working for the IT environment versus having the IT environment work for you.

Hey, today, thanks for being on the show. Thanks for having me. It's a pleasure.

All right, back to you guys in the.