The Translation Layer

Summary

Ask why an enterprise needs dozens of business and systems analysts to run its software estate and you will usually be told it is because the business is complex. That is true and it is not the reason. The analysts exist because there is a gap between the language the business speaks and the form the vendor's system requires, and somebody has to stand in it. The size of that population tracks the width of the gap far more closely than it tracks the complexity of the operation. Three architectural properties set the width: whether configuration is readable by the people who own the process, whether a change can be made without a services engagement, and whether the system's own record of what it does is legible without translation. Where all three hold, the gap narrows to the part that was never translation in the first place — deciding what the business actually needs, arbitrating between stakeholders who want different things, and knowing which requirement is load-bearing. That part does not shrink, and the people who do it well become more valuable, not less. What shrinks is the part that exists only because a vendor chose to keep the settings in their database. The honest version of this argument is not that software estates will need fewer smart people. It is that a specific, large, and expensive category of work is an artefact of design, and artefacts of design can be designed away.

1. What the analysts are actually doing

Sit with a systems analyst supporting a large regulated platform for a week and sort the work by kind. It falls into four piles, and they are not equally durable.

Translation. The business says "we need to know which samples are past their consent expiry." The analyst determines which tables hold consent dates, which of four date fields is authoritative, how the vendor's query builder expresses a relative date, and what the report will need to look like to be signed off. Nothing here is a judgement about the business. It is conversion between two representations.

Navigation. Knowing that this vendor's system stores that setting in an administration module three levels down, that changing it requires a particular privilege, and that it interacts badly with a setting somebody configured in 2019. This is expertise, and it is entirely about the product.

Brokerage. Getting a change through the vendor. Raising the ticket, scoping the services engagement, negotiating what falls inside the support contract, chasing it. In some estates this is most of the role.

Judgement. Deciding what the business actually needs as distinct from what it asked for. Noticing that two departments have described the same requirement in incompatible language. Knowing which of eleven requested fields will still matter in three years and which is somebody's temporary workaround given permanent form.

Only the fourth is analysis in the sense the job title implies. The first three are consequences of the software's design, and they typically consume the majority of the capacity.

That is the claim this paper turns on, and it is worth stating plainly because it determines everything downstream: most analyst effort in a large estate is not spent understanding the business. It is spent operating the gap between the business and the vendor.

2. Why the gap is wide

The width is set by three properties, and none of them is a law of nature.

Configuration lives where the process owner cannot read it. When the rules that govern a workflow are rows in a vendor's database, reachable only through the vendor's administrative interface, the person who owns the process cannot inspect what the system is currently doing. They must ask someone who can. That question, asked several hundred times a year across an estate, is a staffing requirement.

Change is an engagement rather than an edit. If altering a validation rule means a ticket, a scoping call, a quote, a services booking, and a release, then a role exists to manage that pipeline. The role is real and the people are good at it. But it is a role created by the vendor's delivery model, not by the difficulty of the change.

The system's record of itself needs interpretation. An audit trail exported as old-value/new-value pairs is not a description of what happened; it is raw material from which a description can be assembled by someone who knows the schema. So QA cannot self-serve, and another translation seat appears.

Notice what these have in common. Each is a decision a vendor made about where to keep control, and each converts directly into headcount on the customer's side. The cost does not appear on the licence invoice. It appears in the customer's payroll, which is why it is rarely compared across vendors and almost never priced in a selection.

3. What actually changes this

Two shifts are in progress. They are frequently conflated and they operate differently.

3.1 Declarative configuration narrows translation and navigation

When the data model, workflow rules, permissions, and validation logic are expressed as readable, versioned files rather than as opaque database state, three things follow directly.

The process owner can read the current state without an intermediary. A change is a diff, reviewable by the people accountable for the process, in the form they already use for every other controlled document. And the reviewing of that change is the evidence, rather than a separate artefact produced afterwards to describe it.

This does not make the system simpler. A complex operation still has complex rules. What it removes is the requirement that a specialist stand between the rule and the person who owns it.

Ask to see: the difference between last month's configuration and this month's, as a document a quality reviewer could sign.

3.2 Agentic assistance narrows the residue

The remaining translation work — expressing an intent in the system's terms, locating the relevant configuration, drafting the change — is precisely the shape of work that language models handle well: bounded, textual, verifiable against a known-good result.

