What’s a ”Platform Maturity Model”?

Episode 265 · Wed, 07 Jun 2023 16:31:49 +0200 · 53:59 · SRT · archive.org · all Tanzu Talk

Well, Cora and I are back again. And in this episode, we talked with Abby, who is part of a working group at the CNCF, and they've been working on a platform maturity model. And as I think I start off with, I really like this paper. I was asked to review it at some point. And I think it's a good, concise way of basically explaining the journey of a platform team. And it has five categories that we'll get into. And I think it really is. They're still working on it. As Abby says, it's kind of like an alpha version. But I think it's in a good shape to start sharing publicly. What do you think of the conversation, Cora? I mean, I loved it. So Abby Bangser is a principal engineer, I think it is, at Centasso. And she has just a wealth of experience in this area. And they've been having conversations with a working group where she was describing that they're down to debating about, should it be this word or that word? So they've really given this a lot of thought and a lot of care into it. And I believe this started at Centasso and then was donated to the CNCF. And now, actually, it's, again, we like to find publications to talk about on this podcast. So this document is actually a public Google Doc that anybody could, of course, read and comment on and contribute to. So if you're interested in this topic, definitely listen to this conversation. And then if you want, you can go give your feedback and contribute to this burgeoning platform maturity model. Yeah, I think that's a good point is if you end up listening to this and you're interested, I think they're very interested in feedback, especially as we were talking, I was writing down a few people I know who actually are run platforms and have done for a couple of years. And I need to send this along to them and see what they think, if they're interested in contributing to it. I'm sure they're busy, but, you know, also, they're nice. Maybe they want to help out with the overall thing.

Well, yeah, I mean, let's let's let's jump into it. It's it's a it's a good interview. And why don't you introduce yourself? Yeah, sure. Thanks for having me. I'm Abby Bangzer. I am based in London, despite my East Coast America accent. And I work as a principal engineer at a company called Sintasso, working on trying to improve the lives of platform engineers by building Craddix, which is a framework to help build your platform. And and we caught up a little bit at KubeCon where I let's let's see how. Oh, I think I think. Well, our mutual friend, I suppose, Paula Kennedy, she emailed me. This is three, four months ago. I forget when. And y'all have been working on this platform maturity model paper, which I got the chance to look over. It was fun. And I thought it was just great. It's like nine pages of like a bunch of answers in a, you know, a maturity model thing. And and and I think, you know, I like a maturity model because it basically like I don't know, I we'll we'll we'll see how how you two would describe it. But I feel like it adds a certain amount of comfort and surety. Right. It's sort of like we're going to we're going to go out and like transform things for the better and improve the way we're working. And like, sure, we need to be a learning organization and discover things and have our mind wide open to the possibilities of our own awesomeness and the failure that drives our success. But also here's kind of what's going to happen. And it's like it's like and of course, you update the maturity model as you go along in in time and history. But like, it's it's nice. And I thought I you know, what I I liked about it is, well, among many things is you've kind of gotten it. You break it out into like I think it's five different sections or whatever you might want to call them, sort of like active clusters of activities you will be doing. And then like any maturity model, you, of course, want a numeric rating of some sort, which, again, is handy to know to know.

Sometimes numbers are good. I think in our business of transformation, you're supposed to you're supposed to not like any rating system based on numbers, but they can be fine. I my my my my wisdom on that is bad things are bad and you should do the good things. Anyhow, what you know, the first after my opening monologue there, like what you know, when when y'all were working on this, like what what was in y'all's head about what a maturity model is like? What does it represent? Yeah, I honestly, I thought I was going to have my head absolutely bitten off when we started going for asking kind of feedback on this around people that we know around the industry and people that we respect and in platform engineering and around. And I was surprised how many people were positive about it because I myself am a recovering consultant and I can say that I have seen maturity models go wrong and I've also seen them be really effective. Right. And I think that's like when you've seen maturity models applied in a really kind of negative way and kind of a stick to beat people in a way to take away people's bonuses or something like that kind of way. You you tend to get a little bit cautious about just the concept because, as you said, it is familiar. It is something people have probably seen before, probably used before. So why then you might say if I if I had these fears, like why did we even talk about a maturity model and I think for us, we were looking at the work that the CNCF working group platforms working group had done with the white paper and said, this is great. But we're still seeing people, multiple people read the same paper and come out saying what to us sounds like different things. So we're seeing people read this and go, yes, I am delivering a platform like I have Terraform modules that people can copy and they can make PRs to my repo. That's self service. And we're like, yes, but is it self service if you have to learn another language, if you have to wait for another team to merge your PR or like give comments on your PR?

