Architecture Governance: Building Order, Not Just Systems — The Core Logic

From IT Governance to Architecture Governance: Managing Systems, Not Projects

Architecture governance is not a post-project activity nor merely technical selection management. It solves three core problems:

Who decides : Which matters require top-level intervention versus delegation to business or IT units — a responsibility mechanism issue.

Who owns : What roles do business, functional, and IT teams play in architecture construction — an organizational mechanism issue.

How to execute : How architecture goals translate into collaboration mechanisms across planning, design, construction, and operations — a process mechanism issue.

In essence, architecture governance institutionalizes responsibility clarity, rule transparency, and behavioral control across the enterprise informatization lifecycle.

Governance Goals: Building Capabilities, Not Systems

The primary aim is not delivering a platform but continuously strengthening three enterprise capabilities through system-data-process-organization synergy: business responsiveness, resource allocation, and risk control. Four specific objectives:

Clarify power and responsibility to avoid "decision by gut, blame on project lead" scenarios.

Match business and technology via architecture mechanisms enabling bidirectional fusion of business demands and IT solutions.

Optimize resource allocation directing limited people, money, and materials toward long-term value.

Visualize and control risks — technical, process, data, compliance — for early identification, intervention, and governance.

Budget and Investment: Governance Must Bind Resources

If governance is the steering wheel, budget is the accelerator and brake. Without resource matching, designs remain theoretical. Institutional requirements:

Budget front-loading : Architecture governance committee reviews and coordinates IT budget, prioritizing core architecture projects.

Ownership accountability : Business "who proposes, who bears"; IT "who builds, who manages" — preventing "spending others' money for own work."

Dynamic adjustment : Major changes and budget deviations require explicit assessment and adjustment mechanisms.

Effectiveness evaluation : Regular audit and performance appraisal replace post-hoc gut judgments on budget value.

Application Governance: Full-Process Institutional Closed-Loop

Governance must execute, not just design. IT application management needs a closed-loop process:

Requirements analysis : Business initiates; IT participates in solution discussion.

Project approval : Must pass architecture committee review for strategic, architectural, and budget alignment.

Construction and acceptance : IT leads; business evaluates — dual accountability.

Operations and maintenance : Balance technical sustainability with business adaptability; no "launch and abandon."

The article references the TOGAF framework, Huawei practices, ISO 31000 risk management, and a series of prior articles on enterprise architecture meta-models, architecture principles, business process frameworks (EPF, L1-L4), stakeholder mapping, and ADM method — positioning this piece within a broader knowledge system for architecture governance modernization.