Dive into the transformative journey of the Department of Veterans Affairs (VA) with Andrew Fichter and Dave Mazik, key figures behind the VA Lighthouse Program. From its inception in 2019, this program has been pivotal in streamlining software delivery within the VA, introducing an API platform, an internal developer platform, and pioneering the continuous Authority to Operate (cATO). This video offers an in-depth look at the challenges faced, innovative solutions implemented, and the remarkable impact on improving services for veterans.

For anyone looking to understand the intricacies of digital transformation within the federal government, especially in the context of improving services for veterans, this presentation offers a comprehensive overview of a groundbreaking initiative within the VA. Explore the journey of the Lighthouse Program and its role in setting new standards for software delivery and digital services in the public sector.

‍

Andrew Fichter (0:14)

Hi, my name is Andrew Fichter. I'm the Deputy Director on the Lighthouse Program at Department of Veterans Affairs. We're going to talk to you today about our experience growing a program since 2019 to make software delivery easier at VA, and that includes an API platform that includes an internal developer platform, and then continuous ATO, which we've already heard some about today.

‍

Dave Mazik (0:40)

Thanks, Andrew, yeah. Dave Mazik, Director of the program. Fun fact, Andrew and I started the exact same day at VA, so if you saw the OMB Talk earlier, we are a prime example of hiring multiple people with a single position. So just a little bit of a tie in there.

‍

Andrew Fichter (0:55)

Yeah, exactly the same day. Yeah, and then we'll talk a little bit about the history too as we get into this. So, first of all, I just wanted to start off with servicing the VA mission statement. And I'll read it aloud. It says, "To care for him who shall have borne the battle, and for his widow and his orphan." And this was stated by Abraham Lincoln when the Department of Veterans Affairs was created. I do want to point out that this mission statement was crafted very long ago. There are also many women Veterans. There's also their entire families that are supported by VA. So when someone goes and provides service to our nation through the military, that's the ultimate sacrifice that they can make. And not only are they putting their own lives on the line and their own wellbeing, it is their entire family, their children, their spouses. And the VA's mission is really to provide, make sure that when a veteran comes back into civilian life, they're supported and they're able to build a good life for themselves and that they have the care they need. And same with their families and their beneficiaries. So I venture that all of us today, we understand the gravity of solving problems in government. And I do think that the VA's mission is a pretty easy sell. It's very clear. Carrie and Lynette were talking about this, just how powerful it is to see the impact that you can make on people's lives through the work that we're doing. All right, so Veterans, they deserve better than what they have today. You can see on the screen here, just the kind of the scale and impact, the scale and size of VA. Over 390,000 employees, 16,000 of which work in Office of Information Technology. That alone is the size of a Fortune 500 company. And so VA, obviously, has the resources to make change. Just look at these numbers. And the effects of making positive change are pretty massive, even on a low level. When you think about an organization the size of OIT alone, 16,000 employees and contractors, there's a lot of silos, fragmented systems, fragmented processes. And as a result of that, incentives are misaligned all across the organization. And so I guess the big takeaway is that making positive change in the government has challenges at every level, but those challenges also make the change very impactful. So let's talk a little bit about what we've done on the Lighthouse Program. So here on the slide you see a timeline of some of the major milestones we've had. So before Dave and I joined the program, the public API platform was launched in 2018. That was born out of va.gov redesign. We've heard a little bit about the precursor to that today with Marina on stage to kick the day off. And then in 2021, we pivoted to a delivery platform. So we built multiple products there that are further removed from the veteran 'cause we found that we weren't really helping a lot of the enterprise delivery solutions that put the veteran in control. And then from there, we pivoted to cATO. We learned that we can enable teams to ship code faster, but if they can't be authorized, then we're not really getting the full benefit. And then going forward, we're going to be looking to grow adoption and mature platform. All right, I'll pass it over to Dave.

‍

Dave Mazik (4:46)

