Planning the Architecture Around an SAP Transformation

A programme approved before the map existed

The organisation is a wholesale distributor — food service and retail supply, a national warehouse network, tens of thousands of order lines a day. At the centre of its estate sat an ERP system approaching its third decade, customised so heavily that the boundary between product and bespoke code had stopped being meaningful. Around it: warehouse management, transport planning, an e-commerce platform for customers, EDI links to the large retail chains, financial consolidation, and a long tail of small systems that existed to compensate for something the ERP could not do.

The board had approved the move to a modern SAP platform. The business case was solid, the budget serious, and a systems integrator was about to be selected. What did not exist was a map. Nobody could say with confidence how many interfaces touched the old ERP, which business processes depended on which customisations, or what would break first if a cutover went wrong. The programme director — who had lived through an ERP migration elsewhere — wanted the architecture documented before the integrator's first workshop, on the reasonable grounds that a vendor should not be the one to tell you what your own estate contains.

That framing shaped the whole engagement. We were not there to design the SAP solution; the integrator would do that. We were there to put the surrounding truth into a repository the programme could plan against — processes, systems, interfaces and dependencies, in Sparx EA, at the granularity a transformation needs and no deeper.

Two hundred interfaces, half of them folklore

The interface register, when we found it, was a spreadsheet last updated several years earlier, listing about ninety interfaces. The middleware configuration listed nearer a hundred and sixty active routes, and the EDI platform another forty beyond that. Reconciling the three sources, and adding the point-to-point connections that bypassed middleware entirely — database links, file drops on shares, one venerable FTP job that everyone had forgotten and nothing had broken — the true number came out at just over two hundred interfaces touching the ERP.

Roughly half were undocumented anywhere except in their own configuration. For a good number, the business purpose had to be reconstructed: the interface demonstrably ran, moved data nightly, and consumed effort when it failed, but the process it served had to be traced by asking who screamed when it stopped. Three interfaces, as far as anyone could establish, fed systems that had been decommissioned; they ran anyway, faithfully delivering files nobody read.

The customisation picture was similar. The ERP carried hundreds of bespoke objects, and the honest inventory question was not "what exists" — the system could list that — but "what still matters". A meaningful share of the custom code supported processes that had changed shape years ago, and finding out which share was precisely the kind of question the programme would otherwise have paid integrator day-rates to answer slowly.

Process knowledge, finally, was tribal in the precise sense: complete, reliable and attached to individuals. The order-to-cash flow worked because the people running it knew where the system lied to them — which stock figures to distrust on a Monday, which order types needed manual correction after import. None of that lived anywhere a programme could read it. An ERP transformation replaces exactly the system those work-arounds compensate for, which means the work-arounds themselves are requirements in disguise, and undocumented ones are the requirements you discover during hypercare. Getting them into the model early became one of the workshop series' quiet objectives.

Processes first, systems second

We started with the business processes rather than the systems, because in an ERP transformation the processes are the unit of migration: waves are cut by process scope, testing is organised by process, and the business signs off processes, not interfaces. With the operations leads we modelled the core value streams — order to cash, procure to pay, warehouse operations, transport, financial close — as ArchiMate business processes in Sparx EA, each one served by the application services the systems provide.

The granularity rule was firm: we modelled to the level where a process step maps to systems and hand-offs, and no further. A transformation programme needs to know that credit checking happens inside the ERP during order entry and that a custom module does the checking; it does not need the keystrokes. Where the client wanted detailed process documentation for training, we kept that out of the architecture repository and out of scope — a decision we have defended on every programme since, and one that kept the model maintainable at programme speed. The approach follows what we describe in our work on process modelling in Sparx EA, applied with a transformation's priorities rather than an analyst's.

With the processes in place, every application component, service and interface we subsequently modelled had somewhere to hang: each interface serves a process, directly or through the service it enables, and that single connection — interface to process — is what later made the wave planning honest.

Building the interface inventory

Two hundred interfaces do not get modelled by hand in a workshop, so we scripted the skeleton. The middleware and EDI configurations were exported, parsed, and loaded into Sparx EA through the automation API as flow relationships between application components, each flow carrying tagged values for protocol, direction, frequency, payload type and the middleware route that implements it. The initial load took a few days of scripting rather than weeks of drawing, and gave us a model that was already more complete than any existing register. It is exactly the kind of work our automation API guide exists to make routine.

The workshops then did what only workshops can: attach meaning. Session by session with the application owners, each interface gained a named business purpose, an owner, a criticality, and its connection to the processes it serves — recorded on a paired interface element, since EA traces element to element, while the flow connector keeps the runtime facts. The three orphaned interfaces were confirmed dead and scheduled for switch-off. The FTP job turned out to feed a pricing report a commercial director received every Monday and would have missed by Tuesday.

