Las Vegas 2019
Digital Framework for an Agile Cloud Governance Program
Brian will cover a specific requirements and a solution that USAA utilized to solve the challenges in a vendor neutral and technology sanitized way.
BM
Brian McCarty
Principal Technical Architect, USAA
Transcript
Hi, my name is Brian McCarty. Um, I'm with USAA. I'm going to talk today about, uh, what USA has done for a cloud governance program. Uh, basically gonna focus a lot about how we try to digitize as much as possible to, to remain agile in a highly regulated environment. So before I really get started, though, this is a, I've done this talk a couple of times. Uh, this by far is the largest group. Uh, normally there's only a small number of people that are really interested in, uh, FFIC regulations and, uh, how to do dev ops there. So just maybe a quick show of hands, how many people actually work for a financial services organization. So, okay, so that, I guess that explains it then. So, okay. So, uh, this is the, uh, this is a significant amount of, uh, work. Uh, one of this, this is something that's actually, uh, you know, operationalized.
So, um, we won't be able to cover everything in the small amount of time we have here. However, I will be at the speaker's corner. You can also just find me on LinkedIn and just send me a note. I love talking about this stuff. So, uh, we'll get into that a little bit in a minute. So, um, maybe just another quick show of hands who actually knows a USAA is okay. Even better, uh, may members, uh, hold your hand up if you're still a member. Okay, great. So if you were in the armed forces, uh, you know, we appreciate your, your, uh, appreciate your commitment to, uh, USA and to the U S so, um, if you weren't, no, even if the member, even if you are a member, uh, USA was founded as an innovation group back in, uh, uh, back in 1923 by 22 army officers, basically what happened was at the time, um, army officers are actually anyone in the military was deemed to be a high risk, um, uh, to be able to insure them, uh, for automobile insurance.
So basically, so basically USA was founded on an innovative idea of like, well, if we can't find someone else to do it, we'll just do it ourselves. So the 22 army officers actually, you know, uh, created, uh, an organization that's referred to as reciprocal interest exchange, if you're paying attention. Um, but so, so, um, you know, it's a great story and we actually use it all the time, even internally about, uh, any new innovations that we're working on. So a hundred years later though, you know, we do provide a full range of, uh, of, uh, insurance, uh, banking and, uh, life products. So, um, so, um, I am going to talk a little bit about a background just to make clear about where we came from, the reason that we had to put so much emphasis on cloud governance. So just give me a second, you know, it will come together.
So, um, um, USA recently actually just broken the fortune 100, actually a hundred spot. Um, uh, that's not by itself, isn't as relevant as, uh, the next point, which is we're now the, uh, in the top 30 largest banks in the United States, which means there's a level of rigor that ha that goes along with being a large financial services institution, uh, that we weren't, didn't, weren't previously subject, subject, subject to, um, but, um, you know, more, more than that a second, but, uh, basically USA is, uh, always been considered a great place to work. Um, you know, I've, I've worked there for bulk of my career, you know, I love every minute of it. So, um, uh, but so, yeah, specifically though, um, uh, since we're not a corporate structure, uh, you know, all profits return to members, um, or reinvest in the company, um, but since we're owned by the membership and that membership has done something, um, uh, has, has, you know, bravely, uh, uh, you know, fought and died for, for, uh, for the United States, right.
For, for America, what we do is we try to have, we have an extreme focus on understanding, um, being ethical and having compliant operations, right. Um, it's, it's all, it's all part of our, uh, you know, it's part of our DNA, it's part of our culture. And so, uh, when we realized that we needed to increase the level of rigor and accountability for delivering technology solutions as a large banking institution, uh, we, we, we had, uh, kind of retune ourselves and, you know, it's kind of reassess, what is it we weren't doing, uh, or should be doing better that, uh, to meet those needs. So, um, and just wanting to serve. So, um, uh, uh, part of those regulations though, um, were mainly around, uh, the financial crisis 2008. Uh, but even if, you know, some of the FIC regulations go back, you know, decades, uh, but some of the increased scrutiny did come out of, you know, the 2008, uh, too big to fail factors, which is where that kind of 30 bank, you know, threshold, uh, you know, came from, right.
But since we've always strived for ethics, accountability, and compliance, we had to develop some new muscles. And so that's what we're going to talk about today. Um, uh, uh, also there's to put this mildly, um, our membership, um, uh, you know, serves is, is, is unique, right? Uh, being 100% owned, uh, by members of the armed forces, uh, we're actually a high high-profile target for state sponsored terrorism, uh, state sponsored cyber techs, that kind of thing. Um, I don't actually, uh, getting into some of the statistics there, but, uh, safe to say you'd be very shocked at the level of, uh, uh, of, of cyber threats that do face, uh, face us as a financial institution. There is at least one statistic on there, 13 plus million cyber attacks that was too as a 2018 statistics. So, um, uh, since, uh, cloud and security is cloud, you know, it goes, it goes without saying so, uh, we start every mission meeting, um, uh, reviewing our mission or USA standard to make sure that whatever we're about to do or talk about or decisions we're about to make live up to the mission and live up to the standard.
Um, so w uh, recently though we did do a review of this and understand that now, uh, we added an additional attributes to the USA standard of being compliant and managing risk. Well, cloud governance is being compliant and managing risk. So we're going to show how that's directly, uh, uh, directly related, right. To the USA standard. So just, uh, just a quick, quick thing about me. I, so I work with the chief technology officer, my principal architect there, um, I'm responsible for cloud governance, uh, architecture, technology, business management, agile. I'm probably gonna end up referencing technology, business management a little bit later. Does anybody here know what technology business management is a raise your hand? Does anybody know? Okay. Just one, two, maybe. Okay. Uh, interestingly enough, I'm actually back here next week for the technology business management conference, two weeks of Vegas in a row, not sure what that's going to do to me, but you get to see me only on the second day.
So, um, so there's a few disclaimers though. Uh, as we're talking about this, um, just wanting to be aware, I did take some screenshots, not a live demo, some things we built. Um, this is a non vendor specific, uh, presentation as was disclosed. Uh, if you've got a quick, I, you probably recognize, uh, what platform is used to develop some of these, uh, the digitized workflow for governance. Um, I can talk about more about that in a more of a one-on-one setting. I just can't do it, uh, up on the stage, but it's not really relevant, uh, to the rest of the conversation. Um, and also, I may, I may say verbally a few statistics, um, uh, but they're not up on print for reasons. Um, that's why there'll be redacted. Um, and just to be clear, um, most of what we were referring to for the FFIC specifically around the OCC office, currency control isn't as a us, you know, regulatory authority.
Um, but some of these things still apply if you're from the EU, um, I've given this talk and I'd given a talk in Dublin one time for the open group. Um, and they were like, they, they knew that they immediately, you know, latched onto it as well. Cause they basically had the same kind of requirements. And also I got a little bit of jet lag, so, uh, work with me there. So, okay. So what are the motivational forces for being able to do cloud governance? So basically there's internal internal, what I call internal factors, right. Which is really business growth. Um, both organic, um, our memberships just growing as well as marketing. Um, you may have seen commercials, uh, probably hopefully you liked them. Uh, not quite as funny as some of the competition, but, you know, they're, they're, they're good. So, um, we're doing a lot more innovation around, uh, eliminating technology debt, um, at USA, as well as building some new solutions.
There's been a few in the marketplace, including an announcement we made with Google a little while ago about doing automated machine learning, using automated machine learning to, um, immediately identify or assess auto damage just by taking a picture. Um, does anybody, does anybody see that in the news? It's pretty cool. So basically just snap a photo of your car and we can tell you instantly what's the, uh, uh, what's it going to cost to re you know, what's the estimate to replace it right to fix it? Um, so, uh, that kind of thing, as well as technology business management is basically like we have a renewed focus on trying to understand all of our technology investments. We have about a $3 billion, uh, technology spend per per year. And so we're going through an exercise. You know, now I've really tried to rationalize all those expenses and really understand what's driving costs so that we can get good return on investment.
If anybody notices, how many people think that their public cloud expense may be running, running away for them, is anybody have that concern? So what we did well, and I'm gonna talk about this some more, but as basically saying, we ingrained, um, their use of infrastructure and platforms, service solutions directly in our technology technology, business managed strategy. Um, you cannot, uh, that's part of the governance, right? So we don't, we're going to try to prevent the runaway, spend that some other companies that adopted public cloud more early are kind of, you know, exposed to now, uh, we'd kind of learn from others and then have embedded some things immediately in our, our workflow here. So, and of course, external factors, almost all suppliers are shifts in the cloud in terms of the elimination of commercial, sell software, moving to soft transition that software software's a service.
The technology cycles are far greater now, right? Recycling through a technology, you know, with technologies that may be in place for 20, 30 years, they may be only a place for months at this point to solve some particular problems. So we've got to go faster and of course the regulation scrutiny. So all of that basically means that we need to be able to digitize all of our, all of our work. We need to automate the heck out of it. Um, and we need to, we need to do risk management, but we need to do that in the, in a reasonable way. Meaning not all use cases have the same level of risk, right? So therefore they don't need the same level of rigor around compliance. It's a lot of what we did was try to understand, uh, take a risk-based approach to governance. If you're not doing something risky that you try to identify if it's going to be risky or not early on right.
Shift left so that you don't put a burden, uh, to the, you know, to the right on the pipeline, uh, unnecessarily. So there's a couple of tricks to that. Um, we'll talk about that, of course, trying to maintain agility. So, um, just to, just as a reminder, if you're not familiar, um, there is several regulations in the space, but basically it all kind of boils down to the FFIC saying, um, and I think rightly so, right. You know, I don't want to, we're not, I'm not actually dragging any, uh, any, uh, regulatory bodies, uh, through the coals here. Um, it actually makes sense that a large financial institution ought to have a really good third-party risk management, uh, strategy. Um, no company in the world survives without third parties, right? So, um, all public cloud in some shape or form is third-party either you're buying something from a public cloud provider, or you're about to deploy something you built to a public cloud provider, but it's impossible to do cloud without understanding what your third party risk is.
Uh, so these, so at the end of the day, really what these say is you need to be doing good third party, risk management and so forth. So that translates public cloud. They actually saw somebody take a picture. Um, I usually stopped to say that it's like, this is real easy to Google. Um, you, that you think it would be really easy to Google, but actually it's, it's kinda, it's, it's hard to get down to like the specific line item that says, what is it you're supposed to be doing or not doing, um, uh, you know, the handbooks like this thick. So, um, literally I seen somebody print them out. They're like that thick, so on, uh, one of my business partners desk. So, um, anyway, so that's it. So what we did was is that we, uh, first we established a program, right. A whole program around cloud governance, and it starts at the very top, the board of directors level.
So the board of directors, um, decided to, uh, well, of course we propose something to them, but they basically said, we're going to put in place a cloud computing policy, what it's tied to, um, mission standard corporate strategy, and then CA left it up to people like myself, you know, in technical leadership roles to define what that cloud strategy ought to be. So what, the reason I start there and I say, well, Brandon, we're not really talking about standards of strategies. We'll be talking about governance. The point is, is that you can't do governance. If you don't understand what it is you're supposed to be delivering on. So you have to have some sort of strategy in place first that is harder than it is to do governance. Um, if you think your organization has a really good strategy place, I love to talk about that later.
It is very difficult to outline a crisp and clear strategy, um, at both a technology strategy. And of course also our cloud strategy. So, um, uh, maybe one day I'll given a talk about, uh, uh, going through that, but basically the cloud governance is saying, we need to align, um, the ability to manage risk and measure risk versus the reward we're going to get on what the strategy is. Right. So if you don't know what the strategy is, you can't really do governance. So, uh, so let's move on to governance itself. Um, at USAA, we actually, uh, refer to, uh, you know, uh, basically kind of six pillars of, uh, privacy data, risk architecture, audit security. Um, you may have something different than that, but basically that's the governance, uh, should encompass at least those dimensions, if not others. Um, okay. So that's kind of, that's kind of clear we have this really cute name called control partners for that.
Um, I don't know if that's an industry term, that's just what we say. Um, and then there's one layer down, which is referred to S uh, cloud management. Okay. So if you Google cloud governance versus cloud management, find out that governance is about standards, uh, establishing, uh, you know, standards in a way of behaving to be able to manage and measure risk. Um, cloud management is about actually operationalizing, right? The pipelines to get, you know, code into production. Um, we refer to that internally USA, we have a product, we purchased safe landing, meaning if we're going to manage the cloud, we need to be able to land workloads into the public cloud in a safe and secure way. And so that's really at the heart of it's a DevSecOps discipline. Okay. It's just so happens that it's ecosystem specific around public cloud. Does that make, does that make sense?
Okay, so that's where the DevSecOps comes in. I am going to talk about software service just a little bit, because I did see there's many people's hands up that worked for a financial services institution, but I'm sure most people are a little more, uh, interested, you know, being, uh, uh, dev ops conference around, uh, software that's being developed and then of course deployed. Right. So, but we'll go, uh, we'll go through that. So the plan of attack, all right. So we had like an outline of what it was we're going to do, but we realized we needed some really key things to make sure we delivered on before anybody, uh, uh, you know, before we could really establish a good program itself. Um, so, uh, we established crock collect repeating policy approved by the board. Um, we identified that political control partners and we solicit executive support.
If you don't have that first two layers of having board of directors level approval, um, and senior vice-president type, you know, commitments, you might as well quit. You might as well give up. Okay. Cause you can't do this unless you have the full commitment at I at both horizontal, you know, horizontal across reporting structures. Uh, so, uh, uh, report, you know, um, uh, commitments at a vertical level, right through the vertical channel of your organization, because the governance is a cross cutting or horizontal concern. So if everyone isn't brought on board and the different vertical silos, right. In an org in a large organization, you'll never be able to get that cross-cutting horizontal view. That's so important. Does that make sense? Okay. So, um, we also, uh, were able to secure funding to basically build up a small team to ensure that even though we're digitizing or trying to automate, you still need a good small team to like continuously look at like the consistency of it, is it doing what it was supposed to do, uh, is that data hygiene, that data that we're capturing to report to regulators, uh, good and clean, um, so that, that does still require some human capital investment, right.
Um, even if you do focus on digitization and automation. Um, and then, so we, we came up with an a, you know, a risk-based approval process that took some iterations. We're on version three now, um, that has some key performance indicators. And of course we digitize as much data collection as possible and automate, automate, automate. So, um, all right. So I'm just going to hit the high level real quick. So basically the risk-based approaches, you know, the corporate leadership, uh, supports our cloud enabling group, which is a body of exec, you know, executive levels that, that, that has the authority to actually make like executive level decision. They meet very regularly, uh, all exception cases, all outlier, uh, outlier cases that we haven't thought about before, um, get reviewed there. It's actually a very lively discussion. Um, we couldn't get people to show up at a meeting two years ago.
Uh, now, like it's a packed room, uh, bringing people, bringing questions and concerns. It's just really cool. That's a measure of success when people actually show up to, you know, and volunteer information. Right. So, um, and then, so then there's what referred as the cloud review panel. It's basically the worker bees, right? So it's the people that the SMEs and the different spaces actually providing support to do the, uh, the governance itself and say, well, what is that governance? It's, it's, it's what we just referred to as cloud review process. You can come up with your own cute name. Uh, we like CRP because, uh, it's, uh, uh, sounds a little funny when you say like, you know, you see the thing, some people got it. All right. So basically we review use cases and then we approve them and it was like, well, Bri, what happens if you, you know, you, do you prove everything?
No, we don't prove everything. We deny things. Okay. Well, what happens? You deny things. Well, we, well, well, like we're grown up. So what do we usually do? Like, we have a conversation about it and figure out what is it that like kept someone, you know, what is it that's causing concern or alarm, right. What is the risk that we feel is unworthy of the reward that we're about to receive? And so it is possible that you could escalate up to the corporate leadership, but, um, has any, has anyone ever done that before? No problems get solved before you have to escalate to that level? Right. Theoretically, I could take something to board of directors. I don't plan on ever having to do that. Right. That would be, that means we, you know, we failed as like adults to have conversations, right. So, and then basically the review process doesn't actually end there.
Um, we trace everything all the way to the time it retires. And so that's actually really, that's actually an important topic. You can't let things just dwindle or just survive in perpetuity. They should be, uh, you know, reviewed on a regular basis to ensure they're still valid. Um, okay. So let's just go through the, uh, the flow real quick. Um, I'm just gonna, uh, touch on SAS real fast because it's, it's really pretty straightforward. It's what I just said before. Except once it's approved, then it goes to contracting. You're not allowed to sign a contract in any shape, fashion, or form, uh, for a public cloud, you know, for technology provider third-party technology buyer, without, at first having an approval from cloud review panel. That's a really key point. Okay. Um, this is what prevents at the corporate level that prevents, um, uh, business areas from, uh, purchasing technology solutions, their own, without understanding the risks that they're, they're exposing the organization to.
Um, this is why you need board of directors level approval. Um, so that, well, there you go, I'll leave it there. And so that moves into adoption. Right? Let's talk about, ask a little bit more, cause, um, it's slightly more complicated. So, um, with that review, what we do is, is we try to, um, analyze what's the risk and what is the outcome that we're trying to achieve for some new effort? The reason that we do this upfront and we get approval, basically in step two down here. What's, I mean, I'll just tell you, cause the sake of time, I don't want to do too many trivia questions. The reason is, is because we're trying to protect the developer community. Do you really want developers to have to worry about the level of complexity of FFIC regulations? And, uh, am I supposed to be doing this?
Am I not allowed you don't? We don't want to do that right. By the time it gets to them, it's we can, they can do their development. They can put things on the pipeline. The work has already been done, uh, by people that, you know, uh, uh, that were, uh, you know, jackets in pocket squares, right. It's done before they, they have to work, you know, so that we can try to protect them from context switching or stopping and starting an effort because someone's put them on hold. Um, so, so I mean, so that's the point, right? As we try to review, what's really showing a step two right here. Um, then development happens, right. Working with operations where, because security make sure the solution is going to our safe landing environment, um, uh, meeting the, uh, you know, the, some criteria that was set out at a time, um, hits the pipeline gets deployed.
Um, I can't mention the name of our, uh, preferred public cloud provider. Um, but you know, it's one of the large ones everybody uses. Um, you know, so, and then, uh, the workload lands. So now what, all right, so the workloads, this is what we're working on next is that we're trying to get it such that, um, all, uh, because we're doing everything from source, right. Basically it's Terraform. So everything comes from source that the appropriate tagging is in place ahead of time so that we can actually verify in production on a regular basis to prove to external authorities and internal auditors that, um, we, we, we consciously made a decision to prove this use case to being pushed to the public cloud. And so that's not actually very easy, right. Um, because, uh, use cases, ebb and flow, they flux, right. They add scope there do scope.
So we're kind of figuring out what can we detect in the workload itself to know that it's still within the, the, you know, the guard rails that was set set in place early on. A few of those is because we tagged some very important things, environment ID, the application ID and the cost center, but we're also looking at some other at other options, if you're, if any of y'all are working on how to do that, right. Like, you know, uh, basically more like a, like a, like a day, two type scenario, uh, to prove what workloads are actually being done, um, in the public cloud. You know, I'd love to talk about that. Oh, let's just do this real quick. I know you may not see down here, so I'm just going to read, it says there's one and only one enterprise level agreement allowed with eyes and past providers. How many, um, so I'm not going to mention vendor names, but let's just say, you know, GCP, right? Google cloud computing, uh, Azure, AWS in those big ones. How many, uh, let's just say, use AWS, how many separate agreements to each of your lines of business have with those public cloud providers? Has anybody won one, two? What? Just one pretty good. Okay.
Five. Yeah. That we know that you know of, you have to put a stop to that. That's that's part of this thing is right. Is it a master service agreement needs to be in place with all the terms and conditions we can negotiate negotiated with the full force and effort of whatever it is that your, your organization is capable of doing from your contract department, with those cloud providers. And then you need to monitor, uh, through expense management that people are not going outside of that master agreement. Okay. If you're a financial services, I mean, you can do it. I think you want to, I'm just saying, this is like what it takes, you know, this is what it takes, uh, because if you're not in the account taxonomy under that master service agreement, you're going to have a bad time. Right. So, um, uh, well, anyway, so I have one and only one, um, a few things, a safe landing controls.
The reason that we have only one account taxonomy that we use in one master agreement is because all of the controls for the public cloud provider on landing workloads are standardized. At this point, they're referred to as like guard rails, right? So you, the big circle, the big wheel of the ones that we care about it's we have, uh, we're going on something in the order of like 400, over 400, a separate controls are in place, uh, that, that basically, uh, you know, fall into these spaces. I just kind of highlighted a few of the key ones that you need to do upfront, but as you get more mature, there'll be additional ones. Um, there's some, uh, there's some industry work going on right now around trying to establish what those controls are, because something like an AWS or GCP or Azure, they expect a shared responsibility, uh, you know, agreement, right?
You have shared accountability and responsibility to use those providers. Um, so we had to sit out with, stand up and figure out what is it that we are, we should be responsible that the vendor is not doing force. And so all those controls fall in that fall in that space. So if you deploy in our pipeline, uh, to our public cloud provider, you're going to automatically receive those, you know, 400 and something controls, right. Because we've governed and we standardized the method for pushing software to that public cloud provider. Uh, just hang on, let me just say it one more thing and I'll take some questions real quick. So there's a cloud service catalog. Um, basically as new initiatives come in, I just wanted to get some screenshots. You could see that, um, you know, we're trying to digitize as much information as possible. Uh, no governance has ever done via email walk-ups spreadsheets, anything like that.
If it's not actually in the system, it doesn't exist. Okay. That's I even do that for my I'm the technical architect for, uh, dozens of, uh, cloud use cases. Uh, if I just don't tell my tech lead over slack or email, oh, it's fine. What to do is actually go to the system and record that I've made a decision here about something, right? So that's, it's recorded in perpetuity basically to the end of time is the point. So a couple of screenshots, I redacted a few things. Um, the main thing I just wanted to point out here was notice the lifecycle drafts submitted pending updates, canceled, validated, scheduled followup, withheld, reviewed, you know, so there's, there's no argument about where we are in the governance life cycle. Um, that's a, that's a really key point. Um, also we do this, um, the space back to the risk-based approach.
I saw some, some people that were, seemed interested in on this is, um, we don't push, we don't based on the phase of the effort trial, pilot production, we increase the level of risk, uh, the level of accountability, the level of controls, because the level of risk has increased. So this is a real key, a key point. We try to really understand, are you in a trial pilot or production phase so that we don't overtax the engineers, the people that are working on the, uh, you know, the solution for something that is not, not yet applicable, this takes practice. This is not something you can do overnight. You have to practice this trial basically means you're doing something without, with no risk to USA, meaning it's usually using a contrived or industry data set of some kind, just to test a capability, right? There's no risk and data loss or something like that at all. So that's basically what trial means.
And then we repeat the review process on the face changes. So it's fully audible history. Current status has never vigorous. Um, I'm just gonna put this up for a second because then, uh, we're gonna switch to some questions real quick. So basically these are the digitized, uh, sources of truth that we have so far. Um, every single one of these is actually pulled together as a digital source of truth in our, uh, what we refer to as cloud service catalog, but basically the inventory of all the governance use cases. Um, we're constantly trying to find better ways of eliminating humans from having to type copy paste. Uh, I don't know if you realize this humans are actually kind of, they're difficult, right. Like to deal with. So, um, it's better to work with, uh, you know, trusted sources of information than try to rely on, um, someone's intuition or their, uh, memory.
So, uh, we relate to these sources of truth back to the cloud catalog. And so they are all these sources of govern. Um, this took a L a lot of, I don't wanna, this took a lot of work. Okay. I don't want to like, act like this is just, uh, uh, all unicorns and rainbows. This is a lot of work to, to do this, but it's worth at the end because now we're driving through something like 400 use cases a year. Um, uh, that's something like 300% growth year over year. Right. Um, if we didn't invest in this back when we did, we would not be able to sustain the level of throughput that we're doing right now. That's, that's, that's the bottom line. So with that though, I'll take a couple of questions since it's a two minutes, 20 seconds worth of questions, like yes.
How long was your charity?
I, uh, so we started cloud Garmin's program in 2009, but what you're looking at, right, is it, this is version three. So the version three took about years, that entire process. We've got everyone on board. We know all the data sources that took about three years. Yup. Yes, sir.
You Sandy or CIC through that thing.
So, um, just going back to that real quick, what we're trying to do is keep th that's kind of why there's a handoff here. We're trying not to have to expose the pipeline, like the guys that handled the keyboard, trying to actually crank out software of having to worry about what's going on around, around this, right. From a governance perspective. So the answer is no, but that's by design. We don't, we don't want them to have to worry about it. All I really need to be able to do is verify, you know, when workloads deployed, if someone comes and tries to audit and say, no, it's fine that those guys built the software, they're delivering a solution that we said they ought to be able to do. And, you know, we've, we fully evaluate it. Right. But that's where tag, that's where the tagging comes in. The only thing we really need them to worry about is make sure you're following the tagging standard, but they should be doing that anyways. So does that answer your question? Okay. Yup. So we have about 3,100 applications in our application portfolio, imagine inventory, but 30% of them are public cloud or hybrid. So, um, you know, it's pretty good, pretty good number. We're actually pretty risk averse in terms of, uh, you know, uh, adopting public cloud. But I actually see the number we'll probably double, uh, within the next couple of years
or database, if everything is in cloud.
So they go, but that's where the hybrid, uh, part comes in. So there is some work going on to basically build, you know, kind of systems engagement and public cloud, but still have, uh, some, uh, reference data mainframe based data, things like that that are still it's still can be exposed through, you know, API APIs, right? So the API be exposed on prem, you know, but the application would be running a public cloud. Um, there's just like, there's this nasty thing called the speed of light problem. That seems to get in the way some of that. So we're still working through that, but we haven't figured out how to violate the laws of physics quite yet, but you know, we're working on it one more.
Yeah. So you're using the CMDB is your source of truth. Oh
God, I wish I had more time to talk about that. And it's really cool how we did that.
We'll figure out what upstream assets, repos pipelines, you know, uh, dependencies, et cetera, belong to one of the apps listed in the CMDB.
Um, because that's, oh, the application ID that tag right there is the business application I class and the CMDB. So that application tag, so anything deployed with that Terraform deployment is anything found, but that with that, whatever it was configured out deployment, any services sped up or mapped back to that business application, the one that it's light it's lifecycle managed, that's a short answer.
We're trying to, there's some limit, there's some technical limitations still do that, but some of the large providers of CDBs are working on discovery in the public cloud and that kind of thing, so that we can basically capture it. We can capture what it's supposed to be on the deployment, but then also discover it right in the public cloud provider and try to match the two up, which is sort of represented on this a little green line here. Right? It's like, you know, we deploy something and then we verify by discovering, but discovering it and bring it back into the CMDB. Does that make sense? There's definitely room for improvement on the technologies available to do that kind of thing though, Multiple assets or whatever. Ah, it's, it's not, it's not really a reasonable sizzle, cause it could be a small, it could be a small app or it could be replacing, uh, the entire claims system. So it's not, it's not really a, yeah. They're all apples, apples and oranges, you know. Does that make sense? Anything else? Cause we're out of time. Okay, great. I appreciate it. Thanks a lot. Yep.