FinOps - You can't tool your way out of bad cloud habits

FinOps is not just spreadsheets and frowning, and this episode is proof!

We dive into the people side of cloud cost control, the habits that actually work, and the common mistakes that quietly burn budget. This episode is very practical, with plenty to steal for your own teams.

If your cloud bill has ever made you wince, this one will feel very familiar. 

Want to suggest a topic for discussion on a future episode?  Simply email Alex and Jason on o2i@softwareone.com.

Transcript

Jason 0:03

Welcome to Optimize to Innovate, a show where we help organizations stop wasting money on things that don't add value to their business and understand the technologies that actually will. Join us as we share practical insights into latest trends and innovations with industry experts across everything from software and FinOps to cloud, data and AI. We've got some great guests with us today. So let's jump into this week's episode.

Alex 0:29

So Jason and I regularly talk with customers, whether in one-to-ones or events, and what we see is consistently like their challenges and concerns, top challenges and concerns. One of those is almost always controlling cloud costs. And what we see is you know many IT leaders, but especially CFOs, like finance directors, etc., they're all very used to, they're very comfortable with this traditional data center model and the licensing model using CapEx. You know, I buy my tin, um I buy my software once every you know three to five years, and then I depreciate those assets. And then along comes this whole cloud and this SaaS movement, and that turns that model on its head. Next thing you know, you know, organizations are really concerned about how do they manage those variable costs and how they avoid uncontrolled spend. Now, the good news is that these organizations, you know, they're not alone in their concerns, but as a direct result of the concept of cloud financial management, otherwise known as FinOps, was born. Uh, little known fact, by the way, Software One is actually a founding member of the FinOps Foundation. And if you haven't heard of the FinOps Foundation, they're an organization who, in their own words, dedicated to advancing people who practice the discipline of cloud financial management through best practices, education, and standards. So today we are very fortunate to be joined by two experts from this field. We have Parker and Anthony. So, Parker, do you want to give us a wee intro about yourself?

SPEAKER_00 1:53

Yeah, my name is Parker Nankollas, and I lead the FinOps practice at Software One. Prior to Software One, I was a FinOps practitioner and I've been involved in the the FinOps community and the with the FinOps Foundation for a long time. So I'm currently on the FinOps Foundation's Technical Advisory Council. But in the past, I've also done things like helped create their FinOps professional certification and been involved in other ways as well. Happy to be here. Thank you.

Alex 2:20

And if I remember correctly, you've not only done FinOps in the context with you know somebody like ourselves, but actually you've worked on the on the customer side, on the client side and integrating it into organizations.

SPEAKER_00 2:30

Yeah. Before coming to Software One as a consultant, I was a practitioner, but even as a consultant now at Software One, really, I act as a practitioner. So it's it's a really hands-on with the organizations we work for as if I was just a FinOps practitioner within that organization. Awesome.

Alex 2:46

It's as much a cultural thing as it is anything else, isn't it? Yep. Anthony, please introduce yourself.

SPEAKER_03 2:52

Hello, everyone. My name is Anthony Thurston. I'm a senior FinOps consultant with Software One. Prior to that, I was a cloud practitioner myself. Um I helped stand up a cloud practice at a large airline in the US. So since then, I've been heavily involved with the FinOps Foundation as well, and really looking forward to today's discussion.

Alex 3:13

Awesome. Well, thank you very much both for joining us. So I'm gonna kick us off with quite a straightforward question, I think, because many people might have heard of FinOps or Cloud Financial Management, maybe don't necessarily know what it's all about. Do you want to just kick us off, maybe Parker, with a give us a just to level set us all on what is this topic all about?

SPEAKER_00 3:29

So the first thing I'll say is a lot of people believe that FinOps stands for financial operations, and that's not correct. It actually comes from combining the words finance and DevOps. But I guess another misconception is that FinOps is all about saving money, finding ways to optimize and reduce spend. It's not. It's about maximizing business value. And if you think about value, I mean there's a lot that goes into that. Some of the main things that you'll think of is increasing what you're getting while decreasing what you're putting in to get that. And so if you think of maximizing value, then half of the equation is what am I paying? And if there's a way I can optimize that spend, yes, I can increase value if I'm getting the same output for a lower cost, then I likely increased value. But that's not always how we increase value. There might be times where we are increasing spend, but increasing the outcome that we're getting for that spend even more than the amount that the spend is increasing. So value is still going up even if spend is going up. So yeah, that's that's what FinOps is. It's really about maximizing the value of historically what you spend in cloud, now it's moving to look at more spend than just just cloud. And so now we say maximizing the value of technology.

