The Engagement
The ministry was responsible for the internal affairs of the country — one of the most operationally sensitive government bodies in the region. Their core systems ran on Z mainframe infrastructure that had been in place for years: reliable, battle-tested, and increasingly under pressure from internal advocates for modernization who were drawn to the promise of distributed x86 architecture.
My role was straightforward in description and complex in execution: provide strategic IT counsel to the ministry’s C-Suite, assess the infrastructure question honestly, and propose a managed services arrangement if the case justified it. The commercial opportunity was significant — a potential 39-month managed services contract — but the evaluation had to be genuine. A government ministry responsible for national-level operations does not benefit from a vendor who tells them what they want to hear.
The Mainframe Question
The pressure to move from mainframe to distributed infrastructure is one of the most persistent narratives in enterprise IT, and it is often driven by factors that have less to do with operational requirements than with cost perception, vendor incentives, and the general assumption that newer is better. For most organizations, the right answer depends on what they actually need.
For a government ministry running mission-critical workloads — continuous transaction processing, sensitive citizen data, operations that cannot tolerate unplanned downtime — the answer requires examining the question from the right starting point. Not “what is the modern approach?” but “what does failure cost?”
The Z mainframe’s case in this context rested on several concrete pillars. Reliability at this class of workload is measured in fractions of a percentage point of downtime annually — a standard that distributed x86 clusters can approach but require significantly more architectural complexity to achieve, including redundancy layers, failover orchestration, and ongoing operational management that the ministry would need to staff or outsource. Security architecture on the mainframe is hardware-level, not software-level — encryption, access controls, and workload isolation are baked into the silicon rather than implemented in software layers that can be misconfigured or compromised. And transaction throughput at sustained peak volume, for the specific workload profile of a large government ministry, favored the existing platform by a margin that the modernization advocates had not fully accounted for in their projections.
The total cost of ownership calculation, done honestly, also worked against the migration. The visible cost of mainframe licensing is high and easy to point to. The cost of migrating decades of mission-critical code, re-engineering integrations, retraining operational staff, and managing the transition risk of moving a live government system to a new architecture is harder to quantify upfront and almost always underestimated. When both sides of the ledger were fully costed, the economics of staying with the existing platform were more defensible than the modernization lobby had presented.
None of this is a permanent argument for mainframes over distributed systems in every context. It is a context-specific argument for this ministry, with this workload profile, at this moment. That distinction matters. The goal was not to defend a technology religion. It was to give the Director-General an honest assessment that held up under scrutiny.
The Meeting That Wasn’t About Technology
The technical case was necessary. It was not sufficient.
My first formal meeting with the Director-General had been arranged through weeks of relationship-building with the ministry’s team — the deputies, the technical leads, the administrators who controlled access to the people who controlled decisions. This is the part of government procurement in the Gulf that Western engagement models routinely underestimate. The formal meeting is not where the evaluation happens. The formal meeting is where the decision is communicated. The evaluation happens in the conversations that precede it.
When I finally sat across from the Director-General, something unexpected changed the tenor of the meeting early. In the exchange of professional backgrounds, we discovered a shared history — both had attended school in England, years apart, in institutions that operated in a particular cultural register that we both recognized immediately. It was a small overlap in a long biography, but it functioned as a signal: here is someone who has operated in contexts I understand, whose frame of reference I can read.
I have thought about this moment often since. It would be easy to read it as luck, as coincidence, as irrelevant to the substance of what followed. I don’t read it that way. In high-trust, relationship-oriented procurement cultures, the decision to engage seriously with a counterpart precedes the decision to evaluate their proposal. The shared background didn’t close the contract. It opened the conversation that made serious evaluation possible. The distinction is important.
What followed was a substantive technical dialogue. The Director-General asked precise questions about security architecture, about the long-term cost implications of each path, about how managed services would work operationally and what the ministry would retain control of. These were not ceremonial questions. They required real answers, and the quality of those answers was being evaluated in real time.
Structuring the Managed Services Proposal
The proposal was for a 39-month managed services arrangement covering the Z mainframe environment — operations, maintenance, performance management, and security. The commercial logic was a straightforward extension of the technical case: if the mainframe platform was the right infrastructure for the ministry’s workloads, and if the operational complexity of managing it at this level required specialized expertise, then concentrating that expertise in a managed services relationship was more efficient than the ministry building and maintaining it internally.
The 39-month term was deliberate. Long enough to deliver measurable operational improvement and allow the relationship to mature. Short enough that the ministry retained meaningful leverage at renewal. Government clients, particularly in sensitive ministries, are rightly cautious about creating dependencies that become difficult to exit. Structuring the term to give the client a genuine off-ramp was both honest and commercially intelligent — a client who feels trapped is a client who looks for reasons to terminate.
The pricing and service level framework was built around the ministry’s operational requirements, not around a standard service catalogue. What mattered to this client was uptime, security incident response time, and the quality of reporting to senior leadership. The SLAs were constructed around those priorities explicitly.
The Close
The final meeting with the Director-General followed the pattern that the preceding weeks had established. There was no high-pressure sales dynamic, no manufactured urgency. The proposal had been reviewed by the ministry’s team. The technical questions had been answered. The commercial terms had been examined.
The Director-General asked two clarifying questions, listened to the answers, and stood up. “We have a deal.” A handshake. A significant multi-year managed services contract, closed in under a minute.
The moment itself took less than a minute. The work that made it possible had taken months and had almost nothing to do with the proposal document.
What Government IT Procurement Actually Requires
Three observations from this engagement that have held up across others since.
In relationship-driven procurement cultures, trust is a prerequisite, not a differentiator. Vendors who treat relationship-building as a courtesy extended before the real work of technical evaluation are misreading the sequence. In many government procurement contexts — and this is particularly pronounced in the Gulf — the relationship is the evaluation. Technical competence is assumed at the shortlist stage. What gets evaluated after that is trustworthiness: will this counterpart tell me the truth when the truth is inconvenient? Will they protect the ministry’s interests or optimize for their own commercial outcome?
Honest assessments are commercially durable. The temptation in a high-value procurement is to tell the client what they want to hear, or to shade the technical analysis toward the outcome that produces the larger contract. This is a short-term strategy. Government ministries have long memories and long contract cycles. An honest assessment that recommends against a migration — or recommends a smaller engagement scope — builds the credibility that makes the next conversation possible. The contract was larger, not smaller, for having been approached this way.
The proposal document is the last thing that closes a government contract, not the first. The document matters — the SLAs, the commercial terms, the technical specifications. But by the time a senior government official sits down to make a final decision, the proposal is already a formality. The real evaluation has happened in every conversation, every question answered, every instance of follow-through or failure to follow through in the weeks and months before. Winning the technical pitch without winning the trust that precedes it is winning the wrong thing.
The ministry’s systems continued running. The managed services arrangement delivered what it committed to. The relationship persisted well beyond the contract term. That is the measure that matters.
