Strategic Cloud Adoption: Balancing Innovation, Legacy Systems and Financial Realities in Technology Organizations | Predict 2024

Well welcome. I'm gonna be talking about strategic cloud adoption and uh, balancing innovation, legacy systems and the financial realities of technology organizations. First, a little bit about myself.

Um, been in the industry for, uh, last 30 years and one of the great things I got to do over Covid was, uh, write a book around some of the things that I've seen in technology over the last 30 years. Today we're gonna be talking about how and what some of that stuff I think is gonna be happening and influencing us for in 2024. But my book End of Abundance talks about some of these concepts that are gonna be talked about today, but there's a lot more out there as well.

Um, here's how you could also reach out to me, um, if there is additional information that you would like, um, both from the podcast and the different articles that I'm writing out there. One of the things that many of us have been doing over the last, realistically 10, 12 years is moving to the cloud and leveraging different cloud resources in different ways. And I always like to understand, you know, sort of how did you get to the cloud?

Um, many times. I also think sometimes it's driven by, you know, I call a boardroom member driving down the highway, seeing that new technology and saying, Hey, I want to go there. Um, you know, that that definitely helps organizations get there, but was it for the right reasons?

Um, when you think about your cloud choice, which cloud provider are you in? Is that the best choice for the applications? How did you guys migrate up there?

These were all the different things that sort of are impacting us today, um, both from a technology challenges perspective and a technology opportunities perspective. So what I'm gonna be talking about today is many of the technology challenges that we have today. Um, and it's sort of coming to a point where we are having restricted and tighter budgets to support essentially 30 to 40 years of technology that we already have built.

Same time as data is growing at 23% compounded annual growth rates. At the same time the business is actually growing at increased paces as well. And even if your top line of the business is not growing, it's use of technology is growing because businesses are realizing that technology and technology services are just as important in getting their job done as it is potentially inventing and creating that new next service that you guys offer out to the market with the business, bringing more applications online, leveraging technology more.

The other byproduct is transactions. Our transactions and everything that we are doing and processing within technology is also increasing at the same time. But is your budget growing at the same pace?

Many of our budgets are now frozen. Prior to two years ago, many of us had these great technology budgets that we could spend, but as money has become expensive, as there has been some inflation pressures, et cetera, now we are having to deal with increased technology requests, still supporting all the leg legacy technology, but our budgets are frozen. So how are we going to still innovate?

Because many of us are talking about AI today and it's gonna create grant, great, great new opportunities, but how are we going to continue to invest in innovate without spending a huge amount of our budget? One of the other challenges that we have is I started insurance about 30 years ago when I started in insurance 30 years ago. There was large amounts of technology that already existed.

Now think about 30 years later, that same insurance company, all the other different technology systems that they brought online. And by the way, some of those same systems that we, that I personally worked on are still there. Those big mainframes, those big IMS systems, they're still there.

But now one of the biggest challenges for many organizations is how do we continue to invest and innovate in the new technologies while supporting the legacy technologies? And things are not getting less complex. They're even getting more complex to where we used to have two tier three tier, now we have interior microservices.

Data's everywhere. You have a hundred different SaaS platforms where all your data is across all those different SaaS for, uh, platforms, potentially having to aggregate gate that back into a central location. These are all the different things that we have to think about as we are technologists or business individuals trying to understand how do we continue to leverage technology going forward?

Businesses want more. Um, one of the, the challenges that we've had in the past is early in the day, the business didn't understand what technology did. They thought we just maintained their email, their file systems.

If something broke, my phone broke, my computer broke, I called 'em. But one of the great things that we wanted to happen, and it has happened and it is happening, is the business understands the value of technology. But the challenge with that, and the byproduct of that is they're asking more of us.

They want us to continue to build more applications for them quicker, faster. They wanna be able to invest in the newest things that are coming around the, the, the corner. And those are creating unique pressures on the technology groups to be able to satisfy those needs.

And this is some of the things that we need to change our mindset and sort of how we approach us both in a service model, technology services, but also what we leverage in both in cloud, the cloud services and the SaaS services. But how do we balance all these different areas and aspects so that we can give the business and meet their demands and needs as well? The other challenge that we've had is things are changing.

So prior to Amazon sort and Microsoft really gaining traction in the cloud, it's everybody had a data center or a colo where we would buy our racks of servers, we'd deploy applications, whether or not I ran them hot or hold meaning high utilization or whatever, I was not charged realistically a different amount of money to be able to support those servers at one, my one capital cost. My CFO loved that as a very predictable expense. But now we're changing into a usage based technology model.

