Sprint Data Sources Are an Architecture Decision in Disguise

On 6 October 2014, a large European retail banking group opened the first sprint of an adviser workstation with a 23-slide technical handover. The subtitle is exact about what it contains: data sources, calling conventions and sequences. Two tables at the front list 24 services the tool will need with a status beside each. The 20 slides after that show one screen of the product apiece, most of them carrying a short line reading "Data source", then the calls that fill it.

Read as a shopping list, it is a procurement document. Read as call sequences, it is an architecture decision that had already been taken, quietly, about who owns each fact an adviser sees.

A data source line is four decisions, not one

Take the smallest thing on the customer card: a badge saying the customer is under guardianship. One badge, one word on screen. The deck writes out what filling it takes. The badge is the surface. Behind it sits a named operation on the customer relationships service. That operation will not answer a general question, so the request has to be assembled with a domain name and a relationship key set correctly, and the answer is read by convention: if the returned relationship list comes back non-empty, the customer has a guardian. Only then does the record itself exist, in the group's customer master data on the service bus.

Four steps, and each is a decision someone has to own. Which service. Which operation on it. Which domain keys go into the request, in a vocabulary the screen designer never sees. Which system is authoritative for the answer. The row is worth reading twice, because it pairs that badge with a second condition, a minority flag defined as an age below eighteen. The deck writes that one as a bare property name with no system beside it. Same row on the same widget, and one half names its owner while the other half assumes you know.

The exhibit takes one read path per system named in the deck and lays them out on those four planes, so the depth is visible rather than described.

Loading exhibit

⤢ Expand

Five of the six lanes run the full four planes. One does not. The customer's role in the relationship, the one that decides whether the customer may hold a profile at all, is marked to be stored in the tool's own database. It is one of only two values on that widget the tool can fill without a call, the other being a flag for an underage customer with their own income, and the specification quietly makes the role the gate for everything else on the screen.

That is the shape of the problem, and it did not belong to 2014. Any team wiring a new front end onto an enterprise estate is taking the same four decisions per field, most of them undocumented, most of them made in a hurry by whoever was closest to the integration.

The readiness column was the sprint plan

The two tables at the front of the deck carry a status per service, and the distribution is the honest version of the plan. Of 24 catalogued services, 2 sat on the group's service bus, which is the only status in the table that names a running system, 4 were mocks with two of those still to be written, 8 were specified in a document with no implementation behind them, 1 was under research, and 9 had not been defined at all.

Two live services out of 24 is not a warning sign in itself. It is the normal state of a sprint one that starts against a large estate. What matters is that this column, not the feature backlog, decided what the first sprint could honestly contain. Screens backed by the customer master data could be built against something real, because those were the two entries marked as live on the bus. Screens backed by the customer-profile and risk-calculation services could only be built against mocks, which means the team was writing to a contract rather than to a system, and would find out later whether the contract held.

There is a sharper point hiding in the same tables. The two sources the screens lean on hardest, the configuration service and the core banking platform that answers the authorisation calls, are not in the 24 at all. The screens call them by name, with method signatures and entitlement codes written out, and the readiness ledger has no row for either. The document counts the readiness of what it was asked to integrate and stays silent on what it was standing on.

The deck is candid about the seams. One authorisation code is written down with a note that it may change and an interim code to use meanwhile. One screen depends on an installed desktop component and the specification asks the build team to name two or three machines so it can be installed for testing. A problem-notification screen is marked to be determined, and so is the version to display on it. Those are not defects in the document. They are the true edges of what was known on the day it was written, and each one is a place where the map and the estate would drift apart within weeks with nobody noticing.

The control plane nobody called architecture

The most useful number in the deck is a count. Across the 20 screen slides, the configuration service is named on 13. The core banking platform, the risk-calculation service and the customer-profile service are each named on 4, the customer master data on 3, and the tool's own database on 1.