Is that truly self service or is that just kind of inner sourcing, which is a step above kind of throw a ticket out into the black void and hope someone responds with something useful. Right. So I don't mean to diminish the value of those kind of workflows, but they aren't yet kind of what we were talking about when we were releasing that white paper. And so we wanted to we wanted to address that by having a conversation at one level more concrete that did actually acknowledge some of the things that can detract from a great platform engineering experience and solution, as well as the things that can support and encourage a great one. A lot of times you talk only about what a good one looks like and you you get kind of nervous to talk about what maybe is taboo or not maybe supporting a positive outcome. And a maturity model gives you that space to talk about, like level one is a platform. Now, is it the most effective you can be? Probably not. Like here are going to be the impacts of operating at this level. And so I think that's the power of it that we were talking about when we got started. It also kind of defines what a platform is right here because the platform is a it's a word that's used in so many different contexts. So a person who does work at the infrastructure layer to them, a platform is what, you know, automating and adding self-service to what they have a purview over. And so this is really a way to say we're defining. And I guess to that point, it seems like developer experience is like the ultimate measure of it. Right. Like if you could break it down to like one metric or one thing to measure everything, would you say what I guess what would you say that is? Developer experience is another tough one. You're just it's just layering more kind of ambiguous terms on top of each other. But I think most recently there's been that space article that's come out about developer experience being a proxy for product developer productivity because it's hard to you can't measure lines of code or hours worked as productivity. So I think in the way they described developer experience as something that tracks business outcomes by reducing the cognitive load and reducing the friction on delivering outputs as a developer, as a software engineer, I think, yes, then that is what a platform is trying.

What we the version of platform that we're talking about is trying to do an internal platform is trying to do so. Yeah. And well, well, let's let's I'll let myself chase this this shiny object or rabbit or whatever. But like what what do you think of this like obsession with cognitive load as a concept? Like, I mean, it's not bad, but it seems like in the platform engineering space, like it's a real like it comes up a lot. And I guess, again, it's not a good situation to have anyone like mentally toiling over something that should be easier, that that doesn't sound like a good way to live. But like what makes it such a big deal in the platform space that there's a lot of focus on it? Yeah, it's a it's again layering. I appreciate you call that out because I think it's again layering those ambiguous terms because cognitive load gets said so frequently, as you said. Yeah. But actually, there's like three different types and the what we're actually trying to do with internal platforms is is focus ourselves on the cognitive load that is bringing business value is actually the complexity of your business domain that you're trying to tackle and deliver value behind while reducing the cognitive load that relates to just getting the job done or and and understanding your environment. Right. So people don't always talk about the fact that like we're not reducing all cognitive load as a platform, we're not just making the software engineers job completely rote and uninteresting, we're trying to give them the power to spend their energies and their cycles on the useful stuff. But I think the reason why it's so valuable and kind of the internal platform side is because I run into two different types of software engineers, there's probably more, but if I'm going to make it black and white, you get the software engineers. You get the engineers who are like terraform what? No, no, I don't want to help. And then you get the ones that are like, ooh, new language to learn. Sure, I'll learn terraform. They go off in there down their rabbit hole of learning terraform becoming the best infrastructure engineers you have at the company.

And in neither case is that what your company wants them spending their time on. In the case of like, I'm just going to stop working until someone hands me a database because I don't know what terraform is. That's no good. And in the case of, I realize I'm trying to work on this feature that, you know, our customer ABC asked for, but actually, I want to make sure my terraform is correctly modularized and variables are easy to reuse and is also not what you want them to be working on. And so I think reducing even the awareness of the implementation of infrastructure is that idea of giving a bit more focus and a bit more opportunity for the software engineers to focus on their problem spaces. And that's what I think when people talk about reducing cognitive load on software engineers, people are really trying to hone in on. Yeah, for sure. I mean, kind of like you're describing to visualize it. It's your cognitive load is like a balloon. Like you're assured a certain amount of it and you just want to make sure the part of the balloon you care about is less full. Like you want to spend all your time focusing on just like the actual application in the business and not, you know, having a perfect set of variables for how you configure your networking. It also requires that the platform team understands better what the developer experience is, what they need, how they operate. So it's funny because like when there isn't a good platform solution, we find developers like the second example you described, the terraform, you know, curious person going and learning infrastructure. But now if we need a platform that is going to service developers well, we actually need to ask the infrastructure people or the platform people, at least, to understand development a little bit better. Absolutely. I guess that's been new. I don't know how the platform sort of community or demographic has experienced this because I think I see it from probably the developer side still.

But yeah, I wonder how, you know, what that perspective is within the platform community that they've sort of been forced out of their silo to learn about development. But I guess on that note, also, they've adopted development practices, right? Like GitOps is an adoption of a development practice to service engineering. So I guess there's benefits. If you get the right people going, they might argue that it was an adoption by developers from the operations space with things like Puppet and Chef and those kind of auto reconciliation loops. So GitOps as a whole is a whole other thing. But I definitely agree. I think that the subtle thing that's happening right now is that people who are on platform teams tend to think of themselves as engineers. They are engineers. They are writing code, whether that be in a different language than their front-end peers. It's the same thing as you have front-end and back-end developer-focused people. And so what you've, in the past, I think, tended to have is these engineers who are building internal services who are like, I'm an engineer. I know what engineers want. And then they build what they think engineers want based on their own kind of skills and knowledge and expectations. And now we're seeing the rise of a phrase called platform as a product come into play, where all of a sudden, it doesn't matter if you are, you share some characteristics of your users. You are not your users. And you need to be building for your users. And so that's where I think where I'm hearing you, Cora, is like, it's not about the platform team understanding development as much as understanding development's tasks or development's needs or, like, what does they actually want to get done? I think that's the thing that people are being challenged with now. And you asked, you know, am I seeing that kind of coming through into the platform space? And absolutely in conversation. I think in practice, it's still growing.

