Critiquing Business Middle Platforms: Problems and Solutions

During the author's tenure at Alibaba, they positioned themselves as a critical voice against the middle platform, architecture, and technical management, extending the critique to themselves.

The "big middle platform, small front end" strategy sparked widespread discussion, but the author questions the underlying logic and value of the middle platform, urging a critical examination.

The core logic of a middle platform is to improve development efficiency through reuse, analogous to building a house on a solid foundation. In the cloud‑native era, IaaS provides compute, network, storage, and OS reuse, while PaaS offers middleware reuse.

Business‑PaaS attempts to extract common business functionalities to reduce front‑end workload, yet feedback from developers and executives indicates that business middle platforms often create more obstacles than solutions.

Three major cost factors make business middle platforms inefficient:

Collaboration cost : Most developer time is spent on communication and coordination rather than coding, leading to high overhead when many teams share a monolithic codebase.

Cognitive cost : The platform introduces numerous new concepts (business identity, activity, domain service, ability, extension points, etc.), increasing developers' mental load and system complexity.

Stability cost : Tight coupling between business and platform makes the platform fragile; changes for one business can unintentionally break others.

To address these issues, the author suggests:

Make business capabilities thin —focus the platform on non‑business concerns such as stability, performance, monitoring, and operations.

Strengthen platform capabilities—build rich solution and component libraries to enable rapid business development.

Simplify system architecture—avoid unnecessary complexity.

Decoupling is essential: shift from a monolithic, tightly coupled deployment model to a distributed service model (Business Platform as a Service, BPaas), separating business‑specific logic from platform services.

The concept of Platform as Code (PaC) is introduced, borrowing from Infrastructure as Code (IaC). Using Maven Archetypes and versioning, new businesses can generate ready‑to‑use applications, allowing rapid onboarding while keeping platform stability.

While code duplication is generally discouraged, the author argues that in certain contexts duplication can be a pragmatic trade‑off for lower coupling and higher maintainability.

Building on PaC, componentization creates a shared component marketplace where business teams can both consume and contribute components, fostering a virtuous cycle of reuse.

Finally, the author acknowledges the challenges of designing loosely coupled components for volatile, uncertain, complex, and ambiguous (VUCA) business domains, emphasizing the need for careful boundary definition.