 I go out and talk to a lot of people, developers, people in the community, customers, prospects, et cetera. And without much exception these days, they want to talk about Kubernetes and how they're either going to do the Kubernetes or how they're doing the Kubernetes, and how I can help them do the Kubernetes. And my first question to them is usually, so that's cool. But what problem are you actually trying to solve with the Kubernetes? And usually what happens is they just start saying the word Kubernetes over and over again, louder and louder, because that's what they've decided they want to do. And so we get to this thing where Kubernetes is this decided thing. And so now you're starting to build problem statements around how you get to Kubernetes, right? And so you're like, I'm going to get Kubernetes. Therefore, I'm going to go to the cloud. I'm going to buy new servers. I'm going to migrate all of my apps to prove out the value of having Kubernetes. Or I've got to hire a team with five years of Kubernetes experience, because it turns out it's actually quite hard. And so this is kind of what I'm doing inside, but I try not to make this face on the outside. I'm kind of face-palming, because you don't actually have a platform problem. But what you've done is you've made Kubernetes your problem and not the solution. So now you're actually fixing for Kubernetes rather than fixing for the actual problems you have in your org that might warrant you actually developing and using a new platform. And so I try and refocus what they're talking about in terms of what their actual problems are. So I have a developer efficiency problem, and therefore I want to move to a new platform. And so I even take Kubernetes out of the story. Well, Kubernetes might be the valid answer for them. I try and just focus on what their actual problems are first, right? So developer efficiency. A lot of people say productivity, but I feel that kind of has a connotation that developers are lazy, which is true, but we shouldn't really point it out to their faces. So developer efficiency, operations complexity, security and patching problem, I have a toil problem. And I think this is the one I always try and end up on, because it's really toil that is the issue here. And toil is the thing that's stopping you from getting value, adding value to the business. It's a thing that really stops you from getting from an idea to code to running in production, because there's a lot of toil involved in doing that. So you don't have a platform problem. You have a toil problem. You have a problem with just tons of added extra work involved in getting from code to production. That being said, I've said you don't have a platform problem, but here we are, and we're going to talk about platforms. So my name is Paul Tchaikovsky, and I should have introduced myself by now already. And I'm a developer advocate at Pivotal Software. That's a little bit weird, because I'm not a developer. I come from an operations background. I think I'm supposed to call myself a devop these days, but I never really got into that as a title. But I've spent most of a lot of my career building platforms and helping people use platforms rather than using them myself, and often actually failing to build platforms. That was a big part of my life as well, failing to do it. So I've learned some things, and I like to share some things. I have some opinions. So we're going to talk about platforms, like what a platform is, the various archetypes platforms, what we have in the Cloud Foundry community, and also maybe a little bit of what's outside of it. Trying to make some sense of it. I assume everyone here has a basic understanding of the major archetypes, container platform versus application platform, et cetera. But we'll talk about what platforms to use for what maybe. We might talk about in what order should you adopt them if you're at a large enterprise, and you've got a lot of people and too much work to really just drop everything and go full on. And we'll talk a little bit about some digital transformation and DevOps concepts, because it turns out just having a platform doesn't actually help you. You've actually got to use it and use it properly. So that's the goal, and we'll see what we get through. So what is a platform? It is a wall of text. Who cares? Let's just keep it simple. So a platform is the environment in which a piece of software is executed, and they abstract away complexity to provide a simpler interface to that execution environment. Different platforms behave differently and have different target users in mind. So you've got, like, Cloud Foundry is really a developer-focused platform. So the abstraction is focused on the developer. Whereas Kubernetes is more towards being an operator platform, so it's a lot of its abstractions are focused towards the operator and running systems rather than running apps. Very quickly, in the 2018 State of DevOps report, they actually mentioned platform as a service as something that is an indicator of very high-performing groups. So while a platform won't magically make you a high-performing company, it's certainly going to help enable those who are on their way to be coming that. So really, that goes for any of these platforms when they use in the correct way. Generally speaking, a modern software platform provides a RESTful API, and that drives compute resources, CPU, memory, disk, network. It looks like this. Every platform looks like this. Cloud Foundry, Kubernetes, and Amazon Web Services. You've got an API, and that drives some sort of workers which then drives your actual physical compute resources or virtual compute resources to create an execution environment for your code to run in. My friend Gabe at Microsoft has said that every IT team is a platform team, and that's kind of true because as an IT group, my job is to run software on servers, and a platform's job is to run software on servers. So we have the same goals, and so as an IT group, we're empowering ourselves by using platforms that help us do our jobs and help our developers have less toil and have less toil ourselves. Technically, as an IT group, you are a platform. So JIRA is your API, and you're the workers, and so your ticket comes in. As a security engineer, you consume that ticket, you do a bunch of work through SSH or whatever, and it's done. But that's pretty inefficient. That's what we call a meat cloud or a cloud made out of people, and it's not great, and it kind of looks like this. It's this massive burning oil fire, and it's all you can do to try and contain it, but it's going to keep burning until all the oil runs out, and there's some dude under these squirting more oil up into the fire. So it's a fight you're never going to win, and so this is where you need to do things like digital transformation. You need to start adopting DevOps processes to split people away to start focusing on building new platforms, utilizing new platforms, new processes, et cetera, so that you can slowly move things away from being on this burning platform that is probably never going to get better, but you can slowly pull pieces of fuel away until there's no more fuel for it to burn. So we kind of have these major archetypes of platforms, from the hardware platform, which I just described, which is just a bunch of people, all the way up to Cloud Foundry, our application platform, or our function platform, and basically you have this control versus toil thing. So at the far end of it, the right hand side, you've got a lot of toil, but you're also have a ton of control. You can run any kind of app you want on a bare metal server, whereas as you come towards the left here, the right, your right, I should say, you're giving up control, but you're gaining efficiency. So if you go all the way to say, well, if you're doing your application platform, you're writing 12-factor-ish apps, so you're writing very opinionated apps in order for them to function correctly inside of that platform. You had that push and pull of control versus efficiency, and so not every app is going to run in a function platform, like a serverless platform, right? And so you have to figure out where in that control versus toil area you need to focus at running a given app, and every app is going to be a little bit different. The platforms kind of build on, I mean, good platforms are like onions or ogres, right? They have layers, and they build on top of each other. When Google created their Google Kubernetes engine, they didn't create a new IaaS. They used their Google Compute IaaS and laid on top of it, right? And so when you're building platforms or looking for platforms, you want the platforms that just focus at one area of the layers and don't try and blur the boundaries, and they build on top of them. So don't try and reinvent the entire thing. There's a ton of platforms at each layer more than I can talk about and more than I really care about, so I'm going to focus on the things that the Cloud Foundry Foundation and Pivotal bring to the table. And so you kind of have Bosch as this delineating mark of above the infrastructure and below the infrastructure. So below the infrastructure, I mean, yes, they're platforms, but either you should have a cloud provider run it or you should have an infrastructure team run it. And you use Bosch as the delineation to then say, OK, these are the platforms that we're really going to focus our end users at, because these are the ones that are going to provide the efficiency. And having Bosch as that installer and guideline also means that we have a lot of choices around the actual infrastructure platform that we use. I'm sure you've all seen this from ONSI from three years ago. I think it was a CF push high queue. And this kind of really demonstrates that toil aspect of how much work you have to do to deploy an application in Cloud Foundry. So here's my source code, run it on the cloud for me. I don't care how. So clearly, I don't have to do a ton of work, but also I don't have an opinion. So I have to do it however the Cloud or however Cloud Foundry wants me to do it. Whereas with Kubernetes, it's kind of a longer poem. Here's my source code. I built it into a container just now. Please run it for me. This jammer will tell you how. So clearly, I have to build an image. And I have to provide some form of instructions. And then Kubernetes will run it for me. So that's definitely more toil. But it's also giving me more control because I have a deployment manifest which is telling Kubernetes how to run it for me. It's kind of a way to compare them. And then serverless, here's a function. Just run it every time you see an event. And that's not entirely accurate because the function or serverless stuff is so new. You just give them your source code or just a snippet of function. Some you will actually have to build a container and ship it up there. So the toil involved in serverless is not quite settled yet. But I don't think, apart from a few unicorns, not a lot of us are actually using serverless yet anyway. So obviously, Cloud Foundry Foundation and Pivotal are around. And we kind of have an opinionated set of platforms. Originally, we had just Cloud Foundry. The changing landscape said to us, hey, you need more than that. So the Cloud Foundry Container Runtime was born. And then Pivotal PKS, the Kubernetes service wrapped around that was born. And then there's also the function stuff, so RIF and Kn8, et cetera, sort of bubbling up. And we'll see some sort of Pivotal service around that at some point. And then Pivotal also brings this services marketplace, which kind of brings the ability to run databases and some other shared services. And then they're kind of like a loosely-coupled group of platforms. So you can have one of them, you can have all of them. But they're loosely-coupled in the fact they share some services. They share some networking. They share security models. They share networking, et cetera. And they're all kind of installed and managed by Bosch. And Pivotal adds a bunch of day-to-operations to doing it. But it's all available open source as well, so you don't need to pay Pivotal money if you don't want to. And also, Bosch allows you to then run it on pretty much any cloud you want. And so with sort of Cloud Foundry and Bosch and Pivotal taking on a lot of that operational burden, it allows you to focus on adding value to the business and figuring out where to run what apps to bring the most value to make that app as efficient as it can in the state it's in. And you can talk about, should I modernize the app? Should I lift and shift it? And that'll help shape your decision on which of the platforms you're going to run it on. And then where are you going to get value out of running it? So where do we start? A lot of folks are still at that. I basically still just have VMware. So not VMware, I still just have hardware or VMware, but I'm not really managing it in any major way. And so I'm still the cloud. I'm still the meat cloud, right? And so I try to talk to them about how we can start adopting the different platforms in a way that makes sense across the business. Folks like across the business should still be experimenting with all levels of platforms inside Cloud Foundry and out, because that's how you learn how you move to new things. But as a business, you need to make some decisions about where you're going to be focusing. And so I have some thoughts around that. Obviously, you have hardware or you have some sort of unmanaged VM infrastructure, KVM or basic VMware or something like that. And there's a good chance you're still going to have hardware around at the end of this unless you're pushing everything to the cloud, which is another big ball of wax problem that may or may not be a good idea depending on your company. But you're still going to probably have hardware. So if you're old enough, you're going to have some mainframes lying around. And you're probably not going to push your cobalt up to Amazon's Lambda service anytime soon. You're going to have large storage clusters like Ceph, HDFS. You're going to have databases like MS SQL, Oracle Rack clusters, stuff like that that you're not going to move them up to a platform anytime soon either. So there's plenty of reasons to have hardware around. You can get better and smarter at running that hardware, utilizing config management, and some of the other stuff that we sort of developed in the new cloud world that work really well on bare metal hardware as well. So you can still be improving that side of things. And you've still got to run VMware or something locally anyway if you want to start running other platforms. And then, of course, you've got some sort of software as a service. So it's kind of a level of abstraction. It may not be a platform itself, but it's good to have that, like Concur, GitHub, Salesforce, all that sort of stuff. You wouldn't gain any value of trying to run Salesforce locally if you could, which you can't. But there would be no reason to do that. So think about strategically grow your SaaS usage based on commoditized services that doesn't make a lot of sense for you to run. And then, which platform do you actually start adopting? I usually recommend you kind of jump to both an application platform and an infrastructure platform. So VMware, managed by Bosch, kind of counts as an infrastructure platform. And then Cloud Foundry or Amazon or Google Compute as your infrastructure platform. And Cloud Foundry is your application platform. And there's a few reasons for that. Obviously, almost any application platform requires an infrastructure platform to run on. Cloud Foundry certainly does. So you're going to need that anyway. But also, they do have that different focus at different users. So your application focus is definitely focused at your application developers. And your infrastructure platform is really focused at your operators, your sysadmin, your devopses, et cetera. So at the very least, you're taking any new and maybe some modernized apps. And you're pushing them up to Cloud Foundry, your application platform. And then you're also at the operations level. You're retooling, going from run books in wiki pages to infrastructure as code, using Terraform, config management, using Chef, whatever, to start making your infrastructure platform really strong and really getting use out of that and reducing the toil of requesting hardware and getting at least basic software installed and running. And developers should also be sopping from SCP and JAR files around or even worse practices and being able to do a CF push type workflow. And you're probably also going to move to modern languages and frameworks at the same time. So you'll get more Golang. You'll get more spring boot. You'll do some reactive stuff. So you're going to spend some time here, because not only are you doing that, but you also need to start thinking about building a support platform, or I like to call it an SRE platform. And that's where you've got a bunch of communal tooling that your operations teams and your developer teams will use for monitoring, logging, telemetry, access control, event queues, stuff like that, even credential management, password management, secret management, all that sort of stuff. And so Prometheus, Sensu, Bastion servers, OAuth servers, and all that sort of stuff will build out to be an SRE platform off to the side that help provide the tooling to your operators, developers, and also endpoints for your other platforms to send logs, monitoring, that sort of stuff. And don't be afraid to use SaaS services for that. So if you're not very good at monitoring, get Datadog or one of those external SaaS companies to help you out, because they're probably much better at running monitoring infrastructure than you are. So if you're willing to pay the price that they charge, because you'd rather focus on other value-added things, then that's definitely a good thing to look at. So don't feel like you have to run any or all of this yourself. It just depends on what comfort level you are at getting partners in to help you do that sort of thing. And then we all know now that the world is moving to containers. Any platforms we're adopting for this foreseeable future will be container-based. And so start thinking about containers for basically all levels of your infrastructure, applications in your platforms, because they're a good general solution for that build, package, ship, and run. And of course, do it where it makes sense. So don't start running all your MySQL servers in containers. But you're going to have a lot of applications that may not go into Cloud Foundry, but are still going to be really good for running in containers. And running containers, say, on VMs or on bare metal, are still going to get you to start exercising those muscles and learning how to actually operationalize containers and figure out how you get logging and monitoring and stuff from containers. So it's worthwhile doing. And if you're using config management, which you should for your VMs, hardware, and stuff, it's just as easy to grab, download, and run a Docker image as it is an app package or a JAR file. So you might as well start doing that and have that kind of unified build package ship run sort of tooling. And then if you want that, then obviously you need to have some sort of image Docker registry as part of your SRE platform. So something like one of the enterprise ones, like Harbor or Quay, they do not just the registry, but they also do security scanning, allow for signing of images and stuff like that, which is important because if we don't bring security into doing this with us, they're going to remain that sort of the folks at the end that just always say no to us. So we want to drag them in to be part of this process with us. And then as well as the SRE platform, you should be building some sort of continuous integration. Hopefully you already have this stuff, but you should be like solidifying it and building it as like a communal set of tooling that anyone that deploys applications in your oil can start to use. And so really it's going to become part of your SRE platform or whatever you call it. But I'm calling it separately just to make sure it's called out. So you're going to have a tool like Concourse or Jenkins and it's going to run tests and build artifacts every time you make a code change. And also every time you make changes to your infrastructure's code or your config management. Because remember we have a bunch of different platforms we're dealing with here. And these tests, again, should include security and compliance testing, as well as your unit test code coverage and stuff. Because again, it's important to bring security into the conversation and start talking about DevSecOps or whatever it is you need to talk about to get them involved, because the further left we take them in the development process, the more integrated they're going to be. And the more secure your software is going to be. And also the less they'll be saying no right at the end when you're trying to get a last minute deploy out. And you can't really do effective continuous delivery or continuous deployment unless security is actually involved in that pipeline. And so once you've got CI under control, you can start looking at continuous delivery. You can use the same tool as CI, or you can use a more continuous delivery tool like Spinnaker. And again, changes, either code or config management, should be deployable to any environment at the press of a button. And then based on your confidence in what you're doing, on the risk you're willing to accept for the individual apps, you can then automate that entire thing. So it's continual deployment. But eventually you want to get things to continual deployment, but just getting things to the point where you can deliver code to production any time you press a button is a very big step. And that's super important. And then so yeah, and so now you have CI and CD. So every new app and every map, every app you modernize to one of your new platforms, you should put through some sort of pipeline that is basically you put code in and you get a running application out the other side. There's some example tools up along the pipeline, but use whatever you feel you need. And then you've got that sort of force it at the end. So if you want to do continuous deployment and let it deploy itself, go for it. Otherwise you can have a human actually as the gate to press the button to do the deployment. Again, based on just your confidence in your automation, the risk you're willing to accept, the type of compliance you're under for the type of industry you're in, that sort of stuff. So you've got a good handle now on your infrastructure platform and your application platform. So like VMware or Amazon and your Cloud Foundry. You've got more applications running on those than not. At least all your new applications are going towards them. And everything you've got more stuff going through CI CD than not. You can start looking at the next platform, which I think is your container orchestrator or container platform. And that's probably gonna be Kubernetes as that's winning the container wars. And again, so it's again, back to being kind of an operator play. So you can have operators basically building manifests, helm charts, and maybe even Kubernetes operators to run and manage services inside of Kubernetes to make it really easy to, like if you need an elastic search cluster or a Cassandra cluster for an app, you might want to run those in Kubernetes and have a fairly easy way to deploy those anytime a new app is deployed that needs those things. And then as well as that, it gives you a good opportunity to start looking at lift and shifting some of your legacy applications that aren't 12 factor and are probably never gonna be 12 factor, but are still reasonably able to be containerized and deployed in a container orchestrator. I know I can run any old garbage in a container platform. Maybe I shouldn't run all kinds of garbage in one, but I can. And so you're gonna play that like, is it worth moving? Like what's the value of the app and stuff? And there's like a bunch of methodologies around doing that. There's the Gartner time methodology where you basically look at the technical quality of the app versus the business value of the app. And you put it on a plot graph and based on where it is, you're like, I'm gonna modernize it. I'm gonna just leave it as it is. I'm gonna lift and shift it or whatever. And so that's a really good way of determining where you should be running your apps. So that's, okay, now you've got a container platform. You're starting to use it. And then you can really start looking at your serverless or function platform. And that's where you're now doing event-driven functions that are tied together with some sort of business logic. You've got an event queue and the business logic managing how information flows between different functions or serverless apps. And so that's a fairly large leap. And not every app is gonna be good at running in that way. And so don't rush into trying to do serverless. Like if you have a couple of teams that are like real unicorn teams, throw them on, like send them out to Lambda and start doing stuff there, but don't make it a business focus. Because the initial business value is all gonna be at the infrastructure platform and application platform if you're still fairly getting started. And then so there's no point having a platform. Like there's no point just deploying a bunch of platforms and like going, okay, we're done, right? You actually have to use those platforms and use them effectively. And so you need to go through some sort of digital transformation. You don't need to start adopting a DevOps culture. And it's hard, it's a lot of work and it is gonna get worse before it gets better. So this is the J curve of transformation from the state of DevOps report, which is by Dr. Nicole Forsgrim and her co-authors. And you can see clearly here, you have some early wins and things look good. And then you start trying to push it across like a larger array of applications and stuff and it gets quite difficult. You've got a lot of issues with writing a lot more tests. So you have to get those tests written. You've got a lot of technical debt to deal with, et cetera. But eventually, if you stick with it, you climb out of that sort of that trough and you start to actually really receive the value. And so you'll start to see the return. But you need to actually make sure you are getting that return. So you need to be measuring things, which means you need to actually figure out what you're trying to achieve with your platform and with your digital transformation. So DBS Bank is the largest bank in Southeast Asia. And that spring one platform just a couple of weeks ago, Sue choose so, I hope I said that right. We talked about their digital transformation. The URL for the talk is up there. And it was really, really, really good talk. I think it was probably the best of the keynotes of the whole event. And she kind of had this slide, which was about setting their goals. So they had goals around like agility, user experience, so like the usability of their applications, the quality, so like security, controls, and then developer productivity or developer efficiency, as I would prefer to say. So they had these goals in mind. And then so they then would figure out ways to measure for these things. So as they started replatforming, as they started going through the digital transformation, they could see that they were actually getting value, they were actually getting a return on the investment that we're putting into this. You certainly don't do this to save money, especially not at first. Platforms are not cheap either through licensing or through just sheer people time. And so don't think you're gonna adopt a platform like in six months time be saving money. Maybe in a couple of years time when things are really rock solid on it, you'll be saving money, but certainly not initially. And then of course, the second word in digital transformation is transformations. You have to actually change. And you kind of need to almost rebuild your organization, focused around the contracts and abstractions that you want your platforms to rely on to be around, right? And then you're gonna build engineering teams at each of these levels and get out of their way and let them engineer. And then those folks, you want them to basically build a paved road that your app development teams can follow that road and get services like logging and monitoring, telemetry and whatever. And basically that helps remove that whole thing of shadow IT. If your platform is the best option, they're not gonna try and go and use their corporate credit card to use something else. But you also need to let them do other things as well. Like if they wanna build an experiment outside of this set of platforms you've built, you should let them, they just lose access to this paved road and they lose access to all these things that you're doing for them. And so it's in their best interest to follow that paved road. And that's kind of the Netflix model. They're allowed to do whatever the hell they want, but most people at Netflix follow that paved road and use like Spinnaker and use all of the tooling involved in that to stick with there and get kind of all that really good stuff for free. Yeah, and so you're gonna change your business. You're gonna, like a pivotal, we've seen a lot of success where we have like build an infrastructure team that are really focused on your infrastructure and are building some form of API layers or whatever up to the rest of the business. And then you have a platform team that utilize that to start to build out your platforms. But also to build out your shared services, like your SOE platform like I was talking about. So like messaging, credentials, certificates, secrets, middleware, all that sort of stuff. A platform team sort of takes on that and builds abstractions for those things for the actual developers to do. So the developers are just focused on like taking an idea, putting into code and getting that shipped to production without having to worry about all those extra things. And so you sort of build teams around that rather than just having like one big IT group, one big whatever group. And that has worked really well with us working with some of our customers and whatnot. And then as you start adopting platforms, you always wanna have an eye to moving things up the stack. Like strategically, the further up the stack, the more efficiency you get out of it and therefore the more value you get out of it. So as you're going through, you kind of have your current state, you have a future state. Start thinking about like what percentage of what types of apps you want running where. And you're gonna do that based on the value they're bringing to the business, their technical quality and a bunch of other stuff. Obviously new apps should immediately go straight to either the application platform cloud foundry or if you have one already a serverless platform. And then as you like start lifting, shifting apps up the stack, start modernizing apps up the stack and start moving things up the stack. So you have as little as possible running in the hardware and infrastructure platforms. You can also look at like what technologies you're using for a given app now versus what do I wanna use on them. So like I have a bunch of web logic and web sphere stuff. That's probably gonna be pretty good to run in cloud foundry, right? Whereas if you have like some all the stuff that's being managed by like Chef or Puppet, that might be a really good target to look at your container platform. So it's another way of taking, kind of looking at your apps and sort of doing a gut check of like what platform might this best run on. Back to DBS Bank. Like you can adopt a platform and you can start to get value from that fairly quickly. But your actual true digital transformation to get your entire organization getting that value is gonna take some time. DBS Bank took like four years to get from where they were to like where they are now which is, you know, they're really using cloud foundry in a really good way. They're doing a lot of CI CD. But it's like, there's no end to this. The whole thing is like it's all about continuous improvement. So it's not like you're like, okay, I've installed cloud foundry. I'm using a CI CD platform, I'm done. There's always some room to improve, right? But you do certainly have like a, I'm really bad at this, so I'm pretty good at this as a boxed out time. Turns out it took about four years for DBS. But they're a very large bank, you know, heavily regulated industry. So it would make sense that it would take longer for them than maybe someone of a smaller business or a less regulated business. So you might be able to get a fair chunk of the way through a digital transformation in a year or two or even less if you're a fairly small organization. And then if you use utilize tooling and partners to help you build and run platforms and help you learn how to actually write software and modernize software to use that platforms, that will just help to accelerate you as well. Digital transformation does provide proven ROI. Pivotal has any number of anecdotes we can tell you about customers and people that we've helped sort of go through digital transformation, start doing, you know, cloud native development and the returns they're getting from that and the values they've gotten from that. If you read Accelerate by, again, by Dr. Nicole Forsgrim and her co-authors, the DevOps, the yearly DevOps report, and there's another, a lot of other places that give good solid anecdotes on people that have gone through some sort of, you know, DevOps culture shift or digital transformation and have proven like business like value out of it has proven that it's actually increased their bottom line and they're actually, you know, making more money because they've gone through such a transformation. At Pivotal, so you wanna like measure these things and you wanna actually graph these things. So before you even start replatforming an application, you wanna measure where it's at and then watch what happens to those measurements as you replatform, as you modernize and as you optimize them for a given platform. At Pivotal, we talk about the five S's, so like security, speed, scalability, stability and savings. And so if you're mapping all of those things for your apps, you'll, as you start to replatform them and modernize them, you'll definitely see improvements there. If you don't, then stop and focus on another app, right? You do wanna get some early wins and you really wanna show this value to the business because that's how you get the rest of the business to adopt it because generally speaking, like the digital transformation will start, especially in a large org, will start in like one group, right? And then you need to get people above you, directors, people at the C level to become like evangelists and advocates for the way you're doing that things. And the way you do that is you prove to them that you're actually making the money, right? Not just saving the money, but actually making the money. And then they'll very quickly say to the rest of the organization, hey, you all need to get on this train and you all need to do that. So measure it, create objectives and measure those measurements against the objectives and prove that you're actually creating that value and adding that value. So that is it. How are we doing for time? We probably have time for questions and answers. So if we do have questions, we have a mic. If we don't have questions, we can break for coffee or hang out or do whatever.