中台之上（一）：重视业务架构，不要让“业务的归业务、技术的归技术”

阳光穿透心脏的1/2处 2022-02-22 05:36 167阅读 0赞

很多企业都将促进业务与科技的深度融合作为发展战略，也都想学学阿里的中台战略，其实，除了中台战略之外，基于企业级业务架构设计来实现组件化开发也是企业数字化转型的优选路径，是弥合业务与技术之间“数字鸿沟”的有效手段。未来，业务不再仅仅是业务，技术也不再仅仅是技术，谁先实现思维方式的改进，谁能更好地联动整个企业，谁就能赢得竞争的先手，而业务架构能力可以在这方面发挥关键作用，而且是超越中台之上的作用。

## 阿里中台 ##

阿里的中台是个累积的过程，从 2009 年建立共享事业部开始，几经曲折，但是一直在积累，直到 2015 年正式发展成中台战略。可见，这是个演化过程，这也符合多数人对架构的认知：大型架构、好的架构都不是一蹴而就的设计，是根据实践不断磨合调整得来的。

阿里的中台大约有十几个共享业务单元，包括用户中心、商品中心、交易中心等。淘宝、天猫、聚划算等 25 个大型业务应用都是由中台的共享业务单元支持的，共享业务单元则由阿里云平台支持。共享业务单元的划分原则其实不是可以简单掌握的，要综合考量设计、运营和工程因素，尽可能遵循“高内聚、低耦合”、“数据完整”、“业务可运营”和“渐进”的原则。阿里在划分中台时非常重视其业务价值和基于业务的设计，而且有业务架构岗位，每个共享单元都有业务架构师。但总体来讲，其业务架构仍然是领域性的。这点在本人与阿里专家的交流过程中，他们也认为阿里仍然缺少更高一层的抽象，也就是常说的企业级业务架构，但是显然这一层比较难于设计和维护。

阿里系统要解决的核心问题是高并发、可扩展，也就是说，规模带来的复杂度对阿里而言更具挑战性。因此，业务通过中台进行共享支持后，基础设施必须能够消解这种压力。阿里采用去中心（也就是去 ESB）的 HSF 分布式服务框架，以支持服务的点对点调用，解决 ESB 可能产生的瓶颈问题；采用微服务设计方式，提高变化响应，并通过大力推行DDD（领域驱动开发）设计模式，提升设计效率；自研设计了分布式数据层框架 TDDL（Taobao Distributed Data Layer，又称“头都大了”）以及分布式数据库 DRDS；研发了支持分布式事务处理的 AliWare TXC；支持高效故障定位和运维监控的鹰眼平台；实现了限流和优雅降级设计，以及做保障的全链路压测平台、业务一致性平台等。这是一套完整的基础设施，提供针对电商业务特点的支持。

总结起来，阿里中台是其自身在业务不断发展的过程中演进和磨合出的架构，其架构即体现了电商的业务特色，也包含了完整的技术支持体系。由于其灵活支持和快速响应能力，成为了互联网架构的优秀实践案例和设计标杆。也正因如此，目前很多人提到“中台战略”基本上就会想到阿里，毕竟他们是主打这张“牌”的。

## 中台背后 ##

互联网行业历来有“胜者通吃”的传统，阿里如今在业务和技术上的成功也使得“中台”这个词名声大噪，好像一颗“银弹”就此诞生了。应该说，阿里确实很成功，业务规划做的很好，符合自身行业特点和需要；技术上独步青云，因为有些场景只有他们有，也只有他们做到了。目前阿里在开源和标准制定方面也走在第一线，“云栖大会”红红火火，IEEE的区块链金融标准制定工作也有阿里一份，阿里更是在JAVA标准方面做了很多世界范围的工作，为软件领域做了很多贡献。但是，熟悉架构设计的朋友也都很清楚，软件工程上是没有“银弹”的，而阿里的优秀也不是学学“中台”就可以移植的。

2018年12月份，我跟阿里的高级管理人员、开发人员又有了一些接触，使我对阿里的认知又深入了一些，不过我毕竟是个“外人”，有些说法难免有失偏颇。