Yeah, thanks, Andrew. So I'm just going to start a little bit about the public API platform again, right? Mina was early speaking about that va.gov relaunch in 2018. And what that really enabled was a lot of modern APIs built to provide access to data and key services in VA that are useful to Veterans. So that was sort of one precursor, and there was a bet that there's probably information that Veterans want to more easily access, like their health information. Those 9 million patients out of the 18 million veteran population. And then there was also an ask. We have a lot of Veteran Service Organizations that sit down with Veterans to help them submit benefits claims. It's a very complex process, so they often assist them. And a lot of these organizations were already using claims management software. But at the end of that, they would hit the Print button, out would come a piece of paper, and they would either stuff it in an envelope or in a fax machine, like a VA, like please let us send just information to you in a better digital way. So maybe just... Next slide. So the public platform was launched in 2018, had an MVP in place when Andrew and I started. Whole bunch of things here. So today, we have 137 apps in production. Roughly 2/3 of those are third-party applications that were built by organizations, not funded by VA. So these are all benefiting Veterans or VA in some way where there's a mutual benefit to both the Veteran VA and the organization that built the application. So super proud of that, really excited. In fiscal year '23 alone, that VSO use case I spoke to, we processed over 1.5 million digital benefits claim submissions. Those otherwise would've been pieces of paper that arrived in VA's doorstep. We really... There's just a culmination of events that put us in a place of privilege to be able to have this success and be standing in front of you, right? One was that va.gov backend rebuild. There was also foresight by the people who launched the program. The people now are the Deputy Federal CIO and the CIO of the National Geospatial Agency, a CTO of the National Geospatial Agency. They said, "Let's go look at what good commercial API platforms do. Like, there's teams and people that have done this, we don't need to relearn and recreate all this." So they did a Silicon Valley tour, looked at what was available, and really what you see on developer.va.gov is really a culmination of that like so. Just, again, like leveraging all the good work that's been done in the federal and commercial space prior to this. 

‍

(7:17)

So yeah, APIs are cool, we love APIs, this is all about APIs. So there's 21 APIs on there today. I think there were roughly 10 or 12 when we started, so some good growth there too. Really, again, this was about putting Veterans in control of their data, right? So rather than having to drive into a medical facility either to get a printout of their information or to create a digital credential that they can use to log into My HealtheVet or va.gov, let them access through third-party apps as well. So really put them in control. Another thing is enable the veteran making an firm choice. So if we're enabling third-party applications, we want to make really sure that the Veteran's aware of what data's going to be accessed, how that data is going to be accessed, whom it might be shared with. Really, what is the intent of the application because we've done a lot of user research with Veterans in that consent flow. And the one thing that comes back loud and clear over and over again is we trust UVA that these apps are okay and we'll be okay with them. So we really want to give them the information to make that decision. Innovation and greater choice, right? So we can only build so many applications. As a federal agency, our budgets are limited, right? So getting back to roughly 2/3 of those 137 apps, we've now sort of put more applications in the community, in the ecosystem that Veterans are free to use and people that support them. 

‍

(8:42)

So like one example. VA has a very successful program in My HealtheVet, which is what Veterans use to access their health information, refill prescriptions. So very, very useful, very successful program. But a large majority of our Veterans also receive care in the community from a private community care partners. So if they want to see that information, well, they have to go to another patient portal. So we've enabled applications like Apple Health, Common Health, that they can connect this application to all the places they've received care and get a combined, de-duplicated, holistic view of all their health information, right? VA could have built that, but it would've been really expensive and we'd never be done. So just an example of that innovation and choice. We really push boundaries on production approval and the things we're doing, but we still have policy and law at the end of the day. So we have a couple of levers there that are helpful to us that may be helpful to you. One is the Privacy Act and that right to access. So in cases where we have applications that are veteran-facing, where we're going through NIST Identity Proofing and OAuth consent flows, that's really easy to tie into a right to access use case. So the privacy people love that because the Veteran's completely in control of their access to their information. It's essentially the digital equivalent of them walking into a VA medical facility and asking for a printout of their medical records. So that's really helpful to us and maybe to you. Even in that case there's still... As part of Title 38, so part of law, there's data ethics that are built into that, where VA is charged with making sure that veteran data is treated with certain ethical standards. So even if the Veteran's accessing data with a application we reviewed, we have to make sure it's living up to those data ethics. So still have that to live by. And then of course, if there's non-veteran-facing cases or we have some federal agencies, for example, that use VA or veteran data to determine eligibility for veteran benefits, there's paper agreements, computerized matching agreements. If there's health sharing, system to system, business-associated agreements per HIPAA. 

