A large operator eventually meets a question that never appears in the architecture documentation: who is allowed to change what, and how long does each change take. Everything else in a transformation plan is downstream of the answer. A global staffing and HR services group arrived at it the way most do, by trying to put one consistent experience in front of clients and candidates and finding that every visible improvement meant editing something a country team owned, had tailored for years, and could not safely hand over.
The estate was fragmented, with heavy local development on top of it. The programme running above it had two tracks: one bottom-up, taking business ideas through prioritisation into a small number of built cases, and one top-down, a multi-country transformation with a target architecture attached. This piece is about a single decision on the second track, because that decision set the ceiling on how fast the first track could ever go.
Three target architectures were assessed against five design principles fixed before any option was described: a good outcome for both the hiring client and the candidate, one consistent experience across every touchpoint, channel and geography, improvements delivered quickly rather than in one distant release, data used as an enabler across matching and everything around it, and building on strengths already present in brand, in-house data, partners and skills. The comparison was written cell by cell in prose. No scores, no weights, no totals.
The challenge
The three options were separate customer-experience and data implementations market by market, a single integrated platform consolidating the touchpoint systems above the estate, and a major integration of the large enterprise systems already installed.
The written rationale was blunt on both rejections. Integrating all legacy systems would be impractical, too expensive and time consuming. Running separate systems per country would forfeit economies of scale and produce an inconsistent experience. A platform, the slide said, offers the best balance of time, cost and impact of end results.
Read as a technology argument that is unremarkable. Read as a governance argument it is the whole engagement. Per-market implementation was credited with local tailoring and fast time to market, then charged with duplicated effort, no shared learning, data points that will not join, and full country autonomy producing divergent end-to-end experiences. Major system integration was credited with scale, consistency and easier analytics, then charged with a long lead time to any benefit, difficulty meeting regulations that differ by country, and rigidity, since large systems are harder to tailor.
Those are the same failure at opposite ends of one dial. At one end nobody can change anything centrally, at the other nobody can change anything locally, and neither end is a setting anyone chose on purpose. The group had been oscillating between the two settings without naming the dial.
The chosen option is the only one of the three where the answer to who may change a given thing depends on which layer it sits in. The platform above is centrally owned and moves at the pace of a release. The systems of record underneath keep their local owners, their local obligations and their own slower pace, and are not asked to converge on a schedule anyone has to defend. Nothing about that is elegant. It is a settlement between two groups who each had a legitimate claim, written down as a diagram.
The approach
Component selection was handled the same way, by capability rather than by vendor. Five plays were evaluated: a cloud data platform, a customer-experience platform, an automated workflow platform valued specifically for how easily it integrates with other systems, a white-label recruitment platform, and CRM. Against the five principles no single play won, and the recommendation said so rather than picking a favourite. The answer was a combination, sequenced: customer experience and automated workflow first, a data platform underneath both because neither functions correctly on poor and unjoined data, and CRM later to complete the 360-degree view of client and candidate.
The white-label judgement is the one worth keeping. It offered quick access to strong technology, but placed the experience inside a third party's system, with an uncertain link back to the group's own estate. Renting somebody else's layer means renting their answer to who is allowed to change what.
The target platform was described as five components: customer experience, data, application programming interface integration, CRM, and a white-label recruitment platform. The integration line does the load-bearing work in that list. It is what turns a legacy system from something you migrate into something you call.
The sequencing followed from the settlement rather than from a wish list. The first wave was itself split into three. The first ninety days were reserved for visible movement across all five workstreams at once, then quick wins, then the new platform. Quick wins in customer experience and data were to be delivered on existing infrastructure, and the only project whose stated objective was to select, procure and implement a platform was enabling technology. Each of the five projects had to declare an objective under three lenses, technology, governance and people, with an explicit not-applicable where none existed, so nobody could hide a governance change inside a technology line.
The lesson written on the plan was about politics, not delivery. Demonstrate progress regularly and iteratively, with visibility across markets, because that is what builds confidence in the programme and prevents people working against it. In an estate where the people who own the systems are the people who can quietly stall you, that sentence is a control, not a platitude.
There was an instrument for the same purpose. A maturity scan across five dimensions, data management, people, technology, organisation and users, benchmarked the operating companies against each other, converted into a value and capability roadmap, and was read back in a workshop rather than issued as a report. Benchmarking country units, then convening them, manufactures consent for a central layer without ordering anyone to accept it.
The outcome
What this work produced was a blueprint, an architecture decision, a hybrid technology recommendation, a first wave broken into three, a hiring plan and a costing flagged as needing further scoping before anyone committed funds. Not a running platform. The counts above are counts of options, components, rationale lines and planning windows, which is what a blueprint honestly contains.
Two things would be done differently now.
The estate inventory would come first, not after the architecture is chosen. A layer is only worth what the systems beneath it will let it call. Deciding to build above rather than into is a short conversation. Establishing which legacy step can be called in real time, which returns an overnight file, and which has to be wrapped first, is work with a cost, and it belongs before the diagram is signed.
The second is the reason this decision matters more today than it did when it was taken. Retrieval-augmented copilots are arriving in recruitment operations now, reading job specifications, candidate records and client correspondence out of a vector store and drafting something a consultant then sends. Reading is the easy half. The moment such a copilot needs to write back, into a record a country team owns, every constraint on this page returns unchanged, and two new ones arrive with it. The data has to be ready, joined and traceable, since a suggestion drawn from a stale record is worse than none. And the decision path has to leave a lineage trail, because European rules on this class of system have reached political agreement, and employment decisions were never going to be the light-touch category. Our Platform work starts at the write path for that reason. Our Consult engagements start one step earlier, at whether a write path exists at all.
The choice to layer above rather than integrate into is usually filed as an integration preference. It is a decision about permission, and it is the one decision in a transformation that everything else inherits.