Why Alibaba Is Dismantling Its Middle Platform – Insights on Agile Innovation

Background of Alibaba’s Middle‑Platform

In 2015, Alibaba’s CEO Zhang Yong introduced the “big middle‑platform, small front‑ends” architecture. The middle‑platform was designed to provide a unified technical stack (service‑oriented architecture), a common product‑support framework, a data‑sharing layer, and a security foundation. Its purpose was to let multiple business units reuse standardized capabilities such as catalog, inventory, user profile, payment, AI recommendation and security services.

Achievements (2015‑2020)

Supported rapid scaling of core e‑commerce operations, enabling stable performance during high‑traffic events such as Double‑11 (Singles’ Day).

Accelerated launch of new business lines (e.g., Hema Fresh) by recombining existing services.

Standardized data models and APIs reduced integration effort across subsidiaries.

Limitations of the Middle‑Platform

The platform excels at “combinatorial innovation” – creating new products by assembling existing services. However, it struggles with “disruptive innovation,” which requires breaking or redesigning the front‑, middle‑, and back‑office layers.

Early‑stage ventures (e.g., Rhino Manufacturing, Taobao Special Edition) found that requesting resources from the middle‑platform introduced latency and reduced efficiency.

To achieve deep innovation speed, these teams were given independent organizational structures with their own product, technology, development, and operations teams.

Strategic Shift (2020‑present)

Alibaba’s “five‑new” strategy (new retail, new manufacturing, new finance, new technology, new energy) emphasizes disruptive growth. A senior middle‑platform architect explained that the platform is being “thinned”: only the most abstract, generic services (e.g., authentication, basic payment gateway, common logging) remain, while domain‑specific logic moves to the front‑ends.

# Example of a thin middle‑platform service
class AuthService:
    def verify_token(self, token: str) -> bool:
        # generic token verification logic
        ...

# Front‑end specific business logic stays in the service owned by the product team
class RetailOrderService:
    def create_order(self, user_id, items):
        if not AuthService().verify_token(...):
            raise PermissionError
        # domain‑specific order processing
        ...

Implications for Enterprise Architecture

Maintain a lightweight shared layer for cross‑cutting concerns (identity, logging, monitoring, security).

Allow business units to own end‑to‑end capabilities when rapid, domain‑specific innovation is required.

Adopt a modular, “fragmented” middle‑platform approach: services are decoupled, versioned, and can be replaced without affecting the whole ecosystem.

Guidance for Other Organizations

Enterprises should evaluate whether their growth goals rely on combinatorial reuse or disruptive transformation. If the latter dominates, a thin, modular shared platform combined with autonomous product teams is more effective than a monolithic middle‑platform.

Key steps:

Identify truly generic services (authentication, authorization, observability) and keep them centrally.

Define clear API contracts and versioning policies to avoid tight coupling.

Empower product teams with dedicated development resources and the ability to extend or replace shared services.

Continuously monitor latency and resource contention when a team requests shared capabilities; migrate to independent implementations if thresholds are exceeded.