中台之上(一):重视业务架构,不要让“业务的归业务、技术的归技术”

阅读数:32502 2019 年 2 月 19 日

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

阿里中台

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

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

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

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

中台背后

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

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

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

中台之上

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

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

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

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

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

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

本主题系列文章已经出版成纸质书籍《企业级业务架构设计》,是一本面向多类型读者的企业级业务架构设计专著。作者超脱了自己原有的实践经验和理论指导,融合企业架构、系统分析与设计等方面已有的理论成果,按照一般方法论阐述企业级业务架构设计的理念、方法及依托业务架构驱动 IT 开发的设计、实施难点和注意事项,提供易懂的虚拟案例进行方法介绍,绘制了丰富的配图,便于各行业、各领域的企业管理者、项目管理者、技术人员、业务人员,尤其是希望成为业务架构师的人员,学习、思考企业级业务架构设计与实现方法。

微信鲜读(复制到微信中打开): https://h5.hzmedia.com.cn/freshReading/detail?id=p_5d25c962686bc_bw14RDTw&path=13220

京东自营 https://item.jd.com/12684682.html

收藏

评论

微博

发表评论

注册/登录 InfoQ 发表评论

最新评论

hope 2019 年 06 月 03 日 15:55 0 回复
楼主确定阿里都在DDD?
kony 2019 年 03 月 19 日 17:39 5 回复
什么是中台?中台的定义是什么?阿里是依据什么标准来定义中台的?从文章中看,阿里是从这几个层面:企业战略、业务范围、业务需求、技术需求。既然不是所有的企业都需要上中台,那什么样的企业可以上中台?达到什么规模?什么标准?是都达到阿里级别的吗?个人认为:概念先要该清楚,范围边界要搞清楚,而不是为了中台而讨论中台,阿里只是一个实施中台的范例,不要搞反了阿里=中台,中台=阿里。是阿里首先提出的这个概念没有错,那它是在什么背景下提出的?要想解决什么问题?实现什么样的目标要搞清楚。阿里要解决的问题和实现的目标是否具有普遍性和适用性?如果有就是有一定的代表性,这种代表性是否只有阿里这种体量的企业才具有一定的代表性?是否适合所有的其他中小型的企业?而不是一句模糊性的一笔带过。这样会给人带路歧途,为了中台而上中台。
展开全部
Winon 2019 年 03 月 13 日 07:43 2 回复
阿里运用DDD的范围有待商榷。17年年底的DDD峰会,盒马的介绍就说阿里内部也没多少人用。
是的,有另外的一些方法论反而接受度比较高 0 回复
王成飞 2019 年 03 月 07 日 12:12 2 回复
讲的很详细,也很接地气,例如文章刚开始的状态是审核、发文、干预等多个服务和平台维护,最后的收敛和使用就会很痛苦,就是数据和行为没有内聚收敛,导致维护困难,所以通过统一的数据和行为收敛可以基本解决场景的变迁问题,但是业务概念的迁移和使用需要更细化,比如文章的状态除了主场景的展示,还有分渠道的展示,每个策略运行的状态,这时候就需要抽象一个类似计数器的服务组件,统一维护各个流程和状态。 还有一个界限问题,如果有一个统一明确的标准,在需求开发时可以快速定位到系统,也决定了组织沟通效率,清晰的边界有利于业务快速迭代,关键是促进了组织沟通效率,提升业务迭代。
展开全部
风再起时 2019 年 03 月 01 日 10:04 1 回复
个人理解,中台战略是公司业务有了确定模式(构成一定生态)后进行的,这块业务架构需要做的是把业务更加的流程化,组件化,让业务可以更有效的扩张,业务架构承载的是公司战略和技术实现。
高田林 2019 年 02 月 25 日 11:12 2 回复
个人理解脱离了业务场景的技术架构是没有任何意义的,每一个公司业务架构的形成是随企业规模,战略目标,文化逐渐的演变出来的,尽管不是银弹,也胜似银弹。
鲍平乐 2019 年 02 月 23 日 19:23 1 回复
以偏盖全,好似阿里的就是经典的。任何企业的架构和文化都是分不开的,也绝不可能一样或者照搬的。阿里的末尾淘汰就好吗?对于阿里这样大规模的员工数,实行末尾淘汰制是可行的,那放到规模不大的小公司,分分钟搞起你,招人和开除员工都是要付出代价的!业务的归业务,架构的归架构,本质上两者也无法彻底分开,任何一项技术都是用来服务于需求和业务的,每项技术的实施都必然由业务和所在的行业的发展紧密相连,不是什么阿里出来的所谓“银弹”!全篇文章没有一点含金量,倒是充彻着对阿里文化的过度崇拜。这种垃圾文章也能放到InfoQ,真是醉了!
展开全部
人家作者说了:软件工程没有银弹。只有更适合自己的,你感觉不适用就不用呗,人家告诉你在这个环境下阿里做的比较好。 而且我感觉文章里面针对企业文化,中台的思想讲的挺好的呀! 7 回复
技术人员的偏激回复,这也是目前技术人员普遍存在的问题,知识面太窄、认知能力有限,根源问题也是中国教育的问题! 3 回复
偏激得可怕 2 回复
查看更多
Geek_4b72d6 2019 年 02 月 21 日 10:12 2 回复
赞同您的观点,论述精彩!我司正在进行面向中台演进的规划工作,方便可否进一步沟通(159 0129 8592 李)
没有更多了