Six Technology Roles in the First Wave and None of Them Build the Interfaces

Integration debt is usually explained as an architecture failure. Somebody chose the wrong pattern, or let a point-to-point mess accumulate, or skipped a contract. In my experience it is settled earlier than that, in a document nobody thinks of as an architecture document at all. It is settled in the staffing table, in the column that says which delivery wave each role begins.

A digital transformation blueprint I wrote for a global staffing and HR services group has one of those tables for every skill family. The technology family is the one worth reading slowly. Eleven distinct roles across twelve rows, because solution architects are listed twice, which is a duplication in the source rather than a second role. Against each role sits a tick placing it in one of three delivery horizons.

Six roles carry the tick for the first horizon: solution architects, an infrastructure architect, a software engineer, a platform programmer and configurator, QA and test managers and analysts, and security specialists. Five wait for the second: the group enterprise architect, an infrastructure engineer, API developers, app developers, web developers.

Sort the same table by what each role leaves behind

The published case study on this design reads the whole organisation for a different pattern, that every skill family is staffed a horizon before the role that supervises it, and the technology family fits that pattern along with the other four. Seniority is one key you can sort these eleven rows by.

Sort them by output instead and a second line appears, running in a different place.

Ask what each first-horizon role leaves behind by the time the first horizon closes. An architecture for specific solutions and services. Configured platform components. Back-end code written to project specification. An agreed test plan and its results. A set of security standards and the assurance that designs conform to them. Every one of those artefacts lives inside the platform.

Now ask the same question of the second horizon. API developers are responsible for developing APIs and other interfaces in line with specification and standards. App developers build mobile applications. Web developers build new online services. Every artefact there is a surface, a place where something outside the platform touches it.

The line through this table is not only seniority. It is inside against edge. Everything that faces in is first wave. Everything that faces out waits a horizon.

Security got the argument the interfaces did not

The security row is the most carefully reasoned entry in the table. The accountability is to agree security standards, to ensure that designs are in line with those standards, and to see that the necessary quality assurance and testing is carried out. Read the object of that sentence. It is designs. Not systems, not incidents, not a scanning schedule. The role acts on work that has not been built yet.

Whoever wrote that row understood something that a great many programmes of that period did not, which is that a standard applied to a design that already exists is not a standard, it is a remediation programme. If you want the property, you need the person in the room while the design is being drawn. So security specialists go in the first wave, alongside the first architects, with no argument recorded because none was needed.

The identical argument applies, word for word, to interfaces. An API is a design-time commitment. It is a statement about what the platform will accept, what it will emit, in what shape, with what guarantees, and it is decided on the day somebody draws the first internal model, whether or not a person is accountable for it. Nobody made that argument on this page, and so the roles that would carry it sit a wave later.

Deferring the API developers does not defer the interface decision. It defers ownership of a decision that gets taken anyway, by people whose accountability stops at the platform boundary.

The rest of the document says the edge is the product

Two other pages make the deferral harder to defend from inside the same blueprint.

The summary page names the target platform as customer experience, data, API integration, customer relationship management and a white-label HR platform. Integration is a named component of the thing being built, sitting in the same list as the data layer, not an implementation detail underneath one.

The technology page goes further. It states the defining architectural move as separating the touchpoint estate from the legacy record systems, and it records a lesson that business services should be API-connected, with agility given as the stated purpose rather than integration for its own sake. Separating the touchpoint from the record systems is a proposition about interfaces and nothing else. If that separation is the architecture, then the interface layer is the architecture, and the people who build it belong to the first build, not to a later elaboration of it.

There is a second signal in the same column. The group enterprise architect, accountable for whether the platform is fit for strategic needs across large and small markets and for governing the key technology choices, is also second horizon. The outward view is therefore deferred twice over, once in who governs cross-market fit and once in who builds the connections. The first wave has a solution architect scoped to specific solutions and services, and an infrastructure architect. Both point inward by definition.

11

Distinct technology roles in the table, printed on twelve rows

6

Required in the first horizon, none of them building an interface

3

Interface roles, API, app and web, all in the second horizon

0

Systems built at the point of writing; the document is a blueprint

What the deferral actually costs

When the interface role arrives after the internal model has settled, the interface becomes a projection of that model. Field names come from the platform's own tables. Error conditions surface as internal states. Pagination follows whatever the storage layer found convenient. Versioning gets retrofitted, usually after the first consumer breaks.

Then every consuming team writes the platform's internal shape into its own code, and from that moment the cost of changing the internal shape is no longer paid by the platform team. It is paid by everyone at once, which in practice means it is not paid and the model never changes again. That is what integration debt is. It is not created in the second wave by people writing weak APIs. It is created in the first wave by nobody being accountable for the outside of the thing while the inside is being decided.

There is a local variant of the same gap. Almost every technology role in the design is central only. Three carry a note that they might also sit in large local markets: platform configuration, QA and test, and web development. The first two are first horizon; web development, the only interface-adjacent role a market could hold, is second. For a group whose stated problem is that every country runs its own tailored systems, that is the wave in which local integration reality most needed a seat.

The same table, with 2026 nouns

I see this table again most weeks, with different words in it. First wave on an agent programme: model access, agent loop and prompt engineering, evaluation harness, security review, retrieval infrastructure. Second wave: connectors, tool servers, the identity mapping into the systems of record, the surfaces where an actual business user meets the thing.

The reasoning behind that split is identical, and so is the failure it produces. Security is staffed early, correctly, because everybody has now learned that lesson. The tool and integration layer is treated as plumbing that can follow once the intelligence works. What ships at the end of the first wave is an agent that reasons well in a demonstration and cannot reach anything a customer would notice, followed by a retrofit of connectors onto a design that never expected them.

Three changes I would make to the table

Put one first-wave role on the edge. Not a review board and not an integration workstream that starts later. A named build role whose output is the interface contract, sitting beside the solution architects while they work.

Write the contract in the first wave even where the implementation waits. Deferring the code is a resourcing decision and often the right one. Deferring the contract is an architecture decision taken by default, and nobody records it as one.

Apply the security test to every deferral in the plan. The question that row answers correctly is whether the thing can be added later without redoing the design. Where the answer is no, the role belongs in the first wave. Interfaces fail that test for exactly the reason security does.

Source: the integrating technical, organisational and governance blueprint I wrote for a global staffing and HR services group, at draft version, covering the target operating model, the role-by-role organisation and the enabling technology direction. The technology role table and its horizon column are the evidence for every count on this page. The document is a design, not a delivery record; no platform, no role and no interface described here is reported as built. The blueprint makes no claim about integration risk. Reading the deferral of the interface roles as the origin of that risk is mine.