架构图只是表达工具。企业架构能否产生价值，取决于它是否进入投资、立项、设计、交付和运营的真实决策过程。

一、问题往往不在图，而在图之后

企业架构项目通常能够形成较为完整的现状图、目标图和演进路线，但项目结束后，成果却可能很少被业务部门和项目团队使用。原因并不一定是模型不专业，而是组织没有说明这些成果将影响哪些决策。

如果架构成果只在汇报或验收时出现，它自然会逐渐失去时效性。企业真正需要的不是更多静态图纸，而是让架构观点成为资源配置和建设取舍的依据。

二、三个常见断点

第一个断点是架构与战略脱节。目标架构描述了理想状态，却没有说明它与经营目标、能力缺口之间的关系。第二个断点是架构与项目脱节，项目立项和方案评审仍然沿用原有流程。第三个断点是建设与维护脱节，系统上线后没人更新架构资产。

这些断点会让架构团队成为单独的信息整理者，而不是企业建设过程中的决策参与者。

三、让架构进入管理流程

企业架构应当嵌入投资计划、项目立项、需求评审、技术选型、方案设计和上线验收。立项阶段关注是否重复建设，设计阶段检查系统边界与数据标准，上线阶段确认架构变化是否被记录。

治理不意味着为每个项目增加一轮复杂审批。更有效的方式是按照影响范围分级：局部配置调整可以快速通过，跨系统、跨部门或涉及核心数据的变化则进行重点评审。

四、建立可以持续更新的架构资产

架构资产不应只按文档名称管理，而应围绕业务能力、应用、数据对象、技术组件和项目建立关联。这样，当一项业务能力调整时，企业可以识别可能受到影响的系统和数据。

资产更新责任也需要明确。架构团队维护原则和总体模型，项目团队提交变更信息，系统负责人确认运行状态，避免所有维护工作集中在少数架构师身上。

五、判断架构工作是否有效

衡量架构工作不能只统计完成了多少模型和标准，更应观察重复建设是否减少、跨系统协同是否改善、技术例外是否受到管理，以及项目是否能够更早发现整体性风险。

当架构成果能够持续影响项目选择和方案取舍时，企业架构才从“画图工作”转变为治理能力。

“画图式架构”通常有三个症状

一是图很多，但没有明确使用者。架构图被放在汇报材料中，却没有进入项目立项、方案评审和系统改造。二是图很完整，但与真实系统不同步。项目上线、接口变化、数据口径调整后，架构资产没有更新，很快就失去可信度。三是只描述现状，不表达取舍。图中列出了全部系统，却没有指出哪些能力需要整合、哪些平台应该复用、哪些历史系统应逐步退出。
     

这些问题的共同原因，是把企业架构当成一次性交付物，而不是持续参与决策的管理机制。图本身没有错，问题在于图与责任、流程和决策脱节。

让架构进入管理闭环，需要四个动作

首先，建立最小且统一的架构对象清单，不急于追求全量建模，先管住业务能力、应用系统、核心数据和关键技术平台。其次，为每类对象明确维护责任人和更新触发条件。再次，把架构检查嵌入立项、采购、设计评审和上线验收。最后，定期回看架构例外和技术债务，明确处理时间，而不是把所有偏离都永久保留。

不必从“大而全”开始

实践中更稳妥的方式，是选择一个跨部门问题作为切入口，例如客户主数据不一致、多个系统重复建设同类审批能力，或项目之间存在明显依赖。围绕这个问题建立能力、应用、数据和技术之间的关系，再将有效方法逐步扩展。企业架构的可信度来自解决问题，而不是来自模型数量。