Government Procurement and Agile – Part 2: From Buying Applications to Buying Architecture

In my last piece, I argued that government procurement forces teams to lock in major decisions before discovery even begins. Procurement craves predictability. Agile assumes you learn as you go.

They clash. But the fix isn’t just making contracts vague or telling vendors to "give us good outcomes" while hoping for the best.

Some things shouldn't be left to chance.

Internal tech teams already know their own sandbox. They know the security rules, the identity standards, and the API needs. They have years of hard-won experience running enterprise systems.

Agility doesn't mean deleting your corporate memory.

The real question we should ask is this: What needs to be set in stone before procurement, what do we judge during the bid, and what do we leave open to figure out later?

It starts by admitting that no two tech purchases are identical.

What Are We Actually Buying?

We often lump everything under "tech procurement" as if a departmental app, an HR platform, and an integration hub are the same thing.

They aren’t.

Take a small, relatively isolated app for one team. The primary question is whether it solves their specific daily headaches. The people doing that work know the pain points best, so their voices should carry significant weight.

But an enterprise HR or financial system? That’s a different beast.

Sure, the business needs matter. If it cannot run payroll, it fails. But this platform may also become an authoritative system of record feeding dozens of other applications. Its identity model, API limits, integration capabilities, and security setup will ripple across the organization for decades.

You aren’t just buying a tool anymore. You are marrying an architecture.

If you move even further down the line to middleware or identity platforms, the balance flips completely. It is infrastructure. The nature of the technology should dictate who gets the biggest say in picking it.

Not Every Opinion Carries the Same Weight

Government loves broad consensus. Excluding the actual users of a system is an easy way to buy something everyone hates.

But letting people participate is not the same as giving them the final vote.

A payroll clerk knows payroll better than an architect. But that architect understands how the new system will talk to the rest of your environment. A security engineer will spot identity risks both of them miss. And a developer trying to connect to the vendor's API will find the hidden flaws a flashy sales demo covers up.

Agile won't make those differences disappear. It actually relies on getting the right feedback from the right experts at the exact right moment.

The trick is knowing which voice matters most for each specific decision.

Some Decisions Are Already Made

Agile procurement fans love to say we should focus on outcomes, not solutions.

That is mostly true, but push it too far and you create chaos.

An enterprise IT shop shouldn’t redesign its whole architecture every time a department buys an app. If your standard is OAuth 2.0/OIDC with centralized identity, authentication isn't optional just because a vendor prefers something else. If core business functions need to be exposed through REST APIs, that requirement stands. If the system will own data that drives enterprise events, its ability to publish those events matters. The same applies to established service identity and credential-management standards.

These aren't arbitrary rules created by bored architects. They are lessons the organization already learned the hard way.

Letting every new contract tear up the rulebook doesn’t make you agile. It just creates a fragmented mess. Flexibility doesn't require pretending everything is up for negotiation.

Stop Scoring Every Single Requirement

This brings us to a massive flaw in how government buys tech. We treat all requirements the same.

They aren't. Some are non-negotiable boundaries. Others are features we want to compare. Others are details we can figure out later.

Imagine your identity standard is worth 5 points out of a 100-point scorecard. Vendor A plays by the rules and gets all 5 points. Vendor B ignores the standard, gets 0, but blows everyone away with a beautiful interface. Vendor B wins the total score 91 to 87.

What happened to your mandatory rule?

Mathematically, you just decided that breaking your security architecture is fine as long as the app looks pretty. If breaking a rule only costs a vendor 5 points, it was never actually mandatory.

For things that genuinely cannot change, the rule should be simple: Pass or fail.

If they don't pass the gate, they don't get scored. Period.

Save the scoring for areas where vendors can actually differentiate themselves—like how deep their API capabilities go, or how flexible their workflows are.

A useful way to think about it is simple:

1. Mandatory constraints determine eligibility.
2. Comparative capabilities determine relative value.
3. Implementation uncertainty is where you leave room for discovery.

Those are three different kinds of decisions, and treating them as one giant weighted scorecard undermines the purpose of having mandatory requirements in the first place.

Pretty Interfaces Aren't Free

The most expensive parts of software are usually the ones you can’t see during a demo.

Picture two competing platforms. The first has a stunning interface. Users love it instantly. The second is completely usable, but it doesn't get the same applause.

Then you look under the hood.

