Why Middle Platforms Fail: A Cautionary Tale from a Chinese State Enterprise

01 Cloud Platform Expert Emerges

Little M, an experienced cloud‑migration consultant, is hired by L, the CTO of a large state‑owned enterprise, to unify the company’s fragmented IT resources. The legacy environment consists of dozens of siloed "smoke‑stack" systems such as customer service and BOSS, causing data silos and high maintenance costs.

The first step is to build a cloud platform that consolidates servers and network resources, aiming to raise hardware utilization and cut expenses. Little M quickly drafts a plan to migrate all systems to the cloud, refurbish what can be refactored, and keep the rest running while departments outline future upgrade roadmaps.

02 Jumping onto the Middle Platform

At year‑end, L asks Little M to propose the next year’s technology roadmap. L believes the current cloud migration has unified resources but still suffers from disconnected business processes, outdated architectures, and duplicated investments.

Seeing the buzz around “data middle platforms”, L decides the company should adopt a data‑centered middle platform. Little M, whose background is cloud rather than big data, reluctantly accepts the challenge and begins researching.

He discovers a flood of buzzwords—data middle platform, AI middle platform, video middle platform, etc.—and realizes many vendors promise quick wins without concrete scenarios.

Little M compiles a high‑level proposal: build a data middle platform to integrate internal and external data, create a new technical foundation, and support future business needs.

03 The Middle Platform Is a Death Trap

Little M gathers more case studies and consults vendors, proposing a three‑layer architecture: data, AI, and video middle platforms. He outlines four implementation mechanisms:

Conduct an inventory of existing IT assets.

Study corporate strategy and perform top‑level design.

Have the CEO champion the project, with each department signing a commitment.

Set milestones: asset survey by end‑May, design by June, deployment by September, and core‑business migration by year‑end.

L dismisses the plan, rejecting top‑level design, asset inventory, and the notion of a long‑term strategy, insisting on minimal investment and quick results.

04 No Middle Platform, Yet the Disease

The project stalls for several reasons:

1. Lack of concrete scenarios. Vendors promise solutions without real business needs; departments see no problem with existing systems.

2. Inadequate planning and budget. Little M’s three‑platform proposal receives price quotes of hundreds of millions, while L caps the budget at a few million, demanding a pilot with immediate ROI.

3. Unclear goals. L cares more about preserving his position and extracting personal benefit than delivering technical value.

4. Misaligned understanding of the middle platform. L envisions the middle platform as a catch‑all replacement for BOSS, OA, and infrastructure, without grasping the architectural implications.

05 Final Thoughts

Little M feels powerless: business units ignore him, the budget is insufficient, vendors withdraw, and L repeatedly blames him for lack of progress. The story highlights three universal IT‑project principles: solve real business problems, spend money where impact is visible, and secure stakeholder support.

Understanding these pitfalls can help practitioners avoid the common “middle‑platform” trap and make more realistic, value‑driven decisions.