Why One Capability Model Has to Hold SAS and Horovod at Once

Capability models resolve the technology question at the level of a noun. Data platform. Analytics. Machine learning. That resolution survives a steering committee, and it is close to useless for anyone who has to buy, schedule and govern the thing, because two products filed under the same noun can share nothing operationally. Same box on the page, different licence model, different hardware, different people, different definition of a repeatable result.

One page in a digital blueprint I worked on for a global staffing and HR services group goes a level further, and the extra level is the whole value of the page. It is the platform overview, and it argues that the group's business blueprints require new digital capabilities on top of the core business ones, plus enhancements to the enabling capabilities the group already had, and that all of it can be delivered through a single integrated platform serving both blueprints at the same time. Five to-be elements sit across it, running from what customers and talent experience through to technology, with infrastructure and facilities named explicitly inside that last element. Five design principles established earlier in the document reappear as the scoring frame for the whole model.

All of that is architecture in the ordinary sense. The part worth a reader's time is much smaller than any of it. In the text layer of that page, the tooling is named. On one side, SAS. On the other, TensorFlow, Python, Horovod and Ludwig.

What that list of five names actually says

Four of those names are one family and one is not, and the distance between them is not a question of vendor taste.

SAS is a licensed statistical environment with decades of institutional custody around it. It has its own data formats, its own scheduling, its own release process, and in most organisations that run it, a named team who have been running it since before anyone in the building said the words machine learning. Results are reproducible by construction, audit trails exist because regulators asked for them, and the operating cost is a licence line somebody in finance already knows the size of.

Horovod is a distributed training framework. Its entire reason to exist is spreading a single training job across many workers, which means it presumes multiple machines, an interconnect worth using, a scheduler that can allocate accelerators, container images that are identical across workers, and checkpointing discipline so an eight-hour job that dies at hour six does not start again from zero. Ludwig is a declarative layer over deep learning. You describe the inputs and the outputs and it assembles and trains the model, which is a deliberate bet that people who are not deep-learning engineers will be the ones building models.

The presence of those two names also dates the page. Both post-date the document's own title date, which means the capability model was revised after it was first drawn, and the revision admitted distributed deep-learning training into it. The SAS entry stayed exactly where it was.

The seam nobody draws

Two stacks on one page with no line between them, and the line is where the engineering lives. I can name five places it has to be drawn, and none of them appear on a capability model in any organisation I have worked in.

Data crossing. The statistical environment holds tables in its own formats with its own type semantics and its own missing-value conventions. The training stack reads something else. Somebody owns that conversion, it is a piece of production software with a failure mode, and it is invisible on an architecture page because it is not a product with a logo.

Scheduling. One side is batch on licensed capacity that is already budgeted. The other side wants accelerators for hours at a time and behaves badly when it does not get them. These are two different queueing problems and they compete for the same money.

Reproducibility. Re-running a statistical program gives the same number. Re-running a distributed training job with a different worker count does not, unless seeds, data ordering and checkpoint handling have been made deliberate. Two definitions of a repeatable result now sit inside one governance regime.

Custody. The old estate has a team with twenty years of context. The new stack usually arrives with none, and the first genuine outage is where the organisation discovers who was supposed to be carrying it.

Arbitration. Both stacks can answer the same business question. Nothing on the page says which answer wins.

Nothing was declared retired. A new class of workload was admitted to the model and the old one stayed exactly where it was, which is how every enterprise stack I have worked on actually got its shape.

The infrastructure line the tool list quietly commits you to

The technology element on this page carries infrastructure and facilities inside it. That phrasing usually signals data centre footprint, hosting and the physical plant, and in a blueprint it is normally left as a heading.

The moment Horovod appears in the same model, the heading has been given content. Multi-worker training with accelerators is a different facilities conversation from a licensed statistical server, and it is one of the few decisions in a digital blueprint that has a hard capital number attached to it in the first year. The tool fragments in the text layer are the only thing on the page that tells you what the facilities have to be, and they arrive without a figure beside them.

The same five elements have been read on this site before, for what they say about two businesses needing different destinations from one shared platform. That piece, How to Run One Platform When Two Business Units Need Different Targets, works the argument at the level of acceptance thresholds. This one sits underneath it. Deciding that two businesses share a platform is a target-state question. Deciding what runs the models, on what hardware, reproducible in whose definition, is the bill.

Write the arbitration rule before the second stack lands

The practical version of this is short, and it applies to any capability model that names more than one modelling technology.

For every named tool, write four sentences. Which decisions is this the system of record for. Which data does it read, and who owns the conversion that gets the data into it. What has to be true for a result from it to be reproducible. Who arbitrates when this tool and another tool in the same model answer the same business question differently.

The fourth sentence is the one that never gets written and the one that costs. A staffing group asking which candidates a vacancy should reach can get a defensible answer from a classical model and a different defensible answer from a trained network. Both are correct within their own frame. Without a stated rule, the winner is chosen by whoever is in the room, and the losing stack starts being described as legacy by people who cannot say what it is worse at.

The agent layer is the third stack, and it arrives the same way

This is the reason a page from a staffing blueprint is worth reading in 2026 rather than filing.

An agent layer does not replace a statistical environment and it does not replace a training stack. It is added, exactly as distributed training was added here, and in eighteen months it will be sitting in the same box on the same kind of page with no line drawn to either of its neighbours. The new property is that an agent can choose which of the two answers a question, which turns the arbitration sentence from a governance nicety into runtime behaviour. A model that quietly prefers whichever backend responds fastest has made a policy decision nobody wrote down.

So the discipline that would have helped this capability model is the discipline that helps now, and it is not an architecture exercise. It is four sentences per tool, written while the model is still a drawing, because the cost of writing them after the second stack is in production is an argument between two teams who both have evidence.

5

Named tools in the capability model, split across a statistical estate and a deep-learning stack

4

Named tools on the deep-learning side, against one on the statistical side

5

To-be elements the model maps, with infrastructure and facilities inside the last

0

Performance or cost figures attached to any named tool

Drawn from the platform overview page of a digital blueprint for a global staffing and HR services group, work I led. The five-element capability model, the five design principles used as its scoring frame, and the named tooling of SAS, TensorFlow, Python, Horovod and Ludwig are the page's own. This was a blueprint and a target capability model, not a running platform, and no result, cost or utilisation figure is reported against any of the named tools. The tooling also post-dates the document's own title date, so it evidences a later revision of the model rather than its first draft. Reading the tool list as a coexistence problem, and the missing arbitration rule as the expensive gap, is ours.