Jason 4:50

That's really interesting what you were saying, Parker, about the the fact that you can you can increase what you're spending in the cloud, but if you're actually getting out multiples more, then you are you're really using cloud as a lever to create value for the organization. So can you explain maybe using this FinOps term of uh unit economics, how we can actually make sense of part of that equation we're working on and whether it's working for us?

SPEAKER_00 5:17

Yeah, so I like to think of unit economics as the way that we actually measure value. Because we talk about maximizing value, so we need to measure it. I think unit economics is one of the best ways we can do that. Because what we mean when we say unit economics in FinOps is if you think of your business, you have different metrics that might be relevant, and it's going to vary based on what specific topic we're talking about. But let's just say, for example, you have an e-commerce website, a unit metric might be transactions or transactions per month or something like that. When we talk about unit costs, what we what we can do is we can say, yeah, maybe maybe we're using cloud resources to support this website. And so if we look at our cloud spend that supports this website, and we look at something like number of transactions, we can now get to a unit metric where we could say the cloud cost for a website is 70 cents per transaction, for example. Yep. Where it becomes unit economics is when we are comparing the cost metric to some sort of outcome metric, which is often a revenue-based metric, but not always. And especially in cases like government or not nonprofit, uh, it might be, or even just internal applications that are not related to revenue. It can really be any kind of outcome. So in this in this e-commerce website example, we might look at our cost per transaction and compare that to our revenue per transaction. And so when we talk value, we might look at our revenue per transaction is $20 and our current cloud cost per transaction is 70 cents, like I said before. Maybe we optimize that spend and we get it down to 60 cents while our revenue per transaction stays at 20. Well, now we just increased value. Or maybe we increase our cloud cost to a dollar per transaction, but in turn that increases our revenue to $24 per transaction. That's that's still value. Or in some cases, we might cut something, try to try to cut costs in some way that, yeah, maybe it gets down to 30 cents per transaction, but now nobody goes to our website because it's terrible. And our revenue per transaction is now a dollar. Or maybe, you know, maybe we look at it differently and we're we're you know, maybe our revenue for transactions is the same, but our number of transactions has gone down or whatever it is. So that's how unit economics can help us measure and track the value, which then allows us when we make changes and we're tracking those unit economics over time, we can see how the change we made impacts those unit economics and very clearly see did that increase, decrease, or or keep value the same. Yeah.

Alex 8:03

And that's all, you know, in an online retail business, as you say, that's relatively straightforward because you have a clear set of inputs, a clear set of outputs. Much more challenging when you're in other organizations or looking at internal IT. Can you give any examples of the kind of unit economics that you've seen with organizations when they're looking at their internal IT organization or maybe an HR system or you know, something that's not quite so directly related?

SPEAKER_00 8:28

Yeah, so one thing to keep in mind is a lot of organizations think they have to find the one unit metric that works. In some cases, and that's why a lot of companies do revenue, just yeah, cost and revenue. Most of the time, you're looking at an individual application, and the unit economics, the metrics that you're choosing are based on that individual application. And so examples of ones that are more internal or not revenue-based or maybe not as simple, you might have, for example, an accounting process that needs to be done monthly, and it takes six people 20 hours a month each to complete this process. So there's a cost to that, right? There's a labor cost to those hours. Now maybe we build something, again, using cloud costs uh as the kind of the original FinOps uh spend that we're looking at. So maybe we we build something using cloud resources that automates part of that monthly process, and that costs us a certain amount of dollars per month to run. But in turn, that now eliminates or reduces the amount of labor labor hours required to complete that. Maybe now you need one person to spend two hours a month just validating what this automation produced. And so again, you're you're just comparing maybe maybe the outcome there is labor cost, and and we're looking for that reduction in labor cost. And then the the cost there is the cloud cost. So we can see this increase in cloud cost resulted in this decrease in labor, labor required, you know, hours, cost, etc., to to get that done.