‍

(10:51)

So it really is, I think we have probably a mural with like maybe 12 different paths through the decision tree of policy, and approvals, and reviews we have to do. So it's not trivial, but we're really trying to make it efficient for the veteran but still protect their data and comply with policy and law. Some of the things we've learned in this program. So strangely enough, out of that 137 production applications, almost 1/3 of those are VA applications. So really surprising to us that people found a public-facing API platform to be easier than any internal mechanisms. You might have to do integrations. You would think if you're inside the tenant, it would be easier, but this has proven not always. And Andrew's going to speak to some of the things as to just how that development community is different and how those needs are a little bit different and bigger in a little bit. Legacy upstream dependencies. So va.gov enabled us with a bunch of really modern, high-quality APIs, but there's dependencies upstream that... Or some legacy systems don't have SLAs, maybe, that meet commercial quality. Maybe they're not well-documented. So there's a lot of things we've done to sort of mitigate that so that we build trust 'cause at the end of the day, the applications we're enabling, we want them to deliver a good end user experience. And if those APIs are going down a lot of the time or they're not performant, you're waiting 60 seconds for a page refresh, well, we haven't really succeeded in anything. So we've enabled caching for some performance issues or system availability, built some async APIs. So maybe there's a really big PDF that has to get built as part of an API, and that takes a long time. So we'll build some async APIs so that you can immediately respond but then have an async or a webhook to indicate completion. So a lot of things there. And then fear. Security by obscurity is a lot easier than security via real solutions. So there's always a fear of, "If I open my API to more applications, whether they be VA or third party, now I really have to get clean on my security implementation." Data quality, right? So just speaking to the size of the data, or 18 million Veterans, almost 400,000 employees, 16,000 roughly IT employees and contractors, we have a lot of data. And we have, in certain pockets, data quality issues, too. And even if we have a 1% data quality issue, which might be very good, it's still Veterans that are impacted at the end of the day in that 1%, so we still need a good solution to those problems. So, exposing APIs that provide easier access to data obviously brings those data qualities to light. So there's some fear in that too. So overcoming that. 

‍

(13:43)

And then as Andrew's going to speak to, we told people what was good, we enabled them to make their APIs available to third parties. But we sort of stopped there. We didn't help them figure out how to modernize their system from maybe an on-prem system to modern cloud-based Kubernetes container. We didn't really help them build their APIs. We just told them what good APIs look like. And then there's a lot of mission-critical APIs that will never be on this developer portal for public consumption or third-party application consumption, but obviously there's a big need for something like this internally to VA from a discovery perspective, connecting with the API teams, going through the integration patterns that those APIs require. So we really weren't helping the enterprise as much as we could, right? Having 21 APIs for over 1,000 systems in VA, that's just a small pocket of the ecosystem that really lives and breathes every day at VA. And then I'll turn it over to Andrew in a minute here, but one size doesn't fit all. Whole bunch of differences we're finding with developers inside VA, and it's not that VA is a snowflake, there's just a broader set of needs and a broader set of richer, deeper communication that's often needed between those API teams and the teams that are actually building applications use them. So I'll let Andrew speak to that a bit more.

‍

Andrew Fichter (15:02)

