What Platform Commitment Actually Looks Like

It's been a few months since I turned in my PIV card as a federal employee and joined Thunder. For the past few years, I led the Transportation Security Administration’s (TSA's) Digital Services Team, including managing the agency's large Salesforce implementation, a role that I loved.

Fortunately, when I joined Thunder, I had the opportunity to step right back into federal service, joining a team that was beginning work on a massive modernization project for a large federal agency. Their goal is to replace a suite of mission-critical legacy applications that were stitched together across multiple technologies over the last 30 years with a reimagined set of modern capabilities built on the Salesforce platform. 

Those 30-year-old legacy systems didn't start out as a problem. They started out as solutions to other problems, each one purpose-built to meet a specific set of requirements. 

But over time, the custom-developed applications, point-to-point integrations, and manual data exchanges piled up until what was once a collection of individual solutions became something much harder to manage, adapt, or operate. That's how agencies end up in this situation. Not through bad decisions, but through the accumulation of a bunch of individually reasonable ones and the relentless march of time.

Looking back, I can see their future

In April 2020, at the start of the COVID pandemic, air travel dropped by 96% compared to the same month the year before. Almost overnight, TSA went from screening millions of passengers a day to a tiny fraction of that. 

With far fewer flights, TSA no longer needed the same number of screeners at every airport. And for their health and safety, TSA leaders didn't want to subject the workforce to unnecessary risk. The need to quickly reset the schedules of tens of thousands of transportation security officers nationwide posed a huge, immediate challenge for TSA. 

Prior to COVID, airports would hold annual "shift bids" where dozens of screeners would select their shifts (work hours and days off) in seniority order via an in-person ritual conducted in waves over hours, days, or weeks, depending on the size of the airport. 

One by one, they would select from sheets of bid lines taped to conference room walls. Like teams during a sports draft, each screener would get a few minutes "on the clock" to find, decide, and select their schedule for the year. TSA needed a solution that would accelerate this manual, time-consuming process and enable screeners to participate virtually.

In just 27 days, my team designed and deployed a virtual shift bid application, enabling tens of thousands of screeners at the nation's largest airports to securely bid on available shifts from home through a simple, user-friendly portal. As an additional benefit, for the first time, TSA leadership at all levels could monitor and report on the real-time status and progress of shift bids at the airport and national level.

Why platform commitment matters

The TSA shift bid application illustrates what's possible with platform commitment: selecting a proven commercial solution, using it consistently, and treating it as "the default" option (for appropriate use cases, of course) for delivering mission and business applications vs. continually layering on additional technologies with each new project or procurement.

We were able to move quickly to deliver the shift bid application because we had already committed to Salesforce Government Cloud as our target application platform two years earlier. Our platform security was already in place. Our system was authorized to operate. Our architecture and data governance processes were established. We had developed a deep understanding of the system. During our first two years, we delivered 12 applications. Like going to the gym every day, we exercised both our application development muscles and our platform operation muscles.

I've described building the platform as laying "technology bricks." Each brick is the solution to a problem. Authentication is a brick. Access control is a brick. Bulk loading data is a brick. Security monitoring is a brick. Every project we took on presented new challenges, delivered as new bricks. And each new application we delivered was built on the bricks of those that came before it. By committing to the Salesforce platform, we were able to build a robust foundation brick by brick, such that when COVID happened, we were ready, strong, and able to deliver.

Every federal agency is different, of course. For my agency, given funding and budget constraints, staffing levels, mission requirements, operations tempo, and a dozen other factors, I always believed we could be most successful focusing on exactly one software as a service (SaaS) platform. I still stand by it.

It's not only a good idea, it's policy

Issued last year, Executive Order 14271 — Ensuring Commercial, Cost-Effective Solutions in Federal Contracts — directs agencies to prioritize commercial software and requires justification for custom builds. The order addresses the "what" more than the "how." The agencies that will get the most out of this policy shift are the ones that recognize that buying commercial and making a platform commitment are two very different things. One gets you a platform. The other gets you enterprise-wide digital transformation in 27 days.

Building on a mission-ready foundation

Committing to a platform is a serious decision. But commitment works both ways. Before investing in a platform and the company behind it, it's worth knowing whether that platform is already invested in delivering for federal agencies.

Salesforce first achieved FedRAMP authorization in 2014 and achieved FedRAMP High with Government Cloud Plus in 2020. That's over a decade of sustained investment focused on the federal sector.

As a low-code, no-code SaaS platform, Salesforce enables agencies to configure and extend out-of-the-box capabilities without building from scratch or maintaining complex custom code. In a federal environment where contractor teams turn over regularly, and institutional knowledge is lost with every contract recompete, that's a significant advantage and directly aligned with the intention of EO 14271 to buy commercial solutions that "can be modified to fill agencies' needs."

Salesforce has invested in Agentforce Public Sector (previously Public Sector Solutions), a library of pre-configured, mission-ready applications built specifically around federal use cases including case management, grants, licensing, and inspections. The goal is to deliver agencies a 70% solution out of the box and enable them to extend or tailor as needed to achieve the perfect fit.

For defense, intelligence, and aerospace agencies, Missionforce goes even further, bringing AI, cloud, and platform capabilities purpose-built for national security missions.

Last year, Agentforce achieved FedRAMP High authorization, bringing AI capability onto the same authorized platform as your data and workflows. The vision is an AI-assisted workforce where agents handle routine tasks and surface insights, with humans staying in the loop on the decisions that matter. For agencies under pressure to do more with less, that capability is available today.

None of this means Salesforce is the right answer for every agency or every project. But for federal agencies looking to make the most of the commercial-first direction in EO 14271, it's worth serious consideration.

Those first bricks

In just a few weeks, my federal customer will launch their first Salesforce app. Their first row of bricks laid. Their second app is targeted for a few months later. Another set of capabilities delivered; another row of bricks laid. Their team is learning and developing competencies. They are developing and implementing new processes. Those app dev and platform operations muscles are being exercised. They've made a platform commitment. They are all in. I can't wait to see what they're able to deliver when they really hit their stride.

Of course, committing to a platform is easier said than done. In my next two articles, I'll dig into some common concerns and counterarguments, and cover how to identify the right use cases once you've made that commitment.

‍