How does one of the largest defense companies in the world embrace agile development? Lockheed Martin set out with a strong focus on cultural transformation and security. At Cloud Foundry Summit, the Mission Systems and Training team took the stage to share their experiences in adopting DevOps and Platform as a Service.
Senior systems architect, Kevin Carlson, framed the problems in the delivery of IT services to their business. The team highlighted culture and process challenges around risk management, knowledge transfer, remote pair programming and removing single-threaded activities from the IT operations processes. He explained how they stood up their Pivotal Cloud Foundry environment to meet the security requirements of an organization that operates critical military and aerospace systems by addressing a range of technology considerations including systems integration, firewalls, OS images and access rights.
Project lead Christine Chesnick also provided insights on how a partnership with Pivotal Labs helped them to understand the culture of agile development and continuous delivery, commenting, “Agile development is a very powerful concept for us to take back. It’s not eight months anymore… in a week you have something that you can work with.”
Finally, IT Applications Director Cecil Miller expanded on why the $45 billion dollar defense company is investing in Platform as a Service, asking, “Why PaaS? Because if we were going to truly transform our applications process and make development more efficient, we need the ability to abstract applications from the underlying implementation details of the infrastructure.”
He also highlighted some of their production successes, including how Lockheed Martin was able to ship a mobile application for their business development team in 10 weeks, rather than the typical 9 months.
“On the technology side, we were able to stand up and secure a Pivotal Cloud Foundry environment, then bring those aspects together to complete a mobile application for our business development team in ten weeks. It’s something that would have taken us conservatively nine months to do before”
For the more details on how Lockheed Martin is embracing agile and Platform as a Service, check out the transcript, or watch the full Summit talk below.
- Missed Cloud Foundry Summit? Read the recap here.
- Watch more Pivotal sessions.
- See all sessions from the Cloud Foundry Summit 2015.
- Learn more about Pivotal Cloud Foundry.
Our next speakers are from Lockheed Martin. For those of you who may not know what they do, they’ve prepared a short video for you.
(Short video plays showing futuristic fighter planes, power plants and satellites)
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.
It’s 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. And 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 for Lockheed Martin. Come on. Thank you very much.
(Theme song from Top Gun plays as they take the stage)
Hahaha, nice music.
First of all, thank you to Sam, and thank you to the Cloud Foundry Foundation for the opportunity to be here. Thank you all for being here late on the second day of the conference. We’re very excited to share our story.
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, the part of the company we represent is the enterprise IT organization, so we’re internal to the corporation. 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. They understand complexity, and they demand a lot.
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.
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. It started with a couple of honest admissions. When we looked around, we noticed that there was a lot of what I 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. 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. 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. 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. They wanted capability sooner rather than later. 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. It was that it was not an afterthought, but it was just a characteristic of the solutions that we supplied to them.
Finally, we learned, again, that our business folks are data junkies. They really want to leverage the data that exist and that’s being created in these transactional system silos, elevated up in a way that allows us to generate new insights. We needed an analysis platform that would assist with that.
That was a mouthful to hear, but it was a very good exchange over a period of time that we had with the business. 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. 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 the time that we needed to, we needed to partner with another organization. We’ll talk a little bit about our partnership with Pivotal 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. 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. No longer were we doing mainframe Cobol, or Coldfusion, or some of the older platforms that we’d become honestly quite used to dealing with.
The third aspect is we wanted to really, in doing this, enable DevOps and at the same time remove single-threadedness from our operation, so this concept that we’ll talk about a little further, pilot peer programming, is really important to us.
On the technology side, we needed to stand up a PaaS development environment. PaaS because if we were going to truly transform our applications process and make our developments 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.
Then finally, and most importantly, we had to challenge the technical norms of our existing culture.
To talk a little bit more about the relationship that we established with Pivotal, I’m going to ask Christine to come forward.
Thank you, Cecil. 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. I guess, one of the things is where do you start? We just saw an awesome video that’s motivating and exciting, and it makes me happy to say, “Wow, I work for a company that can do that.” 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? 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. One of the groups that we collaborated with is our business development group. 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, and we want business development to be happy.
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 was 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. We’re going to have you here with us daily, weekly, helping us figure out what that solution is. At the end of the day, what we heard was you’ve got to make it intuitive. You’ve 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. Our people are all over the world doing this work.
What we did was we engaged with Pivotal Labs, including our business development route, and we spent a few weeks down in Manhattan being immersed in the agile process. My team had no exposure. We’d heard of the word agile. We didn’t know test-driven development. We didn’t know CI/CD, 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.
While we’re down there being immersed in this culture, what we didn’t realize was how ready we were for that change. You don’t know what you don’t know. What we also started to realize was how, within our own organization, people do realize how ready they are for this change also. 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 requirements 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. 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. As you can imagine, Lockheed just doesn’t grant access to anybody. Even if you get access, you’re not going to get that much. 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. 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.
Again, a couple highlights on some of those challenges that we were able to overcome. The one part that I’m living out, though, is where is our customer in all of this. We also need to have their support. Yes, they are in our retros, they are in our standups, they are part of doing the user story acceptance testing with us. 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, we still need a platform to host this application. This is where my colleague Kevin Carlson comes in, and how he solved that for us.
Thank you, Christine. We saw a video today, and there’s some pretty cool technology in that video. 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. With that, Lockheed Martin has built and 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 standup capabilities, and let me tell you we worked some late nights. I think some of you are probably in the audience here, and we do appreciate those late nights. 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 new 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. 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? 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 standup, 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, 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?
Ultimately, we’ve got to provide a design that’ll 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 like to do things in an engineering manner. 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. With that, I’d like to hand you back to Cecil Miller to talk about some of our results.
Thank you, Kevin. You’ve 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, and listen to what they had to say, and you’ve heard some of the things that we got back. Finally, we talked about our approach to partnering with Pivotal, identifying a path to agile and DevOps, and some of the process and technology challenges that we overcame in doing so.
Now you’re probably wondering 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. Typical of Lockheed Martin, we don’t like to jump in too quickly with both feet until we understand that a concept will work. These results are about how we proved the concept.
We proved that we could 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 codevelopment and engagement with an external partner at their lab. In so doing, we accelerated the knowledge for our development team and project managers around the methodologies that we would need to put in place to drive that cultural revolution that we described to you.
On the technology side, we were able to stand up and secure a Pivotal Cloud Foundry environment, and were able to bring those aspects together to complete a mobile application for our business development team in ten weeks, something that would have taken us conservatively nine months to do before.
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, so we have to continue to evolve and iterate. While we’re using the term agile, it’s not a sprint. It’s a marathon for us, so we have to continue to enhance our skills and capabilities in order to deliver this process. 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. How do you get the stuff in that lake appropriately into that fast enclave?
Finally, we have to collaborate and share with other parts of IT, because we believe there are other areas within the IT organization where this approach would be beneficial, but also other parts of the business. 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.
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.
Kevin Carlson, Systems Architect Sr. Stf, Lockheed Martin
Christine Chesnick, Project Engineer, Lockheed Martin
Cecil Miller, IT Applications Director, Lockheed Martin Mission Systems and Training
Sam Ramji CEO, Cloud Foundry Foundation
About the Author