企业级业务架构与企业级业务架构与“中台中台”的关系的关系
随着《企业级业务架构设计：方法论与实践》一书的传播，笔者有了更多的机会与来自不同行业的读者共同讨论业务架构这个
话题，业务架构与“中台”的关系也时常会被读者问起，笔者就以这篇短文，将与大家交流的情况做个分享。
再议中台
经过去年的起起落落，圈内至少对中台达成了一个共识——它仍是一种企业级的软件工程方法，涵盖了一整套解决方案，既包
括方法论层面，也包括具体的技术实现方式，当然，前者相对而言不够明晰。对中台方法的探索也在变得更加“宽容”，很多人
也认可只要达到了企业级功能复用、一体化这样的核心目标，自家的系统也都可以当做中台的成功实践。
当关于中台的讨论越来越深入，实现方式越来越开放，中台也愈加转回到了大家更熟悉的概念：企业架构。与Zachman、
TOGAF这样的传统“自上而下”的企业架构理论相比，中台常被认为是一种“自下而上”发展出来的颇具互联网特色的本土架构方
法。作为案例背书的阿里巴巴集团的实践，的确体现了互联网公司勇于探索、自我激励、注重敏捷、坚守价值等众多特点，但
也正是这样的发展过程，使其整体而言的严谨性与传统理论之间尚有一些差异。
中台常被划分成业务中台、数据中台，之后又出现了技术中台等其他中台定义，在阿里巴巴的实践中，他们很注重业务架构的
作用，通过业务架构分析对产品或者功能进行模型化设计，其实这也是一种标准化设计，比如图1，这是之前演讲中曾经公开
的设计思路：
图1 业务定义可视化
图中的能力模型、配置模型实际上就是对业务的结构化、标准化设计结果，配置数据就是实例化的运行。
通过这种方式，原有的业务能力可以被清晰定义，设计的业务流程可以被很好地结构化，在理想的实现条件下，软件可以
被“业务”定义。
美中不足
上边介绍的中台方法其实有一个关键问题，就是能力模型的定义范围，自下而上的实施方式，其对应的合理定义范围应当就是
领域级的，这与随着微服务再度升温的DDD在思路上是一样的。但是，企业内部对整合、提升的要求并不会在领域级停住，
所以，对跨领域的企业级问题的思考是必然的。此外，对于其他想复制中台模式的企业而言，自下而上的生长过程是没有的，
尤其是传统企业，他们从一开始就是一个自上而下的转型行为，这其中的不对称就很明显了。如果原有的方法论中，缺少了自
上而下的架构设计过程，如何应用中台方法呢？
笔者曾在前文《关于架构演进发展的探讨》中讨论过企业到底是要一个特化的中台还是一个泛化的中台。对于特化的中台，学
的越像可能失败概率越高，这就是方法论的魔力，没有对方法论的驾驭能力而单纯追求方法，可能就是这种结果。
传统方法能帮点儿啥？
当思考到自上而下的架构设计过程时，我们就回到了企业架构的范畴，这些看似笨重的“老方法”一直在整体设计方面勤耕不
辍。当面对企业转型这个严肃话题时，我们必须对企业管理和软件工程具备一个最基本的科学的敬畏态度，因为在当今这个时
代企业转型正是这两者的结合，而面对未来真正的数字化转型，企业管理则需要充分吸收企业架构的设计思维，完成对自
身“技术基因”的“突变”。
中台方法让实践者最为困惑的经常是中台里到底放什么，什么能力需要被沉降到中台，如果没有自下而上的积累过程，那么，
自上而下的规划就必须被采用，脱胎于传统理论的企业级业务架构方法论正好可以满足这方面的需求。
企业级业务架构的整体逻辑如图2所示：
评论0