How the FinOps Open Cost and Usage Specification (FOCUS) is Going to Change the Game

Riley Jenkins:

It’s been an interesting balance to make sure that we have people from finance, we have engineering, we have even procurement, we’ve got ITAM, we’ve got people that have been on all different parts of the spectrum to not only provide just opinions on what it should accomplish, but also to provide like tangible written instructions for how this thing mechanically work.

Anglepoint:

You’re listening to the ITAM executive, a podcast for ITAM leaders and practitioners. Make sure to hit subscribe in your favorite podcast player and give us a rating. In each episode, we invite seasoned leaders to share their tips on how to define your strategy, promote the value of ITAM in your organization, and align your program with the latest IT trends and industry standards.

Let’s dig in.

Kris Johnson:

Today, we’re excited to have Jason Kelly, our Director of FinOps here at Anglepoint, and Riley Jenkins.

Riley, do you want to introduce yourself?

Riley Jenkins:

Yeah, I’m a former angle point er. Is that how you… Angle pointer. Archer. Archer. There we go. I am, uh, one of the, one of the contributors to the Focus Project, and I’m also on the TAC for the FinOps Foundation. And I’m basically the liaison for the TAC and the FOCUS Project.

Kris Johnson:

It’s great to have you, Riley. We’ve just come off of FinOps X and the announcement of the specification, the 0.5 version that’s been released. And there’s certainly a lot of buzz as a result, and a lot of people excited about what the specification is about and what it holds for the future. What are the goals of the specification? What are we trying to accomplish? And more specifically, what do organizations stand to benefit from a specification existing?

Riley Jenkins:

They’ll always thought that I go to is. The amount of human work that goes into just analyzing the bill and a lot of their bills. And a lot of times that’s not starting from what somebody else did or starting from really stable ground. It’s starting from scratch at a very low level. And so the amount of like duplicate work that we’re all doing in the industry to just get the simplest things, it’s really extreme.

And so I view it as being something that if there’s a good specification that the community and the industry can. Narrowed down to and build from it makes the higher order problems of like unit cost economics and looking at other pieces of efficiency that come later, shifting those so much earlier in the timeline, rather than being something that are, you know, we have to do.

A hundred things in order for to get us here, if that’s even 50, that saves all of us an incredible amount of time so that we can get to the business of actually optimizing and providing value earlier.

Jason Kelly:

Yeah.

Kris Johnson:

Uh, I guess it probably bears repeating what focus is. It’s a FinOps open cost and usage specification for a unified data model, essentially for custom usage data across cloud service providers.

Riley Jenkins:

Yeah. So whether you’re looking at whatever provider it is, whether it’s a cloud provider or even a SaaS vendor. Being able to say, okay, we have this data schema that works across those. And whether it’s something that we’re having to translate the data into that schema, or it’s provided natively, um, someday, um, we’ll be able to combine all those and use them together and all speak the same words and use a core set of even just definitions of things will go a long way.

Kris Johnson:

Riley, you, of course, are a practitioner in FinOps, Jason, you come from that world as well. In your experience, how would a, you know, open specification like this have helped you in the past implementation?

Jason Kelly:

It’s, it’s huge coming from large companies where we’ve had to build our own cost and usage reporting engines, our own multi cloud reporting.

Most recently having done it, uh, in Looker and GCP, we had to go through most of what focus is going through, determine how do we homogenize all of this because the cloud providers don’t speak the same language. They’re caught, like the columns aren’t the same. The data they put in the columns isn’t the same.

And even having the spec layout service groupings in terms of this is compute. This is database. This is ML, whatever it is. That’s a huge undertaking to do as an individual company trying to. Group all this stuff together and then that list is constantly changing as the cloud providers add new services and things like that.

So having a specification that at least set some guidelines as to, okay, this is the groupings that it’s likely going to be, you might have to fit something in and whatnot, but that’s incredibly helpful. And then once you’ve built it, it’s the pain of, okay, we’ve got our own engine. It’s all of our data is homogenized.

It looks the same. It’s standardized. But now we’re pulling in data from maybe a cloud health or cloud ability and it doesn’t match now. So now we’ve got to write a translator for all of that. Um, it’s a huge amount of work. It’s having a specification, a standard is incredibly helpful.

Riley Jenkins:

My favorite thing at the FinOps X conference has been even not this previous year, but the year before it was just talking to the number of people that have done that and the list is very large.

And the interesting thing is you actually talk to them on the mechanics of how they did it or what they did or what and how they used it. And there’s a lot of very common things. But then I’m sure if we looked at each everybody’s code or however, they did it totally different and non-compatible and you know.

Uh, moving from one company to another or looking at one scenario to another. It’s not something that is plug and play or not something that’s referenceable.

Jason Kelly:

