Revisiting the Middle Platform: Lessons, Challenges, and AI Era Insights

In January 2020, 36Kr published a technical article titled “Middle Platform, I Believe Your Evil,” which attracted over 100,000 reads. The author was the only positive protagonist featured, and the article mainly highlighted the success of a single company, Bai Guo Yuan, in implementing a middle platform.

Five years later, the middle platform concept remains controversial; even its proponents have started talking about “de‑middle‑platforming.” As rigorous technologists, we must not simply follow the hype. By reviewing both successes and failures, we can extract practical knowledge for future work.

Who still persists with the middle platform?

1. The first group: technical staff who break existing business walls, adopt suitable tools, reorganize the technology stack, and continuously reap benefits.

2. The second group: actual business managers who face fragmented logistics contracts across multiple sub‑brands and solve the problem by establishing a centralized logistics middle platform.

3. AI‑era insights: How can the middle platform concept be leveraged in the age of artificial intelligence?

The middle platform hype often leads to “technical debt” accumulation. When business demands evolve, legacy systems become patchwork, causing frequent breakdowns (e.g., a minor change in module A crashes system B). Limited budgets prevent proper iteration, creating a vicious cycle of ad‑hoc fixes.

Securing a large budget and committing to genuine iteration can use the middle platform’s “halo” to buy time, alleviate business pressure, and reduce technical debt. However, the actual time saved may be far less than expected, sometimes only a fifth of the effort, as the core logic still requires UI, front‑end code, batch processing, and special business rules.

Key points for successful middle platform construction:

1) Domain Division : Clearly define domains that can be freely invoked within themselves, while cross‑domain interactions must go through unified interfaces. This solves the “one‑touch‑all‑touches” problem.

2) Decoupling : Beyond domain‑level decoupling, services must also be separated from permissions, business logic, organization, and processes. Many failed platforms merely rename modules without true decoupling.

3) Supporting Tools : Decoupled components need a logical platform (often a low‑code platform) to store and manage permissions, logic, and workflows, preventing new data silos.

4) Organization & Team : Managing and scheduling a middle platform requires dedicated organizational structures; otherwise, functionality regresses over time.

In the AI era, the foundation is not hardware or software but enterprise knowledge. Without internal expertise, AI becomes a toy. Companies must first build knowledge‑management teams before investing in AI infrastructure.

AI agents should be integrated via an “Agent Platform” that orchestrates human and AI actions, similar to an OA workflow engine. Over‑promising AI capabilities without proper knowledge correction leads to hallucinations and potential failures.

Finally, AI‑driven end‑to‑end solutions blur the line between data and knowledge, demanding stricter IT security management.

— End of article —