企业架构规划细化到开发说明书，拿着就能写代码？

在过去一段时间，我碰到好几个企业的IT领导要做“数字化规划”，跟我说他的要求是：“一定要把企业架构（或者有时说成“4A架构”）做细，细到模型的第五级，程序员拿着五级架构的设计文档，就能直接写代码了”。

听到这样的要求，我有些哭笑不得，不知道他们听说有哪家企业是这样做的？

“企业架构” 这个概念主要是从欧美大公司传出来的，近年来不少欧美的全球化大公司纷纷建立了企业架构管理体系，国内也有不少金融机构、制造业等大型企业开始探索这个做法。由于某些先行企业的示范效应以及部分厂商和咨询公司的推动，“企业架构”这个词开始在国内流行，然而对这个名词所代表的真正含义并不清楚的某些供应商或专业人士在咨询市场上制造舆论，给企业管理者带来不小的误导。

下图是我在2009年参加企业架构方法培训时学习的一张图，这张图很明确地显示了：企业架构的定位是上承公司业务战略，下接各个具体IT系统建设的设计和交付，所以，企业架构本身并不涉及到每个IT系统具体的详细方案设计，它是通过“架构治理”的机制，来协调各个IT项目（以及各IT项目之中会涉及到IT系统的建设）的功能范围、建设优先级、技术标准等。

以这个例子为比方，“企业架构规划能细化到开发说明书，拿着就能写代码”，就相当于要城市规划设计院的规划设计师，去给建筑工地的钢筋工、泥瓦工画施工图。

今天下午我和三位前同事就企业架构在组织内定位及实践做了次交流，他们一位服务于国内某大型金融机构，另外两位则分别就职于两家欧洲大型跨国公司IT部门，这些企业具有一定的企业架构管理成熟度——都在公司总部设置了专门的企业架构管理部门，甚至采用了诸如SAG ARIS这样的专业架构管理工具。

他们的企业内实践支持了我的想法：企业架构管理是业务部门和技术开发部门之间的统筹规划职能，它并不能替代业务部门和技术开发部门之间直接合作的、IT系统开发相关的业务分析、设计、测试、实施管理等工作：

从我了解到的信息，至少在目前的现实应用中，企业架构管理工具和软件工程工具是两回事，架构建模（包括流程建模和数据建模）和实际的系统也几乎没有集成关系，是两张皮——虽然所有架构管理的理论上都说要这么做。架构管理部门用工具画出来的那些业务流程图、数据模型图，和在用系统的实际情况也是两张皮，经常是业务部门不认，负责系统开发的IT部门也不认。

但是，这并不是说企业架构方法和架构管理软件工具没用，这些企业认为仍然有必要用结构化的方法、可视化的工具，来定义业务能力组件、识别部门边界、规划应用系统架构和实施路线，他们认为在目前的管理中，企业架构管理的这个作用达到了。

以ARIS工具为例，我观察到国内某领先大型企业在市场上宣传其采用了ARIS企业架构元模型来进行企业架构建模，但是据我所知，他们的企业架构模型和该企业实际的系统开发软件工程平台基本上没有关系。一位在欧洲跨国公司的朋友也证实了，他们应用ARIS的流程建模和企业架构元模型，希望用TOGAF方法来指导整个公司的业务划分和应用系统规划，但是在实际操作过程中，对于定义应用系统的边界以及处理不同业务单元的业务建模标准化问题，遇到很多挑战，即使是指导应用也困难重重。

就我对ARIS的观察，最近这十多年随着企业架构理论的发展，建模方法论越来越细，从“业务流程建模”发展到了“企业架构建模”（如下图），从工程学意义上来说，越来越逻辑完善、结构精密，固然很好，然而，这又形成了“方法论陷阱”，即当做一件事的方法论过于复杂后，这件事的参与方越多，就越无法操作了。

这位欧洲跨国公司的朋友说在他们实际工作中，企业架构主要是解决跨区域、跨职能的顶层设计的共性问题，抓能集中管控的对象，这个过程牵涉到无数的总部和下属单元之间的博弈。具体到系统的详细功能设计，业务部门画流程图，都没有办法由企业架构管理的职能来统统抓完。

最近几年，国内最大的几家银行开风气之先河，开始实施企业架构管理体系；在银行IT管理体系常见的“一部两中心”组织模式之下，提升管理部门和研发中心、数据中心之间的协作效率，明确工作界面：

今天很多银行都在因应技术发展在开展系统升级，尤其是基于业务流程和业务能力分析，基于“解耦-重构-复用”的思想，来设计并构建数字化产品，支持业务流程和业务实体对象（例如科目、客户、账户、产品、合约、渠道等等），企业架构本身是支持业务和技术融合，持续开展技术创新的一种工作方式。

来源：某银行新一代核心系统公开宣传材料

然而，企业架构能做什么、不能做什么，企业架构管理的范围、边界、组织治理模式是什么？为什么要做企业架构，带给企业的价值是什么？这是企业IT管理者首先要想搞明白的问题。想通过一个企业架构咨询项目，就产出写代码能用的系统设计文档是不现实的。