May 2026
In 2019, Micro Focus had a problem. SaaS made up 9% of revenue and that number was shrinking. The company set a goal to grow it to 15% by FY22/23 — roughly doubling from $240M to $450M while the overall business was declining at 3% CAGR.
The portfolio was described internally as a "mixed collection of 'as a Service' offerings mostly managed with a few true SaaS — no real plan." Too much complexity and manual processes. No shared standards. Financial reporting that couldn't accurately measure bookings, cost of service, or churn.
The VP of SaaS Strategy laid out the vision: a sustainable SaaS business built on shared services, technical standards, automation, and customer-centric operations. The SaaS Strategy team defined the framework. The Product Groups owned execution. And between them sat a new function that didn't exist before — the Cloud Center of Excellence.
That's where I came in.
"We need to figure out where it is going and who is doing the work."
— First line of my OneNote from November 2020
A room full of SaaS leaders, product groups running their own clouds their own way, and no one owning the transition. The company was spending $20M on cloud-native initiatives, labs were a mess, and the hard question being asked was: Should we move workloads, or enable the people who do?
I chose enablement.
The Cloud Center of Excellence I built wasn't another operations team. It was a consulting plus SRE hybrid — part architecture authority, part hands-on engineering, part teacher. We didn't take tickets. We took on the hard problems that no single product group could solve alone.
The operating model had three layers:
The CCoE was the connective tissue. We made sure product groups didn't have to figure it out alone.
We owned 47 AWS accounts across 4 regions — Oregon, Frankfurt, Sydney, and Canada. Eight Classic Landing Zone accounts and 39 GW Landing Zone accounts. Each product group had its own accounts, its own VPCs, its own way of doing things. My team delivered the shared services that made this manageable.
Basic services were the foundation: landing zone deployment, tier 3 support, multi-region landing zones, network and IAM configuration.
Advanced services were where the real value lived:
We operated the CI/CD pipeline (Git, GitHub Actions, Atlantis), managed IAM (NetIQ, Okta, AWS Identity Center), maintained IaC (Terraform, AFT), and supported migration patterns for containers, ECS Fargate, serverless, and APIs.
Our first major engagement was Project CT — the Control Tower modernization program. Control Tower was Micro Focus's shared services platform for order fulfillment, provisioning, and tenant management: the operational backbone of the SaaS business. It had been running on over-provisioned data center VMs for years, and the accepted wisdom was that it couldn't run in containers. Code was fragile, queries were costly, and the database team was already stretched thin.
I assigned one of my team leads to convert the Java codebase to GitOps on AWS ECS and Fargate. Another coordinated with AWS engineering and navigated the internal politics. Within months, CT was running on elastic compute — more reliable, finally scalable, and costing less.
We proved it could be done. Then we built the playbook so everyone else could do it too.
One of the first things we needed was a way to assess where product groups were and what they needed to improve. I helped operationalize a six-area maturity model that covered the full lifecycle of a SaaS offering:
Each area had progressive maturity levels. Product groups could assess where they were and map a path forward. The CT migration was the proof point. The maturity model was the map.
While CT proved the pattern at workload scale, the IOD platform represented the real migration challenge — roughly 1,000 VMs of ITOM test and certify infrastructure, plus product-on-demand and database-on-demand services. Eight years old. Hand-operated monitoring. Four known failure modes that no single team owned.
The Bangalore-based support team was watching institutional knowledge walk out the door as key team members exited. My role was to untangle this: coordinate with regional leadership on service prioritization, work with the operations team on triage, design the Frankfurt landing zone with AWS Service Catalog, and keep the migration moving while the org was in flux.
The guiding principle was simple: prioritize services over workloads. ITOM didn't need a 100% translation of their existing platform to AWS. They needed the services that platform offered, delivered consistently and reliably.
I believe you cannot set standards for something you haven't built yourself. So while I was leading the CCoE, I was also in the lab — on nights and weekends — building multi-OS Kubernetes clusters from commodity hardware.
I stood up K3s clusters across OpenSUSE, Ubuntu, and FreeBSD. I ran Rancher to manage them. I tested Harvester 2.0 and killed it when it wasn't production-ready. I tuned network stacks from 178 megabits per second to over a gigabit per second by fixing MTU, flow control, and jumbo frame misconfigurations. I deployed Prometheus and Grafana, ran load tests, and documented every lesson learned so developers wouldn't hit the same walls.
Network optimization result: 178 Mbps → 1.05 GB/s throughput after fixing flow control, MTU, and jumbo frame configurations across switches and NICs.
>
"Oddly even my pings dropped just about in half. Well worth doing but need to stay on top of it — this is likely something that no one actually pays attention to in the Cloud."
This wasn't delegation. This was doing the work to know what the work actually requires.
One concrete output of that lab work was the hardened AMI pipeline. We built secure base images for Linux and Windows — baked in the security benchmarks our own scanning tools required, aligned with our Security team's standards, and published through a pipeline that product groups could consume directly.
We didn't decide which operating systems the business needed. We shaped the delivery roadmap, found gaps as we went, and deployed serverless agents to manage and enforce the build manifest across all 47 accounts. Suse had a version of this pattern with Suse Builder almost 15 years earlier. Most large IT organizations make common build and deployment baselines a requirement for anything on the corporate network.
But that mandate solves an earlier problem. It does not solve the distribution problem.
The final mile — from hardened AMI to running workload — is where things get messy. A platform that has to account for VMs, containers, network, storage, and the security posture of each form factor builds compounding technical debt in tooling, storage, and security controls. The deployment envelope is not a single form factor, and pretending it is makes the platform team a bottleneck instead of an enabler.
I think about this now because AI infrastructure faces the same problem, amplified. AI workloads do not fit neatly into a container. They are not as well-defined as a JVM application. They are not a classic production VM. And they will not sit comfortably inside a JeOS (Just enough Operating System) model that would make management and security more mundane or cookie-cutter. The deployment envelope for AI is inherently diverse.
If the platform is going to become a consumable service that the business is willing to mandate, it will need to be both secure and cost-effective. That means it must present a common interface — and that interface is rapidly shifting from a user interface to an API endpoint.
The hardened AMI pipeline solved the image problem. The platform problem — for AI or anything else — is what comes after the image boots.
I inherited two talented engineers — Mark and Victor — and watched them grow from individual contributors to Solution Architects and SREs. Mark developed deep AWS expertise and became our primary coordinator with AWS engineering. Victor converted the CT codebase from a data center deployment model to GitOps, developing deep Kubernetes knowledge along the way.
I advocated for their promotions and compensation adjustments. I established the CCoE as a career growth path. We built the credibility that turned "let's go to the CCoE" from a question into an expectation.
By mid-2022, the CCoE had proven the model. Product groups were adopting shared services, the migration patterns were documented, and the organization was ready for the next evolution. The question became: how do you scale a central team of ~15 people across 10+ product groups without becoming a bottleneck?
The answer was to transition from a shared-services CCoE to three dedicated SRE squads aligned with product groups. I led that transition — designing the org structure, managing retention risk, and creating career paths from legacy operations to SRE engineering.
The transition wasn't smooth. The forced push of CCoE resources into SRE roles caused multiple departures. But we rebuilt. The three squads — led by Nurit, Sreehari, and Eyal — covered the full product portfolio, with 9 active openings reflecting the demand for SRE capability.
The lesson was clear: a central CCoE is the right starting point, but platform teams aligned with product groups are the sustainable end state.
Beyond infrastructure, the CCoE owned identity and access strategy. For WebRoot, I led a Cloud Services Acceleration engagement redesigning IAM across 35 AWS accounts — implementing SSO with Okta, AWS Identity Center, and Account Factory for Terraform.
For Danske Bank, I authored the enterprise security response covering Cloudflare CDN architecture, EU data sovereignty, encryption posture, MyAccount operations, Logz.io data handling, and Google Analytics controls. Writing a security posture letter for a regulated Nordic bank requires understanding not just your own infrastructure, but how every data flow crosses regulatory boundaries.
Enablement scales better than heroics. A single team cannot migrate every workload. But a team that builds patterns, standards, and a maturity model can enable dozens of product groups to migrate themselves.
Hands-on credibility matters. The architects who had built K3s clusters on real hardware carried more weight than those who only drew diagrams. The lab work was not a side project — it was an essential input to the standards we published.
Strategy without execution is just a deck. The 47-slide strategy presentations were necessary but not sufficient. The real work happened in the migration factory, the triage calls, and the late-night debugging sessions that turned strategy into reality.
Organizational design is strategy. The three-layer model — Product Groups owning execution, CCoE enabling standards, PSDC running operations — was not an org chart exercise. It was the architecture that made the whole thing work.
I wrote the first version of this story as a private OneNote entry in November 2020. The strategy decks from that era sat in a folder named after a colleague until I rediscovered them recently. Reading them side by side — the formal strategy and the raw notes — the same story emerges from both: a team that built something that didn't exist, proved it worked, then built the playbook so everyone else could follow.
The site you are reading this on runs on infrastructure that grew directly out of those lab experiments. The Pi-hole I stood up in 2021 to test DNS-level ad blocking is now a production recursive resolver. The K3s experiments informed my approach to edge computing. The networking lessons I documented at 1 AM are now best practices in my current home lab.
That is how real expertise is built — not in a single project, but in the compound effect of doing the work, documenting the lessons, and building the next thing on top of what you just learned.
*Built on a home lab, powered by local models, and owned by Andrew Katana.*
---
Sources & Acknowledgments: This narrative was reconstructed from two primary sources — my private OneNote journal (Nov 2020–Jul 2022, 12+ months of daily entries) and a 45-file archive of corporate strategy materials (SaaS strategy decks, the CT Program Plan, maturity model, organizational design, ITOM strategy). The formal strategy and the raw notes tell the same story. That alignment is the strongest evidence that the work was real, the impact was measurable, and the approach was sound.
Built on a home lab, powered by local models, and owned by Andrew Katana.