 Our next speakers are from Lockheed Martin. For those of you who may not know what they do, they have prepared a short video for you. Technology that enables cars to drive themselves. Routine flights to Mars. Fusion reactors that produce limitless energy. To most people, they're pure science fiction from the world of tomorrow, like something out of a movie. But at Lockheed Martin, we live on the cutting edge of physics, material science, technology and engineering. We obsess over things most people only imagine. We're at the forefront of the science that makes them real. And they're available when it matters most. Why we're always thinking about new ways to prevent the unthinkable and building the most advanced fighter the world has ever seen. It's how we redefined what a combat ship looks like, why we're harnessing the tides to generate electricity and protecting our most valuable resources. While we don't know what's going to change the world next, we're probably already working on it. We have invited three speakers, Kevin Carlson, Christine Chesnick and Cecil Miller to please provide your insights into Cloud Foundry from Lockheed Martin. Come on. Thank you very much. Nice music thing. First of all, thank you to Sam and thank you to the Cloud Foundry Foundation for the opportunity to be here. And thank you all for being here late on the second day of the conference. We're very excited to share our story. So you saw a little bit in the video about what Lockheed Martin does, and we're here to talk a little bit more about what it's like to work for Lockheed Martin. Honestly, to cut to the chase, the best part is the employee discount we get on the F-35 fighters. But seriously, we, the part of the company we represent is the enterprise IT organization, so we're internal to the corporation that our customer is Lockheed Martin. They are a very challenging customer because as you've seen, they do hard, and they do hard very well, and they understand complexity and they demand a lot. So what we want to talk about being that we're not on, as we've heard from a number of speakers throughout the conference, we're not on the revenue generation side of the business necessarily, which means that when we look at our operations, we have a constant demand and pressure to really become more efficient. So some time ago, we stopped and really looked at how we as an IT organization could enhance the value that we were delivering to the business. And it started with a couple of honest admissions. When we looked around, we noticed that there was a lot of what I'll call shadow IT. So we have very smart people, lots of engineers, and some of you may be familiar with the paradigm that everybody's an IT guy. But the result of that, at the end of the day, is there's a lot of different ways of doing things in terms of development that had to be suboptimal. So in order to kind of get our arms around that, we wanted to up our game in terms of how we were engaging with the business. So we literally changed the structure of our organization to play man-to-man offense, if you will, with key business stakeholders. And in so doing, we learned a lot about what our opportunities were to improve. The first thing we learned was that these folks really enjoyed designing solutions, not surprising for engineers, right? And they wanted to be intimately involved in those solutions that impacted the way they did work. And they wanted capability sooner rather than later. So what that revealed to us is that our processes, where we were traditionally a waterfall shop, were no longer appropriate to meet the needs of the business. The other thing we learned was folks wanted the ability to do work in many different fashions and from many different locations. So there was this demand for mobile enablement. And it was not an afterthought, but it was just a characteristic of the solutions that we supplied to them. And finally, we learned, again, that our business folks are data junkies. We really want to leverage the data that exists and that's being created in these transactional system silos, elevated up in a way that allows us to generate new insights. So we needed an analysis platform that would assist with that. So that was a mouthful to hear, but it was a very good exchange over a period of time that we had with the business. And so we had to figure out how we would respond. It made a lot of sense based on what we were hearing that becoming more agile had to be somewhere in our response. And we had to address people, process, and technology. I'm sure you've all heard that adage before. As importantly, we recognized that if we were to get there in a time that we needed to, we needed to partner with another organization. And we'll talk a little bit about our partnership with Pivot Oil as we embarked on this journey. But we knew that in jump-starting our agile process, we needed to include our business stakeholders from start to finish. And that took not just reconditioning our IT team, but it took reconditioning our business teams as well. We knew that we needed to gain exposure to new development technologies. So no longer were we doing mainframe cobalt or cold fusion or some of the older platforms that we'd become honestly quite used to deal with. And then the third aspect is we wanted to really, in doing this, enable DevOps and, at the same time, remove single-threadedness from our operations. So this concept that we'll talk about a little bit further paired programming is really important to us. On the technology side, we needed to stand up a past development environment. Past because if we were going to truly transform our applications process and make our developers more efficient, we needed the ability to really be able to abstract them from the underlying implementation details of the infrastructure. We had to establish that tool set for complex analytics and pave the way for the future demand that we knew we'd be getting from the business. And then finally, and most importantly, we had to challenge the technical norms of our existing culture. So talk a little bit more about the relationship that we established with Pivotal and ask Christine to come forward. Thank you, Cecil. So I was given the privilege to be the project lead for this effort and also the product manager for the applications that we are starting to deploy. And I guess one of the things, right, is where do you start, right? We just saw an awesome video, right, that's motivating and exciting and it makes me happy to say, wow, I work for a company that can do that, right? It also makes me motivated when we have a team that is able to move forward and help our organization and company also move forward. When the initiative was started, we had to figure out who are we going to help, right, because this is what it's all about. Behind everything in that video is a tool, a process and a set of people that need to deliver business value every single day. So one of the groups that we collaborated with is our business development group, right? They had a cumbersome tool. Nobody's using it. Executives aren't happy because they're not getting the customer data that they need to be able to make decisions, right? And we want business development to be happy. So as we listened to their user story, which is critical to the process, we identified this opportunity and we also started to condition them on what this methodology and approach is going to be about. We're not going to have a requirement session and leave you for six months and come back and show you some little prototype, right? We're going to have you here with us daily, weekly, helping us figure out what that solution is. And at the end of the day, what we heard was, you got to make it intuitive, right? You got to make it easy for these road warriors to be able to get their data in and move on to their next effort. It needs to be mobile, and by the way, it needs to be able to be international, right? Our people are all over the world doing this work. So what we did was we engaged with Pivotal Labs, including our business development rep, and we spent a few weeks down in Manhattan being immersed in the Agile process. My team had no exposure. We heard of the word Agile. We didn't know test-driven development. We didn't know CICD. So we're excited because of all this new opportunity, a little skeptical because it sounds too good to be true, but left becoming believers. So while we're down there being immersed in this culture, what we didn't realize was how ready we were for that change, right? You don't know what you don't know, and what we also started to realize was how within our own organization, people don't realize how ready there are for this change also. And how do we start getting that knowledge transfer? How do we evangelize it, socialize it, starting within our own groups to be able to get that support? Well, you get the support by proving that it works. So we're in the lab environment, side-by-side with the pivots, have a requirement session, coding starts immediately, and by the end of the week we have a landing page and features that we can actually work with. Very, very powerful concept for us to take back, right? Not eight months anymore. Hey, in a week you have something that you can work with. We did have a few challenges that we did have to overcome that I'm going to highlight just a couple of them. I already alluded to the learning curve that we have with all this new technology and terminology that we had to figure out, solve, and absorb. One of the most important ones that was critical to the success of our project was figuring out paired programming. It's easy when you're in the labs, the pivots are next to you, the developers are all next to each other, communication, tap on the shoulder, here's a problem, let's solve it, here's a bug. But our code is being developed in one place. We need to get our code into our Lockheed Martin environment. And as you can imagine, Lockheed just doesn't grant access to anybody. So even if you get access, you're not going to get that much. So we had to figure out how are we going to solve this to be able to continue moving forward. Well, we got through that hurdle, and here's the second key one. We work virtually. Our development team is not next to each other. My team is scattered all up and down the East Coast. So now we have remote pairing, as we call it, that needs to be solved. And how do you do that? Again, we figured it out, took a little while, but became very successful at that because virtual pairing, virtual workload isn't going to be changing for us. So again, a couple of highlights on some of those challenges that we were able to overcome. Now, the one part that I'm leaving out, though, is where is our customer in all of this, right? Because we also need to have their support. And yes, they are in our retros. They are in our stand-ups. They are part of doing the user story acceptance testing with us, right? Again, to influence that relationship and having them help support our organization to be able to go back and say, wow, IT's doing great things. Go to them for your needs. With that said, while we're in Manhattan, while we're working virtually, building an application, well, we still need a platform to host this application. And this is where my colleague Kevin Carlson comes in and how he solved that for us. Thank you, Christine. So we saw a video today, and there's some pretty cool technology in that video. And I'm the technical guy who had the opportunity and privilege to help deploy new technical solution in our environment. But what you also saw in that video was we also have the responsibility to protect some very secret and sensitive data. Lives are on the line. And with that, Lockheed Martin has built an ecosystem of people, processes, and technology that delivers that in a flawless manner. That ecosystem has been developed over many years. It's something we're very proud of internally, and we were challenged with internally on this project. We had to transform. We had to come up with a way to technically transform our IT processes and people. And in order to do this, there were three critical pillars, starting with the design. When we went into the design effort, we looked at it from your traditional pre-production and production design methodology. We engaged with Pivotal to provide the stand-up capabilities. And let me tell you, we worked some late nights. And I think some of you are probably in the audience here. And we do appreciate those late nights. And I know a few of you were hungry on those late nights, so was I. But we couldn't have done it without you. We also had to engage very closely with our information security team. You know, on the design of the infrastructure, the networks, the firewalls, the rules and processes. We had to incorporate in new network technologies, deploy new systems, deploy new firewalls, deploy new routing mechanisms. All of this led to a level of complexity that was really not straightforward at the beginning. Our network team was challenged with new ways to do things. They were challenged with new firewall rules, NAT rules, translation between the visibility of the systems and our external systems. We had new operating systems involved. No, we could not deploy our hardened Lockheed Martin OS with our great tool suite and all our other monitoring systems. So we were challenged. And this really led to a risk management opportunity. How do we mitigate and manage risk in our environment? What is the acceptable level of risk in our environment? What are some of the new processes and capabilities that you interject to enable technology? And ultimately, in our case, we have to integrate with other production services, whether that's your Active Directory for Single Sign-On, Federation Services for SAML, other business applications that are in production, database connections, all of this led to a fairly complex stand-up. But what it also meant, and most importantly, is a large shift in our culture. We had to change. We had to get beyond asking the question of what is Pivotal Cloud Foundry? What does that mean? We had to get beyond that. We had to embrace automation. We had to embrace change. We had to think of new processes. We had to get out of that gridlock of trying to take the tried and true, the known, and fit it into this. We had to think outside the box. Those new tools, terms, and technology really challenged our team. You know, and really tried to think inside, to understand, really, what does DevOps mean for Lockheed Martin? What does it mean for us to be able to secure our data? And ultimately, we've got to provide a design that will evolve. Our infrastructure evolves. Our technology evolves. Our designs have to evolve. We have to reduce complexity. We have to think smarter, think faster. Try not to over-engineer. We're a lot of engineers at Lockheed Martin. We have to do things in an engineering manner. And ultimately, we have to take our culture and shift it to a point where we can drive innovation, drive business value, be able to execute quickly in a cost-effective manner for our businesses to stay competitive. And with that, I'd like to hand you back to Cecil Miller to talk about some of our results. Thank you, Kevin. So you heard us really kind of frame a problem that we saw in the delivery of IT services to our business. You've heard about our approach to engage more tightly with our stakeholders, listen to what they had to say, and you heard some of the things that we got back. And then finally, we talked about our approach to partnering with Pivotal, identifying a path to Agile and DevOps, and some of the processing technology challenges that we overcame in doing so. So now you're probably wondering, well, what are the results? So I'm going to talk a little bit about results. This activity, which began, by the way, for us in October of last year, was really about proving out a concept. You know, typical of Lockheed Martin, we don't like to jump in too quickly with both feet until we understand that a concept will work. So these results about how we proved the concept. We proved that we can partner in a different way with a key business stakeholder, in this case, our business development organization. We proved that we could initiate and sustain a co-development engagement with an external partner at their lab. And in so doing, we accelerated the knowledge for our development team, project managers, around the methodologies that we would need to put in place to drive that cultural evolution that we've described to you. On the technology side, we were able to stand up a secure Pivotal Cloud Foundry environment, and we're able to bring those aspects together to complete a mobile application for our business development team in 10 weeks, something that would have taken us conservatively nine months to do before. So all those we believe are successes, and as excited as we are about those successes, we understand that we are in it for the long haul, and so we have to continue to evolve and iterate. And while we're using the term agile, you know, it's not a sprint, it's a marathon for us, and so we have to continue to enhance our skills and capabilities in order to deliver this process. And we have to institutionalize these changes. So, in fact, we've now got an enclave of stuff that's happening really, really fast and a whole lake of stuff that isn't. So how do you get the stuff in that lake appropriately into that fast enclave, if you will? And finally, we have to collaborate and share with other parts of IT, you know, because we believe there are other areas within the IT organization where this approach would be beneficial, but also other parts of the business. So I talked a little bit earlier about how we're not on the revenue generation side. We think that these tools and this capability could be incredibly powerful in some of our external-facing platform solutions. So, with that, we'd again like to thank you all for being here and for the opportunity to share our story. We're very excited to continue our journey, and we'll see you in the cloud. Thank you. Thank you.