Rethinking Platform Capability: A Holistic Model for Business, Development, and Operations

Preface

This piece is compiled from articles shared by a community of efficient operations experts.

Why Write About Platform Capability?

Two main purposes:

Accumulate daily insights : By breaking down a large systematic article into smaller pieces, the author records personal thoughts, acknowledging they may not be perfect but are worth sharing.

Spread knowledge : Many in the tech community also think about platforms; sharing ideas can spark valuable discussions.

Is a Platform That Supports Business Enough?

The author, a platform architect, asks whether a platform is good if it only supports business while developers and testers suffer, if it cannot monitor business runtime, or if its complexity prevents anyone from explaining the business.

These questions touch on development processes , runtime operation , and long‑term business management . A platform should be evaluated like a product, requiring a product‑oriented perspective.

Why Traditional Platform Capability Falls Short

Traditional models focus solely on serving "business" and align application platforms with business sub‑domains, using layered architectures (business, application, technical, data). This leads to a "treat‑the‑symptom" approach rather than addressing root causes.

The author abstracts platform problems into two questions:

Should the platform solve a business demand?

Can it actually solve that demand?

Should: Relates to Platform Responsibility

Platform architects must weigh whether a task belongs within the platform’s scope; otherwise the platform becomes overloaded with irrelevant responsibilities.

Can: Relates to Current Business‑Support Ability

If a task is within scope but the platform lacks the capability, the platform must develop the necessary ability.

A New Platform Capability Model

The proposed model divides platform capability into three parts, illustrated in the diagram below.

Why this decomposition? The next diagram explains the problems each part addresses.

1. Business Support Capability

Addresses "should" and "can" questions, providing functional (business domain understanding) and non‑functional (high availability, reliability, performance, maintainability) support.

2. Development Support Capability

Offers tools and utilities that accelerate development, testing, and issue resolution, reducing duplicated effort across many engineers.

3. Business Control Capability

Provides runtime and operational management for ops, business, and product teams, including system monitoring, incident response, and rule‑engine governance.

Why Include Development Support in Platform Capability?

Integrating development support ensures the platform remains a living, adaptable system rather than a static business‑only solution, fostering technical enthusiasm and sustainable growth.

Conclusion

One picture summarizes the entire viewpoint: