Episode Transcript
[00:00:00] Speaker A: Welcome everyone to a new episode of the Finos weekly podcast. And today we are going to talk about all the changes that we have seen about the scope of finops and how is it affecting the different companies and how the different companies are dealing with that. With Sasha Kipperbag, the CEO from Ternary. Sasha, how are you?
[00:00:21] Speaker B: I'm good, Victor. It's good to be here.
[00:00:23] Speaker A: It's a pleasure to have you. I know, you know one of the references that I have in phenoms since I started and you know, today we are going to talk about all these changes that have recently happened into phenoms, about the scope of phenom. So as you probably know, the idea of phenops or even the definition and the things highlighted from the FinOps foundation, the other on the State of PhenOps Report 2026, they mentioned the change from cloud spend to more of the technology spend, so amplifying the scope of phenips. So in your perspective, what do you think about this change? What are the implications of it? So can you tell us a bit more from your experience about what this implies to the FinOps ecosystem?
[00:01:14] Speaker B: Of course. And Victor, I'd like to start by thanking you for hosting me. And I come to you in two different dimensions. First is as a member of an OPS governing board and member and a former practitioner as well who operated at a particular scale and also as co founder and CEO of Ternary. And so maybe I'll start with, you know, as, as a member of the FinOps community and help explain to the wider audience why we made the change that, that we made and what I think it means and then maybe we can go into the history of technical spend management and then talk about terney a little bit after that. So first and foremost, for those of you that don't know, the Finos foundation expanded its scope to include AI spend, third party SaaS spend, data center spend last November and we announced that. And at the time I wasn't quite sure if that was even the right thing. It was a little bit of a debate in my own head about what made sense.
We were beginning to see customers who began to ask for data center spend, and I heard from other practitioners within the FinOps community that they were beginning to approach that as well.
But I wasn't quite sure if we were going to dilute the mission of the FinOps foundation by agreeing to this expansion.
Since then, I think it's become very clear that whether we like it or not, the FinOps team that was assigned the task of managing Cloud spend and then multi cloud spend. They've been asked to expand their mandates and so I think it makes a ton of sense. I think it was good sensing on behalf of the leadership of the finos foundation, and I do support it. What we've seen over the last week is the announcement that the mission changes well, to emphasize the value of technology spend overall, not just cloud spend. And we've adjusted the mission language itself and we're seeing the convergence of ITAM and ITFM as well. And I think this all bodes well for the community and I think it's a recognition that in the market there is no team other than the FinOps team who is responsible for all of the technical spend. And I think it's a recognition of the mission that what the technology suite really cares about most is understanding the value of all technical spend. When executives make decisions about what to invest in, they don't just want to know what we spent and what value was created in cloud. What we've observed is that for the last five years or so of the finos foundation growth, we've had tools and an effort to emphasize engineering, getting engineers to take action, getting them to spend efficiently, getting them to optimize their spend, spending to plan, getting them to just do the right thing. And there are lots of tools out there that have done this.
The market, you could argue, is flooded with them. And maybe the practitioners are even slightly overwhelmed with how many tools there are. But what we haven't had and what I think we are beginning to emphasize now with the FinOps foundation change is an acknowledgement that we have mostly ignored understanding the value created from managing the technical spend. And what the executives and the financial suite want to know is, hey, I've made this extraordinary investment across AI, across not just one cloud, but multiple clouds now, across third party SaaS, abstractions like Datadog and Snowflake and databricks. And I've got all these things I've spent money on to create additional, to create value for my company.
How do I understand if I should iterate on it because it's not quite making me money, or what products of mine should I kill or which one should I accelerate because they're making me money? Those are far more interesting and substantial questions now. I think we've been solving for one half of the equation for the last five years. It's now time to solve for the other side, which I think is a much more valuable and interesting conversation. And frankly, it was part of the reason that I co founded and created TERNARY I thought, you know, almost six years ago that we needed to build tooling for both finance and engineering, for both of them to see the data in their own ways to understand the problem for companies to be successful in the cloud and beyond. And so I think we've arrived at that moment today.
[00:06:21] Speaker A: No, that's, that's fairly interesting that you, you will it on that purpose and now it's, it's arriving. I have to say that when I was discussing with, with other practitioner, I think it was here in the podcast that there was the amount of spend that the cloud meant compared to the total wasn't as relevant as I think we from the people that come from the cloud think about. And there was like all these cost drivers, let's call it that way, that were way higher compared to the cloud, such as the licensing and the on prem and all of that. So I think it was like the effort of the community and expansion of it that makes it reach this point. And I also think that will be considered, I think there will be challenges to integrate everything into finops. So now the idea is there and now we have to execute it. So what do you think from your experience and from the history that you have seen in it, what do you think it, how it will develop? How do you envision this going forward?
[00:07:33] Speaker B: Yeah, well, in order for us to understand the future, I think we have to understand our past first. And so let me take you back to pre 2003, which is roughly when Amazon released its first infrastructure as API services.
When we built things prior to that moment, we built them in data centers, and sometimes they were our own data centers, and sometimes we rented space inside of data centers. But it was a relatively straightforward calculation.
To understand the value being created by our investments, we could do it in a spreadsheet where we would have the list of inputs, we would have how much we spent on data center physical space circuits, storage, cpu, ram, so on and so forth. It was a relatively short list. And you could do it all in a spreadsheet. Your inputs, your outputs, how much total money you made, and then you could figure out your unit cost and your margin.
If you had a very large environment, you could even use the traditional financial systems of record at the time, like SAP, Oracle, whatever they were, to figure all this out and track it. And the bills that came in, they didn't have billions of rows, they just had a few line items and they were easy to interpret. Right. So that's how we did it. That's how we figured out both on the engineering side in terms of efficiency, and then on the business side in terms of what value gets created. It was a straightforward calculation.
And then all of a sudden Amazon appears out of the blue and they say, hey, you know what, you could stand up infrastructure by API and you could get billed by it by the minute. You don't have to pay for it upfront. It's not a capital investment.
Right. It's just an operational cost. And, you know, if you only use it for an hour, great, we'll only bill you for an hour. And you get a bill in the mail that has, you know, many more line items. But in some ways you could pay less if you manage to game the system in some way. Right.
I believe that the cloud providers were building a particular system that naturally encouraged certain behaviors, and they did it purposefully. Okay, I had. I have to believe they did it purposefully on the one hand, to create value for startups that didn't have money to spend on data centers and capital investments. But at the same time, they understood that if they could put the decision to spend money in the hands of developers who could sit at a desk and spin up 10,000 CPUs across multiple regions, right, without going to finance, without actually getting buy in, well, of course they would move faster.
But it would create a mess. And who benefits from that mess? Well, there's a financial benefit. Now, of course, that's a cynical viewpoint. Right. And I understand there could be other viewpoints too, but, you know, that's the system that was built and we all jumped into it, okay? And over time, Amazon grew to have many different services.
And then we had multiple cloud providers join the party as well with many more cloud services. And, you know, for the longest time, everyone was on a single cloud and the tools that meant to manage this from the cloud providers made sense.
And you had this budding ecosystem that cloud health and cloudability pioneered. And, you know, I'm grateful to them for having done that. Kudos to them.
And the problem just got worse.
And I remember there were many years, and you could argue even now, where a company would say, we're moving to the cloud to save money.
And everyone knew that that was crazy. And no one said anything because, well, you could go faster, you can get your product out the door faster, you could beat your competitors. All your developers wanted DevOps. In order to make DevOps happen, well, you have to move to the cloud in some way, shape or form. And so we would continue to go over the cliff and say we were doing to save money. And never save any money, but just go faster and create a little bit of chaos.
Chaos can be creative too. And so we got some benefit as well out of it. But the problem just got bigger and bigger and bigger. And over the last five years, what has happened?
Well, on the one hand, FinOps captured the imagination of the ecosystem in a way that no other framework has done. So you have today a FinOps team at every mid market and enterprise company that did not exist five years ago.
And they have been given a language that they can use to speak to their executives, to, to themselves. They've been given a framework with which to approach the problem.
That is very important and it is important for us to understand how unique it is, how special that is and how it has created essentially an entire industry, all in an attempt to solve this problem.
Besides that, the problem of spend has grown to multi cloud. And we went from saying everyone's well multi cloud's not a thing yet, to all of a sudden saying, well, everyone is multi cloud. Whether they like it or not, whether by acquisition or leverage, through pricing negotiations, everybody's multi cloud. And then at the same time, like the SaaS abstractions arrived as well. And they became a very important way to leverage the cloud in different ways, like databricks, Snowflake, and they have variable billing as well. And their spend needs to be efficient. And then now in the last few years, the overwhelming mountain of AI spend which is almost entirely ungoverned, entirely not understood, not made, not translated into value.
And so we now have this giant tidal wave of technical spend that is hitting our shores.
And that is unique and interesting. And I think that is why this moment has arrived. Now what is unique about FinOps tools that the financial systems of record, the existing ones, like what didn't they do? Because you would expect that SAP and Oracle Financials and Workday, they would have developed this capability, but you know, they didn't. And the reason is that cloud bills have high cardinality, lots of changes, and they don't have a few hundred rows, a few thousand rows. You know, a company with $100 million of technical spend might have a billing file with, you know, 40 billion rows in it.
And there are lots of companies that spend way more than that. And when you add in just one of those, along with their other multi cloud bills, along with Genai spend along with everything else, you have a very sophisticated engineering problem.
And then layer in not just the native curve files, the native billing files layer in the Focus standard and how companies want to make use of Both the Focus standards as well as the native billing files, because they don't contain the same information.
Right. Focus is a budding standard and it has certain fields in it, but it doesn't have all of it. And so companies who want to make sense of their technical spend today need a solution that can integrate all of the above.
And who's built that? Well, the financial systems of record have it because their systems were never meant to ingest and attribute cloud bills or any variable spend bills of any kind. Could they build it? Of course, if they wanted to. But that is a very different lane for them. That is why the FinOps ecosystem exists. And it is the FinOps platforms of which there are a handful that can ingest, you know, hundreds of millions of dollars of multi cloud spend and JI and gen AI and everything and convert it all to focus as an option. Like that's a, that's a very small handful. And so that's why the FinOps ecosystem exists. I think that's why we have arrived at this moment in time in FinOps history.
It's an extraordinarily interesting problem that looks simple from afar and then the closer you get to it, you realize how complex it is.
[00:16:45] Speaker A: Yeah, definitely. I can say that the idea is very well explained and then the complexity it has, especially that I come from the technical side when I heard about FinOps and all of that, it's like, okay, this sounds good and the idea is fairly easy to understand. But then when you dive into the complexity of doing reconciliation or doing matching and automating things in finops, I would say, okay, this is a fairly difficult thing. And that's why all the tool ecosystem existed, because people wanted, companies want solution, because it's not there, let's say the business to make sense of that. Is that why, you know, that's why they delegate to their, these services, to applications that are focused on this, because that could make them take money. And with what you mentioned about the expansion of the cloud and then the different services that we're using, we are using like even if you are a small business, you're using a lot of SaaS, a lot of AI, so it's that it only grows with scale. So from your perspective, from what you're seeing in ternary, how are you seeing these to apply to the ternary ecosystem and how are you positioning ternary on this new paradigm and these new scopes for finips?
[00:18:11] Speaker B: What I'd like to do is talk about the customer problem first. What do customers actually want today? Like what is their holy grail. Like, if they could, if they could have a pony, what would it look like? And so if I'm a CFO or CTO or cio, what do I want? Well, I want to understand my margins per product so that I can make the best decisions about how to spend my money across my entire technical estate, whatever that is, whether it's cloud or geni or like a mix of everything. Like, I want to be able to say with some level of certainty that these hundred products that I have, whatever widgets they are, they make me this much money per unit, my margins are X.
And I want to understand that with a level of certainty. I want to be able to go review it on a regular basis and make forward decisions about my investments related to it.
That's, I think, very straightforward.
We have not been able to give the financial suite that answer until now.
And so what did ternary build? Well, a year and a half ago we started to build for Focus because we understood that it was valuable.
My co founder and CTO was part of the original Focus committee and contributed to it. And we thought, hey, this is terrific. It's a normalized standard for cloud billing and this is a great start. And we never felt the ternary value was around the ingestion of a cloud bill. Right. Like that's a, it's kind of a commodity. Right? It's the attribution and everything else that comes along after that. That's interesting. And so we supported the standard and we started to build for it and we thought it was going to be easy, but you know, it turned out that in order to support like an entirely new billing standard while also supporting the existing billing standards, like there's a lot of back end work that has to happen. And then at the same time we thought, well, hey, if we're doing this anyways and we're going to build it at scale, let's build in the capability to ingest not just Focus, but any billing file without an integration.
And we called that BYOD at the time.
And so it took us about a year and a half. And during that time we worked through all the default domains. We understood what our initial customers were wanting from this kind of a solution.
And eventually we arrived at what we now call the Universal spend layer.
It is a canonical system of record for any technical spend that does not require an integration to ingest any data.
We have a five minute workflow where you can point to set a data source, whether it be an S3 bucket or a BigQuery. Table or a CSV file.
We will ingest the data, we will auto map it using AI to the focus standard fields and then we will allow the human being to perfect it.
Once they do that, we're often running and ingesting the data and we can attribute it. And within the platform we can use the focus fields, we can use the native fields, we can, we can use any random billing file in the fields that it has. And so one of our customers is using it today to send sensitive financial revenue data into ternary and they marry it with their multi cloud and data center spend and then they create dashboards that show margins per product.
And their finance teams are using.
It's not just engineering, it's their finance teams.
And so what we're releasing this month and what will be in the platform by probably the time this podcast airs is custom metrics as well.
So rather than taking all this data and then pulling it back into Excel to create a formula that takes one number, divides it by a number and multiplies it by another, you do that all within tery and then we're adding a security model as well that allows you to fence off that data too.
So you can imagine that if you're pulling insensitive financial data, you don't want the entire company that uses ternary to see it. If you're a public company.
Okay. And so we can segment it off to parts of the company that, that need access to it. And then of course we've built in visualizations as well. And so you can have an overlay of a margin line on top of a bar chart representing all of your different costs from whether it be generative AI or a rolled up HR spend per team that maps to a cost center or, or databricks or snowflake spend. Whatever you want to send into ternary. Our default answer isn't yes, we have the integration. Our default answer today with universal spend ledger is yes, we support it by default because we've taken this generalized approach to data.
[00:23:56] Speaker A: That's great. I think one of the most important things that people, especially from the engineering side is we want to see. We, we need to see like the business translation of what the cost means and what the spend means is like we come from, from a more technical, the ones that come from the more technical is like everything, you know, CPU cost and all of that. And is that something that, that for. For business doesn't matter as much as what's the business value, what is the cost for each things, what does it mean for, for the business, how much it impacts related to the HR payroll, how much is this impacts really? Because we sometimes think like, yeah, the cloud bill is the most important thing and it's like maybe the HR payroll is like 90% of the bill compared to what the cost of the cloud is. And how do you correlate all things?
[00:24:48] Speaker B: Right, It's a great point. I mean if you look at the total spend within a company, typically HR is number one, especially within software companies or companies that build software. And then after that comes cloud spend. And I think we're going to see AI spend eclipse cloud spend as well. Right, but the point is like all of those things affect your margin and so you want one system of record that can ingest all of this at scale, that can make sense of it at scale, that can attribute it. Right. And then report on it and then create formulas to understand it. Like that's what companies need today. It's a.
If finops had not taken this leap of faith and understood how the market was shifting, I think I'd be here today telling you that what we're actually building is not even finops. It's like an ITFM tool. It's a, a financial system of record that stands alongside the other systems of record that has a very specific purpose.
It's like a decision support system for technical spend is what it is.
[00:26:08] Speaker A: Yeah, definitely. And also with the complexity that is getting more and more tasks are getting through the FinOps teams, even though they are expanding. And I also said before that, you know, FinOps teams are going to get specialized, like you are going to get a specialist for licensing, as there has already been like with itam, Sam, itfm, et cetera. And then you're going to get a specialist on AI cost and a specialist on SaaS cost and a specialist on cloud cost and even for cloud providers. Because as you of course know, it's not the same to do things in AWS and to do it on Azure and all of that. So I think everything is going to get specialized and it's going to expand and having tools that are able to, let's say, reduce that workload to the FinOps teams, to the engineering teams and to the finance teams, which I think are normally a bit of forgotten. I would say it's good that, because they have to do after all the, I would say the dirty work of reconcile everything we talked about here with, with a FinOps colleague that was doing that, that reconciliation of multi cloud billing and I was like, okay, this has to be one of the most difficult jobs in the world to reconcile.
Multi cloud builders. Right. Is helping those people is going to be crucial.
[00:27:31] Speaker B: You brought up a bunch of very interesting points that I want to tease apart here because I think we're still figuring it out. Right? There's a lot of, and, and let me, let me talk about a few of them that, that might be interesting. The first is like how the ecosystem is evolving.
It is true that the FinOps teams and the practitioners are being asked to take on a much wider mandate and I'm not sure that they're being given the funds to do that. I think they're being asked to just take it on like, hey, you were successful with multicloud. Now here's a bunch of other stuff. Congratulations. Your, your job is expanded, your pay stays the same, your job's expanded. And yeah, like, what does that mean? Like, what does it mean for them? Well, I, I think in some way it's good because it validates that finops was the right thing and it's a good career choice for them too.
But at the same time I think it shifts how they might think about buying tools in market and maybe developing their own tools as well. I, I have always felt as a practitioner first and then as a co founder of a tool, of a platform in the space, that building your own is interesting.
It's probably useful at a particular scale, but in the long run it makes far more sense to buy a product that is 80% of the features off the shelf and then build on top of that. Because if you want to replicate all the basics of ingestion and attribution and building in for focus as it changes and all of these other things that have to become part of the product, well, you're probably spending a lot of money and time and bodies on that when you could simply take probably fewer bodies and use the API to build on top of a tool.
I think this always happens in the SaaS ecosystem where there's a new problem, there aren't tools in market to address the problem, or maybe they're too early or too immature and so everyone builds their own thing and then at some point there's enough maturity in the ecosystem where you're like, well, I could have 10 people building this and maintaining it, or I could buy something off the shelf, probably pay half as much and then build on top of that. And I think, I believe selfishly of course, that we've reached that inflection point in the FinOps ecosystem. And look, I mean, if the scope expansion doesn't Tell you that you could continue to drive with your feet as well. It doesn't mean it's the best way to do it.
[00:30:24] Speaker A: Yeah, definitely. I have to say that also I think the inflection point is getting there especially now with the change of the scope we are going to see another push of probably tools. I know that the environment especially in the tooling is maturing because with all the acquisition expansions and all of that but I think there is a still especially with the amplification of of phenoms I see that the inflection point especially when the maturity is going to start we are a bit I think away especially AI is going to disrupt a bit because if AI keeps changing then phenoms need to be changing to keep track of that. Right. It's fairly difficult to have established when AI is booming and other things that affect AI like the the data center spend like not only the consumption but also like the GPU spend.
All these capex expanded is now coming back right? That before it was like forgotten with the cloud and now we are getting back to multi billion expense on that.
[00:31:36] Speaker B: Yeah, it's a terrific point and I think that the tools have to specialize because in order to take on that entire mandate for your tool like you know, if you want to pursue optimization suggestions a the cloud providers offer the pass throughs and the pass throughs are getting better, they're getting better but it doesn't address the other clouds and you have to build your own in your tool that are better and then you have to address the AI stuff. It just becomes like a very broad problem to solve for and new companies in the space. They have to be able to focus. And so I believe that everyone's going to pick their lane this year.
Our lane is building tools for the core FinOps team and finance. Our focus is a universal spend ledger. It will continue to be our focus. Our focus is being able to ingest any technical spend no matter what it is without an integration and being able to make sense of it at multibillion dollar scale. And we have customers that spend that much money. We have customers that want to ingest the entirety of their billion dollar gen AI spend into ternary and commingle it with their multi cloud spend for purpose attribution, figuring out margins, unit cost, things like that.
I think that there are companies in the ecosystem that are going to focus just on like individual technologies and their efficiency like companies that will focus on Snowflake or just Snowflake or just DataDog or just AI or just whatever. And then at the same time, we've also got like the monster 1.0 companies like Flexera and cloudability and cloud health who are trying to do everything.
And I would argue, like, if you go to the FinOps foundation, the State of 26 report, I think there's a quote in there that says, like, practitioners are not happy with the maturity level of any of the tooling. And so that speaks to the notion for me that there's room in market for innovation, for the right kind of innovation. And if we can build it for the practitioners, if we can make our tools valuable enough that it saves them time, it saves them money, it helps them understand the value that's being created across the technical spend, I think that's the right thing for the ecosystem, for ternary, for maybe for our competitors as well.
[00:34:06] Speaker A: No, I think that you shared like a valuable lesson there that, you know, we need to specialize. And people, I think are not yet.
Because I think companies are not yet there, probably vendors are not yet there, companies are not yet there. End users are still figuring it out what they need and what you probably see from your customers.
It's difficult to target what exactly they need. And we still are improving in the cloud span. And now with all the integration of the different cloud cost drivers, it's making it even more difficult to know. Okay, how do I envision this? How, how is it good for me to see this, to attribute this, to fix this? Because to remedy this goals like, what's the right approach?
I always look forward to shiftless. But okay, how do you remediate things? Because you always have to do remediation and also preventive work. How do you integrate all that? So I think it's such an evolving ecosystem that both the client, like the end users and the tools are constantly evolving. And I think they still need to see, like, okay, this is the final stage. Right. This is where we get there, this is how we want to see it. And from here we can innovate in an established thing. But there is a lot of room and given the complexity, a lot of things to learn in the journey.
[00:35:28] Speaker B: Yeah, I think you articulated that very well.
[00:35:33] Speaker A: Yeah. And wanted to check about, you know, if someone is, you know, listening to, to this podcast and wanted to know, like, how the, the universal spend layer is going to help them, what do you think is the main problem that is tackling it? Even though you have explained it, how it works, like, what's the main problem that you think it solves and who should be, you know, taking A look at it.
[00:35:59] Speaker B: Well, there needs to be a canonical ledger that tracks all technical spend and beyond technical spend, right? And there needs to be one ledger that can adjust not only the technical spend, but the financial revenue data and perhaps HR data as well, in order to create a formula within one system that tracks margin. And you can't do that without commingling all of this data together. You're not going to arrive at margin unless you pull in the financial data. You're not going to arrive at a more detailed margin unless you're pulling in the HR data. And I'm not talking about pulling in pii. I'm talking about like, hey, here's my average cost per team for this cost center. And I want to pull that into my equation, right? And so that's what ternary is. The existing financial systems of record can't do that today, but the executive suite needs to be able to make good decisions about what to invest, what to kill, what to iterate on. And so that's what ternary delivers in the most comprehensive fashion possible.
You could argue, and I've heard it said, that TBM does this.
I don't believe that. And if you talk to customers of tbm, you'll find that, well, it's a professional services engagement. It costs a lot of money. It's ongoing, and anytime you want to move left, right or center, it costs a lot of money. And it was built for a previous problem. Ternary is a much simpler, faster, cheaper, better solution.
[00:37:37] Speaker A: That's a good argument.
So I think it's a great way to end up the episode today.
So thanks for sharing all this information with us. We'll leave all the. All the links to ternary and to your company in the description so people can check more about the universal spend layer. So thanks for taking time today. It's been an honor to have you here and looking forward to what you guys do in the future and to talk soon, I hope in person because I'm eager to converse with you guys in person. So thanks for taking time.
[00:38:13] Speaker B: Sesa, I'm looking forward to eating some Hamon with you.
[00:38:18] Speaker A: Definitely, definitely would be a great, a great way to meet. So thanks everyone for listening today and see you in the next episode. Bye bye.
