 Welcome, everybody. So maturing your platform engineering initiative. So my name is Nikki Watt. I'm the CEO and CTO at a company called Open Credo. We're based out of London in the UK. And we're a hands-on software development consultancy. And we help our clients to build sort of cloud-native architectures, data platforms. And one of the key areas that we work in is around platform engineering. So what I'm going to do today is speak to you about some of the experiences that we've had in trying to help our different clients to mature their platform engineering initiatives, but also have a look at it from how can the CNCF maturity model actually help with that. So there's some of the experiences that we've kind of worked with, different types of clients. And I'm going to try and pull on some of those in order to tell the story. So in terms of what we're going to cover, we're going to start off just with a bit of an introduction, have a look at what is the platform maturity model, platform engineering maturity model, and then go into the main part, which will be around the sort of typical scenarios and journeys that we see our clients going through, and then to finish off with some key lessons, takeaways, and a conclusion. So first of all, where did this platform maturity model come from? So I haven't made this up. This was actually originally donated by the good people at Cintasso and the wonderful Abby Bankza, actually leading the charge there. And I did help to contribute to some of the sort of the precursor to being donated to the CNCF. And so I'm going to try and give our view on how this fits with how we do things. But essentially, it was donated to the CNCF. And then in November 2023, it was actually released in the first version. I think Colin from the working group, the platform working group, actually spoke a little bit about that early on. So I've got the sort of URL there. So if you want to have a look at it, please do either Google it or go to that URL in the slides moving forward. So let's dive into the model and just kind of have a look. What is the actual sort of model? So at its heart, I'd say it's really it's sort of a correlation of trying to find the sort of patterns and wisdoms that various people have gone through to try and sort of put together in a handy matrix style sort of setup and show the different sort of characteristics and the different sort of practices that exist at different levels of maturity as people go through this process. It'll hopefully also provide you with a way to sort of orient yourself. So where am I in this particular process? And also highlight like what maybe are the limitations for where I am and what are the opportunities for where I can move to. Now this is not meant to be dogmatic. So there may well be sections that don't apply to you. And it's really meant to be you kind of take the pieces that work, maybe even add some in. But it's trying to give you a framework to be able to do this. But at a high level, there's these two angles. You've got the aspects that you want to kind of look at. And then you've got the maturity level. So if we start off with the aspects, one of the first one that is kind of looked at is around investment. And this is really around how are the staff and the funds sort of allocated to platform capabilities. So you may find if you're in an organization, it may come from the sort of grass route to get people that are starting to try and cajole it forward. And then it may also come from the top down. But no matter sort of which way you sort of come about it, making sure that you have the right funding and the people available at the right time to progress your initiatives will be really key to making sure that you can actually progress forward. So optimizing for the time, the people, and the sort of money is really going to be crucial to moving forward. So this aspect will have a look at that. Then you've got the adoption. And this looks at how and why do users actually sort of discover your platform and the sort of platform capabilities that you have. So we want a platform that users actually want to use. We don't want something that is non-desirable. So one of the things that we want to do here is really kind of find out where are users on this journey. So in some cases you might have users that they don't even know they have a platform. They just have a collection of sort of common tooling maybe on the one sort of end. But as you mature along you'll find that actually there's more of that curated experience that Matthew Skelton kind of speaks about. And you've got these different sort of levels that people kind of work within. And on the one end you might also have users that are more kind of forced on to the platform. And then on the other end you've got users that really sort of self-serve. They want to be there. And they're actually trying to encourage other users to get on but also to contribute back to the system. So that's on the adoption aspect. Interface-wise this looks at what's the maturity around how your users actually interact with and consume the platform capabilities. So with this you're really kind of looking at interfaces which look at things like provisioning, the managing and maybe the sort of observability of some of the capabilities that you're looking at. And on the one end you might have things where there's ticketing systems. It's actually quite manual. So the systems that you interact with are very manual. They take quite a long time. Maybe even portals that don't have APIs. But then as you mature along the sort of spectrum you get to more API driven setups and more CLI type of setups. And this will have a look at sort of where you are on that spectrum. Operation-wise this looks at how are the platforms and their capabilities actually planned, prioritized and maintained. Now from this perspective, if you think about it, there's a saying which goes, a dog is not just for Christmas, it's for life. And it's the same thing when it comes to platforms. You don't just kind of build a platform and it's only for a day one capability. You really need to have a look at what is the operational aspect moving forward. And this aspect will have a look at that. So this will include things like how do you deal with your users when you need to upgrade the platform or the capabilities around it or you need to create new features. What does that look like and how consistent is it? And this is looked at throughout the whole life cycle. And the final one is really around measuring it. So what is the actual process that you go through for gathering and incorporating feedback and learning from it? So as the saying goes, if you can't measure it, it generally sort of doesn't exist. So how will you know if you're maturing, if you don't have those feedback loops that are kind of coming into you and getting the feedback from your users? So this aspect will have a look at things like do you have explicit or implicit feedback loops coming in but also not just that it's about the actual quality and how consistent is it as you get up the more sort of mature level of the spectrum to where you're going. So that's really around the aspect. So these are different kinds of things that we have a look at. Then you have the maturity levels themselves and this is generally sort of labeled from sort of one to four with some kind of descriptions for the titles here. But the key thing to note is that there's no sort of single standalone definition which says this is what it means to be provisional. You generally need to have a look at it in the context of the aspect that you're actually looking at. So what we'll typically be is you'll find there's more tactical type of characteristics and outcomes that you find on the sort of left-hand side and then as you progress to the right it's a little bit more strategic. Now this doesn't mean that if you find yourself in level one or two of a particular aspect that that's bad. It just means that maybe you're at a place where you need to have a particular tactical setup in order to progress forward. So it's really more about where you are and how you can improve moving forward. So I'm not gonna go through all of the details yet because we'd be here for a very long time but you can go to the CNCF and actually have a look at this they've got this available in a PDF and I would advise you to go and do that. What is worth noting however is that as you are looking to mature your platform engineering initiative the more level, the more sort of maturity levels that you wanna go up you need to be aware that you are going to need greater funding and you are going to need more of people's time in order to move forward. And practically that means that you may not want to automatically aim for being at level four everywhere. You need to be sort of pragmatic and say what is it that, what are the constraints that me and my business has in terms of where I am in terms of people and time and then work within that. So this actually fits in nicely with there was a panel which spoke about build versus buy and there's a lot of different ways of cutting the sort of costs and things and this is an angle which you can have a look at. So let's recap what is the point of this maturity model? Is it to get some kind of comparative score like I'm a 3.5 out of five? Absolutely not. Is it to find the one true way for how you actually kind of mature your platform engineering initiative? Absolutely not. There are many ways to do this but really what it's about is trying to provide a helpful way for you to really understand what are the outcomes, what are the practices that exist at different maturity levels in these different aspects? Where are you currently? And also then what are the limitations and the opportunities that exist for you to mature and move forward? So and finally also to cement the idea if you have a look at all of these different characteristics that the really way to get a good outcome is to make sure that you balance your people process and technology alongside your technology. So that was the sort of platform engineering maturity model. Now we're gonna have a look at the typical scenarios and the journeys that we go on. So here are some common scenarios or we have customers that come with many different reasons for why they want to mature their platform engineering initiatives. And there's a variety of them and I'm not going to be able to sort of explore all of them but we can explore one or two of them. But what I would say is that irrespective of the scenario that you start with, there's a couple of key kind of points that are common across everything when you're getting started. And the first one is that you really need to understand what are your ultimate goals and what are the constraints that you're working within. So this is really important because what it essentially means is that you want to have a look at what are your main business drivers? So am I trying to scale my organization within a particular point in time? Or am I trying to migrate or some legacy technology? Because depending on where you start or depending on what your main drivers are you may land up going and trying to end in a particular sort of different place. And you can have multiple, there may be sort of a mixture of these. But you want to make sure that you can figure out what are the strategies that I need. So once you've done that, you then need to say, okay, I know where I'm going but where am I at this point in time? So you need to understand what your landscape is. You need to try and plot yourself as best as you can sort of in this matrix to see where am I. Now it's not necessarily gonna be perfect and you probably won't find that you fit nice and neatly into a category and that's okay. You can even add extra categories in there. So for example, one of the things that might come up is you might have ESG as another sort of category. So different teams, different customers will have slightly different things but this matrix does give a good indication of what the main sort of aspects are to consider. And finally, once you know, okay, this is where I've started, this is where I'm ending. You then want to sort of plan and say, okay, what are my particular steps that I need to take in order to go from where I am to where I want to be? And you always want to aim to take sort of baby steps and iterate and then rinse repeat as you go along. Because a lot of this process may be experimental to a certain extent. You may not know exactly what's going to work. So if you do sort of little and often, it's much easier to be able to work out whether things are working. If you've got a good feedback mechanism than trying to do everything in a big bang. Okay, so this is a scenario that comes up quite often when clients approach us and there's a desire to improve a particular technology. So they want to improve their Kubernetes platform. But I would argue that this is not a business driver. This is a desire to improve technology. And when clients come to us, we generally need to dig a little bit deeper and say, well, what is actually the reason behind you wanting to improve your Kubernetes platform? And then you kind of get into the scenarios where they say, well, actually, the developers are overloaded and they can't develop fast. And you say, okay, well, that's the reason that's why we actually need to optimize for not just Kubernetes per se. And that's why the title of the talk is also about trying to go beyond just Kubernetes. It's to Kubernetes and beyond. So we want to have a look not just at the technology, but at the overall sort of aspects in order to mature our platform engineering initiatives. So Kubernetes will be a key part of it, but not the main thing. So the scenario we're going to spend a little bit more time on in this talk is around scaling an enterprise, what I call center of excellence. So the scenario is that we want to sort of grow and we need to scale. We also want to sort of deliver a little bit faster and more effectively. Now this could be, your starting point could be a startup actually, but and that will have a very different starting point and a different endpoint than if you're an enterprise. But we're going to focus on the enterprise one from this perspective. So what does that look like? So the first thing, as we said, what we want to know is what are our particular ultimate goals, what are the constraints that we are working with? So in an enterprise center of excellence, we would kind of say, all right, in this particular case, we have some key business expansion that we're trying to do. We probably need to onboard and maybe another sort of 20 plus teams. Maybe that is as a result of some mergers and acquisitions and it'll probably scale up even more after that. But in the initial phases, we need to onboard say another 20 and we've got sort of 12 to 18 months to do this. And maybe we probably need to conform with some sort of security regulations as we go along as well. So we say, okay, the main thing is the scaling as well as trying to go fast. So we are generally aiming to be in the sort of scaling maturity angle, but we'll see as how we go along. So where are we? Now we get to the point where, okay, we need to actually kind of plot ourselves. So this is where if you're looking at the platform engineering maturity model, you would go to it and you'd kind of have a look at the description and maybe the sort of example scenarios and the characteristics and try and plot, as I say, as best you can where you think you belong. What we have found as a sort of a typical setup and this is not necessarily always the case, but often an enterprise that is, they have a platform team, sorry, in an enterprise center of excellence scenario, your people will generally have central funding. So there is a team already or it's maybe called the center of excellence and there is central funding, but it's often treated as a cost center at this point in time. You'll generally have people that are actually dedicated to trying to provide common tools, but it's mostly going to actually be your technology folk that are doing things. You won't necessarily have a lot of other, maybe sort of product type folk in there as well. Just all right, this is maybe where we are from an investment perspective in this particular scenario. What about the adoption? So when it comes to enterprises, one of the things we find quite often is that there's very much a sort of an imperative and a directive for users to get onto the platform. There's generally some sort of, as I say, directors which will say, you need to use this particular type of framework or this particular setup and the users don't generally have the choices to whether they want to be on the platform or not, but they're kind of forced into it. And sorry, and another characteristic that we found with enterprise center of excellence type setups is that you often have a wiki so people have actually got a lot of documentation out there and say this is exactly how you adopt the platform, but it's often out of date and it doesn't actually sort of keep up. So this is a typical kind of setup. Interface-wise, this is a bit of a mixed bag. You can sometimes have a sort of standard tooling there, but it's not necessarily set up in a way that it allows you to be consistent. So it's semi-consistent. Typical sort of characteristics here is that you'll find the interfaces that are provided will focus on things like bootstrapping. So it's like how do I get people maybe onboarded fast, but then once they're actually up to speed, there's not necessarily the sort of ability to carry on in an automated and a consistent way after that. So that is on the interfaces. In terms of the operations, and again, this is not exactly the case for everybody, but we have found that with many of the enterprises, operations tends to be one of the areas which is a little bit less mature, and it tends to happen more sort of by request than in a reactive manner rather than sort of proactively. So what you will typically find, or what we've typically found when we've worked with these type of setups, is that the focus is really on the sort of day one requests and not so much on the day two requests. So a good sort of example of this is if you have, so you may discover a vulnerability in your setup, or maybe actually you've got an operating system that needs upgrading. So you'll know your different sort of teams that are out there and you'll say, okay, we've got 20 or so teams already, and we know that they need upgrading, but you won't have the capability as a platform team to actually be able to do that. You'll need to kind of schedule that onto their backlog and get them to actually do it for you. So that means it's more kind of by request than actually sort of centrally tracked. And finally, so we've also got on the measurement side of things. So this can be generally, there might be some measurement, but it's generally some sort of basic technical setups. There's not necessarily stuff that is customer focused and user centric at this stage. So there may be initial surveys that are done, but if they are done, they tend to be a little bit more sort of custom and a one-soft type thing, but there's not a consistent measurement at this particular point in time. So it's okay, this is a rough sort of indication of where an enterprise might be. Let's have a look, how do we move forward? So what we will typically do if we go into a client is to lay the foundation for building what I'd say the right thing and not just anything. And that means that we want to kind of look at certain kind of key areas that will really help us to make a difference moving forward. And one of the first things that that will be in the investment sort of area. So with this one, if we're gonna scale up to multiple teams, you definitely need more funding. So if you don't already have C level buy-in, that is generally something that it needs to be part of this. But also the key area here is that we need to move from a project type mindset to a more customer focused and more platform as a product type mindset. And we've spoken a lot about that sort of moving forward as well. And practically what that will also mean is that some of the members of the team that will actually sort of be part of your platform team will differ. So now you might actually get some product managers type involved as well. And this is going to be a little bit different. And you actually could have moved to a profit center model as well. So these extra people also gonna help us to be able to advance some of the other aspects that we have looking at as well. So once we've set that in place, so we've got our funding, we've got a few more product and customer centric types in our team, we then wanna have a look at the measurements. So we're not gonna know how we're advancing if we can't measure it. And what we wanna move to if you're in the ad hoc space is at least get to some what I call reliable, reliable Intel. And this is where you can use some of these new roles that people have come in with. So maybe the product managers and the researchers to be able to design you some qualitative research surveys. So how are your users actually using the platform and are they able to progress as things move along? So it's not just gonna be a once or thing you design this so that you can work out if you're actually progressing. You do the same on the operational side. Make sure you move to a more sort of centrally tracked setup. And yeah, it's a more centrally tracked setup. And this will be maybe to the point where you have, you may not have, it may not be manual, sorry, it may not be automated at this stage, but you do want to understand what is my estate, what do I have, who's responsible for what so that I can actually know how I move forward. So making sure that you have this sort of centralized documentation of where you have will allow you to then automate and move things forward. Don't forget to do your technical due diligence. So when we go into our clients, we will often actually do a lot of technical due diligence as part of this. So have a look specifically at the architecture, the observability, automation and infrastructure as part of this. So the things I had spoken about previously weren't very, they weren't necessarily that technical, but don't forget that this is a key part of what needs to be done. And the reason I say this, a good example here is if you kind of look at different multi-tenancy models. So if you're trying to scale your organization up to sort of 20 plus teams, the decisions that you make here technically can have a big impact on the sort of size and complexity of the operational setup that you're trying to do moving forward. So you want to be able to make sure that your technical people and your business and office people all work together to make sure that you can come up with an optimal solution. So as I noted before, you know, you try and do your best to plan and move along. And what you'll find is that you'll make a lot of progress in all of these aspects, but the one you'll struggle with will be adoption. And this is because we found that even if you make various sort of good sort of technical, make technical progress along the way, there are certain things which just act as a barrier to adoption. And these are some of the ones that we have found. So the first one is a lack of confidence. So what we found is that if you go into an organization, you've done things that the developers are still not adopting. And quite often it will be because they're just not confident that the platform is actually going to be able to support them when it goes into production. Or maybe they're the first ones going into production and they're just not actually happy with that, or they're not comfortable with that. The other thing that is also a drag is that there's not enough features. So they may need like a database and a queue and you've only given them a few things. And so they're like, if I don't have all of my pieces, I'm not going to go. And so this is why it's important to make sure that when you choose the teams that you want to progress through as your first sort of exemplars, that you find ones that are champions, but also ones that can take you all the way through the system so that you will be able to learn about the operational aspects and give confidence for others as you go forward. And also finally, you need to make sure about the developer relations. So we found this is really important. So evangelizing to the developers about the platform and how they can use it is really important to getting them to adopt and become more sort of self-selecting rather than having the stick approach, which is what typically happens in a enterprise center of excellence. So that was a little bit of a whistle-stop tour in terms of what it might look like in an enterprise center of excellence type of setup. But as I said before, it's not going to be a big bang approach. You would typically take little steps along the way on your journey. So there can be a lot of different scenarios out there for why you might want to mature your platform engineering model. I'm not going to be able to go through all of them and fortunately due to time. So I'm just going to finish off with some key lessons and some takeaways from this. So basically as part of your sort of strategy for moving towards a more mature platform model or more mature platform, what you really want to do is start with understanding what is your ultimate goal that you're trying to achieve? Are you trying to scale up? Are you trying to develop a productivity or is it something else? Because that is going to inform where you want to get to but also some of the trade-offs you might need to make along the way. Make sure you know where you're starting from so that you can work out what that gap is and then do plan baby steps in order to sort of move forward. Try and lay the foundation for some of the other steps that you'll need to take. So things like investment, making sure that you've got the right people in the team will be crucial to getting this right and then don't forget that this has to all be done sort of collectively. So consider people process and tech together as part of your decision making. So the conclusion is basically in addition to the key lessons I've just highlighted, the maturity model can be a really helpful way to sort of plan your journey as you are maturing but it isn't the plan. You will still need to work out for yourself what are the particular steps that I need to take to move from point A to point B and that is going to be context dependent. As you try and mature your particular initiative, you will need more investment in people and time the more you want to go up those models but that doesn't mean you always need to aim for everything to be at level four. It will be horses for courses in this case. But whatever strategies and the approaches that you take you need to just make sure that you balance your people, process your policy and your technology. And with that, thank you very much. Don't know if there's time for questions. So questions for Niki? Any question? Hi, what would you consider a lot of time when we're talking DIY versus buy when we're talking about the platform? Sorry, can you say that again? What would you consider like rule of thumb when you're considering buying or DIYing your platform? So yes, I said one of the angles to have a look at is generally cost, like there's not an endless sort of monetary supply of money in any organization but also the developers and the skills that they have and the time that you have to be able to implement your setup. So when it comes to build versus buy it would be a combination of looking at do I have the team and the capability to actually build something brand new? Do I even need that? Or actually is there something that's out there that I can use that I'll get 80% of what I need? And maybe that's good enough for a starting point. So it really kind of depends on what your particular constraints are and that's why I say it's really important to understand what it is you're aiming for and what the constraints are. So combination of cost, people's skills would be part of figuring that out. I also have a question, thanks for your talk. So what do you think about the buy versus build versus compose, like adopt something? Yep. What's your point of view about that? It depends, which is always a consultant's answer. But if I have to, there's not a rule of thumb, but I would generally say it's customized, basically. Quite often the build will not do everything that you want. You will always have to customize to a certain extent. But building everything from scratch is also over the top. So there's generally some happy medium, I would say, in the middle. I think the key thing, and this has been spoken about by many people before is to make sure that you do it to APIs so that you can adapt different things. So if you're going to buy something, make sure that it has an API and that you can integrate with it from other things, because that gives you flexibility rather than just portals and things. But in most of the clients that we are in, there's always a customization that tends to happen. It's never just one or the other. Thanks. What would you advise if a customer comes to you and says that one of their drivers to go on with their platform initiative is to streamline the cost profile of the organization or the engineering body? So cost is an angle that some people come at. But I think there's different ways of looking at this. So it's digging, what aspect is it of the cost that you're after? Because there's different paths that one can take. So is it just to cut costs, because what you don't want to do is necessarily just cut the workforce type thing. But there are ways to optimize that. So it's definitely something to look at. And it's a very valid concern, if I'm honest, that people generally come with. But I wouldn't look at it just in isolation. I would also say, well, what are the other things you're trying to achieve? So there's the cost angle, which is the primary sort of thing. But you don't want to sacrifice some of the other initiatives that you're also looking at. So a platform is one of those things that if you get it right, it will allow you to do that. But it's generally not something that happens straight away. It's actually something that takes a little bit of time to get there. So there is initially sometimes an investment that's required. So if people are expecting a quick result, that's not necessarily going to help. So the time horizon for when people are trying to actually optimize for costs, they need to have a bit more of a longer term look at. And so that's the one thing we were generally says, yes, it can come. But it's not going to happen sort of chop chop. You mentioned about needing buy-in from the C-suite. So how do you get that buy-in in the first place? Yeah, well, a lot of pleading sometimes. So I think sometimes when people come to us, it's all gone horribly wrong. And there's actually a recognition that it's gone wrong like three or four times already. And so things need to change. And the C-suite has been impacted by that. And they've recognized the desire. So sometimes, if I'm honest, the C-suite have actually sort of recognized that. However, when you start with organizations where the initiative starts from the grassroots and then you're trying to actually convince management to take it on, that is far more difficult. And so part of that is to find out what are their particular challenges. So the type of things that the C-suite often cares about are things like risk and security. And so if you can speak in their language and say, part of this platform engineering initiative, we will be able to look at risk and whatever. And in the long run, we'll be able to potentially reduce the risk profile or make things a little bit more streamlined. Those are the type of things that they are generally interested in. But if you just talk about Kubernetes and this type of stuff, it goes absolutely nowhere. So it's working out what is their challenge and spending time with them to find out what is the key driver. And often, if you chat with them, you'll kind of find that out and say, well, actually, this is how the platform can help. But it's been able to kind of map what their challenge is to how the platform will be able to actually help that. OK, thank you very much, Nicky. We have no more time for questions. So a big round of applause for Nicky.