Alex 10:05

And for for I think it sounds like the one of the most critical things that we can do in any exercise like this as we start to adopt the call it the culture of FinOps, is we need to start by understanding where we are today, what are our core baselines and core KPIs? Because as we start to make changes, then we uh then we can literally validate what we're doing. Yeah, absolutely.

Jason 10:25

So I have a question, Anthony, um, from your point of view, what Parker's been describing there, you know, that understanding of business metrics that matter. I'm not convinced that all organizations are at that level of maturity, you know, in terms of understanding what's really driving value for them. What what's your experience been?

SPEAKER_03 10:42

I agree with that. I I think a lot of organizations in their journey have are exclusively focused on cutting costs. When they hear the word FinOps, they think let's just cut costs. And they have no real concept of if those cost cutting metrics are really driving the most potential value. So I think that is a journey. Again, FinOps is a journey for a lot of organizations. But uh from what everything Parker was explaining, it definitely is something that needs to be on top of mind. And I think organizations are starting to really think about how much value is this driving.

Jason 11:31

So so when a company initially connects with you around FinOps, is your first challenge always kind of educating them that you know it's it's not just about the cost saving, there is something else that we need to do here that's important.

SPEAKER_03 11:43

Absolutely. And so it's not just cutting costs. So we always start with that frame of mind because we want organizations to not just when they hear FinOps, again, not just focus on exclusively cost savings, but there's such a more big it give system of vet. So they we always we start our conversations with new clients specifically on that.

Alex 12:09

When they're starting, like you know, any organization who doesn't have FinOps ingrained into their cultural DNA, like where where do they start? Where what should they be doing for as the first step to try to get their head around this?

SPEAKER_00 12:21

To Jason's point earlier, a lot of that is just understanding where you are now. So in in FinOps, there's something called the FinOps lifecycle that's inform, optimize, operate. It's three phases where step one is inform, and that's looking at the data, understanding what's happening. Then the next phase is operate, where you're finding ways to improve based on the data that you're seeing. And then operate is where you're putting into practice the things that you found in the operate phase to improve, and then you cycle right back to inform because now you made a change, and now we need to look at what that means in the data, right? So, and this applies to anything. So we we can think of forecasting cloud spend. We could look at what is our current forecast accuracy, and most organizations will find that it's bad. Um, and so then we say, okay, why are we off? That that's the informed phase, right? So then in the optimized phase, we say, where were we off and why? What did we miss? And how could we maybe do that better? And then in the operate phase, we put those new ideas into practice. Where maybe we say, hey, we we didn't account for this variability in in this type of spend or or seasonality, or we just yeah, totally missed a piece of our spend. So now in the operate phase, we account for that, we try again, but then it cycles back to the inform phase where we say, okay, we made these changes. Did our accuracy stay the same, get better, or get worse? And then we just continue to cycle through that. So yeah, I would say that's the the starting point always is starting in the inform phase. We need to understand where we are now, and it's not until we have that picture that we can start coming up with potential ideas for how to improve. And then to Anthony's point, FinOps is is all about continuous improvement. So you cycle through those phases frequently. It's not a one-time thing. You cycle through and and maybe you did something wrong. And when you circle back to the informed phase, you see you were worse this time around than you were last time. Yeah. But that's that's good because because you learn and then you adjust. But the idea would be that as you continue to cycle through that, you improve over time.

Alex 14:28

And I'm I'm curious, who who in this scenario is you? And the reason I say that is because are we talking about is there just a guy or a girl in the business? You know, they're the FinOps person, or is this, you know, is this a broader thing? Like how how do I think about it? I'm the you know, CIO or IT director of an organization and I'm thinking about doing this whole FinOps thing. Is it just me? Am I gonna do it myself, or who needs to be involved?

SPEAKER_03 14:50

We see both. We see organizations with just one person in the FinOps role. You know, that's usually less mature organizations, maybe with lower cloud spend. But we also see organizations with five or six people working in some FinOps capacity. And so it really ultimately should be a culture uh and within the organization as a whole. Moving through the cycles and phases should be something that is not just the FinOps person's job. It should really be how is our finance organization, how is our engineering organization, how is everyone going through those phases? Uh but oftentimes we see FinOps organizations typically between uh three and four people. So yes, it it it should be an organization, but we see the uh actual number of people on a FinOps team, but it varies greatly by organization.

