The Engagement
The client was a major East African revenue authority — a government institution responsible for national tax collection, with the infrastructure complexity that role implies: mission-critical systems that could not fail, a heterogeneous server estate that had grown through years of incremental investment, and budget constraints that made every technology decision a question of economic justification as much as technical merit.
The mandate was a cloud roadmap and infrastructure consolidation strategy. In practice, that meant answering a more specific question: what was the institution’s current infrastructure actually costing, what were the realistic consolidation options, and how did the economics of each option compare when the full picture was visible?
That last clause — when the full picture was visible — turned out to be the operative one.
The Infrastructure Audit
The starting point was a complete audit of the existing server estate. What emerged was a picture common to large government IT organisations that have grown through successive procurement cycles rather than planned architecture: a heterogeneous spread of hardware from different generations, running at low average utilisation, with software licensing costs that had accumulated in proportion to the server count rather than the actual workload.
The estate comprised a substantial spread of Windows x86, Linux x86, and AIX Power servers — each procured to meet a specific requirement at a specific point in time, each carrying licensed cores at a count that had accumulated with every procurement cycle. The cumulative result was a distributed infrastructure with high operational overhead, significant redundancy in hardware management complexity, and — critically — a software licensing bill that tracked core count rather than utilisation.
This last point required careful explanation to the institution’s leadership, and it is worth explaining clearly here as well. Enterprise software licensing in the early 2010s was commonly structured around the number of processor cores on which the software ran. A distributed Linux estate carrying a large number of licensed cores carried licensing obligations for every one of those cores, regardless of whether they were running at 20% average utilisation or 80%. Consolidating the same workloads onto fewer, more powerful servers with significantly lower aggregate core counts did not merely reduce hardware costs — it reduced the software licensing base directly and immediately. In many cases, the licensing saving alone justified the consolidation investment.
The Consolidation Analysis
We modelled four consolidation options for the Linux estate, each representing a different point on the spectrum between commodity x86 and high-density enterprise platforms. The methodology held constant across all options: relative processor performance, chip generation performance factors, co-location networking effects, utilisation factors, and virtualisation overhead, allowing a like-for-like economic comparison.
The options ranged from x86 blade consolidation — which reduced the server count but kept the core count relatively high — to high-density Power systems and, at the most aggressive end, mainframe consolidation where the Linux workloads ran on a small number of specialised processors. The core count reduction across the spectrum was dramatic: workloads that had required a large distributed core estate could be accommodated on a high-density platform using a fraction of that count — a reduction that was difficult to appreciate without working through the performance data.
The economic consequence of that core reduction, applied to the software licensing base, produced the number that shifted the conversation in the institution’s leadership team. For the Power consolidation option — the middle point on the spectrum, balancing consolidation density with operational familiarity — the total cost of ownership calculation showed a substantial reduction against the current distributed infrastructure over the analysis period. The majority of that saving came not from hardware cost reduction but from the software licensing differential between the existing distributed estate and the consolidated platform.
This is the pattern that makes infrastructure consolidation economics counterintuitive to organisations that have not worked through the full TCO calculation. The hardware cost of a high-density enterprise platform is visibly higher than an equivalent collection of commodity servers. The software licensing cost of running that same workload on significantly fewer cores is substantially lower. When both sides of the ledger are included — and when the operational costs of managing a large distributed estate versus a consolidated platform are factored in — the economic case typically favours consolidation by a margin that surprises people who have only looked at the hardware line.
The Cloud Roadmap
The infrastructure consolidation analysis addressed the immediate economics question. The cloud roadmap addressed the strategic question: once the infrastructure was rationalised, what was the path to a cloud operating model that would allow the institution to provision and manage IT services with appropriate agility and cost discipline?
The framework we used structured the journey in three phases, each building on the previous.
The first phase — consolidation and integration — was the foundational work: rationalising the server estate, standardising virtualisation, and establishing a baseline infrastructure that could support more advanced capabilities. This was the phase the TCO analysis had quantified. Without it, the subsequent phases were architecturally unsound.
The second phase — automation — introduced self-service provisioning and automated lifecycle management for virtual resources. In a government institution where IT requests typically passed through manual approval and provisioning workflows measured in days or weeks, automation delivered operational value independent of any further cloud sophistication. The ability to provision a new environment in minutes rather than weeks has measurable impact on project delivery timelines.
The third phase — orchestration — enabled the full cloud operating model: multi-tenant environments, workload mobility, capacity planning analytics, and the ability to manage diverse resources — physical and virtual, internal and external — through a single management layer. This was the phase that delivered the strategic flexibility the institution’s leadership had described as their long-term objective. It was also the phase that required the foundations of the first two to be solid before it could function as designed.
The phasing mattered as much as the destination. Government institutions undertaking technology transformation face procurement constraints, budget cycles, and organisational change dynamics that make a “big bang” approach to cloud adoption impractical and high-risk. A phased roadmap with clear economic justification at each stage and tangible operational benefits delivered before the next investment was required — that is a cloud strategy a government institution can actually execute.
What Government IT Economics Actually Requires
Three observations from this engagement that apply beyond the East African context.
The full TCO calculation is the argument. Government IT investment decisions are made by finance and procurement functions that understand cost but may not initially see the connection between core count and software licensing expenditure. The argument that wins is not the technical one — it is the economic one, made completely. Hardware acquisition cost, software licensing over the analysis period, operational labour, energy, and hosting: when all of these are on the table, the economics of consolidation are typically clear. When only some of them are visible, the decision defaults to the lowest visible hardware cost, which is almost never the right outcome.
Phase the roadmap against budget cycles. A cloud journey structured as a single large investment is a cloud journey that does not get approved. Structuring each phase to deliver standalone economic or operational value — so that the institution has something to show for the investment before the next phase is funded — is not a compromise of the architecture. It is a requirement of the procurement environment.
Emerging market government IT has specific constraints that change the analysis. The economics of core-count licensing were significant in any enterprise context in 2013. In a government institution operating in an emerging market with constrained foreign currency, where software licensing invoiced in US dollars or euros represented a meaningful proportion of the IT budget, the licensing differential between a large distributed estate and a consolidated platform was not an optimisation — it was a structural budget issue. Understanding which constraints are universal and which are specific to the context is the starting point for advice that is actually useful.
The cloud roadmap was delivered. The consolidation economics were accepted. The institution had a structured path from a heterogeneous, high-overhead distributed estate to a rationalised infrastructure capable of supporting an automated, cloud-based operating model. The measure of success was not the elegance of the architecture — it was whether the institution’s leadership understood the economic case well enough to execute against it. They did.