Yeah, we, we’ve probably got a lot of clients, a lot of companies out there in general that use tools, they use a cloud ability, cloud health, whatever it is, a Flexera, uh, to look at their cloud costs, but almost inevitably every company gets to the point where they need their own tool, they need something to do this, and if, even if we can get some of those tools to start speaking the same language, when they start building their own tool, they’re already.

Leagues ahead of building their own and homogenizing all of that stuff.

Kris Johnson:

It’s one thing for them to speak the same language. I think it’s another thing to have them speak the language of FinOps, right? The cost and usage data was being captured and reported on long before FinOps was a thing, and we had a taxonomy.

Riley Jenkins:

And kind of terms of emerged, uh, and a discipline, how has that been as far as the, uh, the focus group working group, as far as that goes, one of the things that we’ve tried to make sure is that there’s a good representation from all of the stakeholders, whatever magic word you use, but it’s interesting to, to, it’s been an interesting balance to make sure that we have people from finance.

We have engineering, we have even procurement. We’ve got ITAM. We’ve got people that have been on all different parts of the spectrum to not. only provide just opinions on what it should accomplish, but also to provide like tangible written instructions for how this thing mechanically works. That’s been really important because it makes sure that we’re not like leaving out some group that has a very needed and legitimate use case, trying to have all those represented.

It takes a lot of work. Coordination, but I think it’s going to benefit us in the long run to make sure we have all those parties there so that we can actually use it centrally. Um, and not saying it’s going to solve all problems, but at least be a launch pad to make the problems, uh, more easily solvable.

Kris Johnson:

What kind of challenges do you anticipate with people trying to use FOCUS?

Jason Kelly:

Oh, just getting it implemented. I think for some, for, if a FinOps team is not mature enough, trying to implement without right now, there’s. And I think this just kicked off a couple of days ago, writing the converters for things like that, trying to take the car and whatnot and put in the specification will be difficult if you try to do it right now, going back to Riley’s point where we talked about the different groups, amortization was a really big one that’s built into the spec, but how do you get a How do you get a finance team on board with, okay, this is how we’re going to talk about amortization because they probably have their own way of dealing with it.

And while FinOps has a lot of that kind of stuff, it’s not often where FinOps comes in and says, Nope, this is how we’re talking about it. This is how it’s going to be portrayed and whatnot. So those kinds of things can be challenging.

Riley Jenkins:

And it’s a kind of a tricky balance to say, look, as a practitioner in the industry, this is what we want versus also providing the flexibility to empower.

FinOps teams at company ABC to do what they need. So we have to provide a framework that provides some canned things, but we’re thinking of it more of providing ingredients so you can do your job, not trying to bake a cake for everybody. That’s going to be exactly what everybody wants.

Jason Kelly:

It’s just generally most companies, their FinOps teams don’t include a cloud engineer or someone like this that was maybe they’ve got some analysts, maybe a data scientist that can do a bit of, but trying to manipulate data that’s come in into a different standard is sometimes difficult just personnel wise and companies, most mature companies will get to the point where they’ve got someone like that.

But companies early on, this is a, big undertaking. Yeah.

Kris Johnson:

So we’re throwing around the terms specification and standard a little loose. Yeah, that’s true. I think it’s a specification and that it’s not an auditable standard or standard to be audited against. I understand the difference between the two.

The data itself.

Riley Jenkins:

Okay. So we will have a specification it’s in 0.5 beta release right now, probably still early days for somebody to really pick up and use or if you look at it right now, you will, you know, It will not be unfamiliar. There’s nothing in there that’s like totally, totally foreign. The amortization. Metric may be the most challenging to just make sure that people understand that, but it is a 0.5. We’re still working on some of the missing elements that need to be included and there will be changes, but if people want to get involved, it’s a good point to look at the look at the repos on GitHub, get familiar with it. And if there’s feedback that people have. It’s always good to get that feedback so we can start taking in use cases we haven’t thought of and make sure that it works.

Kris Johnson:

Yeah, correct me if I’m wrong, but I think part of the intention and the motivation behind creating a specification is to generate more trust in the data by practitioners, by folks in finance. How can an organization make sure that their focus data is computerized?

Riley Jenkins:

I think for me, in order to answer that question, you also have to know what those definitions are for your company and your organization.

Because some companies will define accuracy and trust is that it meets the definitions of a finance role, which is very different than, the accuracy and trust that you would do for an engineering role. Like I’m an SRE. I’m very engineering focused. I sometimes I wear two hats and sit on different sides of my desk because they’re so different.

But, but you have to know what questions you’re trying to answer because those definitions can be very different. But if you have that ironed out, then you can say, okay, things like. How recent is the data? What strategy do we do for cost allocation? Do we use tagging? Do we do use account mapping? All of those things play into that and really stepping out of the data problem and focusing on the what are our requirements for how we want to organize the data, how we want to report it.

