 The way I look at it is because we have unique challenges in for a financial institution being that we are monitored by regulatory agencies, we think that we've established a fairly good pattern and learned a fair bit through our technology journey. And we're hoping that what we've learned will be helpful to you. If you roll back a few years and my colleague Darian will go into more detail on this but a few years ago, we began to understand that in order to remain competitive, in order to progress as a company, we really need to dedicate ourselves to being a technology company. And this involved some changes in various parts of the organization, from the technology we used to how we use the technology itself to how we organize ourselves as creators and users of this technology. If you look at how we approach things like open source, like public cloud, like agile and DevOps, methodologies and principles, all of this was adopted at a broad scale over the past few years. And we learned a great deal in this process. We learned what is possible. We learned about how to overcome some of the challenges we came across due to the aforementioned unique challenges that we face. And we've come to the position that this has been a great growth experience as we go through this cycle of modernization and how we have simultaneously delivered great things while establishing these core principles and putting them in place. So that we have now a culture of collaboration and a culture of ownership. And we've nurtured that for our engineering team so that they can be innovative but at the same and sustain that innovation, more importantly, but also so that they can, while building things, they can maintain them over time and be able to manage the risks associated with some of these technologies. Being a financial institution, we look at risk plays a very heavy role in the decisions we make. So we look through all these stuff through a risk management lens. So in every decision that we make, we're balancing the progress that we'll make versus the risk that we have to manage. And in each case, we determined that going forward with these plans made sense from a risk management standpoint because in putting them forward, we're actually helping to manage risk. Whereas, in some cases, maybe in another situation, someone may make the determination that going forward with these technologies could introduce new risks. But while we take them into account, we balance that with the overall risk that we incur and how do we establish the guardrails and the process so that we can properly govern all of these new initiatives over time. If you look at the slide here, we've laid out some of the core principles that we have established in this technology journey from modernizing our standards to embracing an open source first mentality to really going all in and embracing cloud-native technologies to rolling out agile development methodologies across the majority of engineering teams, I would say. Really doubling down on the continuous integration and continuous delivery story, which we can use to standardize the technologies that are developed and how they're developed and how they're rolled out. And then really focusing on how this affects human beings. How does our technology affect the customers both internally at Capital One and externally? And then finally, we have to get it ready for an artificial intelligence world and making sure that we have ways to embed the machine learning technologies that we're all using to compete. And then finally, balancing that against the cyber risk. So speaking of risk management, I wanted to walk through, take a step back and look at risk management from a couple of different angles because when it comes to embracing open source technologies and open source methodologies, there are some things to take into account. So I have here on the screen a study from Gartner all about software composition analysis and scanning and the role of scanning. But more than that, and this is something I like to talk about a lot is viewing the software supply chain in its totality and how the provenance of the source code we use affects how we govern its usage inside Capital One. But also governs how we think about pushing our contributions back out upstream into these open source communities, which I'll touch on that in a bit more detail later. But first and foremost, how do we look at the totality of the software ecosystem that we depend on? And how do we mitigate the risks by hardening that supply chain and making sure that it's reliable and that we can depend on it to sustain our innovation going forward? This plays a very large role in how we manage risk for our technology rollouts. Along the same lines, Forrester also came out with a report focusing on cloud container adoption and enterprise, but you could really look at the takeaways from this report and apply it to frankly, any new technology that's being adopted on a massive scale across the industry. In this case cloud computing, I'm sorry, container adoption, but it could apply to anything really. But the finding here is that compliance is the number one concern among senior tech leaders using container management platforms. You could insert a lot of different technologies in that place, maybe Kubernetes and container management or some other technology platform. But the key here is when managing risk, it's all about how do we adopt the technologies that are gonna sustain our productivity while making sure that we comply with the various regulatory bodies that monitor us and also making sure that we manage the licensing, the open source licensing in a way that makes sense for our developers and users and how do we make sure that the guardrails that we've established can be monitored without getting in the way of our developers? How do we create a system that allows our developers to do their jobs without us interfering? And further to that point, if you look at the real impact of say, open source of DevOps and Agile and cloud-first principles, you can see a very real impact across the enterprise. This is a 2019 survey from the Linux Foundation, the wonderful host of today's session. But in this survey that was released in September of 2019, you can see that the organizations that adopt open source methodologies and an open source approach, they're the ones that deploy the most often. They're the ones that use the most open source code. There is a tangible relationship there that I think speaks to the flexibility that's allowed by mass adoption of open source software. And then we come to... I spoke a couple of minutes ago about how we view software usage and governance through a risk management lens. And to help us with that view, I often like to refer to the supply chain funnel, which helps us ascertain where a particular product is in its development lifecycle. But it also, when looking at this funnel, it also implies an ease with which it can be bidirectional, so that no matter where you are in the funnel, you're always taking in feedback and contributing back to the source of the software that you use. When you look at the supply chain funnel, think of most of the upstream open source technologies that we use in building our software. Think of those in the top layer. Those are the core development libraries the core platforms that we develop on. Think of all the JavaScript, no JS pieces that most enterprises use on a daily basis. All of that consists of essentially raw parts. And as we move down the funnel, these raw parts coalesce until at the very end we have a released product. And by looking at it at the software development process through this diagram, we're able to, first of all, make sure that we've got the processes in place by which we can sustain the developments of these upstream communities, but also see how it links to our overall product development so that we're linking our open source usage and methodologies directly to the value chain so that there's a clear link. We can demonstrate a clear link between our adoption of open source and the increase of value of what we deliver. One thing I really like to point out every time I talk about the sky chain funnel is this mid tier. It has interesting properties in its own right because this is the stage where the raw parts that you initially bring in, they first start to coalesce around a relatively mature platform, not a polished product per se, but a relatively stable and mature platform that attracts developers. This is where you build out your developer ecosystems as well as maybe get your first early adopters. And I love that the unique properties of this layer and I can talk separately just about that middle layer if anybody wants to hear me in another session. But overall, Capital One, just like a lot of different larger enterprises, perhaps 80 to 90% of the software that we develop comes from open source sources. And so by looking at it in this way, it helps us to understand the provenance of the software we use so that we make sure to think about the sustainable development of each parts of this funnel. Making sure that the top tier, the top of the funnel is sustainable is every bit as important as making sure that the bottom tier, the release product is also sustainably developed. So this is key to our thinking. So as part of undertaking this journey of modernization of our technology, modernization of technology takes the form of both the technology platforms that we use as well as the way we put together technology and the way we put together organizations to ensure this culture of collaboration. The open source program office was started some five years ago to help ensure that we have the processes and people in place to make sure that we're doing the right thing. And so this comprises five different channels or columns. So beginning with usage, how we use the software we take in and going back to this flight chain funnel would be like the pieces of software that fill out that top layer. How do we bring that in? How do we ingest it and push it into our development processes? How do we make sure that we're using the best versions? How do we make sure that we've identified and remediated significant vulnerabilities? How do we make sure that the license management is in compliance? All of these things we look at when we're bringing in new software for our developers. And the second piece of that is the contribution. And this is where I talk about, and this is where in the previous diagram I alluded to the bidirectional nature of the funnel. In this case, it's we help to mitigate risk by making sure that the contribution process is streamlined such that developers can take the changes they make and push them back upstream because we don't wanna be maintaining technical debt over time. And this having a streamlined contribution process helps us to manage our technical debt more sustainably. So it doesn't increase dramatically over time. We can kind of keep it at the base level. And then finally, sponsorship. Sponsorship is a word we use to describe when we release open source software projects. How do we launch open source communities? Again, this is key because for the software we develop and when you think about it from a technical debt perspective and how you manage that, when you think about it from making sure that the software is robust and delivers according to what we'd like, the visibility that it attains by being available in open source communities is highly valuable because now we have many third parties who will determine how well it works. And if it doesn't work as well for them, they will let us know and we can build that into the process and make sure that not only are we managing risk from a technical debt standpoint, but we're managing risk from a robustness of software standpoint. And then the last two things, this fourth piece, inner source, this is all about the culture of collaboration and ownership that we've worked so hard to build here. How do we make sure that our developers are coalescing around those middle tiers in the supply chain funnel? How do we make sure that the platforms we built are becoming viable standards that support the initiatives of developers and users at Capital One? And then this fifth one is, this goes back to the sustainability of the communities that we depend on. How do we make sure that the software we depends on will continue to be reliable over time and can sustain our innovation internally? And so this is where we invest in communities and foundations like the Linux Foundation, like the Continuous Delivery Foundation, like Fianos, the CNCF, the Apache Software Foundation, it's all about making sure that we can continue that symbiotic relationship and rely on these core pieces over time. All right, and now I'm gonna turn over to my colleague, Darian, Darian, take it away. Thanks, John Mark. As John Mark mentioned earlier, there's a whole area, there's multiple spaces that we had to go through and changes to our culture to enable not just leveraging open source, but modernizing our whole technology mindset. And so I'm gonna take you a little bit through the history of that, how we got to where we are, some of the pitfalls that we accounted for, some of the things that we learned along the way. And if you take, go back to the beginning where we decided we need to be a tech company, we need to play in this space because that is what is being, that's where all the competitive realities are. For us to really survive and lead in the financial space, we recognized we had to change the way that we did business and it had to start at the base here. And a lot of that came from our acquisition of ING Direct, that sort of kicked off the, hey, look, technology first seems to make a real sense there. So as John Mark said, going in all in on Agile was one of the first pieces there. And building all the way through getting open source, saying that we're gonna start dabbling in the cloud, going through containers, committing to the cloud, building a container platform for the enterprise, that's led us to where we are today, which is 100% in the public cloud. We have shut down our data centers, we have no more legacy system operations or anything like that. And to understand the scope of that, we have a technology organization that's about 10,000 strong. And having that change from waterfall to agile, educating that large group of engineers and folks comes at a cost, it is hard to do. And those journeys are the ones that are gonna be the most challenging for organizations. Open source actually makes some of that easier because there's so much available out there that we can leverage and bring to the table to enable our technologies to really help us do our business. Next slide, please. So as we started dabbling in the cloud, we have to recognize we're a highly regulated company. We are a financial company, people trust us with their financial health, with their money and we are 100% committed to ensuring that we do the right thing for them and keeping that trust. We also had to make sure that we enabled the engineers working in the cloud to understand the cloud, to how do they start operating the cloud in an effective way so that they could get the job done while making sure that we were compliant, making sure that we were safe in doing those things. Some of the things we had to do is stand up, we built a very comprehensive tech college to help educate. We have very large numbers. I think if this is, we're pretty close to having the highest percentage of AWS certified associates next to Amazon itself, because we believe in that education piece and making sure that the organization has the knowledge necessary to do these things. But we didn't get there overnight, right? Having this constant education and constant learning, it was absolutely necessary. And when we started moving into the cloud, obviously we can't just do everything all at once. It's a, let's take some of these easier pieces, some of the leaves of the tree there, things that were less dependent upon other pieces that we could move over and do a lift and shift to start out with. Next slide, please. So some of the mentality that we clearly had to adopt pretty early was, has to be automated, we have to have DevOps, we have to enable these teams to operate on their own. So we've had this you build it, you own it mentality. But along with that, of course, comes some of its own issues of duplicating problems, duplicating solutions. We've got 8,500 engineers, over a thousand teams, invariably team over here doesn't know what team over there is doing and they need to solve the same thing. Open source was 100% leveraged in almost all of these, but sometimes even leveraging those open source pieces, you can put them together in different ways that duplicate a solution, but in different ways. So there's a lot of undifferentiated heavy lifting that occurs when we wanna try and minimize that as much as possible. So next slide, please. Part of the pieces that enabled us to start being a little bit less duplicative in our efforts were some of these pieces of software that we recognized we had to have. One was Higia, which gave us the ability to view that DevOps pipeline, that CI CD pipeline, very well from start to finish and understand where everyone was. And in 2015, we were able to make that open source and immediately started getting great contributions from a huge part of the community out there. As it stands right now, Walmart, I believe, has over 5,000 active Higia users and they use it widely in their organization. Cloud custodian is a automated governance and security appliance, as well as some cost optimizations cloud environments. And we've had great engagement across the industry, Amazon, Microsoft, and we've recently donated it to the CNCF. And this is 100% behind our mission that John Mark leads here. We need to give back. We want to generate great software and we want those contributions back from the community because we know that there's brilliant people out there that have great perspective that we can also learn from. Next slide, please. So as we're going through this journey here towards more recently, let's say within the past couple of years, as we moved most of our workloads into the cloud using more fundamental portions of it, we realized, hey, there's a lot of opportunity here, maybe to consolidate workloads, to get a little bit more smaller bite-sized pieces. And so we recognized we really had to have a container platform for the enterprise that met our needs from a security standpoint, from a regulation standpoint. And we've been building that for us. Forrester recently found 86% of technology leaders plan to use containers for more applications. That is clearly aligned with us. We recognize that it is the path forward for us. We based ours on Kubernetes. And because we are, again, a regulated entity, we have a lot of unique needs and challenges that we have to solve for. Some of those pieces, some of those fundamental pieces of our container platform, we have open sourced. CRIT is one of them. E2D is another. Those are available on our open source repos on GitHub right now. And as we look forward, as we move forward and build up more, I'm sure more pieces of that will come out because we want to leverage the investment that the community can provide. Next slide. So, in closing, there's so much opportunity with open source software for an enterprise, even a highly regulated one. From our own experience, our journey of moving into the cloud and becoming this tech-first company could not have been made possible without open source. Yeah, that's a very good point. It's interesting to look back over the history and see how much of the current state of technology, as we know it today, how much of that would not be possible if not for the initial development of open source platforms that's been crucial, as well as the cloud platforms that have developed concurrently. The other thing I want to point out is that when we talk about risk, mitigating risk and risk management and the software supply chain, it's crucial. It's a vital importance that you learn how to build the relationships with your risk partners. This is something I like to emphasize a lot, which is there's a tendency among developers to, I guess, misunderstand the intent of the auditors and the risk managers and those folks and legal staff. And I just want to mention that those are vital partnerships that should be built in order to, if you want to build and sustain and make this manageable over time, it's crucial to bring those people along and make sure that they are your core partners when you move forward with any of this stuff. That's one of the takeaways I've had from working with in Capital One as well as a variety of other companies. They can help you unlock so much as you move forward and we couldn't do what we do without their support and input and helping to move this forward. So when you look at things through a risk management lens, run that by your risk partners and make sure that you've established, done the work to establish those relationships. That's a great point. And I think that's the end of our core content. I think right now we can open it up to questions. I think there are some... Yes, I will... I've got some questions. Yeah, I'll be the presenter of questions. Cool. So first one for you, Jean-Marc, is how has Capital One tackled legal and governance concerns around open source contributions? Excellent question. The first part of that is... I'll answer that by taking on the first unspoken part, which was there was a long process to make sure that we were governing open source usage first and foremost. We had to make sure we had the processes and the infrastructure in place to support what we wanted to do with open source from a usage standpoint. When it came to contributing, one of the things that attracted me to Capital One was I've been in open source communities for many years, and I saw that it takes some work to get large enterprises to be engaged and to be contributing to communities. And that's what attracted me to Capital One to help streamline that process. And one of the things that I found out is that speaking of the unique challenges that we face in the regular industry, it was basically a question of how do we frame the issue? If you frame the issue as, yeah, we want to stick some things open source, it's because it's fun to do, it really has to be about what value does it deliver. And once you frame it as, hey, we need to balance risks by making sure that we're managing our risk of technical debt management, we're managing our risks of not being visible externally. These are all the things that we have to balance when we're conceiving of our contribution processes. So we made some initial headway on this a few years ago, and then over time, we've been able to refine that and streamline the process. And in fact, we're in the process right now of further streamlining it and making it more accessible and easy to use for our developers as part of our ongoing building of the culture of cooperation. That's great. Just as a reminder to anyone listening, if you do have a question, please just click the little QA button, you can put it right in there. The next one I'm going to take, what makes a container platform compliant? What regulations does Capital One care about? So that's a very good question. And I think when it comes to your companies, it's going to be a variable. From a Capital One perspective, the things we care about are, do we have some sort of chain of custody of those containers? Can we guarantee what is being deployed into production is exactly what was committed in code? So we have that viability and the ability to verify what that actually is. Are the things running in the container platform all from the appropriate place? Have they all been vetted appropriately? Do they have the appropriate permission lockdowns? Do we have them tagged appropriately so that the right teams get called when those containers are not running well? The composition of the containers themselves, are they as minimal as possible? Do we have as little vectors of attack as possible in there? Are they patched? Are they rehydrated? How long are they running? Do we want a container that sits there and runs for 60 days and never dies? Probably not. We'd rather probably have something that runs for maybe a maximum of 24 hours and leverage the capabilities of containers to automatically spin up and spin down and balance across live containers so that even if someone were to compromise a given container, they would only have a short period of time to do any work inside of that container. So a lot of those things that we think about, they're not necessarily baked into any platform. There's no one tool out there that does all of this for you. A lot of it is open source software that we've had to leverage and software that we've built to help us achieve these pieces so that the developers don't have to think about these things. They just know that they deploy a container and it's gonna be compliant by using this base container and these tools inside of production will automatically handle some things for them. Next question for you, John Mark, is how do you harden the open source supply chain? Is this SDLC simplification? How do you harden the open source supply chain? How do you simplify SDLC? Yeah, maybe I'll take a pass on that one, but hardening the open source supply chain, I can address that. You harden the open source supply chain by being involved and being present. And this comes back to how we view risk. I've seen so many companies that view risk from the standpoint of we're gonna take an open source code and we're going to scan it for vulnerabilities and then we're gonna remediate those and we're gonna use our software and we're done. That doesn't harden the supply chain. That is basically foregoing the supply chain maintenance to somebody else. Whereas if you are involved in the supply chain process and developing it, you're going to ensure that it's more robust, more sustainable over time. And by being present and involved, you're helping the communities on which you depend be more reliable and sustainable over time. I feel that this yields the best results over time because what better way to manage vulnerabilities and protect cybersecurity than to prevent vulnerabilities from ever appearing in the first place? This is especially why contributing and being present in these communities is so important. Yeah, that makes a lot of sense. Okay, next question, I'm going to answer this first one and it's gonna be a quickie and then I'll just answer a follow up to the containers. So the first question is how long does it take for a company to become 100% in the cloud? Well, I can share with you my experience with Capital One. I joined almost four years ago to the day and when I joined, we were about 8% of our workloads in the cloud and we were 100% in the cloud earlier this year. So for us, it was a three and a half-ish year journey. That I think is going to be very dependent upon your individual organization, the commitment you have to that, the buy-in from the very top because it's not an easy process. It is extremely complex to do and there's only really one other major company that we're aware of that's done it and that was Netflix. So there's probably others out there but nothing probably anywhere close to our size and revenue or anything like that. Does that drive with you, John Mark? Oh yeah, absolutely. And then the other piece is, let's see, oh, okay, the question has changed a little bit. So do you still use UbuilditU on it? The answer is yes and we've just shifted that a little bit, right? So now the platform itself has responsibilities for certain things but as a development team, you're still responsible for the construction of your container or your Lambda or whatever it is as well as being responsible for operating it and making sure that the metrics are set up correctly, the scaling is set up correctly, the on-call rotation is all there. Yeah, it's core. Our teams embrace that, it's a core part of who we are. Absolutely. All right, question for you, John Mark. What is your strategy for joining or contributing to open source foundations? That is a terrific question because it changes over time and it really depends on linking the software used to the value that's delivered, taking a look at what software do you depend on? What communities do you depend on? How is it used internally? And then we use that to determine which foundations doesn't make the most sense to support financially. A lot of this comes down to which foundations, which communities are our developers already involved in? So we take input from a variety of sources from our developers but ultimately it comes down to how do we, again, viewing through risk management lens, how do we ensure that we are best able to sustain our innovation internally and using that to determine and basically ranking which foundations are the most important to us and which ones do we participate in? So that's definitely the approach we take. But again, it shifts. Technology changes over time, new foundations pop up over time. We have several different teams that will take on new technologies that we have to be kept up to date with. So it evolves but we're always looking to see where should we be putting, placing our bets. Yeah, I can only imagine and I'm nowhere near as plugged in as you are to the whole ecosystem. I mean, they're probably what, dozens of different foundations out there that you have to keep a pulse on. Yeah, you can't throw a rock without hitting three different foundations. Oh, it's, yes, it's a, there are a number of, there's no shortage of communities to invest your time and money. And that's why you have to be, that's why you have to link it back to the value that you deliver and make sure that it makes sense when you're putting your resources into various communities and foundations. Ultimately, you're going to need to be able to back up your claim that investing in these is important. And what better way to do that than to show the usage patterns internally and what, which ones are the most important to you? Yeah. All right, next question. I think this is one that maybe we can both tag team on. Understanding that company-specific software creation will not be open sourced and that technology-based capabilities can be open sourced. Where does Capital One draw the line on open sourcing when it is industry-specific, i.e. regulation-based capabilities? That's, that's, ooh, that's an interesting question. You know, it's, I would say it's early days yet, but I would say that there could be an opportunity to partner up, speaking of our open source foundations, we are involved in the Phenos Foundation, which is comprised mostly of financial institutions. And I know that's certainly an area that they care about. And I look forward to continuing that conversation. I think it's going to be more important every time. Yeah, that jives with me. And, and, you know, I think maybe a little bit more when I think about it, you know, we open source cloud custodian, right? And that is the way we ensure compliance. And yet we're not necessarily giving away the secret sauce as to what those policies specifically are on how we, we, we secure things, mostly because our environment is going to be different than all of yours out there, right? We have, you know, hundreds of different AWS accounts and GCP and Azure and things like that. And how we've structured them has evolved over time and it may not be the same as yours. So those policies may not be appropriate for your environment. And I would, I would think that, you know, we never want to give away the secret sauce, which is our secret sauce is banking, right? It's financial. So those pieces of software, we will probably never open source, but all the things around it on how we operate, they're probably quite a bit more that is available than we have yet to open source. Thank you for bringing that back to cloud custodian because yes, the core technology pieces, the core platforms, we feel that they're a general enough and we feel that we face the same problems as several other enterprises that those are the ones that are most viable. And to Darian's point, you know, chances are the specific policies that the content that we use on top of these platforms is frankly not useful to the vast majority of people, but the core platforms and getting those in a place where they are more robust and ready to serve general purposes, you know, that's where it makes sense to invest most of our time. Yeah, that makes sense. I've got one more for you, John Marker, and then I think we're gonna wrap. What is the biggest challenge as Capital One sees it around enterprise developers contributing to open source communities? The biggest challenge, that question could be addressed over days, weeks, months. Sorry, go ahead. No, it's a, I mean, that's part of the, I mean, that's an evolving answer too, just because this most significant challenge is change over time. You know, initially, maybe if you scroll back a few years ago, the biggest challenge was making sure that we had, that we knew who was contributing what and that we could manage that a little better, and that was really down to, how do engineers know the best way to contribute software? At this point, I would say that the biggest challenge is how do we facilitate the relationships between our developers and the upstream communities to which they contribute so that we can pave the way for more streamlined processes? Every community has its own standard for contribution, and engineers have to spend a lot of time coming up to speed and what each of those are. And so I feel that part of our job as an open source program office is to help them, you know, learn those skills and learn how to pivot between communities as needed. That's probably the biggest challenge. It's really not technical in nature, it's really community-based. I would 100% agree with you, and I was thinking in my head, you know, when it comes down to it fundamentally, from my experience and seeing my teams, it's time, right? It's what time do they have where they can contribute and they can take the time to go through and engage with those communities, you know, do the PRs, making sure that, you know, the code we, you know, commit is, go through the appropriate process, make sure we're not, you know, exfiltrating any data and all this type of stuff. Yeah, the fact of the matter is, you don't need a majority of your engineers contributing upstream to communities all the time. To make it sustainable, you really only need some group, core group that does this on a regular basis. Frankly, and to your point, it all comes down to time and time management and making sure that people are focusing where they need to be. And that's probably the biggest challenge, just making sure that you've got a clear, you know, guideline for who's contributing and when and how. Yeah, I think that's great. All right. All right. Well, thank you so much, Darian and John-Marc. We really appreciate today's presentation and your thoroughness with the questions. I'd like to wrap us up and just thank everybody for joining us and have a wonderful rest of your day. Awesome. Thanks, everyone. It was a lot of fun. Thank you. It was fun. Bye-bye.