It's definitely growing. But I wouldn't say it's yet the default behavior. I think we're starting to see more and more product managers in the internal platform space, which is helping to bring some skill sets to the teams. And the conversations helping to prioritize that kind of work. But I think it's still a learning process for how to apply those product skills to internal platforms. Yeah, which is really great. I mean, this whole idea of platform as a product has so many angles. And I think, like, when I first was introduced to the term, I think I thought about it more in terms of, like, I guess, I saw, like, more the side of, like, how do you upgrade and how do you manage it as a whole and how you break down your work? How do you work amongst the product team? But really, the point that you're making is really key, that platform as a product means that you start by looking at the needs of your users. Right? That's, I guess, maybe that's the biggest difference, in fact. Yeah, I think it was popularized by Team Topologies, really, that idea that your platform should be something that is optional. You have the upper leg on any competitors because you should be able to be right there talking to your customers, completely bespoke to your company. But if they're able to go out into the market and find something that would meet their needs better than what you're offering internally, they should be free to do that within the constraints of the business requirements. They still are going to have to meet any compliance requirements and things like that. But that just shows you how the gap you might have between what you think your customers need, being the software devs, and what they actually need if they're choosing to go out into the public market, choosing to apply their own security requirements because they're like, oh, this platform isn't meeting my expectations. Right, right, that's, that's, it's so fascinating that to make it optional forces you to build the best thing because you need people to want to use your platform. That's, it's, it's really powerful. Yeah, does that, is that, so the maturity model that you're suggesting has several categories, right?

You have funding, adoption, user experience, backlog, organizational structure, and cross-functional representation. But what you just said seems to tie in best with adoption, perhaps, is that, would you say that? Yeah, I think, I think, so just to call out, all these sections are sort of in their version alpha. And it's, it's an active work in progress with the CNCF working group right now that we're trying to get people to join in. So if this is something, if you're listening and you're interested by this, please come tell us why we're wrong, why we're right, what we can do to, to make it better and, and evolve this. But you're exactly right. The adoption, user experience, backlog, all sort of mixed together and all have influence over that kind of usability of the platform or choice to use the platform by, by the software developers. So is the user experience such that they want to use it? Is it tailored to their needs? Is it giving them high level business options that, that get them going quickly? That's sort of the, the top level there with paved paths. Are they, from adoption, are people actually getting the support? Is there, are you investing as a platform team in internal advocacy, internal DevRel, where you are elevating the voices of people who have had success with the platform? You are answering questions in public, making it easy to ask questions. All those kinds of things can make a big difference. And then obviously how you track what comes next. Are you just taking the next thing off the backlog that someone told you to make? Or are you thinking through the evolution of this product, solving the big business problems that maybe people don't know how to ask for, right? That faster horses versus a car kind of idea. Are you treating it like a product that you're trying to design intentionally and deliver? Yeah, and I think, you know, like the cluster of stuff and the adoption, right? Like you kind of went to the levels. Like, I think especially like the, the platform advocacy part is like, I, well, I've noticed it's one of the two things that when I've talked with infrastructure people who are becoming platform people, like that's, that's one thing that they don't really, it doesn't occur to them naturally.

That, that you would have like advocacy and marketing and those kinds of things. And I think like it really, I mean, I'm trying to think of like a group I've talked with that has put a platform in place that does not have like advocacy and marketing. And I'm pretty sure they all do like, they all like, like, you know, they usually come up with like a brand name for what they're doing. And they have like, usually like a full-time person dedicated to just like doing that. And they do like conferences every three months and on and on and on. And like, you know, having worked in marketing for many years, I just think of that as marketing, but I, it's like, it's, it is like a very different skill and role for like infrastructure or even like engineer people to have to, to need to sell that or market it internally. And, and of course the second one, the second role being product management, which is like, even for software developers sometimes is a wacky notion to, to have product managers. But it's, uh, anyways, I think the advocacy thing is, is, is, is key to that because otherwise people aren't going to use it or, or even, even, even worse. They use it, but poorly because they're upset. Well, yeah, but I guess, I mean, advocacy. So on, on the one hand, cause advocacy is on the scale. It's, uh, what was it like a number five? It shows, it shows, it shows maturity level five, our current top, but the numbers don't mean it's just the top. The fourth is the, maybe I'll have to put those words around those to, uh, to help Coté. So we don't have numbers, you know, toddler, infant, toddler, teenager. Well, we could, we could, we could really appeal. We could, you could appeal to the, uh, the, the, the, the younger demographic and use emojis. Oh, I like it. I like it. See, this is why you've had marketing experience. I can tell. Yeah. But that's really your hook, right? Like, I mean, you, I guess you have to have a platform that is at some level of maturity to go out and advocate and, and, and try to get people to know.