So all this legacy technology that we're slowly migrating up to the cloud, it's the pricing of that is changing. Now we're going to a usage based. Think about those apps, SaaS subscriptions, how many of them have some usage components in there, whether it's consumption based, user based, server based, et cetera.

So as we create more technology, one is the numbers of units that are gonna go up and that's gonna increase our cost of technology. But also what about all that code that you wrote over the last 30 or 40 years, those processes, those systems you designed, were those designed for usage-based model? The majority of them were not.

I do remember back when I started coding, we had very, uh, tight parameters on both the time we could run processes, the amount of resources we could use. Um, you know, we had the three 80 sixes, four 80 sixes, the vein frame. We had to be very careful in co uh, cognizant around what we coded and what number of resources it took up.

Today everybody is coding and building processes on these eight VCPO boxes with 16 gigs a m. That's what we buy our, our team. But is that creating a great outcome to go into a model just like this?

It's similar to me looking at maps, right? So how do we understand the cost of our decision to take the scenic route or the direct route? Uh, you know, this is very similar to code.

So if I take a scenic route to get to my data, to get to my answer, to process a request versus the direct route to get to my destination, in this scenario I'm gonna use potentially a lot more gas, two hours or more time. The same stuff is happening within technology as well. 'cause everything has a cost.

And one of the things that we need to change as a organization, as an individual, as a team going forward, is the way we think we need to think about efficiency and change our mindset. And there's a great quote by Wayne Dyer says, if you change the way you look at things, the things you look at change. And when we think about we are changing many variables both in how we deliver services, where we processes, process our services and technology at the rates at which we're investing in technology.

And unless we start to change, um, our mindset around how we build those fundamental systems, we will write big checks and we'll even impact the environment as well. And those are the things that we need to start to think about when we look at our applications, at our technology, at our implementations of our business services. One of the areas I think that needs to change is our acceptance criteria.

Whenever we build technology solutions, whether it's applications, uh, database schemas, um, technology services, we all accept based upon the functionality of those systems. So when you think about those deployment processes and making sure that that brand new feature that is being built in that sprint, what do we do at the very end? We check to make sure that it is functionally correct and then we promote it up.

If we ever have issues within production within that system, what do we usually do? Infrastructure usually adds more resources. Well, when I use to host that in the data center, adding more VCPUs or memory within VMware or virtualization, a virtualized environment didn't cost me any additional cost in a cloud environment.

If I add and change the service size, the container size of that solution because I am having performance problems and I want to add more resources to power my way through that, guess what I just did? I just increased the cost. But it all goes back down to why am I having issues?

How much am I using? And it goes back down to how did I design that process? How did I build that process?

Meaning when I start to decode that process or design that data model, what are the data types I selected? How am I storing that data? How am I accessing that data via the code?

Is it procedural or set based? Those design choices have financial impacts, resource impacts. One of the things that I see us needing to do as we move to this usage-based model is start to change.

How do we look at our application deployment, uh, life cycles and really step back and say all these other variables have changed. What else needs to change within my ecosystem? I think in the future that we need to start to look at the efficiency of code, not necessarily getting into the code parsing to determine whether or not it's efficient.

Look at the runtime, the output. Did this code run and return a certain amount of value or records per the resources? Ultimately, what's the cost of that code today?

finops is a very large important aspect within environments. How do we impact ops upstream? 'cause today finops is focused on downstream.

Once you've already built, designed, engineered and deployed that feature and you get that bill from Amazon, Google, Microsoft, that is after you've already realized that cost. We need to go upstream to understand the cost of our design upstream, not after we deployed it, because it's a lot harder for us to fix it after we've already deployed and committed that to production. This is where we want to got migrate to, but it's gonna take a large amount of time hardly because we are not thinking about the cost of our design decisions.

When you go and build that application today, usually you get a budget for that project team. You get a budget for building that application. You go and design the application, people start coding, whether it's onshore, offshore, a hybrid.

And then once you've built it, tested it, you feel great about that decision, you go and deploy that to production. Then you ask your infrastructure team, well what would be the best servers to deploy this to? Now think about this.

This is without really understanding the volume metrics of that application, the usage me metrics, the data growth, the transactional growth metrics of that application. I'm deploying it to production on servers that I'm gonna potentially guess what size on code that may be efficient, not efficient, a hybrid. And only then do I ever know the cost of supporting that app.