The inventory settled at just over two hundred interfaces, every one carrying enough metadata to answer the programme's planning questions: what does it serve, who owns it, how often does it run, what happens if it stops for a day. The spreadsheet register was retired, with its owner's blessing, and the repository became the single register by the simple mechanism of being the only one anyone updated.

The customisation question

The bespoke code needed the same treatment as the interfaces: an inventory with meaning attached, built at architecture granularity rather than object granularity. The system could enumerate its own custom objects — several hundred of them — and the platform team could pull usage statistics showing which had actually executed in the previous year. About a third had not run at all; once the owning teams had confirmed no year-end or exceptional use was hiding behind the zeros, that settled their fate cheaply. The remainder we clustered into functional groups — custom pricing, rebate handling, delivery slot allocation, a dozen more — and modelled each group as an application function inside the ERP component, connected to the business processes that depend on it. A few dozen functions the programme could reason about, instead of hundreds of objects it could not.

Each function then carried the triage decision as tagged values: covered by the new platform's standard, rebuild as a sanctioned extension, replace with a satellite product, or retire with its process. Getting those decisions made — in workshops with the process owners, against the model, before the integrator's design phase — was slower than expected and worth every session, because most of them pre-empted a likely change request. The custom rebate logic was the marquee case: process owners assumed it was irreplaceable, the walk through the model showed most of its complexity served two lapsed contracts, and what survived into the new platform was a fraction of the original, as configuration rather than code.

The pattern generalises, and we now open every ERP engagement with it: usage data, confirmed with the owners, clears a large slice; clustering makes the rest discussable, and process linkage turns "what does this code do" into "who would miss it" — which is a question a business can actually answer.

The landscape around the ERP

With processes, systems and interfaces loaded, the current-state landscape could finally be drawn rather than sketched. The central diagram shows the ERP with its satellite systems and the interface flows between them, layered under the business processes they serve — one picture of the thing the programme was about to take apart.

The landscape diagram did its most important work in its first week, in front of the board's programme committee. Seeing the estate on one page — and specifically, seeing that the ERP touched everything, including the systems everyone had mentally filed as independent — recalibrated the room's intuition about risk. The conversation shifted from "when do we switch" to "in what order do we move the pieces", which is the conversation an ERP programme should be having, and the plateaus in the next section are where it led.

Three plateaus, not one big bang

The migration strategy that emerged — finance first, then procurement and sales, warehouse operations last — was modelled as three plateaus in Sparx EA: the current state, a co-existence state, and the target — with a view per wave inside the co-existence plateau, because the middle period changes shape at each go-live. The co-existence plateau is the one that earned its keep. For a period of many months between the first go-live and the last, the new SAP platform would run finance, then progressively procurement and sales, while the legacy ERP still ran warehouse operations and whatever had not yet moved, and the two would have to exchange master data and transactions continuously. That temporary architecture — the most complex the organisation would ever operate — tends to be exactly the one nobody designs.

We modelled it deliberately: which interfaces reroute to the new platform in each wave, which temporary bridges exist only during co-existence and must be built with their own decommissioning in mind, and which capabilities the new platform would not cover at all — the genuine gaps, each recorded as a gap element between the current and target plateaus, with a decision attached: replace with a satellite product, rebuild as an extension, or retire the need.

Because every interface was already linked to the processes it serves, cutting the waves by process scope let a model search produce the candidate interface list per wave; each candidate was then classified by hand — rebuild, reroute or bridge — with the wave assignment recorded as a tagged value the generated reports read. Some interfaces appear in more than one wave, and the temporary bridges add their own. The numbers surprised the programme: the first wave, nominally "just finance", touched around eighty of the two hundred interfaces once master data distribution was counted honestly. Better to be surprised by a model in month two than by a cutover rehearsal in month fourteen.

The model inside the programme

When the systems integrator arrived, the repository changed the shape of the early engagement. The discovery phase the vendor had priced — the weeks where consultants interview your staff to learn your estate — collapsed into a review of generated documents: per-wave interface catalogues, process-to-system matrices, and the landscape and plateau diagrams, all produced from the model with Sparx EA's document templates. The programme paid for design work instead of archaeology, and the integrator's estimates, built on a real inventory rather than a questionnaire, held up far better than anyone's previous experience suggested they would.

Inside the programme, the model became the reference for impact questions, which arrived weekly. What breaks if the custom pricing module retires in wave two? Trace the module to the processes it serves and the interfaces that carry its output: two EDI partners and the e-commerce platform depend on it, so it survives into co-existence behind a compatibility interface, and its real retirement moved to wave three — a decision made in an afternoon, against the model, and recorded in it.

