 All right, good afternoon, everybody. My name is Kyle Campos. I am the Enterprise DevOps and Platform Leader at CSA Insurance. We are a 100-year-old company insurance provider for AAA. I am a frustrated but hopeful cloud leader inside of a large enterprise. Our journey inside of Cloud Foundry actually came out of the frustration of change management to a large degree. It was extremely painful to get infrastructure. It was extremely painful once you had that infrastructure to get your code on it. So really, it was a engineering revolt that started Cloud Foundry at CSA that got it in there. So I know we all have different experiences with ITSM. Some of these are obviously going to be my experiences. I know they are to a large degree shared experiences. Some of the details might, you might have optimized some areas where we haven't, and that's great. But hopefully at the end of this, we can see that we have different delivery models and where we can align, we should. Where we can optimize one or the other, we should. But at the end of the goal, I'm here to talk about injecting value around fast delivery and inverting that risk, speed, fear that currently exists in large enterprises around ITSM. So when I set some definitions to, when I refer to our legacy ops environment, that is very low levels of automation, low to none, and extremely high levels of control. So friction everywhere at every turn. So I can start with, I'm focusing on change management for ITSM. So if I pull up the ITIL definition, the goal of change management processes is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes in order to minimize the impact of change-related incidents upon service quality and consequently improve the day-to-day operations of the organization. So just definition-wise, I'm like, I'm aligned. I'm with you. Like, those outcomes sound great, and we're in full alignment. The trick is, when you extract those words efficient and prompt, I look at what's happening in our legacy ops stack. I look at what's happening in our Cloud Foundry stack, and you can't help but think that those words mean entirely different things to each side of that organization. So we have to kind of tear that back a little bit and say, OK, well, what are the attributes of those methods and procedures in the legacy ops stack versus Cloud Foundry continuous delivery stack? So what I've found is, in the ITSM world, the methods and procedures are traditionally expressed through documentation primarily. The ownership is through governance boards, quite large ones, depending on the size of your enterprise. And the focus tends to be lowest common denominator or slowest common denominator. It has to account for everything. So whatever crazy app team did something 20 years and it's insanely complex, the process has to bend to that. It's measured by compliance. That's kind of its primary focus. Just as long as you do what we say, you're good. Some of the smells here, if you're like, I think I'm in that world, accountability is more highly valued than determinism. So at any point in the process, they feel like there's somebody accountable for that. It doesn't matter in what form they bring that accountability, just as long as they have a name or a team. That's all that matters. And I'm not saying accountability doesn't matter. I'm just saying that it tends to matter the most here. Over time, delivery slows just by nature as more teams come into the process, as you get more applications, governance boards increase, processes increase. So meetings in human touch point tend to increase over time. In continuous delivery models, the methods and procedures tend to be expressed through code, or they should be expressed through code. The ownership should be in the delivery team's hands. The focus should be acceleration, and you measure it by performance. Some of the fruits that start to come out here is that determinism is more important than accountability. So how you get to that decision is more important than who's the name, who can I blame if it goes wrong. I assume most of you have experience in this world. You'll know that a lot of the decisions, approvals are left up to people's whims. They have no idea what this change is about, but they will be accountable because they hit the approve button. So here we wanna inject determinism into how we deliver software. And over time, the delivery should get faster. If the focus is acceleration, we're always looking to optimize speed. And then pipelines increase and human touch point decreases over time. So when you're continuously delivering anywhere a human comes into contact with it, sticks out like a sore thumb, right? And it's a target too for optimization. If we take the same approach here, old and new against efficient and prompt, what are some of the characteristics here? So efficiency, the aim tends to be process refinements. Like that's how you squeeze out efficiency in ITSM. Like, okay, we had five dropdowns on this first ticket. Maybe we'd take it down to four. That's primarily where the process refinements come in. And then the vehicle is training, right? Get people into more training. Let them learn the new processes. It's measured by traceability. Is there other breadcrumbs at every step? The smells here is traceability first. Just as long as you know what happened, it tends to be good enough for efficiency's sake. And then what you run into is that the process, it gets gained to gain efficiency, right? So people naturally feel frustrated that there are changes in getting through in time. And there's all sorts of crafty methods, people gain that system by, whether it's how you get a change approved, whether it's how many changes you shove into some approval form, right? Like, okay, well, if I do one request with 50 things and then I'm gonna get that through faster than I can, I had 50 different releases. There's a very high tolerance towards wasted effort, right? I've been in deployment meetings with literally 100 people on the phone and nobody is embarrassed by that. And I'm embarrassed and nobody's embarrassed. And I'm like, we should all be shocked right now that this is what it's taking. And it creates specialized workforces, right? So there's teams that exist solely to help people navigate that complexity, right? In the new model, the aim is higher quality on time software, full stop. Our vehicle to get there is through automation. We measure it by delivery KPIs. And repeatability first is one of the main fruits, right? It isn't just get it through at all costs and then we celebrate, it's what you've done repeatable and then namely through pipelining, right? The pipeline in this case is the most efficient way to get it to prod. So whereas in ITSM, you're frequently gaming it to get things going faster in continuous delivery, your pipeline is the best way to get there, right? There's no faster way to get it into prod or better way, I should say, faster and better. There might be a faster way, but not a safe way. And in the pipeline world, there's really low tolerance for wasted effort, right? Where you see it, it sticks out and you attack it. And there's team ownership on these pipelines because it's a cross-functional pipeline, right? You're taking it from an engineer's hands and laptop into production and depending on your gates and all the quality and security and performance stuff you have to do, there's a lot of people that are contributing to that pipeline and they have to feel a sense of ownership over it. They have their own KPIs for their boxes along that pipeline and how efficient they run. All right, the illusion. So here's some of the illusions we fall under and inside of ITSM. You get the sense that there's safety and complexity, right? There's this feeling like the harder we make this process, the more people that are involved, the more steps that are involved, it must be injecting safety because there's just so many checkpoints, right? But most of those or many of them tend to be arbitrary. They're non-deterministic. So it's mostly in many cases a facade. Another illusion is that approval is the same thing as accountability. I have conversations probably every week with some other vice president who says, I just keep clicking approve on these things. I have no idea what they are, right? And they're frustrated and they want somebody else on their team to just keep clicking approve. So approval really at the end of the day when you look at changes, there may be one person there that had any idea in that chain of what this change was. The other illusion and it's sort of this false dichotomy that gets set up on the ITSM side, right? Is that if you're going fast, it must be reckless. So I'm here to talk on a third way that is fast and not reckless, fast and safe. The way I kind of explained this landscape for getting software into production is this, this dangerous road off in the horizon there if we imagine off in the valley is where we're gonna start with a code commit and up here are heavenly production on the top of that we ascend the mountain. So many turns, right? We start with a code commit and then our first sort of junction point if we're being good stewards here is that you have some measure of testing that's gonna happen, right? And after that, you gotta make another turn at process. You gotta make a change request with whatever that artifact is and whenever the change logs are. And then that's gotta go through some set of approvals however many it takes to get through your organization. Then you gotta open up a change window when's this gonna happen, right? And then you do the change and then you gotta wrangle another group of people that are gonna come back around and validate the change and say everything that's right, you didn't break the 60 other teams in your company. This is a very generous view. I'm gonna say, we'll say success at that point. That's a very generous amount of steps there. But congrats, you got it into one environment, right? Okay, now go ahead and repeat all of that for your test environments. You're gonna have to cross the bridge of real data which is always a harrowing effort. However many pre-prod environments you may have and then eventually you get it into production, right? And so ITSM overlords will kind of show these huge process maps and say like, yeah, that's it. By the way, you have to drive that road with like the junkiest beat up old car that you're gonna hate. It's really uncomfortable and annoying. And you start complaining enough about that and they're like, okay, we'll optimize a little bit. And then they're like, we got a newer car for you to take all the same turns. You gotta do all the same process bits, right? Nothing is substantively changed with the process. You might, maybe a little more comfortable. We took a few radio buttons away. The approval list is from 30 to 25, whatever it may be, right? And then we come along with Cloud Foundry and we try to explain that there's a paradigm shift, right? Now I have a cable car that goes from the bottom straight to the top of that mountain. It's repeatable. It's the same journey every time, right? I don't have to make those turns. I don't have to stop at that stop light. I don't have to look both ways here or there, right? You're still gonna get the questions. Okay, great. They'll say, I understand you have this whole fancy thing out there, but you still have a driver's license, right? And you're gonna still obey all my rules and you kind of give them, no. That's not exactly what I'm talking about here. So then we get into the paradigm shift and how we explain this. And by the way, just as encouragement, this will be, if you're involved with this now, this will be, you'll have this conversation many, many, many times and you'll win it and then you're gonna have to win it again in two weeks. And so that's the frustrated part of me, but I'm remaining hopeful here. So in the old ITSM, right? Change request is out of band. It's never, it's not event-driven. You've done a bunch of things and then you gotta generate this request. The approval, as we've talked about, it's broad and it's arbitrary. The change windows are very often coordinated and they're static, right? They're either a set window you have or it's a unique one-time window that you set. The change is unique, non-item potent, right? So if you were to do it again, you'd have to do all the stuff again each way, even though if it's a scripted or a standard change set that you have in your process, it's essentially a unique event each time. And the change validation is unique to the change type, right? So you're like, oh, I think I might have messed up group X over there, so get them in here. And the larger point here is that the posture is that the more times you do this, the more operational risk you're adding, right? So everybody's just terrified of you doing the process, the terrible process that they set up. Like, please don't do this. The more times you deploy, the more operational risks there are. In the new, we're saying change requests are event-driven, right? They happen the moment, packages made perhaps, or once your tests say that it can be deployed, right? It's as soon as it needs to. The approval should be deterministic and automated. So when I was doing this change, I would, for our products, I'd look at that approval list, I'd go to each one of them and I'd say, you approve this, what do you need to know about when we're deploying this app for you to say it's good? And they're like, I don't even care, I just always hit approve. So I'm like, okay, you're out of the list. And just one by one, go down. And I honestly, in this case, found exactly zero people that cared for whenever we deployed this. They had no dependency chain to it, not a care in the world. So in their case, it's only our, in this one app's case, it's only our test that matter. But there's certainly room for external dependencies and automation that you can weave in there. And we have that for some of our applications. But the point being, get determinism into that. Like what is the, what needs to light up green for you to be happy that it can go? That change window is encapsulated in dynamic, right? So it's, since we're event driven, the deploy will happen once all the tests say is safe. And then the change window is as small as it needs to be for that change to happen. And obviously with Cloud Foundry, we have a lot of great ways of doing zero downtime deployments, right? Change should be uniform and not impotent, right? So part of this being the nature of immutable software, the other part of it being that you have great pipelines. And again, change validation, we build that into your blue-green deployment, right? So if we have some fear that production is significantly different than staging or your pre-prod environments, which in most enterprises, there's always some measure of surprise. You can build in all types of safety mechanisms into your blue-green deployment, cut over traffic slowly, you know, the Netflix model, you can carry stuff, whatever you need to do in production. But the point is I don't want anybody calling my team to say stay up at 1 a.m. and go tell us if this is broken. We want the robots to do that. And then here, the posture is, change reduces operational risk, right? So we're trying to say the more times we do this, the better we get at it, the better our product is, the more value our customers receive on time. So we're really trying to invert that posture. So I talked a little bit about it performance being measured by KPIs. So there's a lot, obviously each, you know, if you kind of envision a massive pipeline, each job is gonna have its own runtime that you're gonna want those teams to be accountable to. But a macro KPI here for us is the time from the package build, so that the second something could possibly get to prod, to the time it actually lives in prod, what is the time difference between that? And on our most optimized pipeline, that time is 38 minutes, right? So we set baselines for each one of these products. So from the time engineer commands, all the tests runs, the package is built, typically takes about 38 minutes for that to go through all the different testing QA browser tests and API tests and security and performance and land up in production, right? And so for us, we're like that, that's pretty aren't great for us. Like 38 minutes is pretty fantastic. I don't know that we can do much better than that though we should try. Now for others, that is just mind blown. What are you doing? There's 38, when I show this at our QBRs, there's half the room that's like, oh, I wanna know how and the other room is just like pounding their head off the desk, like 38 minutes. And so they're like, Kyle, why are you not getting into the cab meeting for this stuff? And this is actually a real life conversation I had. I am on the board, I've just, haven't been in any of those meetings in a long time. So the big idea that I'm trying to get through here I guess is that undefployed code is at best a depreciating asset, right? Every minute delay from the time it could be deployed to the time it's in production decreases the value and increases the risk. You can ask any engineer, would you rather fix a problem you committed 38 minutes ago or one that you worked on three months ago? If they're still working there by the time it makes production which we've had examples of both, right? So risk in that sense from an application engineering sense also obviously from a security posture, right? So the security has done application developers the biggest favor here in stories like Equifax and such that were sort of frozen by change sets that were too big, they couldn't get through, couldn't update their web stacks. And now everybody learns from that. Oh, I guess it is a problem when you can't deploy at a moment's notice very quickly and safely to your environments, right? So the security story has helped us illuminate the application story here. So some takeaways here. I'm asking us Cloud Foundry evangelists here to really embrace the paradigm shift and to not shoehorn CF in as a step forward optimization. It's a new path. So the bait is for the legacy ops ITSM stack to just say like, hey, you're just another runtime, whatever, do everything the same. And we have to do the hard work to communicate the paradigm shift here. Otherwise you're not gonna reap all the benefits of the platform. And as good DevOps engineers, we need to use system thinking with the goal of continuous delivery into production as the framework through which you optimize. So if our mental framework is that pipeline from engineers hands into production and we use system thinking about how do we optimize that whole pipeline? Your considerations need to be for the performance of that entire pipeline like that KPI I showed. And not just, oh, the QA guys like to work this way. And so they take the football and they run away for a week and they come back or the security guys like to do the same and performance likes to do the same. And then four weeks later, we have a release optimize for continuous delivery in production. And the truth is we're beyond rejecting the false dichotomies and non-to-inverse relationships when I talked about speed and security. So the legacy mindset will be fast is reckless and we're not just saying it's a false dichotomy and they're disconnected. Or now we're on to actually saying, actually there's industry proof that it's the inverse of that. Being slow is reckless, right? If your whole business can vanish if you can't get fixes out at a moment's notice. We got to relentlessly hunt down in determinism, right? Where it exists, where people's whims are there, where it's a phone call, where it's a meeting, where it's people's hunches and fears, you got to drive that out of the room and certainly don't let it all into the pipeline. And time to market is a KPI for every change. Minimize depreciating assets in the form of undeployed code. So I mean frequently we use that KPI at a business abstract layer, right? This product, this big feature, but you really got to drive that down to every change. Like how are we treating every change as important to get into a product as soon as possible? Champion convention rather than chastise over compliance. So this is more of a culture awareness note for the two different models. Frequently the feeling in the legacy ops and ITSM stack is that you're just getting browbeat for compliance on the process, right? Regardless of if you're like, but I found a new efficiency or something like that. So champion the convention of your pipelines, right? And like I was talking about the pipelines, if it is the most efficient way, then you're just creating opportunity for application teams to leverage the most benefit, right? If you inherit this convention, your life will be so much easier. And the process should serve the outcome not the other way around. I'm really consistently amazed about how often you get into meetings and processes held up like this, just like unchangeable force in the room where the humans, we create these things, we shouldn't make them do what we want. And the outcomes are really an alignment opportunity. So as I engage with our ITSM partners, you know, I tell them like look, we want the same thing. We're gonna get there differently and where we can align on technology, let's do it, where we can talk together, where my robot can talk to your robot, let's do that, right? But let's align on the outcomes and not the how. So to wrap up, I think we just really need to leverage this paradigm shift as Cloud Foundry enthusiasts to establish that new organizational value structures around the speed of delivery. It takes a lot of work, a lot of repeated work, a lot of unfun work, but it's necessary. Don't let the legacy pressure of just another runtime pull you back into the land of illusion. Let's deliver fast, safe, and deliver value. And there's one last thing here before I close. I have change request 24, winging 79.68 for ending this presentation. If you could just approve that, I'll be done. There's my contact information. If you have any questions, I will be talking with Pivotal guys on a panel about Platform as a Product a little bit later. Yeah, I'll be hanging out. That's all, thanks.