Yeah, all right, thanks, Dave. All right, so yeah, this brings us to our first pivot. so Dave and I were brought on in 2019 with... Really, our mission and our task was to build the API program into something that was sustainable 'cause at the time I was a pilot. Actually just a fun fact, Dave and I, within our first year in the federal government, had to actually write a new contract to make sure that the program could stay alive. And so that was a really interesting journey. But yeah, so initially, the goal of the API, of the public platform, was to provide that top-notch digital experience outside of VA and enable innovation outside of VA so that things like Apple, companies like Apple and Apple Health, could use their infrastructure and ecosystem and pull in VA data to make lives better for Veterans. And really, our goal wasn't ever to... Like, our, our main objective all along was not to be a shop that built and sustained APIs, but rather we built a platform, and other teams in VA could build APIs and put them on the platform. As Dave mentioned, some of the challenges that made that a harder reality. Just misaligned incentives, budgets, headcount, skillsets, all kinds of things made it really hard for other teams in VA to be well-positioned to build APIs. So that's when we pivoted to the Internal Delivery Platform and dev portal. And in this, there's really three main problems that we were looking to solve. One, VA product teams to have different needs than third parties outside VA. So if you're a product team within the VA, and you're building an app, and you need to get data from a system, and you need to use an API to do that, we really wanted to have a way for teams to be able to access that information easily and without having it be on the public portal. Because as Dave said, the public portal, really, it's public-facing, anyone can go there. developer.va.gov, you could go there right now on your phone. We really want to build public trust in our programs, which means that there's a high bar for what goes on the public portal. So internal and external developer needs are different. Same with standards, which I'll talk about on the next slide. These two are very intertwined, these two problems. And then problem number three, to actually build software in the VA required a lot of time and effort on the front end just to get common things in place. And so we wanted to address that as well. And in all of this, we will also talk about cATO next, but we kind of knew that was kind of like the white elephant in the room. We knew that if we were going to build an internal platform, we would have a chance to affect security. We didn't really have an answer at the time for how we were going to do that. Serendipitously, we did find a way around that, which I'll talk more about too. All right, so yeah, I mentioned developer needs and standards are different. So to address this need, we built what's called the Hub, which is an internal developer portal that's built on Spotify's Backstage. Implementation, that's an open-source dev portal. It's actually getting a lot of adoption in the industry. A lot of large companies are using Backstage. So the screenshot on the right-hand side that highlights a lot of the information that we wanted to bring front and center for VA teams, which is different than the kind of information that we would want available on the public portal. Ways to very easily see who owns a product so that if you're looking to integrate with it, you can reach out to that team easily. And then we've very recently launched, this API maturity model is what we're calling it, but it's basically we want to provide a way for teams to be able to easily see how mature an API might be from the documentation, to its monitoring, to its reliability. And so that's that main screenshot you see there in the middle. 

‍

(19:12)

And yeah, so we basically just wanted to provide as much helpful and contextual information as possible and we didn't want to prevent that information from being made available for VA teams, which they were gated on the public portal previously. And then I mentioned there's a lot of stuff at the front end that teams have to go through if they're building software within the VA. Carrie actually, just on the panel with Rob, with Carrie and Lynette recently, or a few minutes ago, she was talking about how she kind of came in and built out the cloud security model. So VA, like VA, we've made a lot of progress in our cloud adoption, but we're still very immature compared to commercial sector. And so things like requesting. Requesting and provisioning an account within the VA Enterprise Cloud, that could take weeks. In fact, when we were building our platform, I think it took us a few months to get through that because there was a lot of permissions and settings we needed on that account. And there was a lot of back-and-forth negotiation with the cloud team to get that in place. So if you're a VA team and you're trying to get into the cloud, you're going to have to do the same thing. You're going to have to go talk to the team. It's going to take a long time to get an account. Building a CI/CD pipeline, right? Any team who's building something will need a CI/CD pipeline. Why should they have to roll their own? Alerting and monitoring, same thing. And then also just documenting services and integrating with other services. So that's in part what we're trying to do with our Developer Hub, but we want to provide infrastructure within the platform that takes a lot of these concerns away from the development team and allows them to get to the Time to First Hello World, I think, is the popular metric. We'd like to say that our Time to First Hello World could be within a few days in a dev environment. So a team could instantly be provisioned in the cloud and could have the scaffolding in place for a really simple API or application that they could deploy easily. All right, so then we got our platform in place. That brings us to our second pivot, shift left on security and authorization. Doesn't matter how fast software can be delivered if it takes months to get authorized. So three big problems here. We really leveraged many tools in our toolkit, including acquisitions, acquisitions of both people and SaaS products. Plus, a highly-skilled team who had learned many hard-fought lessons over in DoD. So that would be Rise8. We partnered with Rise8 to help us with this problem. So let's get a better understanding of the before state for each of these problems. 

