A group that grew by operating company eventually meets one architecture question wearing a procurement costume. The systems that pay people, raise invoices and hold contracts are different in every market, and each was the right purchase on the day it was made. The question that decides what comes next is not which of those to keep. It is whether the thing a candidate or a client touches has to live inside them.
A global staffing and HR services group put that question on the table as a spectrum rather than as a shortlist of products. At one end sat the model it already had, each country market running and extending its own systems. At the other end sat one consolidated system for the whole group. Three shapes were placed along that line and scored against the same five design principles, written down before the options were.
The challenge
The three shapes are easy to describe, which is the point of drawing them this way. The first leaves the back office estate exactly as it is and layers new technology on top of it, market by market. The second consolidates the back office systems into a single master system. The third cuts the estate in two: the systems of record stay where they are, and the systems people touch are lifted out and replaced with one platform shared across countries.
The five principles the shapes were scored against were customer and talent focus, one consistent experience end to end, speed of improvement, data as an enabler rather than an afterthought, and building on strengths the group already had. Five principles, three shapes, fifteen written judgements, and the recommendation was the third shape, stated with a hedge that deserves to be carried forward rather than tidied away: an integrated platform separating the customer-facing systems from legacy and spanning countries is likely to be the best solution.
Read the losing columns and the reason gets sharper. Full consolidation is not the naive option. It scores at least as well as the winner on the two rows people usually reach for first. One consolidated system does deliver a consistent experience across process, channel and country, and it does make combining data for analysis easier. It also delivers real economies of scale. What it costs is everything else: it is hugely expensive, it has a long lead time before any benefit lands, it struggles where regulation differs by market, and larger systems are more rigid, which makes local tailoring harder exactly where staffing is most local.
Per-market implementations fail from the other direction. They are fast to market in any one country and deliver no economies of scale. Effort is duplicated and nothing learned in one market travels to the next. Full autonomy for country teams produces different end-to-end experiences by construction. The row that settles it is the data one: with the customer-facing systems implemented separately per market, the different data points cannot be integrated easily, so the group-level view everyone assumes will emerge later never does.
Only one of the three shapes holds local tailoring and group consistency at the same time. That is the finding, and it is about where a boundary goes, not about which vendor is best.
The approach
The boundary the blueprint draws runs horizontally rather than by country. Underneath sit the back office systems: contracting, payroll, invoicing, finance, human resources. These stay. Above them sit three shared layers, an integration layer, a data layer and an experience layer, and on top of those sits the customer-facing estate that gets replaced: applicant tracking, content management, customer records, search and match, talent engagement.
The argument for cutting there is a clock argument. The record systems change when a country's employment law changes, when a payroll rule changes, when a contract format changes. That is a slow, externally driven clock. The customer-facing layer changes when a candidate's expectation changes, which is faster and asks nobody's permission. Put both on one release train and the slow clock wins every argument, because the risk of a payroll regression will always outrank the upside of a better search result. The cadence set for the fast side says the same thing in delivery terms: plan in quarters rather than years, release in months rather than quarters, and keep the digital assets loosely coupled through interfaces rather than welded together.
The blueprint is also honest about the seam, which is rarer than it should be. It records that some legacy systems will still need to be changed, because the integration layer will not be able to work around all of them. It records two worked examples from its own estate, and they point in opposite directions. One is a standalone system in a single market that merges with the legacy systems around it perfectly well and extends to other markets badly, because the cost calculations are different in each. The other is a market system that extends easily and still has to be integrated with the legacy sitting underneath it. Read together they refuse to give you a rule. Neither direction is reliably the cheap one, and which is which has to be established system by system.
That seam is where an architecture diagram becomes work somebody has to cost. Deciding to separate the touchpoint from the legacy takes an afternoon. Establishing which record system can answer in a second rather than overnight, and what a wrapper costs for the ones that cannot, is a survey of the estate and then a build. A Consult engagement starts there, because an integration layer specified without that inventory is a picture of one.
The outcome
What this phase produced is a scored comparison, a recommended shape and a written rationale, hedged as the likely best option. No platform was built here. No throughput, cost, adoption or time-to-market figure is reported against any of it. The second decision, what the platform should be made of, was left as a direction: an experience capability and an automated workflow capability, both resting on a data layer good enough to feed them, with consolidated customer records named as a later addition. Straight-through processing was why the workflow side was there at all, and it is only ever as good as the data underneath it.
Three things would be done differently if the same comparison were run now.
The fifteen judgements were written by people, from interviews and experience. Several of them are measurable. How long a change takes to reach a candidate in each market, how many handoffs a placement crosses, where the queue in front of each batch window sits: that is already in the workflow logs, and process mining recovers it with a source attached rather than a signature attached. A scored grid ages the moment the estate under it moves; a mined one refreshes.
The data layer is also the only place model deployment can honestly live. A matching model, or a model that predicts when a placed person becomes available again, is only as fast as the layer that calls it and only as trustworthy as the features it was given. That means a feature store rather than per-market extracts, and lineage from the record system through to the decision a recruiter saw, because the alternative is a model whose training data nobody can reconstruct. That is the split our Platform work is organised around: the centre holds the feature store, the lineage and the path to production, while the markets keep their own use cases. Deciding the platform shape and deciding how models reach production are the same decision, usually taken twice by two committees.
And the cautious language-model pilots now running across the industry in document handling and job description drafting sharpen the same point. A model that reads a CV well still needs somewhere to put the result. If the customer-facing layer is per-market, the pilot has to be built and integrated once per market, and the second country is where the enthusiasm dies. If it is shared, it is built once and the rest is configuration.
The instinct in a federated group is to argue about which systems to replace. The more useful argument is about where to cut. Get the boundary right and the slow half stays slow on purpose, while the half a customer can see stops waiting for it.