What are our goals for optimization? Then that leads the discussion into, okay, what structure do we need in the data? How are we going to use it? How do we build? What do we need to do those types of things? And that’s where the whole trust comes in. If you try and do it the other way, then you just end up restarting.

Jason Kelly:

This is what I’ve found is I’ve learned. A lot of hard lessons. Data validation in FinOps has always been a difficult thing. Cause it’s, it’s hard to validate against like AWS. For example, you get an invoice and you get your curve and you try to put it all together. They’re not going to match because AWS rounds in different ways.

Then, then the more granular you might get from your curve. So you might be off by a couple cents or you might be off by a lot if you’re a large company. So it’s always been tricky to do that kind of stuff within FinOps.

Riley Jenkins:

And that’s actually one of the reasons that that brings a good point is one of the reasons why we focused on the, on the two metrics to the main elements of the 0. 5 spec is because there were, those are for lack of a better term, a true North, as far as saying, look, this is the column that when you summit, we want that to match your invoice, which is. That’s a new concept. It’s not a foreign concept, but it’s something that we really want that to be the true North so that it’s not something where you’re having to know the tricks of the trade, to know how to connect the dots between an invoice and a billing record and any provider.

And then you look at the amortized cost column and it’s even more so because now it’s saying, okay, we distribute costs. This is not a cash basis. Column. This is, this is different than being able to identify what those are and how to use them and staying true to that core set of things we want to accomplish.

Kris Johnson:

So in a sense, it’s building that trust or transparency, being able to reconcile invoice to cost and usage data in a standard form of going super.

Riley Jenkins:

I’m an engineer going into, you look at the. UDP versus TCP. And you can trust those if you know what they do. And that’s one thing that’s been hard in our industry is that I don’t really know because there hasn’t been a kind of a, an outside view of saying, okay, this is.

The specification now what complies with that? What doesn’t that’s been a missing element. So it’s been hard to do that. Whereas with other technological specifications, that’s been something to say, oh, we fit with that, or we don’t. And this is why and even the discussion of why we’re not. Uh, in alignment with the specification, that is not a deal breaker.

That’s not a game over. That’s just saying, hey, we’re calling out that we don’t fall in line with this. And the reason why is because of X, Y, Z. And it’s hard to do that even now, because we don’t really have something like still early days.

Kris Johnson:

We understand that. But are there some best practices that are emerging for organizations that are trying to ease focus?

Riley Jenkins:

Right now, trying to use FOCUS is really just getting familiar with what we’re trying to achieve and the very early beginning of it, but it’s really down to, okay, look, I will, as a practitioner that hasn’t been involved the way that I would look at it is saying, okay, we’re like, it’s going to take time for providers Do this natively, but I think the community is going to drive, Hey, here’s a way to translate one record to something that supports FOCUS.

And I think that’s going to be the first way that’s done. And then the future we’ll see how that, that works out as far as full adoption, native records being in that format. But I think the way to start is to get familiar and even call out like, Hey, what about this cute use case? This causes a problem.

Even the 0.5 spec causes a problem because of whatever scenario being, even being a member of the community would help you a, get familiar with what we’re trying to achieve and B, maybe there’s something that we are not thinking about that we should be the, um, the converters are just talking about those being written are going to be a big step towards figuring out what works and what doesn’t and like a lot of things in FinOps, because it is so new, still people figuring it out as they go.

And that’s a big part of the FinOps community. The FinOps foundation is if you see something that’s not working. Okay. You can call it out. That’s, it’s very open in that regard and the spec is the same way.

Kris Johnson:

It’s probably a good time to do a call out to any practitioners out there that are interested in the standard, want to contribute to the development of the specification.

Go to finops.org/focus. You can find all the information there. You can get access to the repo. Um, the documentation that’s there, that’s where the converters will be as well. What are the resources that are available to help people get started with FOCUS?

Riley Jenkins:

Um, I think that’s really the best place to start.

We are very early. We’re learning as we go. There are going to be things that we come out with that we’re going to see a need to do. Maybe there’s something where we need to have a focus. Documentation for finance, a focused documentation for engineering. I see that kind of coming, but right now the best place is to go to get repo, read through the documents and that’s how I’d start.

Kris Johnson:

It seems that the CSPs are, some of them are contributing. Some of them are interested. Some of them are, have more involvement than others. Perhaps the best thing that practitioners can do as well is. Talk about focus with their sales reps as they’re going through renewals. We can create this groundswell of practitioner support and demand of, hey, we want native billing that complies with the specification, according to the specification, so that we can build it as a community and hope that they’ll come and there may be some individuals within those CSPs that Uh, are trying to pave that way, but these are big ships to turn as well.

Riley Jenkins:

I think we recognize. And so the more community support that we can have and, and even bringing this up and applying pressure as you’re going through renewals can only help. Yeah. Cause I look at the contributors that we have. It’s a very active initiative. And even at FinOps X, the amount of people that reached out and said, hey, this is really cool, how can I get involved?

