笔者有幸参加过一个在全世界范围看也少有的极为完整的大型银行企业架构转型工程，是一家国有银行，工程历时六年多，项目投入和深度都是无与伦比的。该项目采用的是 TOGAF 加 CBM 的融合型方法论，其工程情况如下图所示：
图三 工程情况示意图
工程具有显著的 TOGAF 特征，但是交付物则有明显的 CBM 特征，是两种理论的融合，可见，企业架构的实施并非“死板”的，而是根据需要灵活设计的。但是“灵活”的前提是要对方法论有深入的了解，对实施困难的克服有坚定的信心，办法总比问题多。笔者总结，企业架构的设计与实施，就是“问题决定工具，毅力决定结果”。
在这段长达六年多的实践中，该行采用标准化的流程模型、数据模型、产品模型建模方法，对二十几个业务条线进行集中的企业级建模，建模的时间达到两年左右。其实这并非一个很长的时间，因为其中包含了对方法论的打磨，对行内战略的解读，对 80 多个主要业务专题长达半年的深度研究，是基于较为完整且长期的业务能力规划进行的业务模型设计，其中的数据模型更是对 3000 余个数据实体、20000 余个属性进行了企业级统一定义，对历史数据进行了完整的数据迁移，奠定了企业数据治理的坚实基础。基于业务模型，还对主要业务系统进行了服务化重构，涉及众多核心系统。部分核心系统的重构是难度极高的，比如金融市场领域相关的业务系统，其完全替换更是一直持续到了近期，这对相关系统的国产化设计也做出了有益的探索。完整的企业架构设计相当于梳理了相互对应的一套业务能力地图和一套 IT 资产地图，这两者又共同构成了一套企业能力地图。
业务的标准化是对业务行为的精准认识，这是一切合理化设计的基础，如果没有标准化约束，业务行为的认知可能是极为发散的，比如，该行最初的三级业务活动识别数量曾经达到接近 10000 个，而在进行结合了数据实体分析的标准化后，三级业务活动的数量骤降至 900 余个，这对 IT 设计而言，其需求的去伪存真程度可想而知，这种方法是不是也可以让不合适的需求少很多？
笔者深度参加了该行企业转型工程，在这一过程中完成了从一个业务人员到业务架构师的转变，从 2012 年算起，笔者做业务架构已经 9 年了，可以算是这个小众领域中的“资深”人员。笔者从接触这个领域开始，就认定了企业架构、业务架构的价值，也因此而努力到今天。“不谋全局者不足谋一域”，这就是企业架构的思维逻辑。解决孤岛问题、培养全局设计能力，这就是研究企业架构、业务架构的价值所在。
业务架构也并非一个完全以业务能力为主的角色，当然，也非以技术为主，而是以“架构”为主，通过流程、数据、产品三种模型的结合分析，设计出业务的结构，为 IT 设计提供结构化的分析依据。提供丰富深入的业务信息是业务专家的职责，因为无论业务架构师如何努力，都不能保证在第一时间内感受到业务变化，这是“位置”决定的，所以，能力的关键在于对结构的分析和设计。一个合格的业务架构师要有快速切换领域的能力，而非一辈子专注一个领域，笔者自己也是客户信息、客户关系、养老金、同业、金融市场、资管、托管等多个领域切换过。当然，这不是单纯依靠能力，还要依靠架构资产，也就是业务模型。笔者在从事同业领域业务架构设计时，也是之前没有接触过同业业务，依靠业务人员的输入和既有的企业级业务模型，完成对其全部业务涉及的二十多个业务组件的业务架构方案设计。
从长期对业务架构设计的实践和对相关理论的研究，笔者也发现，其实做好业务架构设计进而做好应用设计的关键，并不是哪个“神奇”的方法决定的，无论是 DDD 还是敏捷，一样都离不开对业务深入的理解，或者极端点儿说，什么方法都比不上你跟业务人员多交流几天、帮助业务人员理清设计目标的效果。也正因为如此，笔者认为企业架构中的业务分析方法，更贴近于如何让业务人员结构化地分析业务，并且更快速地跟技术人员对设计目标达成一致，因为这种方法相对而言是业务人员学习成本比较小的。业务和技术的融合，需要方法论支持，但是更重要的是提供一个充分融合的操作过程，这也是企业架构这种相对“慢”的方法“快”的地方，笔者也将这种思路代入了对企业架构方法论的改良中。
不过从笔者的实践和与其他企业的交流看，笔者还是认为在企业内部采用一致的架构设计方法还是有很大价值的，尤其是对准备进行转型工作的传统企业而言，这些企业本来就是体系化的，内部有很多密切的联系存在，如果在方法上不一致，相当于叠加了额外的沟通成本，对企业而言，这可能是消耗而非提效，企业不是这些方法“百花齐放”的试验场。方法论在企业内不统一的另一个弊端就是影响企业的知识沉淀，无论是业务知识还是技术知识都一样，没有体系化的归纳能力，对人员能力的培养也会成问题，体系化知识训练出来的人员，其执行力和对本企业的理解能力都会显著高于“野生”选手。该行最终通过业务模型沉淀了大量的知识，这些业务模型后来也成为了可以对外输出的商品。
该行的工程中，特别值得其他企业借鉴的一点是对该行对工程的强大组织执行力，正是通过领导层的高度支持才能将众多的业务部门、业务人员长时间集中到一起进行企业级业务架构设计，而这种设计是企业级业务系统之间能够横向联通的关键，毕竟，只有业务部门自己才能打破相互之间的壁垒，这也是一些尝试从技术侧发起企业级业务系统设计在很多传统企业最终难以实现目标的原因，离开了业务的深度参与就不会有真正的企业级业务系统。很多企业觉得学不了该行的“大手笔”，其实这是个认知上的误区，“手笔”的大小取决于企业的“目标”，这是个价值判断题，而且是未来价值判断题。今天国内外看起来非常强大的那些科技企业，都曾经弱小过，都曾经不被看好过，他们几乎都是在自己挣扎的路上时刻拼尽全力才有了现在的样子，也许它们的今天很多企业确实学不了了，比如 Google 小团队里那么高的博士密度，但是它们过去一路对极致的追求，则是很多企业现在能学的，这一点对于做企业架构来讲也是一样的。企业架构也不是一朝建成的，只要企业有足够的韧劲就行。
目前国内银行业，尤其是头部大型银行，几乎都已经开展或者正在开展不同形式、深度的企业架构工作，企业架构的应用范围也正在逐渐向股份制银行扩散。那未来会不会有更多的中小银行开展企业架构工作呢？笔者相信会的，只要没有把数字化转型的全部支出都“误算”给企业架构，那企业架构的实际花销并不是非常大，尤其是当对企业架构设计服务的需求逐渐增多，导致服务商的供给能力提升后，设计费用一定会朝向下降的方向，因为说到底，企业架构是一种整体设计的思维方式，企业经历过一定的实践后，逐步就会掌握这种设计理念，而越来越多的人掌握这种设计理念，就会带动供给量放大和价格的下降。
作为一种设计思维而言，有些企业尤其是 SaaS 类软件服务商，其实正在运用这类设计理念但是并没有意识到这实际上也是企架设计，比如一些为中小企业信息化服务的厂商，他们在为客户提供服务前，也要努力把客户的主要业务流程梳理清楚并尽可能进行全程拉通或者横向拉通，以寻找业务断点、业务改进机会点。笔者曾与这类企业交流过，也为一些很有上升力的互联网企业培训过企业架构方法论。
不过，一些做过或者接触过企业架构的企业和人员也产生了一些“误区”，比如总是想从实例上学习企架，而忽略了它的思维方式，结果，要么是看不出模型的作用，要么是把力气都用在死磕企业架构中那些“模糊”的定义上了。
3 企业架构的未来会是什么样？
讨论企业架构的未来，得先明确企业架构的未来是由什么决定的。答案是企业，企业架构是为了实现企业的“共同目标”，是为企业服务的，那企业架构自身的演进，无论是方法论还是设计结果，都是要随着企业的演进发展的。
未来的企业是什么样的呢？当然是按照实际业务需要，尽可能数字化的。数字化如今是国家级的转型方向，在“十四五规划”中，数字化有单独的一篇，并且这一篇的首段，就点明了数字化的关键问题，“迎接数字时代，激活数据要素潜能，推进网络强国建设，加快建设数字经济、数字社会、数字政府，以数字化转型整体驱动生产方式、生活方式和治理方式变革”，这段话说明了数字化是一个新时代，主要抓手是数据、网络、软件，目标是建设数字经济、社会、政府，方式是整体转型，所以，每个企业的数字化发展也离不开这些关键点，这是“数字中国”的方向，自然每个企业都会深受影响。
我们还可以进一步分析下，这样的企业必然是要建立在更大的社会级、行业级数字化平台上，也就是基于数字生态构建的云上虚实结合企业。这样构建企业软件，需要更为灵活的 SaaS 服务方式，也就是说，不是基于重量级套件，而是由可以更加灵活选搭的、更小、功能更单一的“构件”组成的，相当于基于一个大型标准化开源构件库进行选搭。为什么要这样？因为这样可以降本增效，数字化需要太多的软件，目前的开发模式无论如何也满足不了这么庞大的需求。数字化最重要的生产要素是数据，最重要的工具是软件，因为只有软件才能处理数据。那么，这些要素、工具如果要满足这么多企业进行转型，那得需要什么样的效率才可以。如今，即便是大型科技企业，其开发模式也不过是“大规模小团队手工作坊”，完全无法与工业化生产的效率相比拟，如果继续这样，软件行业是担不起全社会数字化转型大任的。
不仅仅是生产效率问题，传统的竖井式开发在高效推动企业信息化的过程中，也留下了大量的混乱的设计，这与企业架构始终没能充分发挥作用，尤其是在思维影响上发挥作用有着很直接的关系，一个内部连接都有问题的企业，更无法做好生态连接。
这些方向决定我们一定要能力探索与“数字中国”建设方向相一致的企业架构方法论，并努力通过方法论提升整体设计能力和标准化程度，使软件真正具备成为基础产业的能力。为此，笔者抛砖引玉，提出了“聚合架构”，也就是基于底层标准化架构元素聚合上层架构元素的企业架构设计思路，使软件设计逐步走向形成行业级标准化构件库，非竞争性的通用能力基于标准化构件进行微量改造，竞争性能力重点开发的设计模式，通过企业架构方法论最终为基于云的数字生态打造思路更容易跨企业对接的设计思维、设计语言。
云上的数字化生态会不会最终成为“巴别塔”，也许取决于我们的程序员是否能够更好地牺牲一部分“自由”换取更大的“效能”。
“聚合架构”的设计方法和“构件化企业”的概念如下图所示：
图四 聚合架构和构件化企业示意图
