Technical Debt in DevOps – Juan Orlandini, Insight

This is texturong TV. Hey guys. Thanks for the throw.

We're here with one orlandini who is Chief Architect and a distinguished engineer for insight. They are a services provider and we're talking about digital transformation and Technical debt and maybe they use things are two sides the same coin one. Welcome to show.

Hey, thank you for having me. My code is good. See.

I think one of the issues that we have out there is we kind of tell the business side that we more or less have everything in it under control and then they come along and say we need some new ideas and some new capabilities and then we feel a little awkward because we don't want to admit that maybe we don't have the resources to do that because we're trying to hold everything else together with duct tape Belling wire and this is what we call technical debt. What is your sense of? How big is the technical then?

I know you guys have done a survey right now, but how big a problem are we really looking at? Well, it's actually been around forever this technique issue of technical debt, since the beginning of computer history and actually in any technology because if you think about it as soon as you build something when you build it you project into the future thinking that you have Clear Vision into what's gonna happen, but the Futures messy and it's different than what you ever expected to be having and nobody's ever 100% Right? So the systems the tools the technology Stacks that you choose and all of that have to be maintained and and they will over time become older by nature and some of the choices that you made with what you thought were was great wisdom turned out not to be such great wisdom and retrospect right?

So and then some of them you made the right choices, but you just have to be aware that at some point into the future you're gonna have to change those decisions. You're gonna have to update systems rewrite code up they Technology sex and all that and that becomes harder and harder the longer something has been alive and that's why they call it technical debt because you've gone into it. What's interesting is is that there's a maturity that's happening in the industry and how to think about that.

It used to be that it was something that you just dealt with but you know, the more organizations have been involving through this the more they're coming to the realization that this is no different than financial debt and financial that you have a lot of systems and controls that you put in place so that you don't go into Financial that without knowing it no or without controlling it mature organizations are running their technical debt. Just like they run their financial debt where they literally make sure that hey I am gonna have technical debt at some point with this. How do I plan for that technical that and make sure that take advantage of it so I didn't answer your question directly, but I hopefully I get you the swing of what we're trying to do with our clients.

There's a lot of focus on at modernization these days as part of this conversation. And of course, there's basically, you know, five R's they span everything from replaced to rehost and everything in between. But are you seeing organizations moved to one particular model versus another in their efforts to retire some of that technical then?

So that's actually a really good point. So one of the ours is retire right because sometimes so sometimes you do run into a situation where there's an app that's running you that no longer needs to be running at all. And in fact, when we do a lot of these infrastructure or platform modernization engagements with our clients, we find that about 30% somewhere in the 20 to 30% of their work clothes that they're running in their environment could be completely retired and just shut down and nothing would happen to the business.

They're running by inertia. In terms of modernizing the applications themselves, you know, there's a there's a huge push to this microservices container eyes the Agile development methodology and people actually confuse that you have to do containerize workloads or micro services to do Agile development. And that's actually not true at all.

You can absolutely do Agile development methodologies to get you to a a feature or a product faster. But with a more traditional monolithic architecture and and it just depends and it's really important that you spend time focusing on the outcome and the scale and what functionality each architecture brings to the table for you rather than saying Hey by default, everything is gonna be microservices or by default. Everything is gonna be monolithic where everything is gonna be functions or any of those new capabilities that we have.

You have to be very methodical and understand really what you're getting into because you are going to be encouraging some technical debt at the future if you don't plan for it accordingly. Do we do a good job at figuring out what the fit for purpose is for specific platforms. I mean today I will see a lot of microservices based applications running on kubernetes.

That may be probably shouldn't have been there in the first place because I don't know somebody was patting their resume, but do we need a little more discipline? We do and that you know, it's funny that you say that because we run into that all the time as well and it's for the exact same reason. This is a new cool thing every all everybody is doing a kubernetes and we should be doing kubernetes and then you find out.

Hey, this is a simple Three-tier app you can have a front end Middle where in the back end and that's all you really need. Why would you refactor this thing into like a Brazilian little services that then somebody else has to maintain and oh my gosh, is that really hard? Because it's not well documented.

It's not using a technology stack that's gonna survive the test of time whatever it is, right? Yeah. So are we as mature as we should be as a industry?

Probably not do we have some clients that are very mature in that absolutely, you know, and and a lot of our effort as a Services organization is to make sure that our clients actually have that maturity model and are using the right technology stacks for the right workloads and and processes that they're trying to build. We of course talk a lot about devops and Automation and ruthlessly applying that to lower the total cost of it and Technical debtors, of course part of that issue and nowadays can't walk down the street without somebody talking about AI. So once you're a sense of how automating can devops and these processes get You know and a lot of senses that as a question yet to be determined.

All right, there's a lot of hype right now, especially with these generated generative AI models the large language models and things like chat gpte and all those things. There's new models being announced every day. Like I think either today or yesterday Microsoft announced that they have this new Machine Vision model that can actually interpret what an image says so you can point it at a picture and ask it.

