Technical Debt in Application Modernization with vFunction’s Moti Rafalin

This is Textron tv. Hey guys, thanks for the throne. We're here with Modi.

RA is CEO for V function, and we're talking about the tension that exists between application modernization and technical debt. Technical debt of course, will always be with us in some form or another, but it's getting harder to manage. Moori, welcome to show.

It's a pleasure to be here. Mike, Everybody I talk to is having some discussion about application modernization. And the problem is, is to the point, there is a massive amount of fixes that never got addressed.

And some of them are security related and some of them are performance related. And going in after all that stuff is, shall we say, daunting. So, you know, how do I strike a balance here between what I wanna modernize and all the stuff, then I just can't fix.

So I think you, you, you first have to, you know, ask the question of, you know, you can't manage what you, you, you can't see, right? So the problem is that in the first place, you don't even know how much of that technical debt exists. You don't know exactly where it is.

Yes. You know, you have vulnerabilities. Yes, you, you know, you have a substantial architectural technical debt or other types of technical debt.

But I would argue that the first step in addressing this problem is getting visibility into the amount of technical debt that you have. And only once you have the visibility and you can measure it, and you can quantify it, and you can prioritize it to address specific business needs that you may have, then you can start tackling it. Do you think people are just underestimating the amount of technical debt they have and it tends to accrue over time?

There's been multiple generations of applications and multiple IT teams, and maybe we're just kinda putting our heads in the sand, but, uh, eventually, doesn't all that stuff come home the roost? Look, I think that of course everyone is under pressure to deliver more functionality, to innovate faster. And of course you, you've got quarters and you, you just want to, you know, deliver as fast as you can.

And what is not, let's say urgent, even if it's important, gets kind of pushed, right? So that, that is the challenge that every organization has. And so the moment that they start addressing it is obviously the moment that they're starting to experience the manifestation of that technical debt, which is outages that all of a sudden their engineering velocity, you know, goes to almost zero where they're experiencing, you know, scalability challenges, then they know they need to start dealing with the surf root cause of, of that.

But you're right, it's a big challenge of how can you strike the balance between, you know, moving fast and delivering functionality and addressing the business needs and repaying some of that technical debt, which really has to do with the, what we're doing, by the way, right? Because we, we believe that that is a, a really big problem. Uh, and the only way to address it is if you at least get the visibility into that technical debt and you're able to prioritize it and you're able to allocate it on an ongoing basis, right?

So you mentioned modernization. One of my kind of learnings over the past few years is that modernization is not a project, it's a process, right? So no one wants to stop everything and embark on this, you know, $5 million or $20 million modernization project that stops everything and need to rewrite the entire applications, right?

No one is willing to do that. And so the right approach is, you know, piecemealing it, right? Doing small chunks every release.

And you can only do that if you have the visibility and the ability to prioritize those different parts of technical debt that are impacting your business the most. We hear a lot about AI and code these days, and I can't help but wonder if we'll be using algorithms to A, identify the debt, but b maybe automate the remediation process a little bit. 'cause I should be able to generate something that fixes something, right?

Absolutely. I think that that's where we're headed. You know, I get asked this question a lot.

I I think that, um, LLMs are not really, you know, designed to help architectural issues that you may have in your applications. I think that requires a specific, you know, type of algorithms and, and a lot of data science. And yes, machine learning, artificial intelligence will help it, but not necessarily, you know, a large language morals if you ask me.

Um, so I think that is a, that is still a problem to be solved. I think that we are solving it a little bit. Um, but in terms of rewriting things, then of course, you know, artificial intelligence will be able to help you, you know, write new things faster, the fix things.

I think that could be a little bit more challenging. Yeah, I've heard this controversial thought that, uh, with LLS with artificial intelligence writing more software, actually more technical debt will be created. Um, i, I don't know if I, you know, necessarily agree with that.

I think that remains to be seen. Uh, but it's interesting, you know, what would be the impact of, you know, more AI writing software on technical debt? I guess it would depend on how the LLM was trained, right?

