Content
Content
Services
Content
Employer
Content
Challenge
A global sales platform runs on a database architecture that works, but it’s expensive, and it wasn’t built for the scale the business has grown into. Before committing to a multi-year migration, the team needed a real answer: could a modern, cloud-native alternative actually do the job, and is there a better architectural pattern for feeding it data than the one currently in place?The PoC sat at the intersection of two problems that are easy to conflate and important to separate. The first was a technology question: could this specific database meet the operational requirements at production standards latency, throughput, availability, internet exposure?The second, bigger question was architectural: regardless of technology, what’s the right pattern for getting data into a serving layer at this scale?Understanding why each pattern fails or holds under real operating conditions not cataloguing options, but reasoning through the actual failure modes was the core intellectual work of the PoC. It shaped every decision that followed, and it became the foundation of something that outlasted the project itself.
Solution
From the first session, as project manager I made a call: document architectural findings at the point of discovery, not after the fact. Log decisions when they were made, not when someone asked for a summary.It grew session by session. Each architecture debate became a reference file. Each confirmed finding became permanent context. Each anti-pattern was documented with its evidence who flagged it, when, what the vendor said, what it meant for the architecture. By the time the Hybrid anti-pattern was confirmed in session seven, the framework to evaluate it was already there. Nobody had to reconstruct what came before.The finished skill held eleven reference files: architecture patterns, technical capabilities pulled straight from vendor documentation, workload requirements, governance considerations, blueprint alignment, stakeholder contacts, and the full closure rationale. A routing brain sent any question to the right file. A welcome screen made it navigable for anyone who hadn’t been in the room. A two-question decision tree produced pattern recommendations on demand. A ten-criterion framework could score any future technology against the same requirements.
Impact
Because every finding was structured as it emerged, the architecture comparisons stayed current. When a new pattern was proposed, the evaluation framework was already there. When a vendor session produced a significant finding, it was in the skill the same day ready for the next conversation.When the PoC closed, the skill became its most durable output. The team disbanded. The project ended. The findings didn’t. Any colleague who installs the skill can ask about the architecture patterns, the anti-patterns, the vendor findings, the open governance questions, or who to call to reopen the evaluation and get a structured, evidenced answer drawn from everything the team learned.Two playbooks came out of the process: one on building a knowledge skill from project documentation, one on updating it as knowledge evolves. The method is repeatable on any project.The next programme doesn’t start from zero it starts from a knowledge base that’s still growing. That’s the real finding here: in a moment when knowledge evaporates as fast as it’s generated, structuring what a team learns so it survives and compounds is senior project management.The project ended. The knowledge compounded. The infrastructure kept growing.