从我的了解来看，阿里技术上的成功离不开其滴水穿石般逐渐形成的企业文化。阿里在管理上首先有个明确的“底线”，也就是对诚信问题的“零容忍”和带有末位淘汰性质的考核机制，“底线”把员工“逼”到了一个必须有较强自律性、自我负责的状态；其次是有一个开放的“上限”，阿里的员工晋升主要是拼个人实力，每年有评审时间，每个人要通过方案讲解等方式向评委会展示自己的年度成果，打分够了就晋升，而不会像一般大型企业那样有各类明的、暗的类似于晋升限制，并且有多种序列供员工选择，前中后台，不同条线的员工大致都可以达到相同的晋升高度，方便员工转岗；“底线”和“上限”之间就是鼓励培养浓厚创新精神和好奇心。这样一套体制可以让员工相信凭自己的实力能够赢得一片天地，而这种氛围，可以让很多传统企业，甚至在一些互联网企业、科技企业中也存在的组织壁垒、部门主义、人浮于事、推诿扯皮等问题，得到一定程度的解决，尽管不会完全消除。应该说，阿里这些年的成功，包括中台战略的落地在内，与这种企业文化的逐渐形成和稳固是分不开的，如果只是照搬阿里的中台技术，那么学习者可能只是获得了一套工具、一套技术栈，并不会真的改变自己。而且，有一点也不得不提及的，如果企业的业务规模远达不到阿里这么大，那么有些技术手段或者工具其实发挥不出最大价值，但依然要付出一定的学习和迁移成本。获得一把狙击步枪并不代表你就成了狙击手，学习阿里中台，也要在一定程度上学习能够让技术真正发挥其价值的环境，不要仅仅关注技术本身。对于大多数企业而言，都需要认真从自身的角度出发去考虑业务和技术的发展规划问题。

## 中台之上 ##

阿里其实挺重视业务架构设计的，每个共享单元都有自己的业务架构，这恰恰是很多企业没有的。业务架构本身是一个有着二十多年历史却依旧不温不火的领域，但是在阿里却发展的挺好，虽然他们的建模方式选择的是DDD方法。DDD方法是一种从业务设计直通技术设计的系统分析方法，但其特点是面向领域级，对企业级设计支持有限，阿里对该方法的使用也证明了这一点。2018年12月的DDD峰会上，除了阿里等公司实践介绍外，也出现了一个业务架构专场，讲的是画布分析法。应该说，随着软件设计的发展，人们对标准化、可复用设计方向的追求日益强烈，而近年对业务与技术深度融合的要求不断提升，重视业务架构的人也在不断增多。数字化社会、数字化转型已经不再是新名词，但是很多企业在这方面投入不菲，收效却不高，究其根本，多是在业务架构上下的力气太少，而在缺乏清晰规划的情况下对技术又依赖过重、寄望太高，导致了业务向技术传导的不畅和技术对业务的理解不深，使双方无法顺利“牵手”。很多技术人员依然保持着“业务的归业务、技术的归技术”这种设计思想，割裂了业务和技术之间的有机联系，而业务人员也苦于无法深入理解设计，往往对实现“一头雾水”，无法帮助技术人员合理应用新兴技术。

**业务架构**是连接企业顶层战略和技术实现的桥梁，是连接业务人员和技术人员的桥梁，业务架构基于企业目标进行业务能力和流程的整体规划，对业务能力进行标准化、组件化，实际上，遵循业务架构设计方法，不断基于自身的实践进行积累和调整，任何企业都能发现适合自己的架构，包括适合自己的“中台”规划，之后再根据企业业务规模和发展预期选择合适的技术栈。

业务架构并非“银弹”，因为你不能简单照搬别人企业的架构套在自己身上。它是一面镜子，镜子中照出的只能是你自己，而照镜子的过程也是一个“赋能”的过程，赋予你认清自己的能力，“自知者明”。没有这个过程，企业很难选择出适合自己的发展方向和能力建设方向，更别提企业转型了。

业务架构真正的威力还是在企业级业务架构的构建上，这个过程足以将一个企业完整、深刻地联结在一起，这不是领域级设计可以解决的问题，是真正的“中台之上”。

**相关文章**：银行建中台跟阿里建中台有什么不同？

**作者介绍：付晓岩**，原国有大行资深业务架构师，负责业务架构设计、项目管理，热衷新技术探索与实践，具有丰富的银行业务经验和企业级项目业务架构设计经验，曾主导客户关系、金融市场、同业、资管、养老金等多个领域核心系统的业务架构设计。公众号：晓谈岩说。