Spend a moment on what that ratio means. More than half the surface of an advisory product is not advisory logic. It is the machinery that lets each business unit decide what its own advisers see: which versioned data packages are active, which unit acts as a control unit publishing configuration for others, which units inherit rather than publish, with the two states specified as mutually exclusive. The entitlement gating is written control by control rather than screen by screen. One panel opens for a user holding any of three named rights, another for a single right, and one is narrowed further to a single named unit identifier, so that a right alone is not enough unless you are sitting in the unit the deck names. Individual package checkboxes are disabled when nothing has changed, and disabled again when the entitlement behind them is absent, so the permission model reaches all the way into the pixels.

The operating model is why. When separate units share one product, their differences need a place to live, and that place either gets designed or it gets improvised. In this deck it had been designed, in detail, including the unglamorous parts: a contact-data screen with a hundred-character limit and a one-line note stating there are no checks whatsoever.

The lesson generalises past banking. When one product serves many semi-autonomous units, the configuration layer is the product. Anything you plan to put agents on top of will meet that layer before it meets a customer record, because the answer to what an agent is allowed to read, show or change is stored there.

What a loop and a harness do to the same work

Now the part that matters for 2026. Everything described above was assembled by hand. A person read the interface specifications, chose an operation per field, worked out which domain keys the request needed, wrote it on a slide next to a screen image, and typed a status word beside each service. Somebody else read those slides and wrote the code. The document was accurate on the day it shipped and started decaying the next morning, because a status word does not update itself when a mock becomes a live service.

The individual acts in that chain are now loop work, and none of them is exotic.

Reading specifications and proposing bindings is a loop. Point an agent at the interface documents and the screen specifications and it can propose, per field, the operation to call, the request it has to assemble, and the record it lands on. It will be wrong on some of them, which is the point of the harness rather than an argument against the loop.

The harness is the half most teams skip. It is an executable version of every contract in the deck: fixtures that satisfy each request shape, a mock that answers the way the specification says the real service will, a replay of every named call sequence, and an assertion per screen that says which field came from which record. Once the contracts are executable, the proposals from the loop are checked instead of trusted, and the readiness ledger stops being a hand-typed column. It becomes what a probe reports when it calls each of the 24 services and records what came back.

Interconnected pipelines are what make that stick. When the risk-calculation service crosses from mock to live, every screen whose lane touches it needs re-verification. In 2014 that meant somebody remembering. As a pipeline it is an event: readiness changes, the affected lanes are recomputed from the dependency graph, the contract tests run against the real service, and the differences between what the mock promised and what the estate returned arrive as a list rather than as a defect found in user testing three weeks later.

Computer vision closes the last manual gap. Screen specifications of this kind are annotated pictures with a table beside them keying each callout number to a field. This deck works that way throughout: the customer widget is written as numbered rows 1, 4, 5, 5a, 6 and 17, and the configuration slides cite control numbers on the pages they describe. A person used to sit between the design and the table and retype. A vision model now reads the callouts off the design, aligns them to the field rows, and hands the loop a structured starting point, so the binding work begins from the artefact the designer actually produced.

Put those together and the autonomous part is not an agent inventing architecture. It is an agent keeping an accurate, executable map of a large estate current without anyone being asked to maintain it. The four decisions per field still get made deliberately. What disappears is the weeks of transcription around them, and the silent decay afterwards.

The decision you are taking anyway

The deck's real subject is ownership. For every fact on a screen, some system is authoritative, some contract has to be assembled to ask it, and some team is on the hook when the answer is wrong. Writing "Data source" on a slide does not avoid those decisions. It records the ones that were already taken, usually by whoever was nearest the integration on the day.

Teams that treat that line as documentation get a picture that is true once. Teams that treat it as an interface contract, executable and continuously verified, get a data layer an agent can stand on. The difference used to be a question of budget for a discipline nobody could afford. With a loop proposing the bindings and a harness proving them, it is a question of whether you decided to do it.

24

Services in the sprint-1 catalogue

2

Live on the service bus at sprint start

13 of 20

Screen slides naming the configuration service

4

Resolution steps behind a single on-screen badge

The map of who owns which fact was accurate for exactly one day in 2014. Made executable, it is accurate every morning, and it is the thing your agents actually run on.