‍

(22:00)

First of all, the misaligned authorization process, again, Carrie and Lynette were talking about this a few minutes ago, but it's very, very waterfall. Lynette was calling it the biggest paperwork fire drill, I think, in the federal government. But essentially, you would have a team building software. They would go through the waterfall SDLC process. They would go through requirements, design, development. And then finally, when everything was done, they would go off for assessment and authorization, and that's when things would be turned over to Office of Information Security. You would have an assessor within the Office of Information Security basically going through, and it's very compliance-focused. And at the end of the day, what that would result in would be a one to three-year ATO. So the assessment and authorization process was very, very disjointed from the development process. In fact, a lot of developers don't even have access to eMASS, which is the GRC tool that we use at VA. So this might work okay when teams are shipping to prod once a quarter, a few times a year, like the kind of recent past, I guess. But when teams are shipping to prod daily or weekly, this doesn't work. The second thing is the high cost of delay. So as an example of this, scanning SLAs are 30 days. So if you are a product team building an application and you need to go through... You need to get it scanned as part of the authorization process, you have to go put in a ticket with a scanning team. They have a 30-day SLA. I've heard of cases where the 30-day SLA is actually not met. So 30 days go by, you might not get your scan results back. If you do get them back, there's no requirement to actually scan again for another six to 12 months in a lot of cases. And plus, apart from all this, like the assessment team itself, there's just no capacity. They're overburdened with a ton of systems, tight deadlines. Carrie mentioned as an AO, she has 400 systems on her plate. The assessment team, same thing. They have all these systems that they need to get through the backlog and get authorized. And so that leads to rush assessments and emergency fire drills, basically, to get your paperwork in order, in order to get over the finish line and get your system authorized. 

‍

(24:33)

So yeah, I kind of liken this to I live in DC, I ride the metro a lot. A lot of the times you'll see trains during rush hour that are, at least before the pandemic, that would be packed. There would be people trying to rush on and jam onto the train. The train operator would be rushing to close the doors 'cause the train operators are really held to a standard where they need to be on schedule, and they get knocked if they don't stay on schedule. I kind of liken this to that you have the assessment team that they have a huge backlog to get through, and they're just trying to get through and stay on schedule. So that transitions us to the third problem, false sense of trust and security. A ton of manpower goes into this, 568 days, on average, it takes to get an ATO in the VA. So that creates an illusion of security and it instills a false sense of trust 'cause you figure there's all these people working on this, it takes so much time to get through. Surely, after all of that, the system must be a fortress, but that's not the case. Time and manpower, they create an illusion of security, and silos and misaligned incentives that I mentioned before at the individual level, that kind of creates this vicious cycle of too many cooks in the kitchen each following instructions and processes, but collectively missing the big picture through no fault of their own. I mean, this is a symptom of a problem within a larger organization. So it's like forcing a square peg into a round hole. So the square peg being the product that needs to be authorized and the round hole being the authorization process. And then there has to be a better way. Real-time feedback loops like scanning on every commit and at runtime, gate checks to enforce that code can't go into production with critical or high vulnerabilities. We hired assessors from an outside agency that are embedded with the development teams through the whole development cycle. They're working with the teams in the code. You can see their work is very transparent through the tools that we use in the pipeline. So yeah. So we did, we implemented the secure release toolchain that provides any interested party with immediate and ongoing access to risk context. Not perfect. Simple things are hard. We had to strike out order and to get technical assessors; we had to get multiple products in the door, the SaaS products, scanning tools; and we had to get back into support from VA leadership, like Carrie and Lynette. And we did get a signed memo from the CIO, which was also very hard to get that through. I kind of liken that to the example from earlier today about the YouTube video with Obama. Hey, there's a YouTube video. Obama said, "Go fix it," kind of like that. We lean on this memo in cases where we really need to get things over the finish line or convince people that we have authority to do what we're doing. But that's a constant challenge. But yeah, the good thing is that VA is getting onto this ongoing authorization bandwagon. And given the results that we've demonstrated so far, we really have a good opportunity to move the needle in the right direction. All right, so now I will pass it over to... Did I hit the wrong button? Pass it over to Dave to talk about-

