 Hello, and welcome to the CNCF webinar on the business value of cloud native. All right, I'm Danielle cook. I am a CNCF ambassador and I am a VP at CD. I have helped alongside Simon who will introduce himself in a moment, writing the cloud native maturity model and doing several iterations of that. And we're here to talk about the latest iteration of it. But before we do that over to you, Simon. Hi everyone, I'm Simon Forster and as Danielle mentioned, I'm a CNCF ambassador, likewise collaborated with Danielle and members of the work group to formulate the cloud native maturity model. I'm part of the cartographos group within the CNCF. It's a working group, and its main mission is to provide artifacts to help individuals and organizations navigate the ever expanding cloud native landscape. Awesome. So, why cloud native business value now. So, first we're going to go through a few few reasons why there are many reasons but where we're calling out three of them first market fluctuation. So we all know that the tech market has been volatile over the last few years you know we've had a burst of jobs on the scene and now we see a lot of organizations that are right sizing. And the reason is these organizations they need to be profitable so they're cutting expenses they're cutting people they're cutting cutting cloud. But it means that it's so important for all of us to be demonstrating the value of cloud native. Now, because it impacts the bottom line, but as an industry we don't always do that. Wow, you know people are glazing over the business leaders of an organization may glaze over when you start saying Kubernetes and you know high availability and infrastructures code and service match that you know they don't know all the reasons why. And so we need to be translators of the technology, so that when we're saying these things, we're saying them in the way that the business thinks and talks about services customer needs etc. Likewise, we've seen the change in roles. So the role of the developer has risen within an organization so developers, they're being relied upon to do more and more and more, and they are providing, you know, the business functionality they are making the applications they're providing the services. But in order to do that they're provisioning the infrastructure we're asking them to deploy the application to operate it to scale it. So they're taking on more roles. Then they, then they kind of set out to do. And you know we have platform teams that are changing to you know traditional roles of operation and you know getting infrastructure set up is completely changed. So all of these role changes means like we need to be talking about the business value because it might mean we need additional resources or additional people, and that is not a hard one to swallow right now. It is a hard one. It is a hard one to swallow something like that. It certainly is a hard one to swallow and it's because of that Verizon and funk and capability and functionality that we've been seeing now we've got a good case study that's come up in artificial intelligence. Everybody's talking about it at the moment. But we have to consider that AI brings with it new functionality, and it also needs somewhere to run, and that the platform best suited for it is cloud native, as we know. Cloud native technology provides the non functional capabilities that AI is going to depend on to deliver at scale and with reliability. And look, there is a tremendous amount of data. Business is going to be looking at data at storage and it's cost pretty quickly. And cloud native also allows us to deliver the policy and the process and the governance that's required for this, as we know AI is a very regulatory sensitive topic at the moment. Well, and we do want to call it this is just an example of you know the changes in the market so you know AI is really cool but we all know that some of your organizations can't use AI some of them can like it varies so it's just a good example of maybe more and more data more need for flexibility. So, we are going to take you through now a bit of the cloud native maturity model, and then we're going to work through a case study of showing you some of the examples of the business value. So, to set the stage, there are five main models of the five main levels stages of the cloud native maturity model. So, at level one you're building what you want to do you're testing it you're trying to your pre production. There's lots of tech that you're doing, but there's also lots of different areas they're going to go and Simon will talk about those different areas in a second around people process policy tech and business value. In level two, you're in the operation stage so that is when you are moving to production, and you might be doing it with one application or you might be doing it with several, your way of operating will change based on how you're testing how you're rolling out the easiest applications to move to cloud native first and what is going to, you know, perhaps never moved cloud native level three is all around scaling. So this is where across your organization, your team understands cloud native, you have seen the benefits in the previous levels. You want to scale it across the organization so that could be scaling it across many apps. It could be having more people understand what it is, but it's all about helping you use cloud native to benefit your business. In level four and likewise level five, you're improving all the things that you set out beforehand. The decisions you made on day one changed by the time you're at day 10 so likewise decisions you made around cloud native in the beginning are going to change, and you're going to need to improve policy security governance. You'll be doing that and you're going to be looking at the technology to support but also your team's capabilities. Finally in level five that's where you're adapting. So you again are revisiting decisions you made earlier. And you're monitoring your infrastructure differently. You're optimizing it differently because you've been able to take all the lessons you've learned along the way and apply them and adapt. Over to you Simon. Yep, so moving on we've got the cloud native pattern on sitting in front of us. Now those five levels that Danielle has outlined are all the steps leading up to that that path. Now, if we look at this, we've got business value sitting as the roof as the center point is the jewel in the crown so to speak of cloud cloud native. It's there to deliver business value, and it's built on the columns of people process policy and technology. So we, we talk about the people process policy and technology supporting business value, because while we might be technologists, we have to serve business. And we do this through products and services that need to be released. We serve our stakeholders such as a sea level and board. And we also have something a little more ephemeral such as our business model and our competitive advantage. If you can imagine yourself walking up the steps, each step represents where you may be on the cloud native journey, and each of those pillars represents the key areas that we need to bring up and grow as we support business value. Awesome. And you know I really do. You know we do recognize on this. It is the people to process the policy the technist supports all business but if, but we need the business goals to achieve everything. So we're going to dig deep or go deeper into some of these phases. If I can get my slides to move. Yeah, so first we're going to go through level one. So, if we have attended the CTO summit, which the CNCF puts on at cube cons, and the overwhelming feedback from everyone was that the business doesn't see cloud native as a clear cut journey. So there are major shifts that are going to occur within an organization. So instead of, you know, doing, going here and and building and from scratch and saying it's just the tech, you have to understand that there's a big shift. So you need to get people on board. You need to understand what processes you have in place that will can be applied and whatnot. So here in this build stage, you want to also look at the tangible benefits that you can get from cloud native. How do you map those to what the business is doing. So if the business is shifting and doing digital transformation, great. If the business needs to just scale, and they can't scale on their existing infrastructure without it costing a ton of money. This is what you're trying to identify in level one. So here, what what the cloud data maturity model suggests is you need to work on, you know, you've decided you're going cloud native but you need to document why, and you need to ensure that the business understands that why and what the investment is going to be. In level one, you need to prioritize your goals, and you need to prioritize your POVs, pre production goals, and look at the trade offs that are going to be required between all of these. And we have here like customer satisfaction as example, and say your requirement as a business is to get faster website response times because your customers are demanding and you have to meet that demand. Your trade off might be that you need to move to cloud regions closer to the customer versus going to cheaper cloud regions. And those are trade offs that need to be understood early, because if they're not, you're going to have a situation where you go cloud native and the business will be like, I don't understand like this is more expensive this is not cost saving, and that is not exactly why you're going cloud native. So likewise, if you're, you know, looking at a goal to be more cost effective, you might be going to cheaper cloud regions, but your trade off is going to be a slower experience for the end user. And then finally, you know, managing risk. So, if that is one of your goals, or it's a top priority of your organization, then you need to be looking at okay well where do I need to host my data. And that could end up being more expensive for you as an organization. So being able to prioritize those top business schools and then also communicate those trade offs early is going to set you up for success later. And then within each one of the latest version of the cloud native maturity model we talk about costs specifically costs has become such a top topic that is huge and everyone's mind how do we save money. And again, like, as we said earlier with market changes and fluctuation people are looking to save money in various ways. So, in terms of cost and level one, you need to establish first that your teams are aligned. So, unfortunately, unless you're in that new business you're going to be running legacy infrastructure and cloud environment simultaneously. If you've communicated that to the business. That's going to save you know that the cloud names going to save you money you're going to need to better align on that, because you might have to be running both of those environments, everything's going to be more expensive. So that needs to happen early when you are looking at this. Second, you need to make allowances. So, you need to make these budget allowances for running everything simultaneously simultaneously. And then finally like you need to know that your costs aren't going to go down in level one they're probably going to go up. So if, if that is not okay with the business, then cloud native might not be right for you right now. Or you might want to only look at cloud native for net new applications and services. Really important part to remember is that those decisions that Danielle was run through applied a pre production. And also as part of that pre production you're not starting from nothing quite once to get to to in level one, you're building up a significant amount of infrastructure potentially or cloud native resources. And level two that we're just going to touch on now is where we've entered production. It's, it's our first applications into production. And it's a high bar to get to that requires people processing policy and technology prerequisites to be in place. And we have to be thinking through things like does our backup or identity and access. And model work for public cloud. There is a real cascade of activities to build those foundations. And we will have to absolutely align with our business as Danielle mentioned on what applications will we move again. It's not a zero sum game we don't immediately reduce costs and they get in the legacy world moving to cloud native there can be an often will be an overlap. So we need to identify you know where we're hurting and what will be the benefits we get most from migrating. And then of course will we meet our non functional capabilities and requirements capacity performance availability. And absolutely as we're dealing with a business we're going to need to measure and we'll have to have KPIs and okay okay ours objectives and key results absolutely defined. And we will have to communicate between technology and the business units. So if we run through the squares in front of us we've got that alignment where are we hurting most and where are we solving for our return on our investment. How are we measuring and and and again what are the trade offs that we will have to live with. And many organizations get stuck because they can't demonstrate how cloud native is actually helped to achieve a business goal or finally potentially achieve one that was out of reach previously. So if we move on to the next slide, and we take a look at the costs for level two. Again we've talked about how there will be changes in costs. We're going to be often moving from a CAPEX type model to an OPEX model. That is rather than having all of that money leaving the organization at the beginning to go and build by that hardware and all of that networking equipment. Instead we're going to be effectively paying as we go. We'll have that money leaving the organization on a regular basis instead of once every three years or five years and have that operating expenditure. And one of the things this does mean is because we're paying as we go we can't sweat hardware as we may have been tempted to do so. So how many of us have got a server that's way too old and should have been scrapped a long time ago sitting in dev because it was really handy. And we will have to have that that alignment between the tech organization and finance. We need to work with our public cloud service providers, for example, or internal if that's the case around discounts who owns this who owns the relationship. How are we tracking that and cost control becomes everybody's responsibility. If I as an engineer leave that server running over the weekend that's in for dev and no longer required real money will be exiting the organization. So it's now it now becomes everybody's responsibilities and people who weren't thinking about cost before will suddenly need to start being doing so. Definitely. So moving on we get to the level three scale, and we like to call this the messy middle. So this is my little gift that I found of you know if you're going on a road trip with siblings and whatnot and you stuck in the middle you might be the one that's just being pushed around. It's messy. It's not a great place to be. But here's where you don't want to give up so basically your business and your technology teams, everyone's bought into cloud native. You recognize these businesses across the organization, and the businesses are seeing a positive impact. But here like, you know the business are seeing the positive impact on cloud native and the products and services and becoming more competitive and you know managing risk better there's going to be lots of advantages. But you need to not give up at this phase, because this phase does end up, you know, as you organize is more comfortable and everyone's getting happier with where they're at and everyone seeing that things are working well. If you don't continue moving on in your journey, you can get stuck here. And, you know, some applications might be working beautifully, others might not be there at all so you're going to have a different fluctuation of capability across the organization across the applications you have across the services you have across the people you have. So here keep driving forward, keep making sure that the business understands and sees the value because you're going to have to train people here, you're going to have to look at new technology and probably invest in some of that technology. Small organizations they might serve this level and there's no problem, while large enterprise organizations could end up being here for years, because they have a lot of heritage they have a lot of legacy infrastructure that they need to happen. So all of this needs to be part of the business discussions, because it's going to take resources, you are going to have sprawl, you are going to have a proliferation of tools here as people decided hey I want to use this. I want to use that tool and you might be using three tools to do a similar thing. You'll be spending a lot of money, like it's not going to be cheap here, but it's worth getting here and getting through it. It's messy but it's, you know, messy for a reason. But I'm going to have Simon talk about this graph that we, we put together. It's pretty rough but I hope that now it brings across the general idea. The key point is that the messy middle is where we can find a lot of pain. We run the risk of having a very significant set of cloud costs on our hands, as well as our legacy costs, you know, particularly as we're in the middle of our cloud native journey. But remember that if we, if we look carefully at this, we can see our legacy costs do go down as we progress through the stages, and we work to see our cloud native costs also come down. A really important point and something so critical to think of is that when you're in the messy middle, make sure you work with your technical team on areas where you're experiencing specific financial pain. Your technical team, your cloud native engineers and your platform engineers and your developers may have good solutions at hand, such as sophisticated workload sizing, or they may have some technical debt that if they just bring up and priority, reprioritize on their backlog and start working on sooner in line with their product owners, they may be able to sort of pay down. Ask them work with them to find out what optimizations can they bring forward in order to drive down costs. You may be pleasantly surprised. There are many technical options available from your cloud service providers. You also want to be exploring some of your policy decisions as well here, critically for certain workloads that aren't available, don't need to have a high level of reliability that traditionally we would have left on the same tier of hardware. Our policy allow for us to go and drop it on to cheaper cloud native hardware, for example, since these are very important discussions to be having involved everybody. So just moving on to level four, thank you. At level four, we really identify that technology is not as important as the business output. The improvements that we're making at this stage, now that hopefully we've worked through that pain of the messy middle, really are focused on getting business value through out of our investments faster and by reducing repeatable processes or automating them. We expect to see a lot more alignment and understanding between business stakeholders, finance developers and DevOps teams. This is really the time where, if it hasn't been done at level three as I've just outlined, they really need to be working on just getting rid of that technical debt. Think about those legacy systems. What can we move? If we haven't switched over production to cloud native, if we're migrating and transforming, then we should be doing that here. It's really important. We also expect to see a consolidation of technology. In level three, there can be a real sprawl and it will be both because of that mix of the legacy or the traditional and our cloud native platforms, but also we'll have found that there will be, for example, a lot of cloud native technology where there's multiple options that have been brought into the organization. And now we'll be revisiting, actually, we've got multiple GitOps controllers, for example, can we consolidate on one? Or how can we get the best? We want to be really thinking through some of those decisions and we expect to see really effective automation around policy and compliance as well. And again, that's really important for measurement. Remember, a business understands itself best through KPIs. So take advantage of the policy tooling within the CNCF landscape, for example, to get the best out of that. And at this point we also tend to see legacy apps only existing if necessary. There might be a regulatory requirement to hold on to them, perhaps a data or system retention one, something obscure, or alternatively there will be left to simply age out. We also expect to see a reorientation at this point. We're starting to direct our attention more towards innovation and development, rather than having a lot of efforts being spent on support. Those operations teams will become, again, if they're DevOps, they'll be really working more towards a bit more of the dev side rather than the ops side of those equations. And so if we just move on to the next slide and look at what we expect to see around costs, focus on cost optimization, exactly as it says here. And you'll really want to make sure again, as we discussed in a little bit of level three, that your infrastructure is optimized for cost efficiency. And you should be able to report on this. It should be quite straightforward to do so in level four. You can use a lot of tooling to demonstrate cloud and Kubernetes cost optimization. Give your business the proof that they require and show how costs have been reduced. And then as it says here, show why more capacity is needed, if necessary, keep the conversation going between the business and the tech teams. And I think that's so awesome. And just a point to say, like, we've been talking about how in different levels you are spending more level four gives you an opportunity to go, hey, we did spend more, but now we've optimized for it. So it's a journey. That's why it's the model and it's a maturity model because you will get mature as you go along. So, um, level five, you've reached utopia, you've achieved all your business goals. And, you know, now you're adapting to your new business goals. So we all know that as an organization, you're constantly adapting constantly changing constantly, you know, becoming more innovative. So this is where you have created your, your cloud native platform, you've moved all your policies, your people are well versed in cloud native. And so now it's easier for you to adapt to new business goals that are thrown at you. And, you know, the reality is not many people are here. So we talk about it being utopia, you know, as everyone's sleeping while there are no nasty surprises. But, you know, it's, it's utopia. We all know that that's not always achievable for everyone. And here, you know, in the utopia phase, all of your costs are predictable. But we know like that is also not the reality because if you are not constantly looking at optimization and cost optimization, like you will end up having cost issues as you go along down the road. So, you know, we've seen obviously the rise of fit outs to help address this, but in level five, we'd like to think everything's predictable and you're super cost effective, but make sure you're spending time to keep that up. So now what we're going to do, and this is really the area where the latest version of the cloud native maturity model stands out is we dig into some case studies, three case studies, and how you can discuss business value in the organization. So we're going to go through these and have more of a discussion on it. So, the first example, we have acne software acne sells to the enterprise market. And their entire business goal is to sell to this market, but in order to do that, they must demonstrate security and compliance within the supply chain. So like they're, they're using, you know, KPIs like zero policy violations. So the business knows, hey, in order to sell, we need to check off all of this. So Simon talks about the tech goals. So one of Acme's primary requirements is that it doesn't become a threat to its customers. And one good place to start with that is making sure that it's providing signed software with bills of materials. These are really important documents that highlight the, where all of the bits and pieces that make up that software originate from and provide us the means to understand exactly what's in our software. So some of the KPIs, for example, it might be used here are looking at first off, does it have an S bomb to begin with. Then we'll also be considering things like, you know, are there any vulnerabilities within the within the software. And there's plenty of tooling for that. There'll be the time to patch it. There'll be code coverage testing that hasn't been fully exercised as part of its development process. And then there also might be a set of SOC2 reports that are generated as well with that. Well, and for people point of view, you're going to be looking at your people goals. So again, you're trying to demonstrate security to the enterprises you sell to. So your people are going to need to be well versed on security and policy requirements. That requires security first approach to your business. If you're going to need training, you're going to need a security center of excellence. All of these things to train your developers to train software development process make sure that that's covered. So but like security and people will go hand in hand. Likewise, like when it comes to policy goals. So you need to be able to understand what your customers policy requirements are, so that you can build that into your own policy requirements. And then Simon, what about process goals. It's a really important part of the process for delivery is going to be having a pipeline for delivering that software and simply making sure that the appropriate testing is incorporated within that pipeline. And that also that the that some of the deliverables such as S-bombs meet the customer's own policy requirements. So we can live up to the dependencies and the requirements of our customers. And what's really important here to call out is we've just talked about the tech goals, the process goals, the policy, the people goes example KPIs that it all boils up and it all maps to this business goal. I want to sell to the enterprise. I need to check this box. And so when you were communicating that to your business leaders. And I'm going to have this and this and this and this is going, hey, you want to sell to them. We need to check this box. I've checked this box. And here's how I can demonstrate it to you. So the next example is Anvil Enterprise. So Anvil is the organization that Acme is selling to. So in the maturity model, you can kind of see that. So Anvil is buying stuff from Acme, but likewise what they're trying to do is they are, they provide data to financial services organizations. So their business goal is that they need to meet customer demands and it must, their application must scale or their capabilities must scale to meet and deliver services to 20,000 locations. So they are going to be completely focused on, Am, is my customer getting what they need from me? I can we scale to meet their demand? So Simon talked to me about the technology goals. Yep. So with their technology, I mean, they've got to deliver. They've got to have the capacity to deliver as required at all times in 20,000 locations is pretty significant. And it's got to be able to ensure that there is compliance with policy at all times. Yep. So, so that's the key technology goal that they've got there. Yep. And so on that, you know, in terms of the process that they need to undergo to do that, they need a strong delivery process. For the software and the platforms, obviously cloud native definitely helps that ability to meet those locations and demands. What about the policy requirements, Simon? Well, the policy requirements are going to be dictated by the business, often on the basis of regulatory requirements. We're dealing with financial data here. So I can almost be certain that there'll be a strong regulatory component that the business is going to have to uphold. So the accountability for the policy is going to sit with the business and the responsibility for it is going to sit within the tech organization. So there needs to be a really well documented checklist of standards and capabilities and outcomes for the business to review in order to be able to report to its relevant regulator. Super important. Well, and you're going to have different KPIs. So, you know, developers and whatnot, they're going to be looking at release frequency, time to patch respond time SLAs. The business is going to care about uptime. Like, do we have downtime out there? Is that happening? Are our customers happy? Which brings us on to our last one, which is ABC Company. So ABC Company purchases from Anvil. Isn't that lovely how we did that? And so for ABC Company, they want to hit their revenue target so they must improve their customer retention. So I think we're all familiar with, you know, hey, we got to make sure customers are happy and using our products and services. So in order to do that, they need to improve their satisfaction rates. So what is customer retention and satisfaction rates? So how does that translate to the tech? So, so customers can often be frequently sensitive, both to the applications, you know, the modern applications that they're using that they're available and accessible at all times. And really, there's a very important element that's also mentioned here, which is around trust. We're dealing with financial data. And as a customer, I certainly know I'd love to, I like to have trust in my own bank and with the financial details that they're holding about me. So as a business, the reputation is incredibly important, particularly when we're dealing with retail or end users here. Well, and so different KPIs here are going to be on baseline customer retention rates and that promoter scales, customer satisfaction scores, are our customers happy? And customer retention rates, are they leaving us? So if we are not giving them the tech, or we are not meeting this business goal through tech, through our process, through our policies, like it's going to be a problem. Here, you know, our people goals are all around development teams getting new features to market faster. And we know that if you read any material out there in the market right now, it's all about shipping faster, shipping faster. Well, the reality is like that needs to happen. A lot of organizations, they need to get new features to market because customers will find another service that has what they want on it. So really here, it's keeping the customer happy. And all of that translates to various different tech. But if you can demonstrate that, hey, if I make this tech investment, it's going to map on to improving customer retention rates. That's where you're going to get sign off on projects and sign off on cloud native. And just to tie back as well to another point there as well, just our previous organization, we're still dealing with customers financial data that regulatory burden is potentially still here on ABC. So ABC are in a really difficult position where they've got to keep up the new features coming out, maintain the trust of their customers, but they've also got to maintain their accountability that they have off to the business and to their own regulators as well. So the ability to deliver quality and at pace is absolutely crucial for this to keep and to, again, keep the trust and keep the customers coming back, keep up the satisfaction. Awesome. So those were three examples of different, you know, how you can think about a problem in terms of the business goal first, and then map cloud native onto that and cloud native tech cloud native process. Process people, experience, etc. So we have some resources for you. So if you want to dive deep into the cloud native maturity model because there is a lot there. You can do it at this URL. We also have a GitHub area page. Well, you know, where you can comment, you can participate if you think there's something missing in it, please let us know. We also have community meetings where we talk about the maturity model and a CNCF Slack channel where if you want to get involved, which is Simon's next slide, you can. So do come and join us. We'd love to have your contribution. If you're watching this webinar, then you've probably got an interest in the business value of cloud native. And that means you're out there and part of the community and we'd actually really be interested in your insight and your experience in communicating the business of cloud of the business value of cloud native. So how are you communicating with your business and how are you navigating also the risk conversation when we change stuff when we have a transformation. There's always going to be an element of change and risk associated with that. So this is an area that we're really interested in exploring and we'd love your insight on that. And then also cost. It's a perennial topic. We've addressed it hopefully at length here for you. What's your experience been and how are you dealing with it. So come join us. We have bi-weekly meetings, as Danielle mentioned, we have the Slack channel, we have GitHub, and we would absolutely love to hear from you. Awesome. Well, thank you Simon for going through this today. And we hope you enjoyed the webinar. We hope you look at the resources and we hope that you all work on communicating the value of cloud native to the business. Better. All right. Thank you for your time.