And that is today. And how often and how long do apps run within production? 10 years, 15 years, 20 years.

We're working with an app that's been running 23 years. Very large system. Do we think part of the the app could have been more efficient early on?

Yes, but we never know the cost of that design until the end, which is one of the challenges and that's why we need to move upstream as well. Another area is data. So my passion is data.

Um, build a company around data. 20 years ago when I said, Hey, I'm focused on data, didn't have the same meaning as it does today. When I talk about data, we think data analytics, we think of value, we think you know, a lot of storage.

Usually people think storage. What's the byproduct that we all have? You know, I love the HGTV show quarters.

I actually think most organizations when we look at 'em and work with 'em, most of us are hoarding data. Why? There's potential value in this data.

I believe it. There's gold out there, but how much gold is in that data and which data actually is gold versus which one is just copper or which one is actually just byproduct? So the cost of my data is something that we're focused on because it's not just the cost of storage.

Every time you have data and access that, guess what? There's a memory cost to compute cost. But this all goes back down to really having a solid enterprise data strategy.

So as you're bringing all these new technologies online, IOT, that generates huge amounts of volumes of data. You have all your SaaS applications, you're pulling all that back, all the key data from all the SaaS PLA platforms back into a larger data lake or data warehouse, whatever you wanna d term it. And then you start to analyze that.

But then you also have all your non-production environments that have, again, copies of the data potentially. Then you have HA and dr, which have additional copies of the data. Then you have your backup strategy, which has additional copies of data, maybe back seven years.

What about if you just added a dollar sign next to that and then told that story to the business and said, this data, do we need it? It's costing us a hundred thousand dollars a year. So this is where we want to really also start to merge financials over technology as well.

But at a greater level of detail. I just talked about code, talk about data, talk about the design decisions. It's interesting to think what happens when I start to tell a story via financials.

And by the way, what language does the business speak? We all speak financials. No matter who is on this presentation today, I could have one conversation around financials, we'll all be able to communicate.

net, we all of a sudden we are in a subset of audience that we could speak to. It's the same thing within technology. The biggest challenge is data and code.

It doesn't just execute one time. Data doesn't just exist today. Think about what I said at the very beginning.

23% compounded annual growth rates. I wish my bank account had that growth rate. Um, it's almost like my insurance bill does have that growth rate, which I do not want.

But this is what we have today. And if you start to look at your data footprint today, the cost of supporting all your apps today, then start to factor in growth and look at what is that three-year cost? What is that five-year cost of your technology forecasted out?

And then an interesting statistic that we have. So we've been focused on identifying efficiency of code for a while and also the cost of code. And when we think about migrating to that usage-based model and what big challenge it might have with that legacy apps, a lot of times we think we don't have time to rewrite my whole app, let's just do a lift and shift and then we're gonna fix it later on.

That has that large cost impact. But the one statistic I do wanna share with you is this 1% of your workload usually equals 50% or so of the cost or resource footprint. Again, 1%.

So if I'm migrating up, if I identify the top 1%, and a lot of times it's a lot less than that, those calls, those pieces of data, those transactions, if I optimize this, that very small subset, I could potential have 30 or 40% gains or cost reductions. And that gives you back a large amount of capacity to be able to understand and process your, your uh, transactions going forward. One of the things that I think we need going forward is better financial transparency of technology.

I have a ba a financial background and a technology background and it's, it's amazing what clarity I have within accounting at any point in time within a business, the clarity I could have. But once you jump over the technology, you start to look at what clarity do I have around the cost of technology. This server's running hot in this Amazon bill or this Azure bill.

What can I do to reduce that cost? By the way, you've already right sized it, it's already in the best server size. What other options do you have?

Unless we start to have better financial transparency down the stack, the storage level, the code level, the process level, we are not able to solve the root cause of the problem and start to actually take out cost gain margin back in the business and become more profitable. Or another way to look at it is as that business is asking more of us to build more technology over time, how can we use this fine out budget even if it's frozen or only growing one to 5% year over year as far as the technology budget? How do we continue to support more technology and organic data and transactional growth in the same technology budget?

We need to find those inefficiencies within our technology implementations today and that's gonna give us that 30% pop that will enable us to continue to invest in innovation of technology to drive the business. Here's my contact information that you have. Um, if you wanna reach out to me, feel free to shoot me an email as well as there's a lot of other, um, information out there around, uh, me talking to different thought leaders out there as well as, uh, sharing some of these other ideas in more depth.

And I thank you for your time.