We Replaced the Mainframe, But Did We Replace the Architecture?

Many years ago, a local government where I worked embarked on a major modernization effort.

The organization had an aging mainframe supporting Human Resources and Financial operations. Like many legacy systems, it had become increasingly difficult to maintain, difficult to staff, and difficult to evolve. Leadership made the decision to replace it and selected a modern enterprise platform that would eventually become the center of HR and Finance operations.

The implementation took years. Consultants were hired. Business processes were reviewed. Teams spent countless hours in meetings, testing cycles, training sessions, and migration activities.

Eventually, the old system was retired. Employees got paid. Financial transactions continued flowing. Departments could perform their daily work. By most measures, the project was a success. The mainframe was gone from that part of the organization. Modernization had arrived.

Or so we thought.

Looking Back, We Asked the Wrong Questions

To be fair, the questions being asked during procurement were reasonable.

• Could the new platform support Human Resources?
• Could it support Payroll?
• Could it support Finance?
• Could it replace the business functions the organization depended upon?
• Is it configurable?

Those questions absolutely mattered.

Looking back, however, I think another set of questions deserved far more attention than it received.

What happens when every other system in the organization eventually needs information from it?

At the time, that didn't seem like a major concern. We were replacing a business system. The goal was to move away from the mainframe and provide modern capabilities for HR and Finance.

What none of us fully appreciated was that successful enterprise systems rarely stay confined to the problem they were originally purchased to solve.

As the years passed, the platform gradually became the authoritative source for employees, positions, supervisors, departments, organizational structures, cost centers, and financial information. Once that happened, it was only a matter of time before other systems started depending on it.

Identity management systems wanted employee information. Physical security systems wanted personnel data. Department applications wanted organizational structures. Reporting systems wanted everything. The more successful the platform became, the more consumers appeared.

Looking back, I think this was the moment where we made a subtle but important mistake. We thought we were buying an HR and Finance system. In reality, we were selecting the future source of truth for a significant portion of the enterprise.

The architecture, however, never evolved to match that reality.

The Rise of the File

Of course we had a solution. We are techy people so... Whenever another system needed information, the solution was usually straightforward.

Someone would create a file.

One application needed employee information. Another needed positions. Another needed cost centers. Yet another needed employee information as well, but with slightly different fields and formatting requirements.

So another file was created. Then another. Then another.

At first, this seemed perfectly reasonable. There were always more urgent priorities competing for attention. Payroll had to run. Financial operations had to continue. Users needed support. New business requirements kept arriving.

Improving integration capabilities was rarely the most urgent problem in the room.

As a result, it was frequently postponed.

What nobody realized at the time was that postponing enterprise connectivity doesn't eliminate the cost. It simply changes where that cost is paid.

The Cost Nobody Saw Coming

The organization never avoided the integration problem. Instead, it distributed the problem across dozens of teams.

Every consuming application became responsible for reading files, parsing records, detecting changes, handling failures, maintaining mappings, and interpreting the meaning of the data it received. Every team solved essentially the same challenges independently.

The source system team would create a file and move on. The consuming teams inherited everything else.

Over time, small changes became disproportionately expensive. A field that originally meant one thing might later be repurposed to mean something slightly different. The file structure itself might remain unchanged, yet downstream systems would suddenly begin producing unexpected results.

The team maintaining the source platform often had little visibility into how many consumers existed or how the information was being used. The consuming teams frequently had limited visibility into upcoming changes.

Coordination became increasingly difficult.

What looked like a collection of independent integrations slowly became an enterprise-wide maintenance burden.

No single decision created the problem. Hundreds of small, reasonable decisions did. Each one made sense in isolation. Together, they created an architecture that perpetuated the problem.

The Data Warehouse Arrives

Eventually, someone recognized that many teams were trying to solve similar problems and a centralized data warehouse was created.

Data from the enterprise platform was copied into a cloud database where consumers could access it more easily.

To be clear, this was not a bad decision.

In fact, it solved a very real problem and solved it well.

Reporting became easier. Dashboards became easier. Historical analysis became easier. For anyone trying to understand what happened yesterday, last month, or last year, the warehouse provided a much better experience than dozens of disconnected extracts.

The challenge was that operational integrations never disappeared.

A reporting system can tell you how many employees existed yesterday... but an operational system may need to know that an employee was hired thirty seconds ago.

A dashboard can show how the organization looked last month... but an access control system may need to know that a supervisor changed this morning.

Those are fundamentally different problems. One is about understanding the past. The other is about responding to the present.

Treating one as a replacement for the other doesn't solve the architectural challenge for integrations. It simply postpones it.

What Might Have Looked Different?

Looking back, I don't think the answer was eliminating files.

Files still have value. Bulk transfers exist. Legacy systems exist. There will always be situations where a file is the right solution.

The missed opportunity was treating enterprise connectivity as a secondary concern rather than a first-class requirement.

The organization spent enormous effort evaluating business functionality, which was entirely appropriate. The platform needed to support HR, Payroll, Finance, and a wide variety of business processes.

What received far less attention was how information would move throughout the enterprise once that platform became the system of record. Connectivity was treated as an implementation detail rather than a capability that should have been evaluated alongside business functionality during procurement.

Different integration problems require different integration patterns.

Some consumers need periodic bulk data. Some need to retrieve information on demand. Others need to know immediately when something changes.

Modern platforms often address these needs through a combination of APIs, event publishing, data feeds, and, in some cases, traditional file transfers. The specific technology is less important than recognizing that different consumers have different needs and that enterprise connectivity should be designed intentionally rather than emerging accidentally over time.

A healthy enterprise platform typically supports all of these scenarios rather than forcing every consumer down the same path.

The challenge is not choosing a single integration pattern. The challenge is recognizing that the platform will eventually become important enough to need all of them.

The Real Lesson

The most important lesson isn't about a specific product, vendor, or government organization.

It's about something much broader.

The more important a system becomes, the more other systems will depend upon it.

Eventually, every successful enterprise system becomes an integration platform whether leadership realizes it or not.

That's why connectivity deserves the same level of scrutiny as functionality during procurement and architecture discussions.

• Can the system support Human Resources?
• Can it support Payroll?
• Can it support Finance?

Those questions matter. But another question may matter just as much.

• Can it participate in the ecosystem that will inevitably form around it?

Because every enterprise system eventually becomes part of something larger than itself.

The only question is whether that reality is recognized during procurement and design, or discovered years later after dozens of custom workarounds have already been built.

Replacing the mainframe is modernization. Replacing the architecture is transformation. One changes where the system runs. The other changes how the enterprise operates.

The two are not always the same thing.