Jason 15:44

So I I have a question here. So if changing the cost model or the cost pattern, let's call it the cost pattern of a workload, just one particular work code, a business system model, um, requires you to involve um system architects, solution architects, you know, developers, system business owner. How does that single person manage to actually get that kind of stakeholder support? Right. Do you see people when they're working as individuals in organizations do you see them struggling to actually get the stakeholder engagement that they that they need to gain traction with the FinOps agenda? Or is there something that makes a difference when you turn up and you see one person being very successful that there's actually something going on maybe there isn't in other organizations?

SPEAKER_00 16:27

I I've often said that when we see organizations fail, or or or some lighter version of that term, right, but not be as successful as they could be in FinOps, there are two main reasons for that. And one of those is exactly this it's it's stakeholder alignment, and it that the the reason for that lack of alignment is usually because the FinOps team or person is reading the FinOps book or going to a FinOps conference and and they're they are finding the things that they believe they should be doing, and they and they sound good, right? They're doing things that they believe the organization should care about and should see value in. But it what we often see is these teams are not successful when those things that they're doing actually aren't aligned with executive business priorities. And so that's definitely something that's important is having the relationship with the right people across the organization and how helping those people. I guess there's there's two sides of it. One is understanding what their priorities are, and then in the other direction, it's the FinOps team making sure they are able to communicate and show how the things that they're doing support that strategy.

Alex 17:38

There's a it's it sounds like it's the absolute classic what's in it for me. Like the stakeholders, if they don't get what's in it for them, you could go to them with a with a FinOps plan that says, look at all this amazing savings we're gonna do and how much better the business is gonna be. And they're they sit there like, yeah, but is that actually gonna affect my role, my team, our budget for our bit of the business, etc. So if you can sh show them what's in it for them as individuals and hit those nails on the head, if you will, then all of a sudden there's more interest in them come along for the ride.

SPEAKER_00 18:09

Yeah, and I was speaking to that in terms of more executive alignment, but it applies also to anyone that we're working with because a FenOps team is often asking someone like an engineer to do things that the engineer maybe doesn't care about. And they they don't see what's what's in it for them. And and that could just be a culture shift that's needed in the organization. If an engineer has no accountability for costs, efficiency, waste, value, if their job, the only KPI that they are are measured against has to do with performance and uptime and and those types of metrics, then they're not going to take time to go make a change to something that even could potentially affect the KPIs that they are are measured against in order to improve a KPI that they're not measured against, like cost.

Alex 18:58

And I I imagine it's probably even more challenging with the difference, let's say, culturally between infrastructure folks who we're we're, you know, let's say we we're used to having these conversations all day long about the impact of certain architectural decisions and the costs that come out of them, versus perhaps application developers. Maybe, you know, they're looking at it as I just need to get my application working. I'll give you a really stupid example of this, right? Um, this is uh quite a while ago, it was an organization I worked with, and they had an application that was peaking, uh it was basically think of it as a uh mobile application, and it was peaking at 700 megabits a second of throughput uh on this mobile application, really quite significant, right? And we did a little bit of digging. It then became obvious that there was a certain amount of traffic where it was just this one teeny tiny bit of messaging was being sent from the mobile application to the server and vice versa. And each one had to have an identity uh an identifier, and the identifier was something like 14 or 15 characters long, it could have been one to two characters long. By making that change at the application layer, the bandwidth reduced by more than like 5x. It was insane because it just got millions and millions and millions of these tiny messages, and so that simple little change can kind of filter through on your infrastructure impact. I think that's it's interesting that FinOps, as you said before, it's not just quite straightforward, like you know, cut input, output, cost here, cost there. It's every small change or every small impact that you make on an environment can have a really significant impact on overall costs and and your architecture.

Jason 20:30

So I have I have a question then. Do we always come to organizations to talk about FinOps after the person's fallen off the cliff, right? Are we always driving the ambulance to the bottom of the cliff trying to sort out the mess? Or or you know, there are organizations who are kind of getting ahead of the curve with understanding you know what good governance looks like, what cloud excellence looks like?

SPEAKER_03 20:52

