Why Architecture Governance Is the Only Viable Paradigm for Enterprise Architecture in Chinese Conglomerates

Why Group Enterprises Need Architecture Governance

In large Chinese conglomerates, the management model itself predetermines how enterprise architecture can land. Headquarters typically handles strategy, rule-setting, and resource allocation, while business units and subsidiaries execute projects. Digital construction advances project by project, and the most binding governance levers are budget approval, solution review, and acceptance sign-off. Real organizational behavior revolves not around abstract principles but around whether a project can be initiated, funded, and launched.

If enterprise architecture remains only a planning artifact or methodological suggestion, it cannot effectively constrain actual construction. It fails to enter the project decision chain and lacks rigid influence during implementation, ending up as mere reference material.

To make enterprise architecture land, it must be given explicit governance attributes — inspectable, vetoable, accountable . Only when architectural requirements can be audited, rejected, and traced does architecture shift from "planning language" to "management rules."

Architecture governance emerges not from ideological choice but from management reality: in this governance soil, without governance, enterprise architecture simply cannot survive.

How Group Enterprises Achieve Governance Through Enterprise Architecture

Many focus instinctively on the four architecture domains (4A), but the professional crux lies not in 4A or 5A themselves, but in the cross-section of the 4A : precisely delineating the governance boundary between headquarters and the system layer.

1. Horizontal Split: Decoupling Governance Between Planning and Implementation Layers

The 4A cross-section divides enterprise architecture into two segments:

Enterprise Architecture (Overall): Planning and plan phase

System Architecture: Design and implementation phase

This is not a technical phase division but a governance responsibility division. The underlying logic is clear:

Headquarters does not participate in system design, but headquarters must be responsible for whether system design is "compliant."

This is the only governance boundary that can run long-term in a conglomerate.

The hardest part of architecture governance is never "whether to govern" but to what granularity . "Tighten and it dies; loosen and it chaos" is the typical symptom of granularity imbalance. The 4A cross-section is essentially a fine-grained design of layered governance granularity .

2. Business Architecture: Govern Structure, Not Behavior

At the overall architecture layer, business architecture defines only business domains, business capabilities, and high-level processes. Headquarters governs how business is structurally expressed without intervening in specific business activities and operational details. This is the minimum constraint needed for strategic consistency and the only effective way to avoid "business units speaking different languages."

3. Application Architecture: Govern Boundaries, Not Functional Implementation

Application architecture at the overall layer stops at application domains and module levels, leaving components and use cases to the system architecture phase. This actually solves the most pervasive and hidden problem in domestic enterprises: systems without boundaries, unlimited functional stacking .

What headquarters governs through application architecture is not "whether this function should be built," but:

Which category of system this function belongs to, and whether it breaks existing system responsibility boundaries.

4. Data Architecture: Govern Semantics, Not Model Implementation

Data architecture at the overall layer ends at data domains, data subjects, and conceptual models — a highly mature governance choice. It acknowledges two realities:

Without unified semantics, data will inevitably be chaotic.

Governing down to logical and physical tables will kill projects.

Therefore, data architecture governance focuses on business object and semantic consistency , leaving engineering implementation to the system layer.

5. Technology Architecture: Govern Platform, Not Engineering Details

Technology architecture at the overall layer defines technology domains, technology capabilities, and platform views, not specific products and deployments. What this solves has never been "technological advancement" but long-term controllability and maintainability , especially as the group scales and systems accumulate.