Two legacy estates, one 14-month decommission commitment
Northwind Retail has completed its acquisition of a regional competitor. Between them they run 62 production integrations: 41 on an on-premises TIBCO BusinessWorks estate and 21 on Mule 3.9, with 240 endpoint definitions recorded in a CMDB that the operations team admits is roughly 30% stale. The board has committed to decommissioning both legacy platforms within 14 months and has funded two integration architects plus six Mule 4 developers. The CIO wants a current-state integration architecture document in eight weeks and a target-state blueprint before the next budget cycle. No source system owners have been interviewed yet, three of the largest integrations are undocumented because their original authors left, and no scope has been frozen - new e-commerce and EDI workloads are requested weekly. You are one of the two architects.
1. Define the structure and evidence plan for the current-state document so it is credible and deliverable in eight weeks with two architects. What do you include, what do you exclude, and how do you handle the three undocumented integrations?
Read the worked answer
Organise around decisions, not inventory. A document that lists 62 integrations alphabetically answers no question the board is asking. Structure it as: purpose and audience; capability map with each integration attached to a business capability rather than a server; a per-integration record (producer, consumer, protocol, data entity, direction, volume and frequency, criticality tier, runtime, owning team, auth mechanism, retry behaviour, SLA); cross-cutting views (runtime topology, network zones, identity, monitoring, batch windows, file transfer); and a risk/unknowns register.
Evidence plan within the timebox. Weeks 1-2: pull the CMDB extract and treat it as a candidate list only; pull Anypoint Platform application and API inventories; pull TIBCO deployed EAR and domain configs; then corroborate with runtime evidence - firewall and DNS records, MQ queue depths, SFTP landing zones, APM call volumes. Anything with no traffic in 30 days goes to an appendix as a presumed-dark candidate with a decommission ticket, not into the main inventory. Weeks 3-6: per-domain drafting with 6-8 targeted interviews prioritised by volume and criticality, not by org chart. Weeks 7-8: review, consolidation, sign-off.
Exclude message schemas and code-level detail - link to Exchange and Git instead - and exclude speculative target-state opinions, which belong in the blueprint.
The three undocumented integrations must not appear blank. Reconstruct each from traffic evidence, database audit tables and consumer-side walkthroughs, then publish them explicitly labelled low-confidence with a named owner and an open validation task. An honest gap is defensible; a silent one destroys the document's credibility.
2. Propose the decision criteria you will use to classify each of the 62 integrations as retain-on-Mule, rebuild, replace-with-SaaS, or retire, and explain how you would defend the classification in front of a CFO.
Read the worked answer
Use five criteria and score each integration on all five, because a single criterion always produces a wrong answer:
- Business criticality and usage - revenue impact, transaction volume, number of consumers, whether a capability is differentiating or commodity.
- Change pressure - how often the contract or mapping changes. High churn justifies rebuild; static, low-volume flows do not.
- Technical risk - unsupported runtime versions, no tests, undocumented, single-person knowledge, security findings.
- Availability of a commodity replacement - EDI translation, expense feeds, tax calculation and similar capabilities are usually better bought.
- Cost of ownership versus replacement - run cost, licence, and the effort of a rebuild, expressed per year over a three-year horizon.
Then apply simple rules: differentiating and high-churn goes to rebuild on Mule 4 with an API-led contract; commodity and low-differentiation goes to replace-with-SaaS; low volume with no consumers in 90 days goes to retire; everything else is retain-on-Mule with a remediation backlog for risk items.
Defending it to a CFO: never present a list, present a cost curve. Show current run cost per integration per year, the cost of the target plateau, and the point at which run cost crosses below legacy licence plus dual-running cost. Classify by money and risk, keep the decommission savings visible as the funding source for the rebuilds, and be explicit that retire decisions require consumer sign-off and 90 days of traffic evidence, which is why they are cheap but slow.
3. What must the transition architecture (plateaus) contain so the 14-month decommission commitment is defensible?
Read the worked answer
A transition architecture is a sequence of stable operating states, not a Gantt chart. Each plateau must be independently supportable and must have entry criteria, exit criteria, and a named accountable owner.
- P0 - Baselines: current-state documented, criticality tiers agreed, run-cost baseline captured. Exit: CIO sign-off on the inventory and the risk register.
- P1 - Consolidation platform: one target runtime pattern (Mule 4 on CloudHub 2.0 for cloud-appropriate workloads, Runtime Fabric for data-residency workloads), CI/CD pipeline template, observability and logging standard, API Manager baseline policy set. Exit: first three integrations running in production on the new pattern with pipelines, proving the pattern before volume migration.
- P2 - API-led layering: System APIs in front of the highest-value systems of record, Process APIs for the shared business capabilities, Experience APIs per channel. Exit: the top five capabilities consumed only through APIs, no direct point-to-point access.
- P3 - Wave migration and decommission: migration waves grouped by capability, each with a cutover, a dual-run window, and a hard decommission date for the legacy flow. Exit: zero traffic on legacy for 30 days, then decommission.
Each plateau needs dependency and constraint statements: mainframe and SAP batch windows, data migration, network changes, and the consumer migration plan. Crucially the document must state the capacity assumption - two architects plus six developers is roughly one wave of 8-12 integrations per quarter, which is how 62 integrations in 14 months gets tested. If the arithmetic does not close, say so in the transition architecture rather than in month twelve, and propose the reduce-scope options: retire candidates first, defer low-criticality flows, and buy rather than build the commodity ones.