From my perspective, most of the time it is that ambulance into the cliff we've our our costs have exceeded you know what we expected them to, or the executives are saying our costs are out of control. That is most of the time. However, we are seeing more organizations with the FinOps organization calls the shift left mentality that they're thinking before our costs get out of control. How do we make sure our architecture is the best, you know, in place to be the most cost efficient as possible? So we're seeing a little bit more of that for organizations whose cloud spend is increasing, and I think that's due to just all of the dialogue and conversation that's been out there with the FinOps Foundation emphasizing, hey, don't waste your costs are out of control. Look at it earlier, get ahead of it, and so I think that has trickled down to certain organizations as well.

Alex 21:51

But I I'm gonna ask a really simple question here, and feel free to hate me for it. FinOps, don't I just go out there and get a fancy tool and I plug it into my system? Uh should Is that just the best tool? You guys could just recommend that tool, and then we can just close down this this the session today.

SPEAKER_00 22:05

Tooling is part of it. Tooling can be very helpful. A lot of organizations do that. Yeah. Let me give one uh data point that really describes a bigger picture here of why it is more than just tooling. So yeah, you can, I mean, you don't you don't even need a tool. You can go into the cloud native portal and you can see recommendations that that cloud provider gives you for how you can optimize your spend. And you can take those actions and you can save a lot of money. AWS has a cloud economics team, and they did some research, looked through some data for a lot of their larger customers just to get some insights, see trends, etc. And one of the big insights that they got was that at organizations where 80% of resources are tagged, which just means that tags are key value pairs where you can add context to your usage. And so it's just saying what whatever it is. People use tags for all kinds of different things. It might be environment, team, owner, whatever it is. So like sticky labels on everything, effectively. Virtual sticky labels. At organizations where 80% of resources are tagged, there's a 50% increase in savings. And the reason for that is when you are tagging your resources, you're giving it that additional context. When you have that additional context, you can make better data-driven decisions. And so if you don't have that context, you are somewhat limited in the actions you can take. Because if I don't know who owns something, I'm probably not going to if I have a question, right? If I see an opportunity that I think I could do to optimize that spend, but I'm not sure. Yeah. But I don't know anything about it, I don't know who owns it, I don't even know who I could go ask. I'm just not going to do it. But when I have that context, it might be as simple as, well, now I know who to ask. And when I go ask that person and they say, yes, you can do that. Now I now I just got that extra savings. Yeah. That's one example, but the same concept obviously applies in in a lot of other ways. A tool is great. We can get a lot of good information from a tool. And if all you had, if if you went and just bought a third-party FinOps tool, you would see a lot of improvement over if you're doing nothing. But you are going to miss out on some of that potential increase in value if you also don't have the right processes in place, the right relationships built, the right people involved. By by doing all of that, it augments what what you can do by just using the tool.

Alex 24:38

So it's tools useful for the the let's say the cost savings side of the FinOps methodology, but it's not really going to help with understanding that if we make this tweak here or that tweak there, that's where we're going to actually generate potentially multiples of value on whatever it was that the workload was actually providing in the first place.

SPEAKER_00 24:55

Yeah, tools can do a lot. And there's a lot of adva advanced tooling now that can automate a lot of things. But you talk about people process technology. The tool is the technology piece. It's one piece. If you're missing the the people process side, then you're missing two-thirds of the puzzle there.

Jason 25:12

And I I just want to pick up, Alex, if I can, just pick up on that tagging question. That whole issue of not just understanding, you know, what application, what business application, what internal processes this infrastructure aligned with, what's it responsible for delivering? Is it production? Is it test? Is it dev, all of those important things? Um, one of the things I've seen when we've been working with clients and they've been planning their migration to the cloud is actually how long it's taken them to identify application owners, like business system owners for key workloads. And if you think that you know FinOps is really identifying opportunity, right? Potential to bring cost saving in workloads, we're gonna have to make a change to realise that saving. Now, whether that change is a small one or a big one, every organization has some kind of change management process. And you're gonna need the people who are the ones who are responsible for that workload's uptime, performance to actually give their approval or for somebody to actually sign, you know, whether it's digitally or whatever, to say that they're happy for that change to happen. And I think this is an important part that people don't necessarily uh think about it, but the ownership of systems and even I'd say if you want to do FinOps well, and and I'm I'm kind of a bit freestyling here, and you guys can tell me what you think, but to what extent is even something as simple as the way an organization does change management and the way they see uh FinOps related change compared to some other kind of release, to what extent does that get in the way of or enable FinOps to actually happen for organizations?

