The surprise that should not have been one
A postal services organisation came to us shortly after an uncomfortable discovery. During the preparation of a routine infrastructure change, someone noticed that the operating system under a parcel-sorting control application — software that helps move a seven-figure volume of parcels through sorting centres every week — had passed out of extended support several months earlier. There had been no outage and no incident. There had also been no decision: nobody had chosen to run a critical application on unsupported software, and that was precisely what unsettled the IT leadership. If this had slipped through, what else had?
The information had not been missing. The end-of-support date sat in a vendor lifecycle spreadsheet maintained by an infrastructure engineer; the application's criticality sat in the architecture repository; the dependency between the two sat mostly in the heads of the operations team. Each fact was known somewhere. No single place connected a date to a technology, the technology to the applications running on it, and those applications to the business processes that would stop. The organisation did not have a data problem — it had a joining problem.
The brief was to connect technology lifecycle information to the application architecture in Sparx Enterprise Architect, so that "what leaves support in the next eighteen months, and what does it hit" becomes a query with a standing answer, and renewal becomes something planned rather than discovered.
Spreadsheets, and what they could not answer
The estate on paper: around two hundred and fifty applications in a reasonably maintained EA repository, and roughly four hundred distinct technology products and versions in the wild — operating systems, database engines, middleware, runtime platforms — tracked across three spreadsheets owned by different infrastructure teams, plus a CMDB whose technology records were, as the operations manager put it, directionally correct.
The spreadsheets were genuinely good at what they did: each row a product and version, each with dates the responsible engineer kept fresh. What they could not do was answer any question that crossed their edges. Which applications sit on this database version? The spreadsheet did not know; the CMDB half-knew, with server-to-application mappings that were complete for the estate's newer half and speculative for the older — and the older half is where lifecycle risk lives. Which of the technologies leaving support next year sits under anything the business would call critical? That question needed all three spreadsheets, the CMDB and the repository at once, so in practice it was answered annually, by hand, for an audit, and was stale by the following quarter.
We also found the quieter half of the problem: a meaningful share of the estate — in-house frameworks, a national customs interface component, an aged sorting-machine integration layer — had no vendor and therefore no vendor dates. A lifecycle process built only on vendor announcements silently exempts exactly the software nobody else in the world is maintaining either.
We shaped the engagement around those findings: roughly four months, part-time, in three phases. First the modelling decisions and the scripted load — the shortest phase, despite carrying all the visible technology. Then the long middle: confirming the application-to-technology dependencies with the people who operate them, which no script performs. Finally the roadmap work and the installation of a quarterly rhythm, because a lifecycle model nobody refreshes ages into exactly the spreadsheets we had been called in to replace. The client's architects worked alongside us throughout — deliberately, since they would own every part of it within the year — and we stayed attached to the quarterly reviews for the first year, which is the vantage point this account is written from.
Modelling the technology estate
The design in Sparx EA is deliberately conventional ArchiMate: applications the repository already held; beneath them, the technologies they depend on, as system software and node elements; between them, the serving and assignment relationships that carry the whole exercise. Every technology element carries a small set of tagged values agreed in the first workshop: vendor, product, version, the general-availability date, end of mainstream support, end of extended support, a source field recording where each date came from, and a review date for the technologies that have no vendor to announce one.
Two structural decisions earned their keep. First, technologies are modelled per product-and-major-version, not per installation — with a finer split where a vendor’s support terms genuinely turn on it; the odd patch-set boundary earned its own element. The lifecycle question is "Oracle 12c leaves support", not "server PRDDB07 leaves support" — instance-level detail stayed in the CMDB, where it belongs, and the model stayed small enough to maintain: a few hundred technology elements rather than several thousand server records. Second, versions of the same product are distinct elements, because "we run PostgreSQL" is exactly the sentence that hides a supported 15 and an abandoned 9.6 in the same breath.
The technology catalogue lives in its own package hierarchy — one branch per technology family, owned by the infrastructure team lead rather than the architects, since the people who patch the platforms are the people who know when the list changes. Applications may only depend on catalogue entries; the import script only ever writes catalogue entries, and a validation search flags any dependency drawn to anything else, so the estate cannot quietly grow "Oracle (Kevin's version)" the way the spreadsheets had. Adding a technology to the catalogue is deliberately cheap — a script prompt and two minutes — because any friction there would send people straight back to free text, and the catalogue's authority survives only as long as it is the easiest place to record the truth.
Getting the dates in, and keeping them honest
The initial load was scripted rather than typed. We consolidated the three spreadsheets into one normalised sheet — the hardest part being deduplicating product names, where "MS SQL 2014", "SQL Server 2014" and "SQLServer14 SP3" turned out to be one product and, in two irritating cases, genuinely different installations — and then a script over the EA automation API created or updated the technology elements, keyed on product and version, writing the tagged values and recording the source spreadsheet in each element's source field.
Keeping the dates honest is a process, not a script, and we were direct with the client about that. Vendors move dates — extensions are announced, products are handed to new owners, "end of support" splits into finer-grained phases. So each technology element's source field names where its dates come from, and a quarterly refresh (an afternoon, scripted comparison against the engineers' updated sheet) is written into the operating rhythm described below. For the in-house technologies with no vendor, the review-date tagged value stands in: the owning team commits to reaffirm or revise the date annually, which converts "no information" into "a named person's current judgement" — weaker than a vendor bulletin, and considerably stronger than silence.
Vendor dates also carry their own traps, which the source field exists to defuse. "End of support" is not one date but a family — mainstream, extended, security-only, and the paid extensions vendors increasingly sell for products they have nominally abandoned — and two teams reading different phases of the same product had, in the old spreadsheets, recorded two "correct" dates a full three years apart. The model's convention is explicit: both mainstream and extended dates are stored, the classification runs against extended support, and a paid-extension arrangement is recorded as its own dated fact rather than by quietly moving the end date. When a vendor rebrands or hands a product line to a successor company — which happened once during the engagement — the element keeps its identity and history — the rename goes into the normalised sheet’s mapping so the import key follows it — and only its attributes change. Spreadsheets lose that thread; a keyed model element does not.
Connecting technologies to applications
The expensive part of the engagement was never the dates; it was the middle of the join — which applications actually depend on which technologies. We seeded the relationships from the CMDB's server-to-application mappings where they existed, imported as draft-status relationships to make their provenance visible, and then confirmed or corrected them in short sessions with each application's operations contact: about twenty sessions over six weeks, working through the estate in order of business criticality, most dependencies confirmed in minutes with the occasional genuine surprise — including a customer-facing tracking service quietly dependent on the same ageing message broker as the sorting control system, a coupling nobody had drawn anywhere.
We make no apology for how manual that sounds. Automated discovery tooling can enumerate what runs on a server; it cannot tell you which of those things an application would miss. The interviews were where the model earned the right to be trusted, and trust is what an exercise like this exists to produce. By the end, the critical half of the application estate had confirmed technology dependencies; the long tail was mapped to draft status with a plan to firm it up opportunistically, change by change — an honest partial state the model itself records, rather than a completeness the data could not support.
The draft-versus-confirmed distinction is carried, like everything else here, in a tagged value on the relationship itself, and it changed how people read the model's answers. A query result that says "four confirmed dependencies, two draft" invites exactly the right follow-up question; a result that presents six undifferentiated lines invites false confidence. Models that admit what they do not know get consulted; models that bluff get quietly cross-checked against spreadsheets until someone declares them dead.
Making time visible on the diagrams
With dates on elements and relationships underneath applications, the repository could finally answer the standing question — and, just as importantly, show it. A scheduled script classifies every technology element against the calendar: support already ended; ending within twelve months; within twenty-four; beyond. The classification is written to a status tagged value, and the landscape diagrams colour themselves from it — red for expired, amber shaded by band for the twelve- and twenty-four-month horizons, and the quiet green of things nobody needs to discuss; elements with no vendor date classify by their review date, and an overdue review surfaces on the same list — so a review meeting looks at Figure 1's real equivalent and sees the exposure without anyone preparing slides. Model searches produce the working lists: every application touching a red technology, every red or amber technology under anything marked business-critical, every dependency still in draft status on a critical application.
The search definitions are versioned alongside the scripts and imported into every client, named for the question they answer, and owned like any other artefact — because ad-hoc queries composed live in meetings are how two people bring two different answers to the same steering committee. Anyone who can open the model can run them; the quarterly report simply prints the same searches everyone can already reach, which keeps the report boring in the correct sense: it never says anything the model does not say to anyone who asks on a Tuesday.
The colour scheme did more for adoption than the queries. Executives do not run model searches, but a landscape with three red boxes under the sorting operation asks its own question in any steering meeting. Making risk visible where decisions are made is most of the value of putting lifecycle data in the model at all.
From exposure to a renewal roadmap
A red diagram is a diagnosis, not a plan. The final phase turned the worst clusters into a modelled renewal roadmap: three plateaus in EA — the current estate, a transition state, and an eighteen-month target — with the moves between them as work packages. Upgrade the database cluster the parcel-tracking estate shares; replatform the sorting control application off its expired operating system; retire the last two servers of a middleware product whose replacement had been running alongside it for years without anyone declaring the migration finished.
Modelling the roadmap in the same repository as the exposure keeps the two connected in both directions. Each work package is linked to the technologies it retires and the applications it touches, so the roadmap view answers "why this, why now" by traversal rather than by narrative — and when a work package completes, its dependency changes are confirmed with the operations contact and updated in the model, so the next refresh shows the red genuinely gone, rather than moved to a slide nobody updates. Prioritisation among the clusters was decided in two workshops using a frame we kept deliberately blunt: date proximity, business criticality of what sits above, and whether a credible landing zone already exists. The temptation to build a scoring formula was resisted; ranking a dozen renewal clusters is a conversation, and the model's job is to make it an informed one.
One cluster, end to end
The sorting estate shows the full journey. The initial classification painted it the worst colour available: the control application's operating system already out of extended support, its message broker eight months from the same cliff, and the tracking service — customer-facing, named in the company's service commitments — sharing that broker. The dependency traversal put numbers and names on what had been a vague unease: two critical applications, four supporting services, six technologies, two of them red.
The workshops broke the cluster into three sequenced work packages rather than one heroic programme. First, separate the tracking service onto the broker's supported successor — smallest move, largest risk reduction, since it decoupled the customer-facing service from everything else's timetable. Second, replatform the sorting control application, the expensive move, planned into the next budget year with the operations calendar's quiet season. Third, retire the old broker and the expired hosts once nothing depended on them — the step that historically never happened, because retirement is nobody's emergency; modelling it as its own work package with its own owner is the only treatment we have seen work. Each package was linked in the repository to what it moves and what it retires, and the quarterly report tracked the cluster's colour through amber to green over the following year. The sequence completed about a month behind its plan, which for an eighteen-month infrastructure programme is close to plan by any standard we have seen.
The quarterly rhythm
What keeps the model alive is a quarterly cycle, deliberately small enough to survive contact with busy people. The infrastructure engineers refresh their date sheets, the comparison script updates the technology elements and flags anything that moved, the classification recolours the landscape, and a generated two-page report — new exposures, cleared exposures, draft dependencies still awaiting confirmation on critical applications — goes to the architecture board with the roadmap view attached. The report is produced from the model through EA's document generation, so producing it costs the practice an hour of checking rather than a week of assembly.
The board session then does the one thing no tooling can: it decides. New amber items get an owner and a stance — renew, replatform, retire, or accept with a date to revisit. The stance is written back as a tagged value, which means "we knowingly accepted this risk in March" is a recorded fact with a name attached, not a memory. That single habit is the difference between the surprise that started this engagement and the way the organisation runs now: unsupported software still exists in the estate, but it exists on purpose, visibly, with a revisit date.
The first two quarters shook out the process in predictable ways. Quarter one ran long because the engineers' sheets and the model disagreed about eleven technologies and every disagreement needed an owner to rule on it — exactly the debt the old arrangement had been accruing invisibly. Quarter two took the promised afternoon. The board initially wanted the report monthly; we argued for quarterly and held the line, because vendor dates rarely move faster than quarters, and a cadence faster than the data changes teaches people to skim. The one refinement the client added themselves — flagging any red or amber technology that has sat through two reviews without a stance recorded — is a better idea than anything in our original design, and we have borrowed it since.
What changed for the client
The annual audit exercise that used to take a specialist most of a month is now the quarterly report plus an afternoon of narrative. Renewal spending, which had historically arrived as emergencies — the worst possible procurement posture — moved into the budgeting cycle, because the eighteen-month view exists in January when budgets are argued. The sorting-control replatforming that motivated the engagement was delivered as a planned work package; the tracking service's shared-broker coupling had already been broken deliberately a quarter earlier, on a timeline the business chose. And the phrase "leaving support", which used to arrive in incident reviews, now arrives in steering decks — earlier, cheaper, and with options still open. Procurement noticed the difference in its own terms: renewals negotiated eighteen months out have alternatives, and alternatives have prices, whereas the emergency renewal of an unsupported platform has exactly one vendor, one timeline and one number on the page. The head of procurement, not the architects, made that argument to the board, which is generally the moment this kind of practice stops needing to defend its budget. The practice runs on the client's own team, on the same repository disciplines we describe across our Sparx EA consulting work.
What the model does not solve
Three limits, named. The model's dates are only as good as the quarterly refresh; skip two quarters and it becomes the spreadsheet problem with better diagrams. The long tail of draft dependencies is a known soft spot — the critical estate is confirmed, but an impact query over the tail answers with the CMDB's original uncertainty, and the model marks that honestly rather than hiding it. And technology lifecycle is one lens: a supported platform can still be the wrong platform, and a model that tracks support dates says nothing about fitness, cost or strategy. The organisation still has to want to renew things; what the repository removed is the routine surprise.
We would also caution against the expansion that tempts every successful lifecycle model: pulling in per-server patch levels, CVE feeds and licence counts until the architecture repository tries to become a configuration database. It should not. The CMDB and the vulnerability tooling do those jobs at the granularity they require; the model's contribution is the join between technology fate and business consequence, and it makes that contribution precisely because it stays small enough for an architect to maintain in an afternoon a quarter.
If your technology lifecycle knowledge lives in spreadsheets that cannot see your applications — the join is buildable, the first load is scriptable, and the quarterly rhythm is lighter than the annual archaeology it replaces. Talk to us through our contact page, or start with our Sparx EA maturity assessment.
This case study describes a representative engagement pattern. Organisational details are illustrative and do not identify a specific client.