But on the other hand, um, yeah, that's your, that's your arm into like really understanding user experience, because if it is optional and you're going out to, to show people and hope that, that, you know, if you explain to them how it works and its benefits, they'll want to get on. Those are the people who can best see why you choose to use or not to use it. So do you think like, that's where maturity models, this is, this is one of the places where maturity models can start to rub. Because I don't, I don't believe you have to have a super mature product, super mature platform to have a mature adoption strategy. Otherwise, when you think about like, um, an early stage startup, us, like then we would basically have no talk about marketing or advocacy because we're not a fully fledged, completely ready to go to market product. Except we do have all of that because that's what's helping us build the right product for people. So yeah, yeah, to me, that level four is about, um, actively making space for an investing in and acknowledging the need for that kind of advocacy dev dev rel marketing sort of skill set. And it's not that there's a one size fits all to like, this is how you do marketing, this is how you do dev rel, it has to be a mature product ready to, you know, here's your documentation kind of thing. Yeah, yeah, no, you're right. Like you do have to, that is a good point that you don't want those things to necessarily be, to use a fancy word, uh, what is it, temporal or chronological? Like, like, like it's more, I guess it's the case, at least as, as we're going through it and like, you know, as, as y'all are modeling it, that it's more of less of like, uh, uh, uh, a line on a chart going towards awesomeness and more like a spider diagram where you've got like multiple, you know, multiple attributes that you can like fill out. And, you know, you can, you can wait out what you have, what you want to focus on.

And, uh, because you're basically saying if you achieve all of these, if you're, yeah, see that, that you've really thrown a loop for it there because, because it does seem like it requires, I agree with what you're saying. Like, I, I always find that like, you need that advocacy almost right away, even if you don't have full maturity for exactly the reasons y'all were saying. And, and, and, you know, you're highlighting core that like, you need a way to get input of what's going on. So that is, uh, well, that's annoying. I think the, I know, right. It's the, the, the, the virtuous cycles, right. And one of my, one of my, um, teams that I know that did kind of UX on like develop, um, user experience on one of my past projects, past, past lives, uh, had what they called beers and tears. And they would like watch kind of watch back user testing, or they'd go and like, ask someone to try and ask someone to come present how they currently achieve something. And it would just be, they would just tear it apart as like, oh my gosh, how is this what we're making our users go through? Like, what could we do to make this better? And, and it's actually kind of the whole idea of what's painful do more of like, go find the things that are really terrible and really lean in and, and be outwardly okay with acknowledging your faults as a platform, uh, platform currently so that you can show that you're open and ready to improve. Because if you get there and go, our platform's perfect, of course you should be using it, here's, here it is. And other people are just looking at it and going, the emperor, I don't think it has any clothes. And then it's harder to fix things if you, but later you find them, if you do bring in advocacy when you're, when your platform is, you know, quote unquote perfect, then it's probably too late to fix some of the decisions. It's more painful when people say it's not perfect, uh, it's much more painful, right? Right, right. Yeah. So that's, and that's where like this maturity model, I think we're still growing. I think you mentioned a spider model, Coté, and that was something we did talk about whether or not we should have more aspects like a nested so that you can sort of show that you have a strength around the people and process side, but maybe not so much in the technology side or, you know, sorry, sort of start to get that shape of your platform.

Um, we didn't go with that complex model to start, but those are the kinds of things we're discussing right now on, is that the way it should go? Is that going to be more helpful to people or is that going to become more of a box ticking exercise, which is what we want to stay away from that sort of, all right. So I don't know. Those are the pros and the cons when you're designing a model, right? All models are. Yeah. Yeah. So what, I guess, what about, um, speaking of different models, um, I guess, can you talk a little bit about the, the cloud native maturity model? And, uh, how, how this is different and what kind of led to a decision to create something new? Yeah. The cloud maturity model, cloud native maturity model is fantastic. So we're actually, one of the pieces of work right now is trying to make sure we're in, um, intentional where we split from there and where we try and align. So there's going to be some pulling closer and there's going to be some more explicit splits. One of the things that I'd say is very different between the two models. And as of now is staying different, but again, work in progress, uh, is that their model is a stepped model. So as in level one across people, process, technology governance, I think was the fourth is you are level one for all of those things. And that is like adopting, I think, or what's the, I have the words around here, building your cloud native experience. Then you go to level two is operating your cloud native experience. And that is across all four of those areas, uh, people, process, governance, um, technology. And that's not the way we've gone with this model. This model is more like these things can move independently and you may find yourself at level three for something and level one for something else. And you may find yourself unable to move further in a certain category until you kind of improve one, at least a little bit, a different category, at least a little bit. So they are interconnected, but loosely. Um, yeah, and I think that that was partly based on honestly, like, it's really, one of the places I think if you fall apart first, trying to apply maturity model is when you go, well, my people is level three, but my process is level one.