Just reaching out to whether it’s your SaaS provider or your CSP and saying, hey, are you aware of this? We are interested in the outcome of this. That goes a long way to make sure that no matter their involvement or where they’re at with the project, so that they know that, hey, this is something that the community actually wants to see.

And we, it’s not only just a, hey, we want you to do this. It’s also, hey, you should probably contribute here because you probably would have. But you would probably provide great value. I’m really, I’ve been really encouraged by the amount of that’s been going on. And that’s led to, we’ve got lots of great contributors and lots of good feedback from the community at large.

Kris Johnson:

Let’s double click a second on the SaaS provider elements of this. CSPs, I think we all get that from cost and usage data standpoint, where the real relevant overlaps with SaaS, where it can really be common across vendors.

Riley Jenkins:

Yeah, I think of providers that are out there that, that provide billing data to their customers and doing that is, that’s a difficult project.

That’s a difficult thing to achieve because you’re starting from zero. It’d be like writing a, writing a, writing TCP from zero, everybody doing, it’s not really a great way to do it. And having SAS provider can say, Hey, like we want to do this. We want to provide billing data to our customers. And being able to say, Hey, here’s this focus thing.

Hey, this is actually really relevant. We should use this and then build from it that matches our context. I think that makes a lot of sense. So I’m encouraged to see that because you talk to a lot of companies that are, that have a large SAS spend, they’re doing it, they are doing it. They’re taking the cost from whatever vendor it is, and they’re splitting it up so that they can move it right along with their, their CSP provider.

So that they can fully report the cost of a feature of the cost of a department. They have to build that stuff in and moving that towards a more data centric practice, I think is going to.

Kris Johnson:

Yeah, it certainly is a mixed bag in the sass world. They have data or type of data that you’re able to actually get from a SaaS provider and how they make it available like practitioners.

Jason Kelly:

They struggle with multi cloud and homogenizing it all. And this would help with a lot of that. This is adoption of this and it. Like I said, at the beginning, it gets people familiar with this. So if they do build their own, if they build more off of it, they’re already familiar with it. It’s not something new and foreign because right now trying to pull that data out of anywhere is just, none of it matches even in the places where they, they do try to bring it together.

Riley Jenkins:

You end up with very high-level reporting. That’s not terribly useful.

Kris Johnson:

Yeah. Yeah. And hopefully for those SaaS providers that don’t really provide a lot of good granular data from a usage standpoint, and hopefully again, if. We can create a specification, create an expectation that, uh, consumers, practitioners have of their providers that, uh, new entrants to the market will, uh, see that as an ex as the expectation and, uh, maybe some of the laggards will, uh, come along.

Any other thoughts on, on FOCUS, uh, uh, things that are coming up, anything from a timeline standpoint,

Riley Jenkins:

I think that our next goal is to work on the 0.1 spec, not 0.1. We’ve already done that. 1.0 spec, sorry. It’s been a long day. The 1.0 specs, that’s what we’re working towards. We’ve realized, and I’ve seen, and this happens with any project, especially where it’s data centric, is you do the first thing and then you realize that you need to build in some ways to make sure that the.

Initiatives are working together because we’re talking with a small set of metrics right now, and that’s going to grow very quickly and we need to make sure that we can grow that very quickly and not conflict with each other. So there’s going to be some work to make sure that’s something we can plug in changes and make sure that they’re not cross contaminating.

So that’s probably more of a deep, dark, like answer for how I think about it from a data perspective, but we’re marching towards the one. Everybody took a little break after the conference because it was pedal to metal. But we’re working on it and I’m excited to keep working on getting one of them out.

Awesome.

Kris Johnson:

Thank you for the time, Riley, for stopping by, uh, it’ll be great to, to see how this, uh, evolves and, and shapes the industry for, uh, for, uh, many years to come.

Jason Kelly:

I’m obviously interested in, I contribute to it as well, so I’ll be following with it, but yeah, this is, this is potentially something that’ll change.

A lot of how things are done.

Kris Johnson:

Yeah. And again, to find out more, just go to finops.org/focus. All right. Thanks.

Anglepoint:

The ITAM executive is proud to be supported by Anglepoint, a better way to manage software. Anglepoint helps the global 2000 reduce their costs. And mitigate risk in their software and technology assets.

Anglepoint is a leader in SAM and ITAM projects, thanks to their team of uniquely experienced experts from across the industry. Anglepoint’s managed services provides you immediate access to the people, processes, and technology you need to optimize your entire software estate. To learn more, visit anglepoint.com/schedule.

You’ve been listening to the ITAM Executive brought to you by Anglepoint. Make sure to hit subscribe in your favorite podcast player and give us a rating. Thanks for being part of the ITAM community. Until next time.