‍

Dave Mazik (28:01)

All right, thanks, Andrew. In the interest of time, I'm going to go pretty quick. So I'll try to just cover the high points here. Just some of the successes and how we think we got there. So we talked about the public platform. The internal developer portal, so launched I think roughly a year ago, maybe a little bit more. Already 197 APIs on there, right? So far more than a 21, many more to go. But really just immediately solving the discovery problem. Like, there was an incident actually in VA about one to two months ago. There's an application that's used to manage a call center for Veterans in crisis. So Veterans at high risk of suicide, really important application. They were sourcing phone numbers for the mental health clinic in each of the VA facilities that obviously, if you have a veteran crisis, you immediately want to connect them with a mental health counselor. They discovered that that data was old and stale. So they identified the API immediately that was causing them a problem. It took us, in VA, two days to find out what team and what developer could actually fix that API. Two days. This immediately solves that, right? So basically, this Developer Hub, the way it works, it's all authorized with GitHub credentials. So actually, it's self-service. You document your API. To do that, you need to be the owner in the GitHub team that owns the API. So the fact that it's documented in there means you have immediate proof and transparency as to what team and what developers are actually managing that API, so that problem would've been solved immediately had it been here. Delivery infrastructure. So the numbers bounce around a little bit, but I think we were roughly 70 days, and that's not a hugely large sample size. But our traditional process bounces around from like 200 to 420 days to obtain that full ATO. So like huge improvement in just the time to ship. More secure software, right? We're actually scanning on demand, we're not waiting for these 30-day scans. We're actually having assessors look at software changes and/or test results at times. Not just documentation created by engineers that says we're doing the right thing. 

‍

(30:14)

Therefore, we're more compliant 'cause what we're actually shipping is accurate to what the ATO says it is. And it's more transparent. So basically, the whole dev workflow now has the ATO integrated into it. It's very analogous, right? The whole industry, years ago, went to an infrastructure as code model. I kind of view this as like an ATO as code model. It's remarried with the dev process. It's, like, it's just a natural part of the work. And that doesn't mean we have developers spending two or three days out of the week creating documents. It's just that they're doing it much more in an efficient way and it's automatically just in part of their workflow. Why were we successful? I think, right, we're really here standing on the shoulders of giants when we jumped into this program. We jumped into leadership on the VA side. That was very forward-thinking in terms of recognizing that we need product, UX, and engineering. Like, all three of those are required. Why do we need product like infrastructure and dev tools? They're products. Even probably about a few weeks ago in VA, I heard someone say, "Well, we don't call those products." No, they're products. They have outcomes that we want to achieve. They just have very highly technical end users. And as part of that, right, we want to optimize for outcomes, right? It's really easy in infrastructure and dev to look at shiny objects and output of the capabilities we can deliver. 