What's what hairstyle is this lady having and we'll say ponytail which is amazing right now. They have new models that'll actually build around coding. There's a new models that are built around all sorts of stuff.

I think over time what we're gonna find out is that some of the drudgery that we do in our daily lives is gonna be taken away. and our jobs will become to be much more of instructing and guiding rather than doing some of the drudgery and I think that's where these AI models are gonna take us how far and how much of that is gonna be overcoming when yet to be the term so that don't buy into the hype too much but there's some promising things coming out that are pretty exciting. All right, we both have a little gray.

So I think we've been around since this conversation about the Divide between it and the business has been going on for three or four decades. Now, do you think things are better now or worse now in this day? Yeah, you know anyway, let me finish the question because I loved it on.

So we both have a little gray which means we've been around the block a few times and we've been talking about the Divide between 19 and the business or the better part of three four decades. Now, is that any better in the age of digital transformation or getting worse? That's a great question and I'll tell you that it's it's shifted around because initially if you look back when you and I were new at this thing The Divide wasn't between it and the business it was the Divide was was really between the consumers of it and and itself so the users in that kind of stuff.

So there was the white pillar or the White Tower kind of a concept then it evolved. There was a Divine between the developers and it and a lot of this devops journey that we've undertaken is to start reunifying all those Concepts again so that you could have the developers the line of business owners as well as the financial people to thin Ops people as well. We call them now working together to bring out individual products and I'm much more cohesive whole but interestingly when we surveyed our clients.

One of the points that stood out as pretty historic is that one of the barriers for Innovation at their organizations is that there's still a divide between it and the Developers? And I think what that really means is that this devops thing is still got a long runway in order for it to become mature and most organizations. It's probably not been implemented properly in many places.

Right and I think the maturity of the industry as a whole continues to move towards reunifying the business the it and the finance side and which includes the developers and to making sure that they're bringing out features and functionality and products in a fiscally responsible way. In a model that supports the business goals and it also allows for the developers in it to work together. So that is still maturing.

All right, those are not the only gaps that exist in that world. There's always a gap between the internal it and team in the external IT services providers. Is that getting any better at we learned how to cooperate with each other?

We still kind of Wiggy something. Well, there's there's different ways to interpret who the external providers are right, so there's people That provides you services that you consume as a service. So think of it as Cloud providers or even in software service kind of providers and that's actually gotten significantly better.

And that's why you see the explosive growth of those Industries. All right that said the choice of what you're using as a business is not gotten very much more mature. We often run into clients that have chosen multiple service providers for the same outcome, but it's because internally one side of the house like one versus a different side of the house that like another one and then neither one of them implemented it completely and it's just a mess.

All right, so that hasn't yeah 100% of all it seems like the larger the organization is the more we run into that. All right. There's also service providers that bring Services into the house into the client.

So organizations like us and know that has gotten better in many ways because How as we engage with our clients more on business outcomes rather than technology driven conversations, we can actually partner with their clients a lot better than just saying. Hey, here's the greatest and latest of whatever it is. Good luck.

Well stand it up and you take care of it from there on when we approach it from a Hey, this is what the business needs to have. And this is you measure it against the business outcome. We both end up doing much better because we can bring the expertise from all of the different things that we've done the client can bring the expertise on there and their their needs and their requirements and deliver a better outcome, but that's that's Something that is typically done by more mature organizations rather than newer startups.

The survey you guys did Cover a lot of ground what surprised you most of anything in there that you didn't expect to see? You know I get asked that question all the time every year that we do this. And there's not one data point that really jumps on and goes.

Oh my gosh, this is brand new. All right, what does surprise me is to constancy of some of these numbers like that it and And developer divide that remains almost like a constant number and has been for quite a long time. So I would have thought by now.

We would have come across that Chasm a little bit but we haven't so we have some maturity go do almost things. So if I were to say succinctly what surprised me it's probably that we're not making as much Headway in some of the things that we thought we were gonna make Headway on as a as an industry then and then not and you know, it might just be that we live in the world where chaos is normally what's your best advice and I just throw everybody in the room and lock the door and hope reason prevails or is there some other way to think about this, you know? There is always a better way to think about it.

What seems to work the best is when you take a holistic approach to problem solving that rather than approaching it from a individual angle. If you look at it from a people or side you're probably missing the process or and platform side you look at it from the process side. You're probably gonna miss the people and platform side, right?

So looking at the three legs of that stool and making sure that you have them all covered. It's probably the best thing and you have to be rigorous and methodical about making sure that you're always including all three. All right, folks.

Well, you heard it here technical debt is not necessarily a bad thing. It's kind of like a credit card. But if you can't make the payment then things get pretty ugly quickly.

Hey Juan, thanks for being on the show. Hey, thank you for having. Right back to you guys in the studio.