 Hello, hello. Good afternoon, everybody. My name is Kyle Campos, and I'm the technology operations manager for our digital services organization inside of CSA. So CSA is an insurance provider for AAA inside of the United States, so we service millions of members across the United States. Today I'm focusing on the digital transformation story that we've had inside of CSA around Cloud Foundry. It's a crucial role in it. If you've been coming to CF Summits for any length of time, you've probably heard a lot of these different journey stories, like I had, and most of them were in the sort of top-down vein or in the top-down model where there was some C-level sponsored digital transformation effort, a lot of energy around ad-giling up the organization and the technologies around that, and whether that's a new organization spun up just to service that or a lot of money dedicated to it. And while those journeys were personally motivating, and it was very nice for me to hear, they weren't altogether that helpful for me and my organization, because it felt like the sort of unicorn story that I would die waiting for. So we took a different approach and said, how can we lead this transformation from the bottom up when there is no C-level project demanding it? So this is just a quick sort of context of where we started here. In 2012, Digital Services Organization was established. In 2013, there was transformation planning, and there's probably no more enterprise phrase than transformation planning. It just kind of sums up all that is wonderful about the enterprise. And then from 2014 to 2016, we were in this execution phase building, and then now we're kind of in this awkward year where some people say we're in innovate mode, and Digital Services says we never get out of transformation, that's just the way it is. So depending on who you ask, we're either innovating or transforming. It doesn't matter to me as long as we get to build stuff, as it all matters to me. So when Digital Services was formed, we started with creating the digital way, and that was, there were some early pivotal labs engagements that was really crucial in that. They helped us build a few products, incubated a few, handed some over. They helped us sort of build our agile transformation, how we work together, how we build products, that type of thing. And then while we were engaged in those, there was this sort of, hey, every time you guys are building something for us, you're able to deploy it very quickly and there was some interest on how are you able to do that, and that's where we sort of got introduced to Pivotal Club Foundry. So I was brought on to lead the DevOps transformation, digital transformation efforts, however you want to say it, and it was my third lift of this kind, and they're all uniquely painful and heavy to do. So I swore this would be my last one of these, and usually the first phase is just kind of like, all right, give me how bad are things right now? Like how painful is the world? So that was where I started out and it was really bad. There was pretty much nothing automated. The tech debt was just crushing. It was on that tipping scale where there's really no way to recover this. Silo's everywhere, of course. We were in the worst kind of ticketing hell. We had no insights to anything. It was very over the wall, just pray that it's working and that ops teams don't call you. And maybe worse, the worst aspect was that nobody, there was almost no one that believed it could be any different. And then the ones that did believe it could be different were either powerless or didn't have the insights or ability to help in any measurable way. So it was a rough starting point. So what did we do from there? So we started with insights. So first let's get some real automated metrics and analytics in showing us what's happening with our app so we can respond accordingly. We spent a bunch of time adding a lot of automated testing layers and improving our CI process. And then these insights helped sort of focus our attention by highlighting the pain points. Now we'll say in doing this, one of the main, particularly challenging aspects of being the sort of truth teller in that phase of transformation is that it's really, really difficult to get to draw that attention in a healthy way for the culture. So that it motivates the culture instead of sort of shames it or embitters it towards you. So there was a lot of this exposing the fact of how bad some application was currently running and then also sort of working with engineering and saying, all right, this isn't about trying to dig up the history of why things got to this place. We're a hundred year old insurance company. Nobody here working on these apps there. You can always point the finger at somebody else a generation ago that led to these sort of decisions of how you got there. So it's really focusing on how do we move forward today? What do we do to make the world a better place for ourselves? Another challenge that I ran into here which was a bit new for me here, as we had all these insights and then I started pitching the new world, what the new world would look like. I was met with a lot of disbelief. In fact, one of our IT leaders told me, which is kind of been a famous quote we've thrown around, which was, they said, the world you describe does not exist. And so I was kind of taken aback. I'm like, I promise you it does. Just believe me here and we can get there. So despite all that work, we still had our hands tied with no access to our infrastructure. We were still filing tickets for deploys, our feedback loops were really long. And beyond time constraints, there's a lot of just functional things that you're just blocked from doing in a ticketing, an enterprise ticketing mechanism. There's a lot of systems that if you want a new technology, you're going to have to wait a year to use Redis or whatever it may be. And so it's not just time. It's that you can't build apps the way you want to build them because you have to alter your behaviors to the current enterprise systems if you want to deploy anywhere near on time. So we started this sort of own the stack project, I guess you would call it. Nobody really knew what it meant. Nobody really knew the implications outside of digital services, but we had, we did have C-level support and saying, hey, if you've gone through the steps with the enterprise and they can't give you the service you're asking for, then go build it. You're telling me you can't do it, go do it. And so I think they might have met that more as a threat and we took it very much at their word and said, all right, well, we will do that. So we did do that. And our first take at it was Pivotal Cloud Foundry on premise. So that was, you know, it was great. Everyone's like, all right, this is wonderful. Everybody's motivated and excited. Let's go do this thing. We're working through all the enterprise processes for, you know, capacity planning, all that stuff. It's great. The deal is signed, you know, enterprise money, take it. It's no object. And then after the deal's signed, we find out, wait a minute, you guys are actually thinking of using this thing that we just spent a bunch of money on in prod. And so they're like, no, that's not going to happen, right? So, so needless to say, we're a little bummed out about that. This was not just a dev project for us to prove that we could deploy to our dev environments quickly. It made no difference, or it made a huge difference to us in that we didn't want a sort of the worst type of bimodal IT where we had this whole other process for getting to everything pre-prod and then we had to go hop over the wall and do something different for prod. There's no way we're going to do that. So take two. This is where it gets a little challenging. So we're trying to figure out how we get through this, right? How we navigate this problem. I had a lunch with one of my bosses and I said, hey, let's, we have this new opportunity with this application, which is Pivotal would help been incubating through a lab's engagement. It's cloud native already. It's using some technologies our enterprise cannot support. The type of data we're sharing is very, it's not risky data that we're using. Let me just go build this in the public cloud. And then we had some market pressure on timing for this product. Let's just go deploy PCF in public cloud. I'll say, ta-da, here's the app. Maybe they don't even really care. Let's find out. So we went and did that. And it was a great, fun time. Built some bright shiny new infrastructure within a week. We had PCF running in the public cloud. I mean, in our most successful enterprise version of this, it would take at least three months to even get development VMs. And from Duncan's earlier talk, I now found out he knows a story of 18 months for that. So I don't feel as bad. We're not the worst in that. So that was obviously world shifting there. We had our new cloud native app running. And then within a few more weeks, we had three foundations running, automated CI CD pipelines. We had monitoring across infrastructure and APM monitoring, centralized logging, all the goodness and most shocking engineering had access to it all, which was just sort of mind blowing and scary world for everybody to absorb. So we did it. We felt, all right, this app is working great. All the world that did not exist now exists. It's made manifest. And so everybody can see and enjoy. But then as we went and said, hey, a new app you were asking for is ready. Go ahead and just tell the customers to start using it. It's there. They're like, wait a minute. You put how? You guys never requested infrastructure. How did this happen? And we explained. And then they're like, you put this. That's not going to happen. You can't do that. And so now we're kind of back in a precarious situation. Take three. Now we're saying PCF, private cloud. This time we mean it. And you might be wondering, well, why would take three, succeed and take one doesn't? And this is where I think there's some valuable lessons learned for us. So first off, we punctured the disbelief. So there was that whole motto of it doesn't exist. And there's only so much that C level PowerPoint presentations and conference attending and sales pitches and all that type of stuff can do for you. At the end of the day, when you're dealing with a large enterprise that's had a legacy IT stack decades and decades old, there's always this enterprise snowflake effect where they're like, yeah, but there's something different about us. Either the market we serve, the type of applications we run, our history, our context, our business need, any of that. Pick your excuse as far as why it's different for our enterprise. And we had that in spades. So us being able to refer to real living reference architecture, well, now it's referenced because we couldn't let anybody use it, but it was intended to be used. We could say, look, we've done this work. We did that hard stuff that you didn't think could happen. But then I think more importantly, so with the hypotheticals were real, but it was a DevOps own platform. We built it. We were supporting it. We sponsored the processes all around it. And that's kind of where the frozen nature of enterprise IT comes in. On take one, we were asking them to shove this whole new platform, whole new way of thinking and approaching problems through existing legacy IT processes. And there was just, it was just a non-starter, right? They're like, I don't have a ticket form for that. I don't, I don't, there's no way I can do what you're asking. Now, on take three, they were partners, they were IAS partners for us, right? We're saying like, hey, what we're asking is for us to use your vSphere. And so now we had very specific asks for them, hey, partner with us, compare with us, and we're going to lead you through how to do this. And that partnership with our enterprise IT went amazingly well. And today, they're big fans of what we've done. And that's because we led, we were able to now be the experts leading them from inside through that process. So yeah, we had the expertise, we had the patterns and proof to drive it through. We also had a fair amount of market pressure, which was a great use to us to say like, this is getting done in a month. And let's, let's sit together and get it done. I talked a little bit already about that app, how it was well suited for PCF. But at the end of the day, our action and take two forced the conversation, right? Without doing that, this would have, PCF would have never happened for us. So this is what we ended up building. That's today that take three is alive today. We have PCF at the center. In this year, we've, we've replatformed all our flagship applications. So all our, all our flagship apps are running inside of PCF. We have concourse pipelines doing city, not just for applications, but also for infrastructure. We have a whole new host of characters involved in, in the quality testing through our pipelines, bunch of SaaS partners for monitoring as well as analytics. So it's a whole new digital platform. And that was helpful for us to sort of stand up, hey, there is the existing enterprise platform that there's the same solutions for monitoring and analytics and, and, and testing solutions. And then we have this new platform, a new digital platform, which is, it's helpful to draw a distinction, a line of distinction between the two. We don't have much overlap between the two lands except for V sphere itself. Some of the highlights, and this is actually some of this data comes from that VSM process that Duncan and Sean were talking about earlier. One of the challenges for us around VSM is some of the numbers are so high, you just want to arbitrarily bring them down for executives to believe it. Like, you know, this thing is like 50,000% better. And you're like, I don't know, just say it's 25,000. It's, it's, it's, we can, maybe they'll believe that. So over 205% improved dev productivity. So in the legacy stack, you know, most development time has spent debugging infrastructure issues chasing down why this doesn't work, why that request, you hit the wrong checkbox and you know, all that type of stuff. 1400, 1400% improved deployment frequency, 1600% patch frequency uptick. The dev to prod cycle almost taken down to infinity, infinity improvement. Same thing for the initial environment costs. So what that translates to in real numbers here is on our best days in our legacy stack, we're deploying once a week if everything went right. And now we have continuous deployment running in production and we deploy the production for each app around three times a day, depending on the app. That's a normal day. Our dev to prod cycle. So this is in our legacy environment, if we did a code push into dev and everything was green, how soon would that code arrive in production? Again, assuming the happy path, everything goes right. It was about eight days for us. And now once the, all the tests pass and they get into dev, that's like from there, it's about 20 minutes until it gets into production. The humans required for dev to prod. This is actually talking not about the initial environment setup because that's dozens and dozens of people over many months. This is like you already have your infrastructure and you're just trying to push some code up to the existing infrastructure. That would take four people on a phone to get it from dev to prod and depending on how many environments you have that you just multiply that across. And today our pipelines do all that. Patching frequency, that's a quarterly process in the legacy. And now we do that at least once a week. We do, we just recently with help from Pivotal got our repave pipelines down and continuous delivery for minor versions of PCF. So that's, we'll be, we rotate every day. And then we have the minor dot releases come out about once every week. Time to market. So that bottom four months was the last release we did on our legacy stack. So that's as fast as it's ever gone. And from the time we said we need some environments, it was four months until we got our dev development environment. Forget about production or anything else. The PCF story we share is that some engineers were sitting around talking about wouldn't be nice if we had an Alexa app integration with our policy app, which lets users manage their insurance policies. From the time that discussion happened, they're like let's try it tomorrow. I was two and a half days and we had a production app running that worked. You could link your policy to it and manage it over Alexa. So that's where that almost infinity decrease of time comes from. I couldn't even do apples to apples. Like to prod for our last one, I don't, I don't even know what it would have been. But it would have been much higher. There's also some, you know, infrastructure footprint comparisons, obviously moving to microservices and infrastructure utilization is much higher. Some lessons learned. I'll try to zoom through this here. So the enterprise IT steady state inertia is built of myopic disbelief, fear, and risk averse incentive. So what I'm trying to say there is there's a reason why this just machine moves the way it does. And for us to kind of we had to accept that fact and try and disrupt it. We couldn't ignore it or make fun of it. You have to, you have to get your arms around that and deal with it. And so, you know, our belief when we went to our take two public cloud route was that sometimes you have to build the real thing before they're convinced it's the right thing. And so that's the tactic we took. And when you take that path, someone has to put their neck and credibility on the line. So that can be a gating factor for many who aren't willing to do that. I think building the new team that races ahead that can then teach the old team was the only way we could do that. You know, take one was trying to use the old machine with all the new tricks and it was just not going to work. But now we have a lot of great collaboration between the two. And then when you build the new state, the new land, your rapidly increased velocity will send shock waves through orgs and processes. There is not a ticketing system that deals with the pace of change that we have and that will freak a lot of people out inside of the enterprise. And so you have to be prepared for that, have alternate processes ready. You know, if it's not in some cases, it can be like, okay, I didn't know you wanted to know about that. Here's the API endpoint and you can either come get it or I'm going to pipe it all to you, but I'd be where it's going to be a lot. It's going to keep coming fast and furious. And then at that point, they're like, okay, well, let's think about this. Like, how are we actually going to do this? And then if you thought getting people to believe transformation is possible was tough, we're going to try and convince people that you actually accomplished successful transformation. That's the new challenge, right? Where it's like, you spend all this time trying to get people to believe you that something better exists, then you do it, and then you, you know, there's examples of how, you know, like, well, we just haven't figured out our, you know, our security posture on this or that or our cloud strategy. And a lot of it is like, no, we absolutely have. It didn't come, it didn't originate from the places you're used to, but we have this new cloud ops. We have this new team here that has figured those things out. And now you just got to take the learnings from a different direction. And so that can be really challenging. And I'll let you know when I figure that one out. A couple of things to be aware of. The impact transformations has on others in the legacy space. You can't avoid it. Some people are not going to like it. The other bit I would say is the entrance criteria for apps and CF. Because not everybody's going to like it, they're going to look for reasons to blame cloud foundry for nearly everything. So if you just, you know, lift and shifted some crappy application into PCF and then it starts sending off all your alerts and, you know, all the bells are going off and say, I thought cloud foundry is going to fix that application. So you at least want to be strategic about those decisions. You don't want to just, you can't have your eyes closed about that. What's next for us? So now that we got our applications in there, we have a lot of work to do around reaching the sort of expectations from a digital consumer around high availability. It's around our data services, every layer. So there's some work there for us to do. Type of pivot tool, cloud cache. So along that we're experimenting with new shared and memory cache for applications very early in that process and then multi-cloud shares on top of most enterprise's mind and it's on ours as well. Okay. I think we made it through. I think I can seed the question phase with one that I think you guys probably all have is what is the enterprise think of us now that we kind of took that path? And I mentioned a little bit that the people we ended up partnering with on the ground, so ground level IT, very excited about it, right? Now they see the new stuff and they're like, that's amazing. I wish I could work in that world all day. Now as you work your way up that organizational tier, there's more than just technical reality that is guiding people's opinions, right? And so you, this is actually something I've spent a lot of time talking with Pivotal about. Yeah, the technical implementation is one thing. The organizational implementation is a whole other challenge around how you work with the culture, how if you are spinning up a new CloudOps team, how does that work with the old enterprise team? People will be fiercely defend their kingdoms of course and they feel threatened by, you know, you see Comcast come up here and say they got four people running 26, you know, 100 apps on PCF and that scares a lot of people, right? So I'd say it's a bit of a mixed bag, right? There's a lot of hope in what it can be, but there's still a lot of unknowns and how does the organization sort of metabolize now this, you know, this, the new platform. I think, yeah, I think we got a couple of minutes. Any questions? Yep. So we have three platform engineers that maintain the platform and then we have probably, I'll say around 20 or so application engineers that are developing apps on it. Sir, how many applications are running in it? Yeah, so we have our flagship apps, that's four major flagship apps and then there's a bunch of them. Depending on what level of decomposition you want to go to, each one of those can have four or eight different apps servicing them. Yeah. So our digital executive was very much in favor of this path. Our C level sponsorship was that on your stack. That's as far as they would go, right? They would say, okay, I understand you're saying you're frustrated and I get it. Try it first and then if you're telling me it won't work, go build the new thing. Now, so we did that, but then there's those worlds end up coming together at some point, right? And that tends to be production, right? So the enterprise space will say like, once you talk about production, you're talking about my world, you know, from enterprise IT perspective. And so then that's where it gets messy and that's where a lot of the hard work comes in, you know, relationships matter, being humble matters. So now we have, you know, we've, those bridges of, we've mended some of that, you know, we're working together in a healthy way, I would say, but there's still a lot of outstanding questions around who owns this part of it, who owns that part of it. So two of the three were new hires that were sort of fluent in this space. One of them was somebody who had been working with us as a, like an enterprise SI type of person and was excited about what we were doing and asked to come over. So it's, it's a bit of a blend somebody with enterprise IT experience and then to two new people. So mix, which I think is healthy. It's good to try to do that, I think. So the existing IT function owes a lot of the compliance knowledge, a lot of those sorts of things. What was the group to extract that understanding? So what, we kind of went MVP-ish on it as far as we didn't want to expand the scope of data that we were already responsible for. So from a compliance standpoint, we said, let's make sure we don't expand the scope at all for this first round. Let's just, let's just take the applications we have and replatform them, but from a data perspective compliance, it's all the same concerns we had. It's all the same trust levels that we had before we're not asking for anything elevated. So that was strategic on our part, which made that a lot easier. I would say now we're getting, now we're getting to the point where we're asking, we're saying, we're going to take a little bit more ownership and responsibility when we talk about caching and stuff like that, where we're going to start holding on to state in ways that we didn't before. So now, now those concerns come into it, but there's been trust developed over this runtime now, over this entire year, whereas if we came right out of the gate with that question, I think it would have been super challenging for us to get anywhere with them on that. But now they've had time, security teams have had time to absorb what we're doing, you know, risk and compliance has had time to absorb it a little bit and there's not as much as that reflex of no. Good question. So from my perspective, I am very much saying, don't do that. Please don't. And we have broad support for them to not do it. I would, they, I don't know what they're going to do. I'll just say it that way, because I'm on camera. So catch me out there. All right. Yeah, you can reach me on Twitter over there or outside. Thanks, everyone.