Cutover planning drew on the same structure. Each rehearsal worked from a generated checklist of the interfaces in scope for the wave, their owners, their test evidence and their fallback. The checklists were boring, which is the highest compliment cutover documentation can receive.

The EDI trading partners deserved and got their own treatment, because they are the one part of the estate whose changes require someone else's calendar. Every partner connection was modelled with its message types, direction and the partner's technical contact, and wave two's planning generated a one-page interface sheet per partner — what changes, when, what to test, what stays the same — sent out months ahead. Coordinating test windows with large retail chains is slow at the best of times; doing it from generated, consistent documentation rather than ad hoc emails compressed the negotiation noticeably, and two partners replied asking what tooling produced the sheets. The answer, as always, was the repository they will never see.

Keeping the model current at programme speed

A transformation programme changes its own facts weekly, and a model that lags the programme by a month is a liability wearing a badge of authority. We put three disciplines in place, borrowed from our standard governance approach for large programmes, and sized for this one.

First, the model got a named owner — a client architect, not us — with model maintenance written into her role rather than left as an ambition. Second, the programme's decision log and the repository were joined: any decision that changes the architecture is applied to the model in the same week, with the decision reference in the element's notes, so the model always answers "why is it like this" as well as "how is it". Third, a weekly half-hour model review, timed just before the programme board, walked the diff since last week — new decisions, moved interfaces, changed wave assignments — so drift never accumulated past seven days.

Baselines anchored the gates. At each wave gate, the relevant model branch was baselined as part of the gate approval itself, so "what did we approve" has a durable answer with a date on it. Twice during the programme a later dispute — once about wave scope, once about a temporary bridge's agreed end date — was settled by comparing the current model against the gate baseline, in minutes, without archaeology through meeting minutes. Programme governance produces paper; a baselined model produces evidence.

None of this is glamorous, and all of it is why the model was still true in month eighteen. The alternative pattern — a heroic initial model decaying quietly while the programme sprints ahead — is common enough that we now treat the governance as part of the deliverable, priced and planned, not an aftercare suggestion.

What the model changed

The first wave went live on schedule. One undocumented interface surfaced during the final cutover rehearsal — a file drop from a plant maintenance tool that had escaped every configuration export because it wrote directly to a share the ERP polled. One, out of a starting position where the honest answer to "how many interfaces do you have" had been wrong by more than a hundred. It was bridged in a day, added to the model the same day, and became the programme's favourite war story precisely because it was singular.

The quieter results accumulated across the programme. Estimate disputes with the integrator were settled against the inventory rather than by negotiation stamina. The three dead interfaces and the obsolete custom modules identified in discovery were retired without ceremony, and the co-existence bridges — the classic source of permanent temporary architecture — were decommissioned on schedule in wave three because each one carried its planned end date as a tagged value from the day it was designed, and the model review read the overdue list out loud every week.

It is worth being precise about what the model did not do, because the claim is easy to inflate. It did not design the SAP solution, shorten the build, or make the data migration less miserable — data migration is always miserable. What it did was remove a category of surprise. Every ERP programme carries a budget line, admitted or not, for discovering the estate during the programme; this one spent that budget in the first three months, deliberately, at consulting rates rather than at crisis rates. The gap between those two rates, applied across two hundred interfaces' worth of discovery, is the shape of the business case for doing the mapping first, and it was the number the programme director quoted when asked whether the architecture work had paid.

Perhaps the most durable outcome: the organisation kept the practice. The repository that was built to serve one programme is now simply how the estate is documented, maintained by the same architect, still reviewed weekly, with the target plateau quietly becoming the new current state as the programme closed.

What we would do differently

We would model the master data flows as first-class citizens from the beginning. Our initial inventory treated master data distribution as interfaces like any other; in an ERP transformation it behaves more like a nervous system, and the wave-one surprise — eighty interfaces where "just finance" was expected — was mostly master data's migration weight being recognised late — the flows were in the inventory from the start; their implications were not. We now model master data domains and their distribution explicitly, before the transactional interfaces, on every programme of this shape.

The limitation worth naming: the repository documents the estate around the SAP platform, not the platform's insides. Configuration, custom code within the new system, and the integrator's detailed designs live in SAP's own tooling, and duplicating them in Sparx EA would have created a second, staler copy of someone else's truth. The model stops at the boundary — components, services, interfaces, processes — and points across it. Knowing where to stop was, as usual, most of the design.

If your organisation is heading into an ERP transformation with an estate nobody has mapped — or a programme already underway that keeps being surprised by its own interfaces — this is exactly the shape of work our enterprise architecture consulting practice does. You can reach us through our contact page.

This case study describes a representative engagement pattern. Organisational details are illustrative and do not identify a specific client.