From Experiment to Trusted Platform
Organisations create AI pilots and internal platforms faster than they create the disciplines needed to support them, so convincing demonstrations quietly become production services that nobody owns. This eight-part series sets out a four-stage lifecycle, Experiment, Incubating, Trusted production and Retiring or archived, inspired by the CNCF project lifecycle but adapted for enterprise portfolios. It covers what a sandbox label should promise, what production-ready actually means, why users are not maturity, how to run due diligence before promotion, how to graduate an internal developer platform, how to retire systems responsibly and how to report a portfolio on lifecycle as well as delivery status. One fictional Limpopo mining contractor with 23 initiatives carries the examples, and every figure is illustrative.
8 articles
- Part 1Every AI pilot needs a graduation pathA convincing AI demonstration can attract users and executive attention long before anyone has decided to run it as a service. Part 1 sets out a four-stage maturity lifecycle, borrowed in spirit from the CNCF, with evidence gates that make promotion, remediation and retirement explicit decisions.9 min read
- Part 2Sandbox is a risk label, not a place to hide permanent systemsCalling something a sandbox or a pilot should tell people what data it may touch, who may use it, what support exists and when it expires. Too often the word does the opposite, and an experiment quietly becomes a service that nobody owns. Part 2 shows what the label should promise.7 min read
- Part 3What does production-ready actually mean?"Production-ready" is said in almost every steering committee and defined in almost none. Part 3 replaces the adjective with nine areas of evidence, each of which either exists or does not, so a promotion decision can rest on something a reviewer can check.7 min read
- Part 4Your pilot has users. That does not make it matureA rising user count is the most persuasive and least reliable evidence in a promotion meeting. Part 4 separates curiosity from adoption, explains why the project team's confidence is not evidence, and shows how to gather adopter evidence from the people who live with the system.7 min read
- Part 5Due diligence belongs before promotion, not after failureMost organisations do their most thorough review of a system after it has failed in production. Part 5 moves that review to the moment before promotion: an independent reviewer, an evidence pack, adopter interviews, and a clear line between blockers that stop promotion and follow-ups that can wait.7 min read
- Part 6How to graduate an internal developer platformInternal developer platforms are often declared finished when they are merely large. Part 6 applies the lifecycle to a platform: what each stage looks like, what evidence promotes it to trusted production, and why voluntary adoption is the evidence platform teams most need and most avoid.7 min read
- Part 7Archived does not mean failedSystems that no longer earn their place tend to linger, because retiring them feels like admitting a mistake. Part 7 treats retirement as a governed outcome: the signals that should open a review, the steps of a responsible shutdown, and why timely archiving protects users and frees capacity.7 min read
- Part 8Portfolios need lifecycle labels, not only red, amber and greenA traffic-light status tells leadership whether delivery is on track. It says nothing about how much the organisation may rely on what was delivered. Part 8 shows how to report a technology portfolio on both dimensions, and how lifecycle labels change investment, support and risk conversations.7 min read
Working through any of this in your own organisation?
These articles come out of delivery work rather than theory. If the problems in this series look familiar, a short scoping conversation is usually the quickest way to work out what is worth doing first.
Talk to CloudNala