Because if it was trained with examples of code from everywhere, well, a lot of that code has issues and so then the output's gonna have issues. So we would need to train the LLM with more code that was vetted. Is that correct?

That is one aspect. The other aspect is that, let's say that you're using AI to write the software. How much does it know about the, the environment and the ecosystem within your organization, for example, right?

How much are you now, you know, uh, duplicating things that may exist within your organization? So, so the, these are questions that are, I think are hard to, to address as, as we're thinking today about a AI and writing software, because it's not, you're not writing it in a silo, right? Usually you're, you're writing software and it's in an enterprise, it is part of some, you know, larger ecosystem within the enterprise, you know, more services, more lines of business.

So really how much are you, you know, reusing existing components? How, how much are you reinventing the wheel? I don't know that, that, those are, I think, outstanding questions.

We've also seen, you know, this whole approach where there's the five Rs of application modernization, sterning with refactoring and all kinds of stuff that goes with that. Um, is that still relevant in this age? Is that the process?

Or is, or is that changing? You know, uh, I think that that was by the way, invented by the cloud providers, uh, the, the five R model, right? Because they were thinking, you know, how can we get as many workloads as possible and as fast as possible to the cloud?

Uh, but that goes to the heart of the problem that in my opinion, it's not a one time thing. You, you don't refactor in order to bring it to the cloud. Let's say you refactor, you want to make it your, you want to make your workloads, let's say more cloud, uh, native or suitable for the cloud, fine, you do that, but you need to continue to refactor it into modernize applications because they re accumulate technical debt, right?

Technical debt is something that you need to manage on an ongoing basis. So you need to observe the architecture and you need to remediate the technical debt that accumulates, again, maybe two, not a hundred percent of it, but to a certain degree all the time. So it's not a one time thing that you migrate to the cloud.

So that's why I think that the, the R model is, is an interesting framework for, you know, the cloud providers to sort of assign different modernization strategies for your application estate. But I don't believe that modernization is a one-time thing. And so that's why the R model in my mind, is not as useful As part of that question.

The assumption is sometimes that we're all moving to some sort of microservices based application architecture. But I talked to some folks who were like, you know, that's hard and maybe a little overkill, and they'd rather stay with their monolithic application. So, um, what is the arc of modernization and when should I do what?

Should I break everything into microservices? Or is a monolith essentially just a big microservice? So, absolutely, you don't have to, you know, transform every, every moderat to microservices.

Of course, there's a trade off, there are advantages. And of course there are disadvantages in the microservices world, right? So, you know, sometimes they hear organizations that they have mandates to move to microservices, but then I challenge them.

'cause the question is why, I mean, 'cause there is obviously overhead. There's overhead in deployment in complexity, right? You know, multiple, you know, uh, services that need to deploy.

So, so, and, and you know, coordination. So these are disadvantages of microservices latency, right? And so you have disadvantages with microservices.

So you would want to move to microservices only when you have one of, you know, maybe two reasons, I would argue one, engineering velocity. So the application grows to a certain, you know, size and complexity that you need to break it in order to have multiple teams working on different parts of the application. So I would argue that is a good reason to move to microservices.

And in that case, you're willing to pay the price of the overhead of having microservices. And secondly, scalability, right? So if you need to scale something to scale something out, then of course neurolytic application may not scale very efficiently, right?

So you want to break it into microservices. You can then take advantage, you know, of the more advanced cloud services that allow you, you know, unlimited kind of scalability. I would say that these are the two main reasons.

But if you were concerned, concerned with latency, and let's say the application doesn't change a lot, stay with the monolith for sure. It's a, it's legitimate architecture. Will people hide their efforts to address technical debt in a modernization effort built around ai?

'cause I could see a model that goes, or a conversation that goes something like this. We need to put AI in everything that we're doing. And so we're gonna like start adding that capability, whether it's an API call or embedded into the application.

