Building a CoE from PoC to Production Scale
What started as a proof of concept run by a business analyst and two BA-trained developers grew into a fully structured Blue Prism CoE — with defined roles, clear specialisations, and the architectural depth to make platform-level decisions at the right time.
A Blue Prism proof of concept can be run with a small, generalist team. A BA manager and a couple of developers trained up on the platform is enough to demonstrate value and get automation into production. But what works at PoC stage becomes a structural liability as the programme scales — the skills that get automation off the ground are not the same skills needed to run it sustainably at production scale.
As the volume of live processes grows, the complexity of the estate grows with it. More system dependencies, more operational surface area, more interactions between processes, more decisions that have consequences across the entire programme rather than within a single delivery. A team that isn't structured to handle that complexity will feel it — in operational incidents, in technical debt, and in the quality of decisions made under delivery pressure.
As the programme grew, the gaps in the PoC team structure became visible. Without dedicated process controllers, operational monitoring fell to the developers. Without solution architects, design decisions were made ad hoc during build. Without an RPA architect, platform-level decisions — the ones with long-term implications for how the entire estate operated — weren't being made at all.
The challenge wasn't finding people. It was identifying exactly which roles the programme needed, at what point it needed them, and what level of experience each role required to have the intended impact.
Building a CoE that can scale sustainably requires deliberate capability design across three layers. Getting any one of them wrong creates a ceiling the programme will eventually hit.
Defined roles and clear ownership
The team grew from a PoC configuration — a BA manager and two BA-trained developers — to a full CoE structure: RPA developers, business analysts, process controllers, senior developers and BAs, solution architects, and RPA architect. Each role filled a specific gap. Process controllers gave operations its own dedicated function rather than leaving monitoring to developers. Solution architects introduced design rigour before build began. The separation of responsibilities meant specialists could go deep in their area rather than everyone doing everything adequately.
The architect function
The RPA architect role carries a different weight to the delivery roles around it. Deep knowledge of the Blue Prism platform — across process design, solution architecture, runtime resource management, environment configuration, and infrastructure topology — enables decisions that the delivery team can't make alone, because they require a view across the entire estate. The move from a single application server to a fully HA implementation is the clearest example: a decision with significant infrastructure implications that required understanding load balancing, session management, and how the platform would behave under real production conditions.
Proactive decisions, not reactive ones
The HA migration wasn't triggered by an outage. It was identified as the right architectural step at the right stage of programme maturity — before the single application server became a single point of failure that the business had come to depend on. That's what the architect function is for: understanding the platform deeply enough to know what the next constraint will be, and making the call before it becomes a problem. The impact of getting that timing right is measured in operational continuity — processes that ran without disruption through changes that, handled reactively, would have caused them.
The evolution from PoC to production CoE wasn't just about hiring more people. It was about building a team where each person's role was clearly defined, responsibilities didn't overlap in ways that created gaps, and the programme had the specialist depth it needed at each layer — delivery, design, architecture, operations, and business relationship management.
A broader technical background proved as important as Blue Prism delivery experience when it came to understanding how the platform sat on infrastructure, how runtime resources behaved under load, and what production resilience actually required. That understanding is what made the HA decision possible — and what shaped the quality of architectural decisions across the programme more broadly.
The right team structure doesn't eliminate risk. It ensures that when risks materialise — as they always do in a production automation programme — the programme has the capability to identify them early, make informed decisions about how to address them, and act before they become incidents.
A CoE with the structural depth to make decisions at the right level, at the right time.
Each person in the team knew exactly what they owned. Architectural decisions were made by someone with the platform depth to make them well. And the programme scaled without the operational incidents that come from a team structure built for a PoC trying to carry a production estate.
People & Capability in ROM2 asks whether the CoE has the right roles, skills, and culture to deliver sustainably. The difference between a programme that scales and one that doesn't often comes down to how deliberately the capability structure was designed — not just whether people are competent, but whether the right people are in the right roles with the right level of ownership.
Assess your CoE's people and capability maturity →