Where am I? And then you start to really fall apart and we didn't want to try and tackle the most perfect. Everybody's here. We're seeing people tackle us in very different ways. Yeah. So it's interesting, like, you know, from, from what you're saying, it's interesting to think of it. Well, because, because the, the bad thing would be, would be like, well, this year we're going to go up to at least four on all of these, right. To just like have some unconsidered, like, because four is better than two. And so we must do better. Whereas, whereas, whereas really there, there's almost like, there's, uh, uh, in, in, there's, there's some value in thinking about the trade-offs you make between these five areas. Right. And, and, you know, whatever the final form may take, it's almost like by defining four levels, uh, in, in each of these, like the backlog, you can be reactive, scheduled evolutionary or platform as a product. Right. And so like, if, if you kind of define these, these like four levels you can have, you could say like, well, we're only going to be scheduled right now because we want to favor. I don't know, getting more platform advocacy, like that's the more important thing. So you can actually make trade-offs and because they act more independently, it's not like you, you have to feel bad about yourself or your organization that you're not like progressing through all of these. It's more just like a, uh, a recipe that you can, you can, uh, maybe not mix and match things. That's the wrong, weird idiom, but you can, you can sort of choose where you want to focus. And you might choose to be scheduled for now because you have a certain amount of backlog right now of fires that you have to put out. And that is not something that you want to try and shift just yet because it will cause a lot more havoc. And so actually being scheduled is the right decision for your company for this moment in time. And so therefore it frees you up to spend time on another category. So you can even think of it in like a positive way, right? Where you are choosing to be here so that you can spend the, but that gives you time to spend elsewhere. So, um, yeah, that's, that's definitely the intention as it stands is that like, you can trade these off and focus on them and see that if you're struggling to move between the levels, maybe you should look at some of the other categories to see your aspects to see, are they what's holding you back?

So are you struggling to get to kind of platform as a product because you're actually at still level two of adoption where you're sort of assuming that if you build it, they will come. And actually that's like the antithesis of having a product that is optional and that people have to give you feedback on and that you are going to market with. Right. So, uh, those things will happen. So, so let's talk about the funding part. That's always fun. No pun intended. That's terrible. Uh, but the, the, the, the, the four levels there are that you have one off, right? Like it's a project and then you have a, like an annual budget, which means it's determined every 12 months. And, you know, depending on your organization, I'm sure you spend two to three months just on slides. A regular budget. Yes. Yeah. And then, and then there's the, the, the platform team budget and then the, the, the P and L, the profit and loss. And like, so, so first of all, like what, what are y'all's like modeling here? Like, like what's the aspiration of this maturity thing, like the ideal state that, that you're, you're going to. Yeah. So just to, to flesh it out a little bit, the like secondary, the subtitle of funding is how does the company value and therefore fund the platform efforts. And I think that what we're talking about here is the fact that everything we should be doing at a company should be about improving the output of that company. And it's very capitalist. I get that, but that is why we're hired. It's what we're doing. And that includes internal work that we are saying will improve the efficiency or effectiveness of our engineering, which in turn will improve the delivery of features and value to our, our paying users. Right. And so we should be able to articulate the work we're doing in, on internal tooling and how that impacts the bottom line. It might be that we're saving money by reducing the, um, uh, reducing the amount of compute we have to run on because we're able to like bin pack a bit better.

Or it might be that we are increasing revenue by increasing the speed at which developers, we can onboard more developers, which therefore lets us onboard people to more feature work. So, but, but that's sort of the, the conversation there is how do we make sure that anything we're building, even if it's internally facing has a business eye to it. That's right. Right, right. Profit and loss. Yeah. Interesting. Yeah, yeah. No, no, that, and that, that like, that makes more sense than just how you get the budget. Right. Like you're saying. The ones that's been under debate, the wording of it for sure. It's funny, like a lot of people ask, um, how do they, how can they sell this idea to the, to stakeholders or to, to the, you know, to the business to fund? And this is a really great, I haven't heard this sort of, you know, uh, tie in with profit and loss, you know, of eventually getting there. But, uh, it's, yeah, it's the hard part and like what these, like the middle layers, the annual budget up to platform team budget are starting to, to, to expose to people is that you can't get to the point of proving the value of your work. If you can't measure the costs in any way. And so if you don't yet have a mature tagging strategy to be able to do a kind of chargeback sort of idea of how much does it cost to run this application? How much does it cost to run this type of infrastructure that's needed by these five different applications? You know, it might not be the most perfect spreadsheet of, of data there of accountancy, but being able to make it so that people don't look at the platform team and say, they cost us millions a year. Cause look at that cloud budget, look at that cloud spending and have people realize that that cloud spending is actually on all of engineering. And what that platform team is costing you is their salaries and not the data running the database, because that's actually the databases for another team that's running.