This is worth stating carefully, because it is where the argument is most often overclaimed. An agent drafting a configuration change is not exercising judgement about whether the change is right. It is doing the conversion an analyst would have done, faster, and producing something a human then reviews. The reviewer is still required. What has gone is the wait, and the specialist scarcity that made the wait long.

The combination matters more than either half. Declarative configuration without assistance still requires someone fluent in the configuration language. Assistance over opaque vendor state produces confident output nobody can verify. Together they change the economics; separately, much less.

4. What does not shrink

Four things survive, and it is worth being specific rather than gesturing at "the strategic parts."

Deciding what is actually needed. The gap between a stated requirement and a real one is not a translation problem and no architecture closes it. Someone has to notice that the request for a new field is a workaround for a broken process upstream.

Arbitrating between stakeholders. When two sites describe incompatible requirements in the same words, resolving it is organisational work. It requires standing, relationships, and knowledge of who can be overruled. No system property touches this.

Knowing what is load-bearing. Which requirement, if dropped, causes a regulatory finding two years later. This is domain knowledge accumulated over time and it is the least substitutable thing in the role.

Accountability. Someone signs. Regulated change control requires named humans who carry responsibility for a decision, and that requirement is fixed by law rather than by architecture.

Notice that all four are the fourth pile from §1, and that the same people who are good at those are usually the ones currently spending most of their week on the first three. The argument is not that the role disappears. It is that the role is being crowded out of its own job description by work that the software should never have required.

5. What this means for an estate

Three consequences, in descending order of confidence.

Analyst headcount attached to a platform is a measurable property of that platform. It can be counted, compared between vendors, and asked about during selection. Almost nobody does this, which is odd given it is frequently the larger number. A vendor selection that compares licence and implementation cost while ignoring the standing internal cost of operating the system is comparing the smaller half.

Ask any vendor: how many of our people will be needed to configure and operate this after go-live, and doing what? The answer, and the confidence with which it is given, is informative.

The reduction is not uniform. Estates dominated by brokerage work — where most analyst capacity goes into managing vendor engagements — see the largest change, because that pile is almost entirely artefact. Estates where analysts genuinely do domain judgement see the least. Most large estates are the former and describe themselves as the latter.

The transition is harder than the end state. Moving from a platform that needs twenty analysts to one that needs six is not a staffing exercise. The knowledge those twenty hold is real, largely undocumented, and substantially about how the old system behaves. Some of it becomes worthless and some of it is the only record of why a process works the way it does. Distinguishing the two is difficult and mostly nobody tries.

6. Scope of the claim

Where the claim applies, and what it costs.

The category boundaries are cleaner in this paper than in a real week. Analysts do not spend Tuesday translating and Wednesday judging. The piles interleave, and the judgement often happens during the translation — noticing, while mapping a field, that the requirement makes no sense. Removing the translation may remove some of the occasions on which judgement gets exercised. That risk is real and worth designing against.

Declarative configuration moves the specialism rather than eliminating it, at least initially. Someone must still be fluent in the configuration model, and early in adoption that person is scarce in a different way. The claim is that this fluency is more transferable than product-specific navigation — a readable, versioned model is closer to skills people already have than a proprietary administration console.

7. The question worth asking

Not "how many analysts will AI replace." That framing produces bad answers in both directions.

The better question is: how much of our analyst capacity is spent on work that exists only because of how our software is built? It is answerable. Take a quarter of change requests and sort them into the four piles from §1. The ratio is the finding, and it is a property of the estate rather than an opinion about technology.

Organisations that run that exercise are frequently surprised. Not because the work is unnecessary — it is entirely necessary, given the software — but because so little of it turns out to be about the business.

Appendix — Sorting a change request

A practical instrument. Take twenty recent change requests and place each one.

Two cautions. Requests often contain more than one pile, so score the dominant kind and accept the imprecision. And a request that looks like judgement may be brokerage in disguise — "deciding what to prioritise" is judgement when the constraint is real and brokerage when the constraint is the vendor's release schedule.

This paper argues from mechanism rather than from measurement, and says so. It makes no claim about any specific vendor's analyst footprint, including our own. Where an assertion is checkable inside a reader's own organisation, the check is given.