May 2026
In late 2020, the Cloud Center of Excellence had a credibility problem. We had proven we could migrate one workload — Project CT was running on ECS Fargate, costs were down, reliability was up. But one workload does not make a transformation. The question from the product groups was reasonable: *"This worked for CT, but how do we know where *we* stand?"*
We didn't have a good answer. Every product group was at a different point in their cloud journey. Some had been running containers for years. Others were still SSHing into VMs to deploy WAR files. Some had CI/CD pipelines. Others had a Jenkins job that someone's cousin set up in 2017.
The SaaS review board needed a framework to evaluate new offerings consistently. The product groups needed a way to self-assess and identify gaps before formal review. And the CCoE needed a shared language to talk about maturity across teams that didn't share a technical stack, an organizational structure, or even a time zone.
So we built one.
The framework was organized around six dimensions that covered the full lifecycle of a SaaS offering — from business planning through support operations:
Business Planning — market definitions, pricing models, profitability analysis. Could the product group articulate their target market? Did they understand their unit economics? Was there a pricing model that could scale?
Go To Market — routes to market, sales execution, pricing lifecycle. How did customers discover and buy the product? Was the sales motion repeatable? Could the organization support multiple go-to-market channels?
Solution Architecture — containerization, tenancy model, scalability, availability. Was the application architected for cloud-native operations? Could it scale horizontally? Did it support multi-tenancy? Was it containerized?
Development and Testing — CI/CD, test automation, deployment operations. How did code go from commit to production? Was the deployment automated? Were tests run on every change? Could the team roll back cleanly?
Operational Complexity — customer onboarding, operational maintenance, self-service vs managed touch. How much manual effort was required to keep the service running? Could customers onboard themselves? Was the team firefighting or improving?
Support — escalations, knowledgebase, self-service tools. How were customer issues handled? Was there tiered escalation? Could customers find answers without opening a ticket?
Each area had progressive maturity levels — typically four stages ranging from ad-hoc to optimized. Product groups could assess where they were on each dimension and see a clear path to the next level.
Critically, maturity was not a score to maximize. A product group at level 2 in architecture but level 4 in go-to-market had different priorities than one with the inverse profile. The framework was diagnostic, not judgmental.
The maturity model became the centerpiece of the SaaS Review Board — a governance gate that every new offering had to pass through before GA. Product groups would submit a self-assessment against the six areas. The board would review, challenge assumptions, and agree on a maturity baseline.
But the real value was in what happened between reviews. A product group that scored low on operational complexity didn't need a lecture — they needed a path. We would recommend specific improvements: adopt infrastructure as code, establish monitoring, create a runbook. The CT migration playbook served as the reference pattern. The SaaS maturity model was the map.
The framework also proved useful in unexpected ways. When the SVP of sales wanted to understand why some offerings were more reliable than others, I could show him the operational complexity scores. When the CTO wanted to prioritize shared services investment, I could map which capabilities were needed across the most product groups. The maturity model became a communication tool as much as an assessment tool.
The maturity model did not emerge from a conference room. It emerged from a lab.
I had spent nights and weekends building multi-OS Kubernetes clusters from commodity hardware — K3s on OpenSUSE, Ubuntu, and FreeBSD, managed by Rancher, monitored by Prometheus and Grafana. I had tuned network stacks from 178 Mbps to over a gigabit per second. I had tested Harvester 2.0 and killed it when it wasn't production-ready. Every failure and every lesson went into the standards we published.
When I told product groups that containerization was achievable, I could point to a working cluster that I had built myself. When I wrote the architecture standards, I was drawing on mistakes I had already made at 1 AM on a Friday night. The maturity model was the theory. The lab was the proof that the theory worked outside a pristine slide deck.
This is the part of the story that doesn't make it into most maturity model presentations. The framework matters. But the credibility to apply it comes from having done the work yourself. You cannot assess someone's path to cloud-native if you have never run a container in production.
The framework itself was not the hard part. The six areas are not novel. Any consultant could produce a similar matrix in an afternoon. The hard part was the organizational context — understanding which product groups had which constraints, which CTOs were open to change, and which teams needed coaching versus which needed patterns.
Self-assessment requires safety. Product groups that felt judged would inflate their scores. Groups that felt supported would honestly assess their gaps. The maturity model only worked because the CCoE had earned trust through delivery — the CT migration, the IOD triage, the late-night debugging sessions.
The lab work was an essential input. The framework would have been academic without the hands-on validation. I could not have written credible architecture standards without having built and broken K3s clusters myself. Strategy without execution is just a deck.
When I left Micro Focus in 2022, the maturity model was still in use. I don't know if it survived the HPE acquisition, but I know that the product groups that had adopted it were migrating independently, running their own CI/CD pipelines, and making architecture decisions without the CCoE's involvement.
That was the goal. A maturity model that becomes indispensable has failed. A maturity model that makes itself unnecessary has succeeded.
The same pattern applies to what I am doing now with local AI infrastructure. The CCoE model — assess, standardize, enable, step back — scales to any technology transition. The tools change. The framework stays.
*Built on a home lab, powered by local models, and owned by Andrew Katana.*
---
Sources & Acknowledgments: This narrative draws on the same source material as the CCoE series — my private OneNote journal (Nov 2020–Jul 2022) and the 45-file Gary archive, which contained the formal `Maturity Model Overview v4 gma.pptx` that framed our approach, alongside `Charts-atk.docx` (my adoption analysis across product groups) and the `SaaS - Scale to a Sustainable Business v5-atk.pptx` strategy deck that tied the maturity model to the $240M-to-$450M revenue target.
Built on a home lab, powered by local models, and owned by Andrew Katana.