You're running an internal business, like it's platform as a product and it has to, this idea of chargeback, I guess that's, that's concretely, that's how you get to profit. Profit and loss. Exactly. So that makes, yeah, that makes a lot of sense. I have seen that. Right. And then you can report on these, on who's buying. Yes. Right. Exactly. And then, cause then you can also see who's, who's buying exactly who's using it is, are people choosing your internal platform or are you funding something internally where people are actually running off and using a cloud provided thing or a SAS provided thing instead? Right. And what are they saving by using you? Yeah. Right. Fascinating. Yeah. Yeah. But that, I mean, that is, that is a very common question for people to say, like, how do I sell this within my business? And it's interesting that the platform maturity model can help with that. Yeah. And, you know, I mean, another thing you, you, you get with models like this is, uh, and we were talking about this a little bit at the beginning is, uh, yeah. Like we're talking about here, like oftentimes people just don't know how to think about something. Right. Like, like we were saying, like, no one really knows how to think about how would I, what is the value of a platform? Like, do I think about it as like the way I pay for paper clips or is it something else? Like I, I always wonder in like other industries, like in manufacturing, do they have these same debates about like factories? And, and like, you know, if, if you're, you know, I don't think anyone would be like in manufacturing, I don't know if we need a factory. Like it, it just, it's sort of like the ROI of a factory is like existence. And, and like it, so it seems like, sure, you want to make sure you're not like overpaying for something. And you want to make sure that when you're like running the factory, you're maximizing usage productivity, I guess you could say. But like, at some point, I mean, it would be absurd, you know, analogously to like platforms to go into a manufacturer and like, you know, someone's trying to prove that they need to pay for a factory. And for people to be like, yeah, I'm not sure if we need that or not.

Like, and, and so it's like, I'm kind of, I've been hoping recently, well, I have many hopes, but this is just a minor one in my life. And this grand sum of things, but like, you know, maybe as, as like more managers and executives, and especially finance people at company, like, you know, we're like born with computers. Like, like, for them, it won't be such a big deal to be like, yeah, we, we need computers, like we need the platform, and we need to do development, and sure, don't pay too much for it and make, you know, think of it more as a factory and not that we have to like, prove that we should pay, you know, spend money on it. And instead, you like, prove the fitness of the platform, that it actually works well, and it delivers on what you're promising. Well, that, I mean, that, I keep thinking about this build versus buy question, because I feel like, you know, with everything, right, there's, there's a point at which you have to build, there is no option to buy the thing that you need. And platform teams have been in the business of building platforms for, you know, a couple of decades, at least not, if not more. And so, I don't know, does, like, is that a question that comes up for you guys as you do the, as you define the platform maturity model? Because I know you're focused on outcomes, not tool recommendations, but is there an opinion or a perspective on build versus buy? So, not, not as a part of this piece of work. I think build versus buy definitely comes up often in the conversations within the working group and around how to encourage and engage with the CNCF projects for how those can support people with as open source projects, but also often having commercial models around them, and non-CNCF projects as well. So, yes, it comes up all the time. It's not something this model, what I'm hoping from this model is that you could look at this, take this model and say, would buying this part of our platform help us achieve or not achieve success, right?

And I say in that way, buying this part of our platform, because I think the thing we're sort of learning is that, as an industry, I think, is that there is not a platform. There's not the platform. There are tools which get pieced together to achieve the delivery workflows that are needed by the company, right? And those workflows might be starting up a new project team or a new application. They might be delivering value to production. They might be testing something, user acceptance testing of something. These are sort of things that people need to achieve internally. And there might be tools that help you do that in different ways, depending on the technology you're using. And your platform needs to provide all of those so that you can have all those experiences kind of approved by what you need from the business to achieve the business. And so I think, tell me if I'm wrong, but part of what you're saying there is, like, because you have these five groupings of things, like this kind of, and it defines as we're talking about the platform maturity. Like, again, you can look at a buy versus build thing to see, like, well, if we build versus we buy, how does that help us or harm us in improving in one of these categories, right? Like, it potentially would let you get more detailed in figuring out which of those two you want to do, rather than just, like, I don't know. It seems like a lot of build versus buy discussions are more global in scope, right? It's just like, like, we want to consider the whole gigantic thing just as a whole, instead of like, well, what are all the different trade-offs we would have between this? Because it's really, I don't know. It doesn't seem like there's that much nuance to that debate. I think if you want one platform in order, and you want to build versus buy one platform, the only thing I can think of is the cloud providers. I don't know any other tool on the market, no matter how expensive or how cheap, that solves literally every interaction that a software engineer needs to have with your internal tooling as a single tool, right?

Like, we just don't have that. We have CI pipe, like, we have CI tooling, and we have app delivery tooling, or, like, app, like, hosting tooling. And we have, you know, security management tooling and incident management tooling and debugging tooling. And we have all these different tooling. And each piece, each one of those is a part of what you need from your platform. So I agree. I see a lot of people talking about, oh, build, buy, like, two kind of binary options. And I just don't quite understand how that works in practice. Yeah, I mean, I guess, I mean, VMware is, VMware is, is in that business. And that's, I think that's what, that's what we're trying to achieve. So, so maybe that's one example of a company that's trying to do that. Even within you, although this, you have a suite of tools that do it for your customers, right? So you're not, there's not, like, one VMware tool that is, like, to rule them all. It's like, there's, you piece together a whole lot of them. It's the components that, that different customers will piece different components together. And that's what builds their version of the VMware platform for themselves. And that's, like, that's a nice packaged environment because then they know those components work well together. And that's going to be one of your best kind of chances at piecing all of these pieces together and having them be a coherent whole, which is really nice. Yeah, but I do, but I guess that's the build versus buy, like, that, like that, wherever, wherever a company is in that scale of being able to offer customers an integrated version of that, that it's only going to get better, right? And so that build versus buy question just shifts. Every day it shifts, in my view, a little bit more. I mean, maybe not for, I mean, these bigger companies like VMware who are aspiring to that and who, you know, who are somewhere on the path of offering that, they're, you know, they're not for small companies. These are for larger enterprises. So that build versus buy also depends on who the buyer is, right, and what your budget is and what scale you're operating on. So it's still a different question at every stage. And if you do, which is another great question, because if you start off a smaller company and you're maybe not, you know, able to afford these larger solutions, then at some point that shift is going to happen for you too.