SPEAKER_03 26:56

I think from a change management standpoint, going back to the people process technology, the process is a part of it. So if we even have a tool in place that gives you all of the cloud cost optimization opportunities, you have visibility in your costs. If you don't have a process in place for engineers to go in and understand what their applications is costing, or if there's not a process in place for the FinOps organization and team to effectively communicate with the engineers, this is the actions you need to take, it won't matter, right? The tool is only as best utilized as those processes. So the change management piece is huge, and I do think it is difficult at at times to make that connection because everyone's just used to doing things their way. Engineers aren't necessarily used to having a FinOps organization, you know, hounding them for cost, optimization, and this is how you should potentially re-architect this. So having an effective change management process and just really organization that can communicate well uh it makes a huge difference in in how effective your FinOps organization will be and how effective you can utilize any tooling.

Alex 28:13

Yeah, that what's interesting there for me actually is you know you're touching on things like engineers and other folks within an organization. Sometimes people just don't realize. Like it can be that simple, can't it? Like, that's one of the things I thought was really interesting about um, you know, some organizations are really hot on uh chargeback, for example, right? Okay, you're you're part of the organization's consumed this much of our IT infrastructure, so we're gonna send you a bill for this much off your off your PL. Cool. Um, other organizations where they just, you know, IT, for example, is treated as a uh it's a cost center and we just accept it as part of the business. Um often departments have no clue what the impact is of the workloads that they're running. And so even something as simple as like introducing showback can be really effective with people just going, oh, I had no idea that we were spending a hundred grand a month on this particular service. I mean, are there any other kind of ways that you've seen that have been really successful and helping to help people to understand what they're doing? You know, any kind of rituals they might go in and get into.

SPEAKER_00 29:13

Yeah, the showback chargeback conversation, that that's a good one. An interesting thing there is a lot of people see chargeback as more mature and showback as less mature, where really it's it's a strategy. When you do chargeback, a couple things happen. One, your data has to be right, that you're gonna get a lot more scrutiny if you're actually billing someone for something. Yep. And then because they're being billed for it, there was one organization we worked with who had some internal shared costs for things like security that they provided to all the other application teams. And when the organization started charging those teams for those shared costs, there were teams who said, we can do this cheaper ourselves. We don't want to use your interesting shared security processes. We we we can do this cheaper ourselves. And obviously the organization didn't want that. Yeah. So unintended consequences. Yeah, so that's that's maybe a risk of chargeback, is you do want to be aware of the behavior that that's going to drive. When you're charging someone for something, they will take it more seriously. And in some cases, that's bad because in some cases you don't want them denying something or or turning something off because they're being built for it.

Alex 30:27

Are you suggesting marketing shouldn't be in charge of the uh security budget?

SPEAKER_00 30:30

Is that what I'm getting from this? But with showback, you get the opposite, right? People won't complain as much if the data's less accurate. You'll still want to get it as accurate as possible, but you'll you'll get l yelled at less. But yeah, on the flip side, people might not care.

SPEAKER_01 30:44

Yeah.

SPEAKER_00 30:45

Another organization was using two very similar, to be honest, I don't remember what the tool was. I'm gonna use this as an example. It might have been this, I might be remembering wrong. But it was something like they they had an agreement to use across the whole organization, both Zoom and Teams. And it was an organization-wide agreement. So they were paying both vendors to license everyone in the organization for these two overlapping products. And they were doing showback and no one cared. But all of a sudden, I mean, let's say each of these cost a million dollars a year for the whole organization. And when that split between a hundred teams, the cost per team is a lot lower. When this organization was doing showback on these, and and there was one team who was still on the old tool. And doing showback, they didn't care. But once they they didn't even have to start doing chargeback, they just said, Hey, by the way, we've been giving you these reports all year. Next year, we're switching to a chargeback model, you're gonna have to start paying for these. And when the one team sees that they're about to be charged a million dollars a year for this product that they're not getting that value out of, yeah, that caused them to switch over to the one everyone else had switched to, and then the organization could could not renew that agreement. So really interesting. So yeah, it's just interesting. It I I don't see it as a maturity thing, showback chargeback. I see it as a a strategy based on the behavior you're trying to drive. And sorry, I strayed a little bit from your question, Alex. Uh, we can circle back to it if you want, but I would say, yeah, so showback chargeback, if you do it right, that is definitely a way that we can drive accountability and make people aware of their costs and then hopefully also change their behavior.