And while I'm doing that, I'll go in and add some budget to clean up the technical debt that already exists in that application. And 'cause it's difficult to go to the, um, senior leadership of an organization and go, yeah, we need to allocate budget for technical debt. 'cause they'll just be like, you know, let us know when it breaks.

It's possible that AI is a catalyst to addressing some technical debt. Um, I certainly hope so. Uh, out of my own benefit Uhhuh, uh, um, you know, what remains to be seen.

I think we're obviously in the early innings of that. Um, but for sure I mean it, you know, the generic problem is, you know, how quickly can you innovate and how, what is your, you know, the engineering velocity. And so if you want to add now AI and, and you have two complex applications and your engineering velocity is, is very, uh, slow, then, then of course you need to refactor.

You need to modernize in order to take advantage of ai. If you visit the city of New York, you'll see a ticker in one of the squares tracking the national debt, and it goes into trillions and trillions and it's just a meter that keeps tracking all that do it Organizations need some sort of equivalent meter to track their, uh, uh, technical debt on an ongoing basis. So I don't forget about it 'cause it's easy to kind of put it outta mind.

I certainly believe that they should have that ticker. 52 trillion of tech debt problem in the US Mm-Hmm. Uh, so, so that's, uh, it's not as big as big maybe as our international debt, but, uh, but definitely, but, but at least that one gets tracked, right?

And your technical debt is something that organizations are actually struggling to measure and to, to observe. Um, so I think that the first step in addressing it is measuring it. And I think that organizations are not there yet, for sure.

They're not there yet. So that's definitely an area for improvement As the organization or the entity that built the application in the first place. Am I really able to assess its technical debt?

Because I'm gonna be a little biased, am I not about what is and what is not technical debt. So do I need some third party validation here? I, I think you need, obviously you need tools, right?

And you need, and if you think about technical debt, and I like to think about this holistically, right? So you've got code quality tools, right? That deal specifically with, you know, code smells and, and there's, you know, a bunch of tools that do that.

And you've got vulnerabilities of course on the security side, right? So you have aging frameworks that of course you need to, to have, you have tools to measure that. And that is measurable by the way, and it is measurable to the point that people are drowning in, in, in, in their ability to actually address it, right?

So there are so many vulnerabilities, they don't even where to start, uh, in terms of, uh, upgrading frameworks to address those vulnerability. So that's another aspect of technical debt, uh, that is actually a little bit more, uh, measured. And then there is the architectural technical debt that, uh, based on, you know, studies and based on, you know, analysts are saying is growing to be 80% of technical debt will be architectural technical debt, right?

Because when you're developing and you need to speed more and more features, you're cutting corners in the architecture. That is where kind of you're, you're making the, the, you're cutting corners and you're trying to accelerate, and that is where you're making bad architectural decisions just to get the features out. So I think that architectural technical debt is the biggest portion of technical debt and the one that is not measured, and then while there, that there is no good visibility into.

Um, but there are objective tools to do that, right? To, to understand the modularity of your architecture, right? The complexity of your architecture.

These are things that are absolutely measurable. Uh, so there are less, uh, subjective. Now, I, I I know that where maybe where you were coming from is that there are some tools that measure technical debt by counting like bugs or defects or things of that sorting the kind of, as part of the development process.

I, I think that's less, uh, objective way of measuring technical debt. I think you just need to look at the architecture and assess it. How big do you think our cybersecurity technical debt is for these applications?

We hear a lot about DevSecOps, so might we not address some of that portion of our technical debt through these more advanced DevOps processes? 4 trillion per year. That's the impact.

Uh, and I believe that a good portion of that is cybersecurity. All right, well there you go folks. I think you heard it here.

Technical debt. It's just like the debt on your credit card. If you keep just paying the bare minimum, that credit will eat you alive.

So there you have it. All right, Moni, thanks for being on the show. Thank you, Mike.

Uh, it's a pleasure. And back to you guys in the studio.