And you've already invested some work. So it's a tricky question about, like, maybe when you make that shift. Have you ever tried to apply Wardley mapping when you start thinking about these things? Have you come across Wardley mapping before? No, what is that? So this gentleman, Simon Wardley, it's named after him, but it's grown many legs since then, though he's still, like, strongly the driver of the community. And it's basically an idea of looking at the evolution of a market. So, you know, 20 years ago, people were really heavily invested in worrying about on-premise compute. So they were thinking about things like power supplies and CPUs and things like that. Today, to think about a power supply when you're spinning up, like, a cloud instance would be not on most people's to-do lists. And so that evolution into commodity is, like, what has happened. It went from something that was a differentiator to something that is a commodity. And Wardley mapping tries to take what is within your domain, within, like, what you need to use, what you rely on as a company, and map it on, is it, like, is it something that is new and a differentiator for you? Or is it something that is a commodity to the market? And how close to your users is it? So there will be people today, so high-frequency traders, who are still wildly interested in things like power supplies and on-premise compute, because that is a differentiator for their market, whereas it's not for lots of other markets where an extra millisecond or two isn't going to make a difference. And you can, you can, it's okay. And that, so the map is contextualized to your environment. So what is it that is differentiator for you versus a commodity for you? And it tries to have you, tries to challenge you on, should you be building this? Is this actually a differentiator for you?

Or is this something that you require to be successful, but is not going to be the thing that makes you beat out your competitors or be top of market? So, yeah, it's an interesting way of modeling things. Yeah, it's sort of like in our lore, Cora, there's the James Watters value line, right? And if you were to add like a time trajectory of like as something gets commodified, some nice, I don't know, complexification of it. But yeah, good old fun stuff. Also, serverless is going to be big next year. That's all. So you have seen worldly mapping before. Of course, yes. Yeah, it would be nice. Yeah, you know, as you two are discussing the build versus buy thing, it was occurring to me that like, it's almost like a non money changing hands way of saying it might be like integrated versus build. Like if you have, if you have like a platform that's all integrated and like, well, I hesitate to say easier, but is like more intentionally put together. Then like, it's like, yeah, rather than you actually have to like, piece together with bash scripts and other judas over here. Yeah, yeah, it's like, you know, I mean, I'm always leery of metaphors when it comes to programming and operation stuff. But it's like, you know, if you went to someone's house, and you're like, those windows don't really seem to fit those window frames are like those doors. It's like, they've just kind of like, they've like found, yeah, they've like found some parts and like gotten sod some things around and it fits together. And it's a house versus like, oh, this door closes, right? Like everything actually is integrated together. And like the, you know, the bathroom is just a bathroom. And I'll, you know, think things are fit together more, which you can only do with standards, right? I mean, it only works if you can go to Home Depot and say, I mean, this kind of hinge, and it will fit all doors.

Yeah. That's the only way we can. I mean, I look up American recipes and are like, what, how many, what ounce, which type of ounce? And it's just a mess. Exactly. Yeah. And then you convert between like milliliters and tablespoons. And you're like, one of these systems is insane. Like, what, what is, what does it mean that a tablespoon is like 14.2 something? Good to know there's something harder than building a platform. And then, and then, and then you realize that the recipes, exactly. And then the recipes are just like slightly off. Cause like mysteriously, the cooking, cooking temperature for the same thing is a round number, which, which I don't, I don't think that works. That's so true. That's so funny. Especially baking, which is so precise. Yeah, yeah, yeah, exactly. Well, uh, let's see. I, I mean, I think we, obviously we haven't read the maturity model. It's, it's, as it stands, I think it's about, what is it? Uh, eight, eight or nine pages or so. It's actually, it's, it's actually briefer than I remember it being, which is great. It's only at four. Come on, Coté. Well, when I scroll here. Oh, there's like the intro part about how to participate. Yes, yes, yes. See, so even better. That's true. It does have the contributor part, but it is, uh, yeah. And, and so like, I mean, if people interested in contributing, like, uh, like, like what's, what's the whole process for that? Or like the whole culture around contributing to something like this? Yeah. So this, this started as a bit of a brainchild with some colleagues, uh, at Centasso and quickly, we realized that if this was going to have any value, we'd have to make sure it was not a company owned thing. Cause this is much bigger than any one company, regardless of our level of experience in the industry. So we sort of threw some ideas together, got a bit of a draft together, and then immediately threw it out to a bunch of people who are, are all very nicely thanked at the bottom of the model, uh, for having done reviews for us.

