The Enterprise Platform Trap

Government Procurement and Agile (Part 2)

In the previous article, Government Procurement and Agile – Part 1, I argued that government procurement was never designed with Agile delivery in mind. Procurement naturally favors predictability, detailed specifications, and selecting solutions before the work of discovery has truly begun.

But procurement raises another question that I believe deserves equal attention.

What happens after the procurement succeeds?

Almost a year ago, in When Leadership Missteps Hurt Everyone Except Leadership, I wrote about a large government modernization effort that replaced an aging HR and financial system with a modern enterprise platform. It was a massive undertaking involving years of planning, consultants, significant investment, and countless hours from both business and IT staff.

By almost every traditional project metric, the implementation was successful.

• The legacy platform was retired.
• A modern enterprise solution took its place.
• Business processes were standardized.
• Users received a dramatically improved experience.
• Few people would have considered the project a failure.

And yet, nearly a decade after I first saw the system, I find myself asking a very different question.

Did we modernize the architecture, or did we simply modernize the application?

That distinction may explain why so many government organizations continue struggling to become more Agile long after completing successful modernization projects.

Legacy Isn't About Age

When people hear the term legacy system, they usually imagine something old.

• A mainframe.
• A green-screen application.
• Technology written decades ago.

But I no longer think age is what makes a system a legacy.

A system becomes a legacy when changing it becomes difficult.

I've seen applications that are twenty years old but can still evolve remarkably well. I've also seen modern enterprise platforms that, only a few years after implementation, recreate the exact same rigidity they were meant to replace.

The moment an organization becomes afraid to touch a system because a minor configuration update might break an entire business ecosystem, that system is legacy—regardless of when the contract was signed. Age is a number; legacy is an architectural state.

Modernizing the Application vs. Modernizing the Communication

Looking back today, one thing surprises me more than anything else about that modernization effort.

Nearly ten years later, one of the most common development requests surrounding that platform isn't adding new business functionality or adapting to changing policy. It is creating another data export. Another batch interface. Another flat file for another downstream consumer.

In many cases, those downstream systems aren't even consuming business events. They receive snapshots of data, compare today's file with yesterday's, infer what changed, and then decide what work to perform.

That pattern has survived for nearly two decades.

I've also seen organizations introduce enterprise data warehouses or data lakes populated from those same nightly exports—or by replicating operational databases into analytical platforms. Those initiatives often deliver tremendous value for reporting and business intelligence, but they solve a different problem. They improve how we analyze yesterday's information, not necessarily how operational systems need to communicate today.

When we embarked on that modernization journey, the goal was modernization. We expected a modern platform to remove many of the technical limitations that had accumulated over the years.

Instead, one day something occurred to me that I hadn't considered before.

We hadn't modernized how our systems communicated. We had modernized which system produced yesterday's file.

The application changed, but the communication pattern remained almost entirely untouched.

The new platform inherited the same architectural role as the mainframe before it: a central repository that periodically produced files for the rest of the enterprise to consume.

Procurement Defines Applications. Architecture Defines Relationships.

In hindsight, I don't remember anyone asking how the platform should communicate with the rest of the enterprise over the next ten to twenty years.

We spent considerable time evaluating what the platform could do but far less time evaluating how it should collaborate with everything else.

That realization changed how I think about procurement.

Procurement naturally focuses on application boundaries. We evaluate features, user interfaces, business capabilities, vendor stability, implementation methodology, and cost. Those are all important questions.

Architecture asks a different set of questions.

• How will this system exchange information?
• How will new applications integrate with it?
• How will it evolve alongside everything else we haven't built yet?

Those questions rarely receive the same level of attention, even though they may have a greater impact on the organization's long-term agility than any individual feature.

Conway's Law Beyond Software Development

This persistence of old communication patterns also made me think differently about Conway's Law.

Most software professionals know Conway's observation that organizations tend to design systems mirroring their communication structures. We usually apply that idea to software development teams.

But perhaps it also applies to enterprise software procurement.

Government organizations are often structured around departments, programs, and business functions with clearly defined responsibilities and communication paths.

If information typically moves between those groups through formal requests, scheduled reports, shared files, and manual coordination, shouldn't we expect our enterprise systems to communicate in much the same way?

Perhaps that's exactly what happened.

We bought a modern platform, yet the integrations still behaved exactly like the organization behaved.

The software didn't modernize our communication. It reflected it.

The Missing Procurement Questions

If we want to avoid creating tomorrow's legacy systems, procurement evaluations need to expand beyond business functionality.

The traditional questions are familiar.

• Can it manage our HR processes?
• Can it process financial transactions?
• Does it meet our reporting requirements?
• Is the vendor financially stable?
• Does it satisfy our security requirements?

Those questions remain essential.

But I now believe we should also be asking architectural questions.

• How is this platform expected to communicate with the rest of the enterprise?
• Can it publish meaningful business events when something changes?
• Can new applications integrate without requiring another custom export?
• If another system needs this information five years from now, what integration pattern do we expect it to use?
• Can components be replaced independently, or does everything revolve around this one platform?

These aren't implementation details to figure out later. They are procurement questions. Because procurement doesn't just determine what software we buy. It influences the architecture we will inherit for decades.

Looking Ahead

One realization continues to stand out to me.

A procurement can be an unquestionable project success while simultaneously creating an operational architecture that becomes increasingly difficult to evolve.

That isn't necessarily the fault of the vendor, the implementation team, or the technology itself.

Sometimes it's simply the result of asking the wrong questions during procurement.

Throughout this series, we've explored how government's pursuit of predictability influences Agile adoption. We've discussed tightly coupled systems, traditional procurement practices, and now the architectural consequences that procurement decisions can leave behind.

The common thread is becoming increasingly clear.

Agility isn't something we purchase.

It is something we design.

In the next article, I'll explore what that might look like in practice and how procurement can evolve from selecting isolated applications to evaluating how those applications will participate in the organization's long-term architecture.

Editor's Note: This article is the fourth 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.