‍

(31:36)

But the questions we need to ask is: But, why? Like, how does that help developers? And ultimately, how does that deliver value to the business outcomes? If you can't make that tie in all the way to the business outcome, it might not be worth doing. UX. Developers are users. Just as much as a Veteran or a VA clinician as a user, our developers are users. If they come to an API catalog or they go to use our delivery infrastructure to build and ship product, if they can't easily figure that out, like they're going to walk. Like, especially for those 70 plus third-party apps that VA's not funding, If they can't easily discover APIs, figure out what they do and build an app to them, they're not going to bother, right? And so critical, critical that we work with our users, not for them. And then optimize the experience. After we built something, continue to do research, continue to do testing, and governance on the API side as well. And then of course, if we've done a great job on product and UX and the system doesn't stay up or we've got huge security risks, like none of that other stuff matters, right? So it's not that that's any less important, it's just one of three things that are equally important. So just, right, some of the challenges, I think we touched on these, so I'll go quickly on these two. Very diverse development community. As you can imagine with many legendary systems, as I think we heard yesterday across 16,000 employees and contractors, we have people still building Oracle databases on-prem, on VMware instances to VAEC, AWS, modern containerized applications. So really diverse set of skillsets and knowledge. That's been a challenge. Opening up data, right? 

‍

(33:21)

We talked it forces the security discussion, it puts data quality issues into the wild where they're visible. Incentives, right? Very different incentives that work in at play. On our side, from the federal side, infrastructure doesn't deliver business requirements directly, right? So it's all that more important. I think Bryon talked about it yesterday morning from a marketing perspective. That's so important is proving the value you're delivering not just to the developers, but to your business stakeholders too. If you tell them that it's going to cost your application team half as much and take them half as long, that's immediately going to provide more dollars so they can do more things, right? So you really need to make that tie in. When teams come in to solve a problem, right, if they're going to build an API as part of their solution, very hard not to just solve the immediate business need 'cause cost and schedule are always under pressure, right? Think about what you can do just a little bit more to make that maybe more reusable. Think about the Amazon model, right, where basically Jeff Bezos said, "No two teams can talk to each other unless they do it through an API, right?" Really try to strive for that to build some lasting and enduring value, so your things can be reusable. And then security, right? We often have competing stakeholders in here where nothing's as secure as something that never ships, right? So if you have people that are solely responsible for Siri, they're probably going to lean towards that. And if you have people that are solely responsible for delivering value to the business, that can lean in the opposite direction. So really marrying those two to come up with an optimized outcome, whether you ship or don't ship and how secure and what your remaining risk is. And then, of course, the last talk. ATO is hard. So I'm probably going to just quickly go to the last slide here, Andrew. Just to wrap up real quick. One more? Oh.

‍

[Andrew] Sorry.

‍

(35:14)

That's all right. So we have a whole roadmap of things we're doing. More automation, especially on the provider side in the public platform. The developer portal, we're not just doing APIs, we're expanding it basically to be a developer portal for all content people doing custom development and VA may need. And we're also looking to add some of the public API platform capabilities we have in place today on that platform. And then delivery infrastructure. We still have quite a few legacy ATO processes and policies that we need to optimize. And then of course, a long list of new capabilities. And in terms of how you can help, like really bake product, UX, and engineering into the work you do and the contracts you work on, try to build an enterprise solution if you can. And then, like, just as we're standing on the shoulders of giants and the people before us who did leverage the work that's out there, like we'll be more than happy to talk to any agency or any federal program on any of this stuff. Like, we love collaborating, so please reach out to us. And maybe just one more last slide. And so there's our LinkedIn links. And if you want to actually get in touch with the team too, you can just go to our portal. There's a Contact Us. We have a full CRM-based support team managing that. So if we're bad at responding to LinkedIn, they'll be better than us. So either route will work, though. So thanks for your time, guys. Any questions, or? All right.

‍