And as I said, when we first passed it out, I think none of us had very high expectations. I think we all thought people are going to look at the word maturity model and they're just going to say, nah, or they're going to look at it and say, you know, it's too far off. And what we found was actually people were really excited about it. And we got ourselves into the nitty gritty debates quite quickly, which usually means you're onto something useful, right? When you're, when you're looking at those one word differences and you're not talking about the overarching thing. So, yeah. So once we went through that first review, we then donated it to the, the CNCF, uh, platforms working group, which I am a member of. Um, and so I'm helping just steward and make sure that people understand the initial context and have accessibility to, to make edits. So to contribute today, um, I'll make sure you have the link Coté for any show notes and whatnot, uh, to be able to just right here in the Google doc, it's, it can be anonymous. I'd love for you to be signed in so that we can have a great back and forth, but any feedback is great feedback. You, everybody, it's globally suggestible. So people can make edits and we'll, we'll look to, uh, incorporate them as we can, especially if you share what your intention of the edit was, that'd be great. Cause that gives us why, um, we should, we should include it. And you can also comment and respond to other comments. Uh, and that's going to be open for a couple of months, uh, really until things start to slow down on the interest, but we're targeting hopefully a more formal GitHub issue type review cycle in maybe September time, uh, in order to hopefully, if we feel like it's ready, uh, have it be ready for KubeCon North America and Chicago, but there's not actually a hard deadline on this. So if we're finding that there's still big questions to be answered come September, we'll keep going. We'll keep having, keep workshopping it until we're comfortable with it as, as a document. So, um, and then if you want to get more involved, the working group meets, uh, every month and an hour call and you can join the CNCF Slack and find the working group and join those calls.

So there's lots of other really interesting work going on in the platform space with that group. Yeah. Yeah. Yeah. I, I like the other, uh, just the platform reference architecture. I always use that very nice. Uh, so great job on that stuff. Working group. Yeah. Huge, huge props to the working group. Josh, the driving force of a lot of those things from red hat. And he's been, he's been great and, uh, and doing a lot of work there. So definitely it's, it's been a whole team effort through that working group, but I really enjoyed being a part of it. It's the conversations have been the most interesting bit as it is with all models. Uh, I, I hope people who read it will get value, but I know that the people who are helping create it are getting the most value because talking through what to do, where the trade-offs are, how to word it. Those are the really interesting bits. So for sure. No. And, and like you were saying, like, you know, if you're, if you're working with someone on a document or a concept, like you can tell they're very engaged and care if they're debating, if you should say investing versus funding, like, like, you know, exactly. Yeah. And also like, it probably is like, it would be, it would be really weird to incorporate feedback from someone and be like, well, as you may recall, wet yak said that this was a, uh, an idea we should incorporate because Google docs is always putting in these absurd names, uh, which, uh, anyhow, uh, well, great absurdly made up. Uh, well, how about yourself? If people wanted to, uh, catch up with things you were doing or, uh, you know, in a non-creepy way, see what you're up to online, where would you refer them? Uh, I don't know where to these days. Uh, uh, so I think we are all spread out quite widely at these, at this point. So my, the one thing I will say is my last name is very unique. So if you look for an Abby Bangzer and it's in the software world and not the art world, you found me. Uh, so I'm on Twitter as a underscore Bangzer. I'm on, I've made my way over to blue sky with the same handle, uh, Mastodon, uh, and LinkedIn

with, with my, my full name. So I'm sort of all over the place. I try and do cross posting. So if you have a favorite platform, I'll hopefully see you there. So, yeah, there, there's, there's what we need a working group on, uh, is the, uh, too, too, too many social silos. And, uh, we need, we need some, uh, uh, some consoling and advice about what to do. We're on level two on that one. Yeah. I think it's an XKCD around that something, make another standard. Yeah. Uh, it'll help out. Well, well, great. It was, it was great talking about this with you. I think, I think I, I, I've got some more, uh, my understanding of it beyond, uh, looking at it and it's, it'll, it'll be, it'll be fun to, to, to have it evolve and, and see how that pans out. Well, as always, uh, if you've listened this far, I'm not sure how you subscribe to this podcast, but if you're not, if you're not subscribed already, you can go to tanzu talk.com and, uh, find out easily how to subscribe. You could tell all your friends, tell your enemies too. If that will increase our downloads, that's fine. And your neutrals. Uh, and, uh, also we, we stream these kind of, I don't know, would you say Cora at a random unexpected time whenever it is. So, so we're totally breaking that rule of streaming where you're supposed to be regular and predicting, but whatever. Uh, but if you go to our YouTube channel, it's just VMware Tanzu, you could look up the video as well. And I guess if you, you know, if you've written our, our hook here is we, we like to find something that somebody is publishing and talk about that and have a conversation around that. So if you are, uh, you know, if you have a blog or if you've written something that you would think is an interesting topic and want to come on and chat with us, let us know. Absolutely. All right. Well, we'll see everyone next time. Bye-bye. Thank you so much, Abby. Thanks y'all.

Tanzu Talk · 🍕 Get more pizza.