搜索
大数据中国 首页 大数据技术 数据处理 查看内容
企业文化、业务架构与中台:移植阿里的中台战略能成功吗?
2019-10-28 21:26 | 查看: 1846| 评论: 1

01 阿里中台简介


笔者曾参加过阿里培训班,现场聆听了“云栖大会”精英们对阿里技术体系的解读。培训前后又读了子柳老师的《淘宝技术十年》和钟华老师的《企业 IT 架构转型之道:阿里巴巴中台战略思想和架构实战》,算是对阿里的中台概念有个粗浅的认识。


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


阿里的中台大约有十几个共享业务单元,包括用户中心、商品中心、交易中心等。淘宝、天猫、聚划算等 25 个大型业务应用都是由中台的共享业务单元支持的。共享业务单元的划分原则其实不是可以简单掌握的,要综合考量设计、运营和工程因素,尽可能遵循“高内聚、低耦合”“数据完整”“业务可运营”和“渐进”的原则。


阿里在划分共享业务单元时非常重视其业务价值和基于业务的设计,而且有业务架构岗位,每个共享单元都有业务架构师,并将其视为非常稀缺的“复合型人才”。


但总体来讲,其业务架构仍然是领域性的。这点在本人与阿里专家的交流过程中,他们也认为阿里仍然缺少更高一层的抽象,也就是常说的企业级业务架构,但是显然这一层比较难于设计和维护,或者并不合互联网公司以前的“胃口”。


阿里系统要解决的核心问题是高并发、可扩展,也就是说,规模带来的复杂度对阿里而言更具挑战性。因此,业务通过中台进行共享支持后,基础设施必须能够消解这种压力。


阿里采用去中心(也就是去 ESB)的 HSF 分布式服务框架,以支持服务的点对点调用,解决 ESB 可能产生的瓶颈问题;采用微服务设计方式,提高变化响应,并积极研究DDD(领域驱动开发)等设计模式,提升设计效率;自研设计了分布式数据层框架 TDDL(Taobao Distributed Data Layer,又称“头都大了”)以及分布式数据库 DRDS;研发了支持分布式事务处理的 AliWare TXC;支持高效故障定位和运维监控的鹰眼平台;实现了限流和优雅降级设计,以及做保障的全链路压测平台、业务一致性平台等。


这是一套完整的基础设施,提供针对电商业务特点的支持。值得一提的是,阿里在其发展过程中,是主动进行去“IOE”化的,因为其业务规模的迅猛增长导致“IOE”模式不仅出现效率瓶颈,更重要的是需要极其高昂IT建设成本,在阿里尚未如今日般“富有”的时候,不先摆脱“IOE”,公司可能根本就发展不起来了。


总结起来,阿里中台是其自身在业务不断发展的过程中演进和磨合出的架构,以“厚重”的共享中心支持“灵活”的前端应用,其架构即体现了电商的业务特色,也包含了完整的技术支持体系,实现了业务与技术的充分融合。


由于其灵活支持和快速响应能力,成为了互联网企业架构的优秀实践案例和设计标杆。也正因如此,目前很多人提到“中台战略”基本上就会想到阿里,毕竟他们是主打这张“牌”的。




02 企业文化的作用


互联网行业历来有“胜者通吃”的传统,阿里如今在业务和技术上的成功也使得“中台”这个词名声大噪,好像一颗“银弹”就此诞生了。


但是,熟悉架构设计的朋友也都很清楚,软件工程上是没有“银弹”的,而阿里的优秀也不是单纯学学“中台”技术就可以移植的。从笔者的观察来看,阿里技术上的成功离不开其滴水穿石般逐渐形成的企业文化。


1. 明确底线


阿里在管理文化上首先有个明确的“底线”,也就是对诚信问题的“零容忍”和带有末位淘汰性质的考核机制,“底线”把员工“逼”到了一个必须有较强自律性、自我负责的状态。


2. 开放上限


阿里在人员晋升有一个开放的“上限”,晋升主要是拼个人实力。


