The Rise and Fall of Mid‑Platform Architecture: What Modern Enterprises Can Learn

1. Origin of Mid‑Platform

Mid‑platform originates from a small Finnish game company SuperCell, which allowed any employee to propose game ideas, obtain approval, and quickly form teams to develop, launch, and either keep successful games or shut down unsuccessful ones. This rapid development approach embodies the mid‑platform concept.

Alibaba adopted SuperCell’s idea to create its own “large mid‑platform, small front‑end” model. The notion of a mid‑platform varies across companies and is not a concrete product.

2. Types of Mid‑Platform

Mid‑platform extracts reusable functions from various business lines, separating commonality from individuality. It can be divided into three categories: business mid‑platform, data mid‑platform, and technical mid‑platform.

Business Mid‑Platform

Provides shared components such as user center, order center, payment center, etc.

Data Mid‑Platform

Unifies data storage, modeling, and computation across the business system, supporting analysis and utilization.

Technical Mid‑Platform

Encapsulates common technical frameworks, lowering the barrier for upper‑level business development and accelerating delivery.

3. Practice of Mid‑Platform

Before mid‑platform, businesses used siloed “chimney” architectures, leading to duplicated components and data islands. Introducing a mid‑platform requires an independent team to abstract common services like product and order centers, enabling data integration and capability reuse, thus speeding development and reducing costs.

Traditional development involved each business line requesting features from a central R&D team, resulting in isolated front‑ends. After adopting mid‑platform, product teams interact with the independent platform team, while small front‑end teams consume the shared services provided by the large mid‑platform.

4. Drawbacks of Mid‑Platform

1) Blurred responsibility boundaries: product teams may be uncertain whether to approach the small front‑end or the large mid‑platform for new requests.

2) Poor suitability for new business lines: development speed can slow because each new requirement must be evaluated for abstraction and reuse.

3) Platform bloat: as the platform matures, fewer development tasks remain, leading to speculative feature requests that create unnecessary complexity.

Mid‑platform works well for stable, mature businesses that can benefit from capability reuse, such as Alibaba’s e‑commerce operations (e.g., Hema). However, applying a single platform across vastly different domains like finance, health, and entertainment can be ineffective, prompting Alibaba’s 2023 “1+6+N” architecture revision.

Conclusion

Mid‑platform is suitable for companies with years of stable business to aggregate capabilities, offering coordinated, standardized, and flexible IT architecture that drives digital transformation and innovation.

Conversely, it is unsuitable for rapidly changing businesses, as it hinders quick iteration and does not fit all scenarios.