Jason 32:26

So it's really interesting you're mentioning um software there, you know, because we we think that cloud financial management is just about clouds, we think FinOps is just about the hyperscalers, right? About making the best value, you know, cost value decisions around using hyperscaler services and products. But FinOps has been changing. I've noticed it's been adding in additional scopes. And for those who aren't familiar with it, the scope is really the demarcation or the edges of what matters to FinOps as a as a movement. So, Andy, can you talk a bit more about those two scope additions? Maybe if you talk first of all about the software as a service one, and then we can lead on to talk about the AI one, would that be okay?

SPEAKER_03 33:04

Absolutely. The software as a service as scope has really gained a lot of traction recently. But we've had numerous clients talking about how can they do FinOps for SAS essentially. You know, I think that that scope term has really started gaining traction within the community. The good thing about it is all of these concepts can be reused a lot of times. So we always emphasize the clients that FinOps for SAS, for example, the same foundational concepts still apply. So you're not having to do anything brand new, but you are having to get different levels of visibility into costs that you may not currently be looking at. That is, you know, one of the challenges I would say right now uh within organizations is getting that cost visibility into one of their SaaS costs, for example. We haven't seen tools so far effectively give you that full range of SaaS costs, for example, but it is coming along in certain organizations. But I I would say that is the biggest challenge right now organizations are facing is getting that cost visibility. But a lot of the other foundational elements of FinOps still apply um even to these new scopes that are that are coming.

Alex 34:24

I mean I know some of our uh consultants, one of the quote unquote tricks of the trade is to look at the DNS on the corporate network and just see some of the names of the SaaS companies that are going through that nobody has a clue that they're actually utilizing that software because it turns out it's being paid for on somebody's credit card. Again, it can be a really interesting way to get a bit more visibility on what's going on inside the business. And you talked about uh Jason was touching on AI there. So it wouldn't be a podcast in the year 2025 without the uh the two eponymous letters being used. So what like what's been the impact of this whole AI movement in FinOps?

SPEAKER_00 34:59

Yeah, so within FinOps, we talk about FinOps for AI and AI for Finops. And we have to clarify that because when you talk about AI and FinOps, some people think of one or the other. So AI for FinOps would be using AI to support your FinOps practice. We we could talk about that, but I think the more interesting one right now is FinOps for AI, where we're talking about how do we apply FinOps principles to AI spend. Yep. And that is getting traction in the community as well. Companies that are using more AI software, tooling, resources, it's very important gaining a lot of traction. There's still a lot of companies who don't really care about FinOps for AI because they don't have a lot of AI usage, but obviously that's only going to grow. AI, at the FinOps X conference this year, the FinOps Foundation shared some data about the growth of cloud spend over time and the growth of AI spend over time, and AI spend is growing at a as fast as cloud grew, AI is growing significantly faster. And so it's going to become a much bigger topic. But the interesting thing is, yeah, at first we were thinking of within the FinOps community, thinking of AI as its own scope. How do we do FinOps for AI? The interesting thing about AI is there's not a single pricing model for AI. Some spend is consumption-based, like traditional cloud spend. Some is SaaS, some is a combination of both. Even when we're talking consumption, there's different types of consumption when we're talking, yeah, potentially things like tokens or things like different cloud AI cloud resources that are billed more like typical cloud consumption. So it gets really complicated, but at the same time, it's still FinOps. And so where the community is kind of now starting to think is it's moving from looking at AI as its own scope to looking at AI as something that is within all of the other scopes. When we're doing FinOps for SaaS, part of that SaaS spend is going to be AI spend. When we're doing FinOps for cloud, part of that cloud spend is AI resources. So yeah, it'll be it'll be a little bit of a learning curve as the industry kind of figures out the best way to handle some of the specific complexities around AI spend. But at the same time, it's what we've been doing all along.

Jason 37:22

