 I will go ahead and get started. I think it was the start time, 235, Missouri. I'm a little late, it's nothing unusual. So running a scale, you guys have seen this part, fire exit announcement. I didn't actually get a chance to read it, but I think you've seen it like five times now. So topic here, eyes on target continuously fielding mission-driven value. I'm Keith Strini. I'm the pivotal federal practice lead. So what that means is PCFS, which is our solutions team, is on the delivery side. So we do a lot of the implementation of custom solutions for our customers in the field. And in this particular case, it's a little bit different in the federal government, specifically in the national security sector. I happen to actually come from this background, so I kind of got the designee appointee by Pivotal to be this federal practice lead. And what it was, is we really saw this market of vertical sort of opening up and the need to help do some transformation and not having that exact understanding of that context. So when we started this, this is a real good quote. Before I came to Pivotal, I actually supported Radham Lewis, and he had this quote about speeding up the delivery of innovation while maintaining technological superiority in order to maximize the warfighter's advantage. And it was something that it was the first time I had seen it. This was probably three or four years ago. And it was the first time I had seen it sort of caveated this way, in which it made total sense about how you switch your mindset from a revenue generated like we do in the commercial sector into what really matters in the defense sector. And so I've sort of carried around this quote everywhere I go. It's a nice way to kind of summarize exactly what we're doing here in this particular vertical. Understanding actual security, it's a difficult subject. I know a lot of you, how many are actually in the actual field itself in supporting DOD? I know like all you guys are. Yeah, so you guys all understand it's not easy. There's a lot of things that we do that's fundamentally different by necessity and some things that aren't by necessity that are just a culture that have built up over time. And so when we came to this at Pivotal, we really wanted to make a conscious effort to translate the shared values that we had on the commercial side into things that aligned with the culture that we saw in the DOD and the IC. So we do things with the intelligence community and the Department of Defense and other civilian sectors as well. But this talk is primarily focused on the challenges that we have in the defense sector. Well, we wanted to do this with a sort of a stubborn intent not to sacrifice those things that we enable our commercial customers to do, but while recognizing there were certain gates that we needed to meet. ATOs, security is different, air gap environments are different. So we knew that going into this that there were gonna be some things that we needed to shift on, but we wanted to make sure we maintain who we were in this space and make sure that our customer had that same sort of shared vision on these different pieces. So the primary goal here was the development and implementation of sort of how could we do continuous fielding and how could we do it well? We knew there were gonna be bumps in the beginning, but over time, how would we improve to make this a very efficient process that matched our speed in the commercial sector? So why go faster? Well, there's different threat domains all over the world and they're all evolving at different speeds. And when you realize that and you think about the different domains that we fight or defend and you have cyber, electronic warfare, traditional means, these type of things, all of those things have very different, different countries have different evolutions, countries that can't afford full-blown aircraft carriers and air force, full air forces, they're investing heavily in cyber. So it's still an attack factor. We still have to be aware of it and we still have to develop capabilities to defend against it. And then you have the traditional, like you saw earlier in the talks about projecting air power and all that goes into those different pieces. And so because of these different speeds, we struggle to stay up with them. I mean, it's basically like fighting on multiple fronts and we all know that's a bad idea strategically. So when you couple that with the speed which Captain Kruger had talked about earlier about how fast things are actually getting to the field and I think Tori had said something like 11 to 13 years, right? There's no way you can stay up with those evolving threats. And so we're opening ourselves up to a lot of these different attacks unless we decide as a group how we wanna go faster without cutting corners. And so that's sort of what I wanna talk about today which is what have we done so far in this space and what do we still need to do but then also recognizing that this model is applicable to any of the Department of Defense services, right? This is not specific to Air Force although there are things that were specific, Intel we could do certain things, Air Force we could do certain things and that will change. Navy's got over the horizon challenges, things like that. But we have plans for doing this type of stuff. It's more about communicating the possibility that this really does apply to the defense sector rather than just saying this is a commercial thing and it would never work in our particular vertical. But really this is not about revenue generation. I mean we all recognize that, especially folks in this room coming from this field. It's about how to, in the national security space is about how fast can you deliver a compliant solution to satisfy a mission need. And in the Department of Defense you have a concept called mission effectiveness. And what that means is, is whether or not a mission got executed. And just to give you an example of something concrete is like the tanker planner situation. Tanker planner, bottom line tanker planner was mission effective. It was refueling all the planes that it needed to do. It didn't mean that each actual individual measure was effective. So where we found savings and were able to save all that fuel cost that was an efficiency, a measure of efficiency that could be improved. But at the end of the day they were still fueling all the tankers. And so the idea here is how do you hone in on what those, you know, maintaining mission effectiveness as the bottom line. You know, the app cannot go down. The platform must stay up all the time to serve those mission critical components. But then how under the hood are we getting better and better at that? How do we change TTPs to be more efficient? Tactics, techniques and procedures. Sorry, I'm gonna jump into acronyms all the time. But how do we improve those different pieces so that over time we're becoming more and more effective at those missions themselves, and more and more efficient at those missions themselves? And so really what we want is we want to figure out how to maintain a certain velocity that we have effective operational agility and this is gonna give us a continuous advantage over all of our adversaries. And that's really where our ultimate goal is, right? It's not revenue, it's not P&L. Those are all awesome, right? We all as taxpayer dollars want those different things. But when it really comes down to focusing on the mission, it's how do we maintain that continuous advantage over our adversaries that are all threatening to attack our way of life? And so you always gotta remember why we're delivering, right? So loss, right? We're looking at better ways to put folks forward. How do decisions faster so that it gets them out of harm's way? How do we more effectively drop ordinance on targets to minimize collateral damage and things like that? These are all the different pieces that we're trying to do as the number one priority but then still go fast. And a lot of times that's at odds. And so that's what we're sort of learning in this whole effort in terms of like Kessel Run, in terms of what we did at NGA, in terms of our other federal clients is how do we learn from this and reduce the friction in order to do both aspects of this at a minimum? We all know this, right? We all have organizational silos. Every single effort that we've done, we come across this. In our own organization, we have this. It's something that's always there and we just learn to get better. And so you heard a little bit about this earlier, so it's kind of nice because I don't have to go through all the stuff because Captain Kruger and Tori did a really good job of articulating smaller deliveries, faster deliveries, less risk, eliminate that stuff. So I don't know if you guys have seen the sawtooth versus the exponential, things like that. I mean, that's really what we're after here is how do we reduce risk through the deployments? DIY platforms, you heard a little bit earlier. Without a unified fielding approach, this is what you get. Everybody goes off and builds their own and then you have to come up with adapters for every single different standard. This is what we're trying to eliminate. Is the system of systems architecture that's so complicated, it requires a large sustainment tail. It requires a lot of troubleshooting and a whole organization stood up to support it. This is what we're trying to get through and be more, be more, I don't want to use agile, but be more nimble in the way we actually approach these different integration points. Because this is what we want to get to. This is really the key, right? The faster you can get feedback from the warfighter, the more the applications resonate, the better the intuitiveness of the actual application is, so that then they can effectively do their missions and then even start thinking outside the box with this extra time that I've got because it became more efficient, I can now think of better ways to do those techniques, tactics and procedures in order to be more efficient in my mission. And it becomes like a cycle that's good, but we'll get to that later. Non-functional requirements. I'm sure you guys are all aware, non-functional requirements tend to be the first thing scrapped when budget cuts come. It's like, hey, it's out there, it's good, it breaks, hey, we'll support it, get it back up and running, but it's not, it's things that, if you're proactive about it, we can get it much more stable, we can get that ahead of the curve in the beginning, we can address more things on the non-functional side, and it doesn't have to be an extra effort and the first thing cut when budgets come, it can be part of the integrated process, which a lot of it, we do some of that with the TDD, sorry, the test driven development sort of focus, and we do a lot more quality types of coding and things like that, but there's even more processes that can be put in place with automated pipelines graduating through environments and going through maturation gateways, like canary testing, like load testing, chaos testing, resiliency exercises to prove that the designs are valid and that they'll hold up under the adverse conditions downrange in the field. The two most important factors, performance and testing. These are often overlooked, and like I said, they're the things that require the most care and feeding in the beginning, but then once they're built into the DNA of the applications going forward, we're able to actually carry that all the way through to better stability out in the edge. And you heard a little bit about this earlier too, functioning acceptable is no longer acceptable. So a lot of this, we go in and we start talking about culture and cultural changes, these things are really important to understand because the way business has been traditionally done, it has been, here's the requirement, did you meet it? Yes, check. There's no qualitative aspect to it. It's we've done the bare minimum and that's no longer good enough. You heard Captain Krueger say earlier about building joyful software. And it's really, I mean, that's definitely part of it, like the joy of the user, but there's also a whole another under the iceberg type of aspect, which is if I can go in and I can pull the plug on a rack and we've designed the applications with the idea that it's a mission-critical application and pulling the plug on that rack will not cause any outages in the mission capability. Those are the type of things that we wanna build up to and the resiliency in the mission-critical space. And this is fundamentally different. Yeah, I get the commercial likes that too, but it's less likely to happen in commercial. You'll have outages and you'll have these kind of things. When you have the threat of actually being under fire and being able to do disaster recovery and shifting sites and conducting mission operations on the next heartbeat, that's the type of things that we need to build into the DNA of the quality of the stuff going forward. So these elements are critical in fielding every delivery and sustainment of every capability going forward. Because like I said, we wanna get to this. The only way we build trust with the warfighter is when they know that when it gets put out in operations, it's not gonna go down. They can't trust that if, you know, I have a sexy new feature that I asked for and it's there, but then it disappears on me midway through and I've gotta revert back to the old way of doing business, that's a problem. And then as that erodes the trust, then it becomes more and more difficult to solicit feedback from them to build better, more resonant apps and do this kind of stuff. So to get back to that cycle where they're providing us feedback, we're building better software, they provide us more feedback and we're getting more and more effective missions, this is the type of thing that has to be built into the DNA of this. Cause we wanna focus on code, right? Platform is always treated as an african thought and I'm a platform guy, so it's fine. I can say those type of things, but that's what you want, right? The ultimate testament of success is when I plant the flag and say, nobody notices me in the room, right? I mean, that's ultimately what we wanna get to. We wanna get it to where you're not even thinking about that, but that doesn't mean that we can cut corners, right? Because safe software is difficult. I mean, don't let anybody fool you. I know we love to sound bite a lot of different things from all different levels, but at the end of the day, safe software is tough. It is tough. It requires a lot of thought in how this stuff is deployed. It requires a good understanding of the characteristics of the objectives of the application itself. It requires understanding the environment that the platform is going into, that the app is going into and the types of missions that would be conducted on top of it. And so these things, when you kind of find that empathy with the platform teams and the application teams, you start realizing what is actually important in the delivery and it starts helping you set the priorities on feature development. It starts helping you set the priorities on platform evolution and things that you wanna do in this particular vertical. But ultimately, this is what a DIY platform looks like. Like this is what you wanna get away from because you're not in the business of building a platform in the Defense Department. You're in the business of actually conducting mission operations. And so this is why you come to like sort of a unified platform strategy. It's because it offloads a lot of these different things from you and having to learn all these different skill sets and then keeping track of all the different evolutions of all those different technologies, licensing, supportability, those different types of things. And so once you kind of take this and look at the unified strategy and you kind of take that off the plate, now you can focus on organizing around the mission. And this is really what you want. Yeah, it's crown, it's my cartoon, so it's fine. I don't really have a graphic for it, but these are all the different elements that go into the application. Like if you think about this, in this particular vertical, user experience, warfighter owning the product and providing that feedback, government sponsors and a lot of you guys are those folks in the room. It's how do you organize around the mission so that instead of having these vertical silos, we can get more into a horizontal flow and out to the field faster and faster. And so that's really why we do this organization around the mission. Because remember, we wanna do this, right? This is what we're trying to build up to, but we can't cut corners. There's no work around for IA. There isn't, like as much as IA has always been that long pull in the tent and we're starting to conquer it, we're starting to get through that. You heard earlier about shared application controls that are inherited all the way up from infrastructure, all the way up through the platform, and now you're only dealing with 40 some odd controls. We did not shortcut that. We knew we wanted to go fast, but we did not shortcut the process because ultimately it then opens us up to vulnerability. And that's what we do not want. At the end of the day, we wanna be reliable and we wanna be secure. And then from there, the sectionist comes with all the different features. Continuous patching is part of that piece. Introducing that whole different concept and idea, which was like, oh my God, like you guys can patch like all the time. And there's no end of life. There's no EOL problems like we had in the past where you're still sitting on Windows 98 because we can't get a new operating system out there. We can keep the operating systems up to date across the entire portfolio. From the VM level all the way up through the application, we can continuously patch that. And in working with those MOAs and understanding how those things are gonna roll out and how we still maintain the stability of patching all the time, but being able to canary style those things out and see if they're gonna crash and burn. And if we need to go back to the drawing board and provide another patch, or everything is good and roll it across the entire platform. And in four to six hours, your entire piece is all up to date, which then becomes a moving target for any of our adversaries to attack. I'm sure some of you guys have probably heard our repaving story. And things like that, creating a small moving target is a lot harder to hit. And then you combine that with all the in-depth layer of security and stuff that we put around the platform and networks. And now you have a very resilient system, but also a very secure system in order to move forward with mission critical pieces. And we also are able to then offload resources to the experts. So things like a unified security model. I don't know, you guys ever remember working in the past about how we had to do security before? Every app had to bring their own security. And then every time there was a change or there was a vulnerability, you had to go through and figure out who was using which security model and how that stuff would work. Identity access was the same way. And it became very problematic to do any kind of updates. And it always required long lead times and RE events and all these different pieces just to patch or just to update or just to upgrade some aspect of identity management security. And you had to do it because if you left it, then you have a vulnerability in there. And sometimes those vulnerabilities would sit there for three years, you know? And so what you do here is you say, okay, we have a security team and they will run that piece and we will integrate with that security. And then that shared security model will then move down across all the applications within the platform and in the entire portfolio. And you know what? The developer doesn't even need to know about it. They say, bind to my SSO app and I get passed a resource token. And I know what to do with that resource token because it's talking about roles that I need to develop in my application. And I know what those mean, but I don't know what that PKI stuff is. I don't know what all is, you know what, you don't have to worry about that. That's all gone, right? There's a team that's handling that. We've integrated with that team and now everybody with the roles across the platform can just deal with the actual application pushes. Runtime, same kind of thing. How do we verify what's in runtime? How do we know we don't have an advanced persistent threat that is burrowed into our stuff? We don't care because we paved that stuff. You know, you set your policy guidelines, we can pave through containers. We can pave through VMs. We can pave through entire architectures to make sure that if there is something all the time that they spent trying to penetrate and get in there, suddenly they just got wiped and they got to start all over again. And so pretty soon they'll give up. You know what I mean? If they even get through in the first place. And so the idea is we can even verify at runtime the types of things that are out there and making sure that these things stay stable. Continuous feeling, what is it? Right, that's a culmination of all these different pieces. The resultant outcomes that produce the tangential benefits from the fiscal responsibility that Tori talked about through the mission applications and how we continually provide actual capabilities but without sacrificing anything in the meantime. So now we're ready to talk about this, right? So you heard a little bit about what we call our UCD or user-centric design process. And the biggest benefits to this is I think if you went out and you talked to our users that have gone through this process, be it labs or AppTX stuff or just now as the Air Force and NGA stand up their own organizations to do this. I think what you find, which is often a understated benefit is that there are no tech manuals. There aren't a need for tech manuals, right? They're very lightweight. Why? Because they told us exactly how you would want to use the application. And so this is the epiphany, right? The idea is that if you tell us how to use it we don't have to provide a tech manual for it. I mean we're going to provide release notes and things about it, but we don't have to provide these big giant tech notes and then it doesn't make sense how they're using it. It's all becoming intuitive, which means what does that mean? It means that we actually look at how do we train techniques, tactics and procedures instead of worrying about in the tech manual how to pull down a drop-down box, how to change my font size, how to do these different pieces that have nothing to do with my job, nothing to do with the mission that I'm executing. It's all stuff that is, it's just been there and I've always had to deal with it before. The other thing that we do is realistic data, right? It's this idea that you can't mock up the kind of stuff that we see. This could be something as simple as real, link 16 stuff or USMTF messages or formats that come over and not realizing that they can go beyond a certain character that we thought was there, right? That then suddenly mangles displays on the screen. It's from that level of detail all the way up to the size and scale, like tanker planner and how many tankers are in theater, how many planes are they trying to refuel? How many targets are we talking about here? Global operations. What does that actually look like and how many things do we have to keep track of and do this type of thing? Using realistic data gave us some new insight into that mocks don't always do what we need them to do and so there needs to be a realistic testing environment in order to make sure that when it goes out into operations it's gonna perform as expected. And again, the ultimate goal, training time shifts from tools to mission function. I mean, there's no better thing than that, right? Like the idea that now I'm doing my job and that's the only thing I'm doing. I'm not doing all these other things that I have to do in order just to get to being able to execute my particular job. And that's the intuitiveness of the user-centric design and how that payoff works at the end of this. And then, you know, never settling for less than direct feedback from our users. And this is a big thing, right? This is, you know, in the past and this is not a knock on anybody, it's just how the organization's worked. You had a requirements office and you heard what Tori has said before. You have a requirements office that gets a requirement and it vets it for three years. Then it goes through an acquisition process that tax on another piece. And the thing is is what that requirement was is not what it is today in the mission space. And so by not eliciting feedback directly from the actual warfighter, then you don't know if the actual mission requirement is still valid. And so the same way you can save money like creating a more efficient tanker planner, you also save a whole bunch of money on requirements that you can sunset that you never even started building because there's a implied debt that's sitting out there. You know, all my unsatisfied requirements all add up to some dollar amount. And if I'm just getting chunks of money from Congress to just execute those requirements and 80% of them are no longer valid because they're stale, I just saved whatever 80% of that budget was, right? So there's also this addition by subtraction that you get by having this direct feedback from the user. So there's the cost of delay and then there's the cost of implementing the wrong thing. And that's the other thing that we get or we minimize when we have this direct user feedback. And then quality, right? We don't wanna sacrifice. Developers and testers are not a different function. This is the new way of doing software, right? There's no test organization doing manual checklist anymore. And then that goes into a black hole and then you provide feedback and you don't understand the context. You don't understand how they actually ran the test. The feedback is maybe not useful or by the time you got that feedback you're already three releases forward and you already discovered some of these problems so you wasted manpower. So the idea here is that when you switch to more of a test-driven development model your developers are the testers and the testers are developers which means that if you think about this from a DOD perspective with test organizations you have a whole bunch of billets sitting out there. I know this is controversial but you'll have a whole bunch of coders that are sitting out there when you start rethinking about the test-driven organizations and making them into TDD coders. And so that's a huge set of billets that are outstanding that you could actually start converting and make them part of the fight and being able to deliver these capabilities forward. It's all about the journey, right? So we do journey testing in mimicking user base, how they do operations, these type of things. Quality and coding is an art form. I'm sure you guys give you a chance to read the cartoons but this is what you see all the time in the past, right? This is the idea, is you have a quality assurance organization that's separate from your actual coders, that's separate from your actual testers. And so what ends up happening is you get these type of things where it's like nobody understands what the actual code did. The QA folks don't understand what it's there for, they can't really articulate why it shouldn't be there. You've got coders that built something that they think they understand what the requirement is but then it doesn't function in a production sort of setting. And so you have all different kinds of disconnects between these organizations which is another reason why we organize around the mission and do this. And then this was a big challenge specifically with the Air Force, we didn't have as much in the NGA part but overcoming that transient workforce, right? Transient being loosely user. Right, and so the idea here is that, it was something that was just, it actually just happened to be a side benefit, right? Because we do pairing, because we do pairing it really illustrated the strength of pairing that you don't normally get to see in a commercial setting is the idea is like, if you have people shipping out every six months, if you worked anywhere else that did not do pairing, all that context would be lost and you'd be constantly on resetting. But not only did the Air Force survive, they ended up thriving on that pairing model such that there was, people would come and go, guest appearances, people would come and go in six months, people would come and go in a year and they were still able to maintain that consistent context across the entire effort. And that's a testament to the pairing model working and then the Air Force fully understanding the power of that pairing model and how to apply it to the adversity that they were experiencing with that particular workforce. And then of course, the most difficult part, right? Velocity to the edge, a lot of great ideas end up on the shelf. They get through developments, they get maybe through QA, sometimes die in testing, sometimes die in exercises. It's really getting over that last hurdle to get it out to the field and that's where we focused on first was what would it take to get it? How do we start at the field? How do we build the pipelines back so that we could turn on like, the moment we can get one drop means the moment I can turn the faucet on full blast and get capabilities delivered out to the field. And so that's really what we were looking at is how do we overcome the most difficult part, the velocity to the edge piece? And then why? So here's a whole another benefit to why we do this and why we offloaded the platform, the invisible hand of the market. So how many Silicon Valley efforts do we have around the country now? Boston's a hub, Silicon Valley is a hub. You know, here's tech solutions popping up all over but the reason why those things aren't getting into the government is because what you have is you have this barrier to entry. You either have to be a defense contractor, you have to understand the FAR clauses, you have to understand all these different pieces. So two kids in a garage shop that are brilliant at building pathing algorithms will never get that in front of the warfighter in the past. But now with this and offloading all of these different elements of how to graduate code into production and into operations, how to offload the security identity pieces, they just have to focus on what they do well. And what this does is it lowers the total cost of ownership of capability development. It means that if this isn't performing well, some big defense contractor over here, five layers of management is costing me this much money and I can do a fly-off with a two-person shop and that actual algorithm is just as effective but yet the cost is super low because they don't have that and this is going to scare big defense contractors. Sorry, Johnny. Anyway, so like the idea here is that when you look at that, that is what we want as taxpayers. We want the best ability, best capabilities going out to the field to support a warfighter. But all those sides that I showed before about not sacrificing anything, that's what we have to maintain. So this is a perfect model for that because by offloading it to the platform, you've done that, right? You've already ensured the maturity is going to be there by the time it graduates into operations but now you're able to source five different pathing algorithms. Have them fly off. Which one won? Which one was the most value based on its cost? And then the support and sustainment pieces come through because why? If I want them to continue to use my pathing algorithm, I better keep updating it, right? Because the next one's right behind me and now I've got a competition for it. So it's awesome, right? It creates this whole invisible hand in the defense sector, which has been kind of non-existent since the 60s, right? Because the big defense contractors kind of boxed everybody out and this is the gateway and everything became so complicated to get in and now we've eliminated that. And so this is an exciting new time pioneering where people can set up two four-person shops and build businesses and have a nice little business being service marketplace inside a cloud foundry and these type of things and they can continue to sustain and maintain this. And what this means is simplifying delivery means the overall TCO goes down, total cost of ownership. And that's gonna be pay huge dividends in the long run for us as U.S. citizens and taxpayers in the Department of Defense. And so ultimately what we learned from this is that this model works, right? Have you guys heard the phrase watching the vapor trail? So this is where a spotter is looking because snipers are shooting so far you can't actually see the rounds on target. So this is making those micro adjustments here and there until we can actually hit on target every single shot. And that's really what we're trying to do here is continually to learn and continually to evolve but make sure that we're constantly giving that micro adjustment so that we're always trying to get those shots on target. And that's it, any Q and A?