The Pitfalls of Building a Middle Platform: A Cautionary Tale of Project Management

"Damn, what the heck is A‑Factory talking about? I can’t understand! Tell me, how much did the middle‑platform construction cost, and after investing that money, will our information systems become more consolidated? Roughly how much can each system save?" L, the CTO, asked after touring factories A in Hangzhou and T in Shenzhen.

Junior M hurriedly replied, "Saving money with a middle platform can be an outcome, but it must never be the goal."

L, angry, retorted, "I build a middle platform to save money; our company spends tens of millions on IT annually. If the platform doesn’t save money, why build it at all?"

Junior M is a reader of the author, a middle‑platform project manager at a large state‑owned enterprise; L is the head of the IT department, equivalent to a CTO.

The story begins with Junior M’s one‑hour venting, revealing the core issues of their middle‑platform project.

01 Cloud Platform Expert Shows Promise

Junior M had previously worked on enterprise digital transformation, helping several companies migrate to the cloud and accumulating project experience.

L’s company suffered from an outdated information system architecture that had evolved into dozens of siloed "smoke‑stack" systems, making data interconnection difficult and hindering business growth.

For example, the customer service system and the BOSS (Business & Operation Support System) were not integrated, causing poor coordination, delayed after‑sales support, and high customer churn.

L appointed Junior M as the head of “basic resource integration,” tasking him with building a cloud platform to unify servers and network resources, improve hardware utilization, and cut costs.

Junior M’s clear plan: move all new systems to the cloud, migrate or refactor legacy systems, and for those that cannot be moved, keep them running while each department drafts future upgrade plans to gradually transition to the cloud.

Within a year, the platform was organized, and L was impressed with Junior M’s performance.

Junior M, a young idealist, dreamed of owning a house in Beijing by age thirty; now he is thirty and halfway there.

02 Middle Platform: Never Tried Pork, Never Plucked Pig Hair?

Planning the Middle Platform

At the end of last year, L asked Junior M to propose next year’s technical work plan.

L noted that although the company had moved business systems to the cloud and achieved unified resource scheduling, many problems remained: disconnected business processes, outdated architecture, and duplicated development, preventing rapid market response.

After research, L decided that a “data middle platform” should be the direction of the architectural reform.

Junior M was assigned to plan and implement the data middle‑platform project, despite his limited experience in big data.

He began studying the topic, only to discover a flood of buzzwords—data middle platform, AI middle platform, video middle platform, technology middle platform, mobile middle platform—each promising agile development, rapid response, and consolidated capabilities.

Junior M compiled several articles and drafted an overall vision: “Next year, the company will build a data middle platform to integrate internal and external data resources, create a new technical infrastructure, support future business, and enable technology upgrades.”

L approved the plan and incorporated the middle‑platform construction into the 2020 annual plan.

03 Middle Platform? It’s a Death Trap!

Detailed Planning

Junior M consulted architects from A‑Factory and T‑Factory and produced a detailed middle‑platform plan, identifying business walls, data walls, and duplicated investments, and proposing three middle platforms: data, AI, and video.

He also suggested four implementation mechanisms:

Conduct an inventory of IT assets.

Study corporate strategic planning and perform top‑level design.

Have the top executive lead the project, with departments signing commitment letters.

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

L rejected the top‑level design approach, shouting, "Who the hell told you to do a top‑level design? I might not even be able to do it!" and dismissing asset inventory and executive‑led initiatives.

04 No Platform, Yet the Platform Disease

The project’s fate was sealed for several reasons:

1. Lack of concrete scenarios. Vendors promised that a middle platform could be built if a specific need existed, but Junior M could not find any real business demand.

2. Inadequate planning and budget. Junior M gathered price lists from A‑Factory (over 100 million) and T‑Factory (≈40 million), but L limited the budget to 3 million, demanding quick wins before any large investment.

3. Unclear goals. L cared only about protecting his position and possibly extracting personal benefits, ignoring the real value of solving business problems.

4. Misaligned understanding of the middle platform. L, coming from a networking background, set three goals: integrate the BOSS system into the platform, replace OA with the platform, and use the platform to manage cloud, network, and business systems.

These contradictions left Junior M frustrated and the project stalled.

05 Final Thoughts

Junior M feels powerless: he is the sole driver of the middle‑platform project, business units ignore him, the budget is tiny, vendors are uncooperative, and L blames him for lack of progress.

The core workplace skill highlighted is the ability to create and break situations—knowing when to go all‑in and when to quit.

May Junior M find a way forward.