Shaping the Architecture Before Procurement

The Context

A global retail enterprise was in the final stages of a highly visible data modernization programme. The leadership team had spent six months evaluating vendors to replace their legacy, on-premise data warehouse. The procurement decision was down to two modern cloud data platforms, and the commercial negotiations were almost complete.

I was brought in by the transformation lead not to help them choose the software, but to review the target state architecture that the winning software was supposed to enable.

The Diagnostic Discovery

The client's internal architecture team had designed an elegant, highly decentralized Data Mesh target state. The design assumed that data ownership would be pushed down to individual business domains (Supply Chain, Marketing, Finance), and that the central IT team would merely provide the underlying self-serve platform.

However, during a two-week diagnostic phase, I reviewed the operational realities of the organisation:

  1. Talent Distribution: 90% of the organisation's data engineering talent sat within central IT. The business domains had SQL analysts, but zero capacity to build or maintain complex data pipelines.
  2. Data Quality: The source systems were highly fragmented. Supply Chain and Finance had radically different definitions of "inventory," which currently required manual reconciliation by the central team.
  3. Governance Culture: The organisation had a culture of "shadow IT." When business units were given autonomy in the past, they built undocumented, siloed reporting systems that eventually broke.

The Intervention

The target state architecture (Data Mesh) was completely incompatible with the operational reality of the organisation.

If they signed the multi-million pound software contract and attempted to implement the Data Mesh, the business domains would immediately fail to take ownership. Central IT would be forced to step back in to build the pipelines, entirely negating the value of the decentralized model. The programme would stall, the software vendor would be blamed, and the investment would be wasted.

The Architectural Redesign

I halted the procurement and ran a series of workshops with the CDO and the domain leads to realign the architecture with their actual maturity level.

We abandoned the strict Data Mesh model. Instead, we designed a "Hub and Spoke" Lakehouse architecture.

  • The Hub: Central IT retained ownership of the complex, fragile ingestion pipelines from the legacy source systems. They were responsible for cleaning the data and establishing a governed, "bronze" and "silver" layer.
  • The Spokes: The business domains were given governed access only to the clean, silver layer. They were empowered to build their own domain-specific data products (the "gold" layer) using simple, SQL-based tooling.

The Outcome

By shifting the architectural strategy before the software was purchased, the client avoided a multi-million pound failure.

When procurement resumed, the requirements had changed. They no longer needed a platform optimized for deep, distributed software engineering. They needed a platform optimized for centralized governance and highly accessible SQL consumption.

This realignment saved the client an estimated 18 months of wasted implementation effort and ensured that when the new platform was finally deployed, the organisation actually had the capability to use it.