每年有定期评审时间,每个人要通过方案讲解等方式向评委会展示自己的年度成果,打分够了就晋升,而不会像一般大型企业那样有各类明的、暗的晋升限制,并且,阿里有多种序列供员工选择,前中后台,不同条线的员工大致都可以达到相同的晋升高度,这很方便员工在某一序列的发展中遇到瓶颈时进行转岗。


3. 鼓励好奇


“底线”和“上限”之间就是鼓励培养浓厚的创新精神和好奇心,不止一位阿里高管人员在公开场合称赞阿里员工的“好奇心”,正是这种精神鼓励员工不断探索,自我驱动,挑战极限。


这样一套体制可以让员工相信凭自己的实力能够赢得一片天地,而这种氛围,可以让很多传统企业,甚至在一些互联网企业、科技企业中也存在的组织壁垒、部门主义、人浮于事、推诿扯皮等问题,得到一定程度的解决,尽管不会完全消除。


应该说,阿里这些年的成功,包括中台战略的落地在内,与这种企业文化的逐渐形成和稳固是分不开的,如果只是照搬阿里的中台技术,那么学习者可能只是获得了一套工具、一套技术栈,并不会真的改变自己。


有一点也必须指出,如果企业的业务规模远达不到阿里这么大,那么有些技术手段或者工具其实发挥不出最大价值,但却依然要付出一定的学习和迁移成本。


获得一把狙击步枪并不代表你就成了狙击手,学习阿里中台,也要在一定程度上学习能够让技术真正发挥其价值的环境,不要仅仅关注技术本身。对于大多数企业而言,还是先要认真从自身的角度出发去考虑业务和技术的发展规划问题,之后再跳进解决方案中。




03 由业务架构方法可以推导出中台设计吗?


1. 业务架构可以推导出“中台”模式


阿里其实挺重视业务架构设计的,每个共享单元都有自己的业务架构,这恰恰是很多企业没有的。业务架构本身是一个有着二十多年历史却依旧不温不火的领域,但是在阿里却发展的挺好,这也证明了业务架构设计有助于建立中台规划。


阿里内部做架构设计时有称使用DDD方法,在每年的DDD峰会中也都进行了经验分享。DDD是一种从业务设计直通技术设计的系统分析方法,但其特点是面向领域级,对企业级设计支持有限,阿里对该方法的使用也证明了这一点。


阿里对共享中心的设计,实际上和业务组件设计是异曲同工的,每个共享中心在前端支持上,既包括单独服务的调用,也包括整段流程的封装,这与企业级业务架构设计,包括作为改良建议的面向构件的设计,并无逻辑上“天壤之别”;而共享中心设计中对工程上的考虑,其实质是从实现角度对业务组件或者构件进行的分组。


所以,完全可以基于企业级业务架构设计得出中台规划方案。


“中台”模式和组件化一样,都是实现快速响应的方式,单就这点而言不能简单比较孰优孰劣,由企业级业务架构产生的组件化模式,核心优势还是在于有效连接战略与开发,实现上下贯通的一体化设计,这是“中台”模式考虑较少的地方。


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



2. 业务架构方法具有更大优势


2018年12月的DDD峰会上,除了阿里等公司实践介绍外,也出现了一个业务架构专场,讲的是画布分析法。应该说,随着软件设计的发展,人们对标准化、可复用设计方向的追求日益强烈,而近年对业务与技术深度融合的要求不断提升,重视业务架构的人也在不断增多。

免责声明: 除非特别声明,文章均为投稿或网络转载,仅代表作者观点,与大数据中国网无关。其原创性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。如果本文内容有侵犯你的权益,请发送信息至ab12-120@163.com,我们会及时删除

发表评论

最新评论

引用 yiniuyun 2020-3-12 17:27
非常棒

查看全部评论(1)

关闭

站长推荐上一条 /1 下一条

 
 
大数据行业交流
大数据行业交流
大数据求职招聘
大数据求职招聘
站长电话:
15010106923
微信联系:
hb-0310
站长邮箱:
ab12-120@163.com
大数据中国微信

QQ   

版权所有: Discuz! © 2001-2013 大数据.

GMT+8, 2024-3-29 16:54 , Processed in 0.051337 second(s), 23 queries .