So I have a quick question there. I mean, would you say that one of the differences between where we're at with cloud and where we're at with understanding AI consumption um driven spending is that, you know, in the era of cloud, we've had years now for the hyperscalers to try and bring us data formats that we can work with, for the tools to get used to those data formats. And what I see on the AI side is people implementing technological solutions in code because they're not seeing visibility on spend through from the vendors. I mean, how different is that visibility between what we see now with the traditional cloud hyperscaler consumption and some of those frontier models that people are using?

SPEAKER_00 38:01

There is a lot of inconsistency, and I assume over time that will go away and it will become more consistent in how AI is built, how usage is measured. But right now it's it's new. So so yeah, there's there's more inconsistency. So some some of it is easier, some of it is a lot more complicated, and so yeah, not a good answer, but but it it it depends. There's certain cloud resources that it in like in AWS, you can use different resources like SageMaker, and it's billed like other clouds men. So the the billing side of it is is no different than getting billed for any other resource. And similarly, there are other products that are just it's a license and you you pay an annual fee for a license. It's getting complicated where there's some that there's a license portion as well as a usage portion. So it's a little complicated because you're combining two, but it's still two things that organizations are often familiar with, how to manage that type of spend. But then there are others where yeah, it's built in a way that feels more different than anything else that we're doing. And so that I think the industry is still figuring out the best practice for those, but I think also, yeah, it'll get more consistent over time and and that should make it more simple as well.

Alex 39:16

So it's a really fascinating topic. And actually, I think given the the zeitgeist, if you will, of AI, it would definitely be a really interesting topic for us to follow up on later on. Maybe we'll do that in another show uh in a few months, looking at how do we how do we control those AI costs in this in this new world. So I think we're we're up on or maybe even out of time now, but I'd be super interested to know uh maybe if both of you chaps could give us a a little uh recommendation of either a book you've read or uh a a further learning resource for somebody who's uh interested in either maybe the FinOps journey or something else.

SPEAKER_03 39:52

Absolutely. I have two recommendations. One is the FinOps pod by the FinOps Foundation. I listen to that weekly. They put out new content just on things that are going around in the broader FinOps community, great resource. Another one is LinkedIn actually. So I just search FinOps and then I go to posts, and it has all of the posts globally of everyone posting about FinOps, and there's tons of great articles, just learnings that people are putting out um FinOps wide. So that is another great resource.

SPEAKER_00 40:25

Fantastic. And uh Barker? Yeah, my my recommendation is is not a book, and it's funny, FinOps probably moves too quickly for books, right? So looking for more real-time information. There is the FinOps book. The FinOps Foundation has put out a book called Cloud Finops. The next version will probably just be called FinOps since it's evolving beyond cloud. But also, if if you join the FinOps Foundation, you get access to their Slack channel, and there is a lot of good information there. If you do FinOps for your job or anything FinOps related, it's a really good resource. But one of the channels is called Reading List, and people post there every week different links to interesting articles or videos that could be interesting. They're not all necessarily FinOps specific, but they are just meaning it might not be articles about FinOps, but it might be articles about managing SaaS costs or about AI spend or topics that are going to be interesting or relevant to FinOps practitioners. That that would be my biggest recommendation.

Jason 41:30

Yeah, that's great. And one of the things about the FinOps Foundation that I've always found been really impressed by is the fact that they open their content right out to everybody because it's it's like um it's a Creative Commons license, isn't it? So you can use their stuff as long as you give them credit, you can use their slides, you can communicate with their decks. It's really, really good if you're doing something internally with FinOps to actually go on the FinOps Foundation and see what have they got that says you know these wonderful pages where they've got the the key processes or some of the things you've been talking through. So I just want to say thanks very much for being able to join us on the podcast today.

SPEAKER_00 42:03

Yeah, thank you. Happy to join anytime, happy to share what we're seeing. Thank you so much. Thank you for allowing us to be on it today.

Jason 42:10

If you liked this episode, don't forget to hit subscribe on your favourite podcatcher and leave us a review. It really helps more people find us. And if there's something you want us to cover in future, don't hesitate to leave a comment or let us know via socials. We're at Software One just about everywhere. And we'd love to hear from you by email on o2i at software1.com. That's o the number twoi at software1.com. Until next time.