The pretty app requires proprietary middleware. It relies on scheduled file exports instead of live APIs. Service integrations depend on stored credentials. Every significant integration change seems to require vendor professional services.

The second app plugs right into your identity system, offers mature APIs, supports the integration patterns your organization already uses, and fits your existing environment naturally.

If architecture is buried at the bottom of a weighted scorecard, the pretty app can easily win.

Maybe the business value really is worth the technical debt. But let’s be honest about what we're signing up for.

You aren't just buying the smooth demo. You are buying the messy integrations you’ll have to build five years from now. You are buying the workarounds, the security risks, the proprietary dependencies, and the future consulting bills.

You are buying the architecture.

Those costs just don't show up on the initial invoice.

Exceptions Should Be Deliberate

Look, sometimes you have to break the rules.

Maybe no vendor on the market supports your specific standard. Maybe a critical business need outweighs the technical risk. Maybe the standard itself is outdated and the procurement just exposed something that needs to change.

That’s fine.

But that choice must be conscious. It should be documented and accepted by the people who actually own that risk.

A business committee shouldn't accidentally waive a security standard because they liked a product's dashboard. Likewise, the tech team shouldn't block a critical tool just because it doesn't fit perfectly into their ideal architecture.

The power to waive a rule must match the responsibility for the outcome. Don't let a weighted spreadsheet make that choice for you.

Own What You Know

This points back to the core tension between procurement and Agile. Agile loves uncertainty, but it doesn’t demand blindness.

There is zero value in pretending you don't know what you've already learned.

If experience says you need modern authentication, demand it. If you know you need open access to your data, say so. If you know core business functions need APIs because other systems will depend on them, say so. If you know a system must be accessible or follow certain regulations, lock it in.

But stop pretending you know the exact layout of every screen or workflow on day one. You don't. Those are the areas where you need room to breathe, test, and pivot.

Be incredibly specific about what you know, and incredibly flexible about what you still have to learn.

Keep Options Open Where It Counts

Once you build those basic guardrails, procurement can allow room for learning without turning into a free-for-all.

Use discovery phases to check your assumptions. Build prototypes to expose technical limits that look fine on paper. Run realistic hands-on tests instead of watching a vendor's canned slideshow.

Smaller scopes, modular contracts, and clear checkpoints let you course-correct before a mistake becomes a multi-million-dollar disaster.

It isn't a blank check. It's just admitting that uncertainty exists whether your contract acknowledges it or not.

The choice is whether you create controlled opportunities to learn or discover your mistakes after the decisions become expensive to reverse.

You Don’t Have to Rewrite the Laws Tomorrow

If you work in local government, you know the reality. You cannot just reinvent your city's or county's purchasing rules on a Monday morning. There are lawyers, ordinances, budgets, approval authorities, and strict policies you have to follow.

But you don’t have to wait for a systemic overhaul to start changing things.

Take just one upcoming procurement and map out how it actually works. Who is writing the requirements? When do security and architecture get a seat at the table? Who decides which requirements are mandatory? Who has the authority to approve an exception? Which rules exist because you actually need them, and which ones were just copied and pasted from an old template?

Where are you making decisions before you actually have enough information to make them?

Most importantly: What exactly are you buying?

Stop evaluating a major enterprise platform as if it’s an isolated app, and stop picking infrastructure based on who gave the prettiest presentation.

Start Small

Before you copy-paste your next massive solicitation template, get everyone in a room early.

Ask the business what outcomes actually matter. Ask the architecture, security, integration, engineering, and operations teams what hard constraints the solution must respect.

Separate the non-negotiable gates from the capabilities you actually want to compare.

• Mandatory constraints determine eligibility.
• Comparative capabilities determine relative value.

And where you genuinely don't know the answer yet, stop manufacturing fake certainty. Leave room for discovery.

Agile procurement isn’t about abandoning discipline or breaking the law. It’s about being deliberate. Decide what is fixed, what is compared, and what is open to discovery—and make sure the people accountable for each area have the appropriate authority over those decisions.

The goal isn't fewer rules.

It’s the right rules, applied at the right time, by the right people.

Editor's Note: This article is the fifth in a series exploring Agile adoption, procurement, architecture, governance, and modernization within government technology organizations. The series was inspired by Adopting Agile in State and Local Governments by Sukumar Ganapati and expands on several themes discussed in that paper. Read the first article here.