文章来自健荐微信公众号,做者王健,ThoughtWorks高级咨询师。王健将于5月18-19日在上海A2M峰会分享关于中台的话题,更多A2M峰会内容可点击此处查看。前端
从去开始,好像就有一只无形的手一直将我与“微服务”、“平台化”、“中台化”撮合在一块儿,给我带来了不少的困扰和思考与收获。算法
平台化正兴起,从基础设施到人工智能等各个领域不断涌现的各种平台,对于软件开发人员及企业带来了深远的影响。然而,在中国提“数字化平台战略”你们可能会以为比较抽象,比较远大空;如果提“中台”你们则会更熟悉一些。数据库
那…中台究竟是什么?会不会又是另外一个Buzzword呢?这个从名字上看像是从前台与后台中间硬挤出来的新断层,它与前台和后台的区别和界限到底在哪儿?什么应该放到中台,什么又应该放到前台或是后台?它的出现究竟是为了解决什么问题呢?后端
这一个接一个的问题就不断的涌出并萦绕在个人脑子里。直到一年多后的今天,随着参与的几个平台化、企业中台相关的项目已顺利步上正轨,终于能够坐下来回顾这一年的实践与思考,再次试图回答这些问题,并梳理成文,与你们交流探讨。安全
1、中台迷思微信
处处都在喊中台,处处都是中台,中台这个词在我看来已经被滥用了。架构
在一部分人眼里:中台就是技术平台,像微服务开发框架、DevOps平台、PaaS平台,容器云之类的,人们都叫它“技术中台”;
在一部份人眼里:中台就是微服务业务平台,像最多见的什么用户中心、订单中心,各类微服务集散地,人们都叫它“业务中台”;
在一些人眼里:中台应该是组织的事情,在释放潜能:平台型组织的进化路线图 (豆瓣)中就提出了平台型组织和组织中台的概念,这类组织中台在企业中主要起到投资评估与投后管理的做用,相似于企业内部资源调度中心和内部创新孵化组织,人们叫它“组织中台”。框架
看完本篇你就会理解,上边的这几类“中台”划分仍是靠谱的,更多我看到的状况是,你们为了响应企业的“中台战略”,干脆直接将本身系统的“后端”或是“后台”改个名,就叫“中台”。分布式
中台究竟是什么?它对于企业的意义究竟是什么?当咱们谈中台时咱们到底在谈些什么?微服务
想要寻找到答案,仅仅沉寂在各自“中台”之中,如同管中窥豹,身入迷阵,是很难想清楚的。不如换个⾓度,从各种的“中台迷阵”中跳脱出来,尝试以更高的视角,从企业均衡可持续发展的角度来思考中台,反推它存在的价值。
为了搞明白中台存在的价值,咱们须要回答如下两个问题:
企业为何要平台化?
企业为何要建中台?
一、企业为什么要平台化?
先给答案,其实很简单:
由于在当今互联网时代,⽤户才是商业战场的中心,为了快速响应用户的需求,借助平台化的力量能够事半功倍。不断快速响应、探索、挖掘、引领⽤户的需求,才是企业得以⽣存和持续发展的关键因素。
那些真正尊重用户,甚⾄不惜调整⾃己颠覆⾃己来响应⽤户的企业,将在这场以⽤户为中心的商业战争中得以⽣存和发展;反之,那些在过去的成就上故步⾃封,存在侥幸⼼理但愿⽤户会像以前同样继续追随⾃己的企业,则会被用户淘汰。
很残酷,但这就是这个时代最基本的企业⽣存法则。
平台化之因此重要,就是由于它赋予或增强了企业在以用户为中心的现代商业战争中最最最核心的能力:⽤户响应力。这种能力能够帮助企业在商战上先发制⼈,始终抢得先机。
能够说,在互联网时代,商业的斗争就是对于用户响应力的比拼。
又有点远大空是否是?咱们来看⼏个经典的例子:
例子1
提及中台,最早想到的应该就属是阿⾥的“⼤中台,⼩前台”战略。阿⾥⼈经过多年不懈的努力,在业务的不断催化滋养下,将⾃己的技术和业务能力沉淀出一套综合能力平台,具有了对于前台业务变化及创新的快速响应能力。
例子2
海尔也早在⼗年前就已经开始推动平台化组织的转型,提出了“平台⾃营体⽀撑⼀线⾃营体”的战略规划和转型⽬标。构建了“⼈单合一”、“⽤户付薪”的创客文化,真正将平台化提⾼到了组织的⾼度。
例子3
华为在几年前就提出了“⼤平台炮火支撑精兵做战”的企业战略,“让听获得炮声的人能呼唤到炮火”,这句话形象的诠释了大平台⽀撑下小前台的做战策略。
这种极度灵活又威力巨⼤的战法,使之能够迅速响应瞬息万变的战场,一旦锁定目标,经过大平台的炮火群,迅速精准对于战场进行强大的火⼒支援。
可⻅,在互联⽹热火朝天,第四次工业革命的曙光即将到来的今日,企业可否真正作到“以用户为中心”,并不断提高本身的用户响应力来追随甚至引领用户的脚步,持续规模化创新,终将决定企业可否在这样充满挑战和机遇的市场上笑到最后,在商业上长久保持创新活力与竞争力。
而平台化刚好能够助力企业更快更好的作到这些,因此这回答了第一个问题——企业须要平台化。
二、企业为何要建中台?
好,到此咱们想明白了为何须要平台化。可是平台化并非一个新概念,不少企业在这个方向上已经作了多年的努力和积淀。那为何最近几年“中台”这个相对较新的概念又会异军突起?对于企业来说,传统的“前台+后台”的平台化架构又为何不能知足企业的要求呢?
这就引出了咱们的第二个问题:企业为何要建中台?
定义一下前台与后台
由于平台这个词过于宽泛了,为了能让你们理解我在说什么,我先定义一下本文上下文我所说的前台和后台各指什么:
前台:由各种前台系统组成的前端平台。每一个前台系统就是一个用户触点,即企业的最终用户直接使用或交互的系统,是企业与最终用户的交点。例如用户直接使用的网站、手机App、微信公众号等都属于前台范畴。
后台:由后台系统组成的后端平台。每一个后台系统通常管理了企业的一类核心资源(数据+计算),例如财务系统、产品系统、客户管理系统、仓库物流管理系统等,这类系统构成了企业的后台。基础设施和计算平台做为企业的核心计算资源,也属于后台的一部分。
后台并不为前台而生
定义了前台和后台,对于第二个问题(企业为何要建中台),一样先给出个人答案:
由于企业后台每每并不能很好的支撑前台快速创新响应用户的需求,后台更多解决的是企业管理效率问题,而中台要解决的才是前台的创新问题。
大多数企业已有的后台,要么前台根本就用不了,要么很差用,要么变动速度跟不上前台的节奏。
咱们看到的不少企业的后台系统,在建立之初的目标,并非主要服务于前台系统创新,更多的是为了实现后端资源的电子化管理,解决企业管理的效率问题。
这类系统要不就是当年花大价钱外购,须要每一年支付大量的服务费,而且版本老旧,定制化困难;要不就是花大价钱自建,年久失修,一身的补丁,一样变动困难,也是企业所谓的“遗留系统”的重灾区。
总结下来就两个字“慢”和“贵”,对业务的响应慢,动不动改个小功能就还要花一大笔钱。
有人会说了,你不能拿遗留系统说事儿啊,咱们能够新建后台系统啊,整个2.0问题不就解决了?
但就算是新建的后台系统,由于其管理的是企业的关键核心数据,考虑到企业安全、审计、合规、法律等限制,致使其一样每每⽆法被前台系统直接使用,或是受到各种限制⽆法快速变化,以⽀持前台快速的创新需求。
此时的前台和后台就像是两个不一样转速的⻮轮,前台因为要快速响应前端用户的需求,讲究的是快速创新迭代,因此要求转速越快越好;⽽后台因为⾯对的是相对稳定的后端资源,⽽且往系统陈旧复杂,甚至还受到法律法规审计等相关合规约束,因此每每是稳定至上,越稳定越好,转速也天然是越慢越好。
因此,随着企业务的不断发展,这种“前台+后台”的⻮轮速率“匹配失衡”的问题就逐步显现出来。
随着企业业务的发展壮大,由于后台修改的成本和⻛险较⾼,也就驱使咱们尽可能选择保持后台系统的稳定性。
但由于还要响应用户持续不断的需求,天然就会将大量的业务逻辑(业务能力)直接塞到了前台系统中,引入重复的同时还会导致前台系统不断膨胀,变得臃肿,造成了一个个⼤泥球的“烟囱式单体应用”,渐渐拖垮了前台系统的“⽤户响应⼒”。
用户满意度下降,企业竞争力也随之不断降低。
对于这样的问题,Gatner在2016年提出的一份《Pace-Layered Application Strategy》报告中,给出了一种解决方案,即按照“步速”将企业的应用系统划分为三个层次(正好契合前中后台的三个层次),不一样的层次采用彻底不一样的策略。
而Pace-Layered Application Strategy也为“中台”产生的必然性,提供了理论上的支撑。
Pace-Layered Application Strategy
在这份报告中Gatner提出,企业构建的系统从Pace-Layered的⾓度来看能够划分为三类: SOR(Systems of record ),SOD(Systems of differentiation)和SOI(Systems of innovation)。
处于不一样Pace-Layered的系统由于⽬的不一样、关注点不一样、要求不一样,变化的“速率”天然也不一样,匹配的也须要采⽤不一样的技术架构、管理流程、治理架构甚至投资策略。
⽽前面章节咱们提到的后台系统,例如CRM、ERP、财务系统等,它们⼤多都处于SOR的Pace-Layered。
这些系统的建设之初每每是以规范处理企业底层资源和企业的核⼼可追溯单据(例如财务单据,订单单据)为主要⽬的。它们的变动周期每每比较⻓,⽽且因为法律律审计等其余限制,致使对于它们的变更须要严谨的申报审批流程和更高级别的测试部署要求,这就致使了它们每每变化频率低、变化成本高、变化⻛险高、变化周期⻓,⽆法满⾜由⽤户驱动的快速变化的前台系统要求。
咱们又要尽力保持后台(SOR)系统的稳定可靠,⼜要前台系统(SOI)可以⼩而美,快速迭代。就出现了上文提到的“齿轮匹配失衡”的问题,感受鱼与熊掌不可兼得。
正当陷入僵局的时候,天空中飘来一声IT谚语:
软件开发中遇到的全部问题,均可以经过增长⼀层抽象而得以解决!
⾄此,⼀声惊雷滚过,“中台”脚踏七彩祥云,承载着SOD(Systems of differentiation) 的前世寄托,横空出世。
咱们先试着给中台下个定义:
中台是真正为前台而生的平台(能够是技术平台,业务能力甚至是组织机构),它存在的惟一目的就是更好的服务前台规模化创新,进而更好的响应服务引领用户,使企业真正作到自身能力与用户需求的持续对接。
中台就像是在前台与后台之间添加的⼀组“变速齿轮”,将前台与后台的速率进行匹配,是前台与后台的桥梁。它为前台而生,易于前台使用,将后台资源顺滑流向用户,响应用户。
中台很像Pace-Layered中的SOD,提供了比前台(SOI)更强的稳定性,以及⽐后台(SOR)更高的灵活性,在稳定与灵活之间寻找到了⼀种美妙的平衡。
中台做为变速齿轮,连接了用户与企业核心资源,并解决了配速问题:
有了“中台”这⼀新的Pace-Layered断层,咱们就能够将早已臃肿不堪的前台系统中的稳定通用业务能力“沉降”到中台层,为前台减肥,恢复前台的响应力;
又能够将后台系统中须要频繁变化或是须要被前台直接使用的业务能力“提取”到中台层,赋予这些业务能力更强的灵活度和更低的变动成本,从而为前台提供更强大的“能力炮火”支援。
因此,企业在平台化的过程当中,须要建设本身的中台层(同时包括技术中台、业务中台和组织中台)。
三、小结
思考并回答了文初提出的两个关于中台价值的核心问题,解决了我对于中台产生的一些困惑,不知道对你有没有启发?我最后再来总结一下:
以用户为中心的持续规模化创新,是中台建设的核心目标。企业的业务响应能⼒和规模化创新能力,是互联⽹时代企业综合竞争⼒的核⼼体现。平台化包括中台化,只是帮助企业达到这个目标的⼿段,并非⽬标自己。
中台(不管是技术中台、业务中台仍是组织中台)的建设,根本上是为了解决企业响应力困境, 弥补创新驱动快速变化的前台,稳定可靠驱动变化周期相对较慢的后台之间的⽭盾,提供⼀个中间层来适配前台与后台的配速问题,沉淀能⼒,打通并顺滑连接前台需求与后台资源,帮助企业不断提高用户响应⼒。
因此,中台究竟是什么根本不重要,如何千方百计持续提升企业对于⽤户的响应力才是最重要的。而平台化或是中台化,只是恰巧走在了了这条正确的大道上。
2、到底中台长啥样?
列举了这么多各式各样的中台,最后都扯到了组织层面,是否是有种越听越晕的感受?好像什么东西加个“中台”的后缀均可以靠到中台上来?那估计很快就会看到例如AI中台、VR中台、搜索中台、算法中台……对了,算法中台已经有了……
让咱们引用一段阿里玄难在接受采访时提到对于中台的一段我很是认同的描述:
本文中咱们一直提到的一个词就是“能力”,从玄难的这段采访也能够看出,在阿里“能力”也是中台的核心。
甄别是否是中台,还要回到中台要解决的问题上,也就是我上面主要关注的问题。我认为一切以”以用户为中心的持续规模化创新”为目的,将后台各式各样的资源转化为前台易于使用的能力,帮助咱们打赢这场以用户为中心的战争的平台,咱们均可以称之为中台:
业务中台提供重用服务,例如用户中心、订单中心之类的开箱即用可重用能力,为战场提供了强大的后台炮火支援能力,随叫随到,威力强大;
数据中台提供了数据分析能力,帮助咱们从数据中学习改进、调整方向,为战场提供了强大及时的雷达监测能力,帮助咱们掌控战场;
移动及算法中台提供了战场一线火力支援能力,帮助咱们提供更加个性化的服务,加强用户体验,为战场提供了陆军支援能力,随机应变,所向披靡;
技术中台提供了自建系统部分的技术支撑能力,帮助咱们解决了基础设施,分布式数据库等底层技术问题,为前台特种兵提供了精良的武器装备;
研发中台提供了自建系统部分的管理和技术实践支撑能力,帮助咱们快速搭建项目、管理进度、测试、持续集成、持续交付,是前台特种兵的训练基地及快速送达战场的机动运输部队;
组织中台为咱们的项目提供投资管理、风险管理、资源调度等,是战场的指挥部,战争的大脑,指挥前线,调度后方。
因此,评判一个平台是否称得上中台,最终评判标准不是技术,也不是长什么模样,仍是得前台说了算,毕竟前台才是战争的关键,是感觉获得战场的残酷、看得见用户的那部分人。
前台想不想用,爱不爱用,好很差用;帮了前台多大的忙,从中台得到了多大的好处,愿意掏出多少利润来帮助建设中台,这些才是甄别中台建设对错好坏的标准。对于中台来说,前台就是用户,以用户为中心,在中台一样适用。
3、中台就是「企业级能力复用平台」
若是让我给出一个定义,目前我认为最贴切的应该是: 中台就是「企业级能力复用平台」。很简单,有点失望是否是?可是为了找到一个靠谱的定义,我几乎花了快两年的时间,期间有各类各样的定义曾浮现出来,但至少到目前为止,只有这个定义我以为最贴切、最简单、也最准确,它能解释几乎全部我碰到的关于中台的问题,例如:
为何会有那么多中台,像上文提到业务中台,数据中台,搜索中台,移动中台,哪些才是中台,哪些是蹭热点的?
中台与前台的划分原则是什么?
中台化与平台化的区别是什么?
中台化和服务化的区别是什么?
中台该怎么建设?
等等…
这9个字看起来简单,重要的是其背后对「中台」价值的阐释,下面就让我为你们一一拆解来看。
企业级
当作中台建设的时候,必定是跳出单条业务线站在企业总体视角来审视业务全景,寻找可复用的能力进行沉淀,从而但愿经过能力的复用一方面消除数据孤岛业务孤岛,一方面支撑企业级规模化创新,助力企业变革,滋生生态。
因此虽然中台的建设过程虽然能够自下而上,以点及面。但驱动力必定是自上而下的,全局视角的,而且须要必定的顶层设计。这也解释了为何在企业中推进中台建设的每每都是跨业务部门,例如CIO级别领导或是企业的战略规划部门,由于只有这些横跨多条业务线的角色和组织,才会去常常反思与推进企业级的能力复用问题。
这一点也引出了中台建设的一个关键难点,就是组织架构的调整和演进以及利益的从新分配,这是技术所不能解决的,也是中台建设的最强阻力。同时企业级也是区分企业中台化与应用系统服务化的关键点,简而言之中台化是企业级、是全局视角,服务化更可能是系统级、是局部视角。
因此从中台的兴起与爆发能够看到一种趋势,就是愈来愈多的企业不管是因为企业运营效率的缘由仍是因为创新发展的须要,对于企业全局视角跨业务线的能力沉淀都提升到了史无前例的战略高度。
能力
提到中台,最常听到的一个词就是「能力」。多是由于能力这个词足够简单,又有着足够的包容度与宽度。
企业的能力可能包含多个维度,常见的例如计算能力,技术能力,业务能力,数据能力,AI能力,运营能力,研发能力…其中大部分的能力还能够继续细化和二次展开,从而造成一张多维度的企业能力网。能够说,中台就是企业全部能够被「多前台产品团队」复用能力的载体。
复用
虽然咱们一直讲「去重复用」讲了不少年,但仔细想一想,大多平台化建设会将重点放在「去重」(消除重复)上,而对于「复用」则没有足够的关注。
不少企业都号称已经建成了各类各样成熟的平台,可是咱们问心自问一下,有多少平台是业务驱动的?有多少前台产品团队又是自愿将本身的产品接入到平台上的?有多少平台建设者是在真正关注前台产品团队的平台用户体验?
「去重」讲的更可能是向后看,是技术驱动的;「复用」讲的更可能是向前看,是业务驱动和用户驱动的。
因此「去重」与「复用」虽然常常一块儿出现,一块儿被说起,可是谈论的彻底不是一件事情,目的不一样,难度也不一样,作到「去重」已然很是困难,关注「复用」的就更是寥寥无几,因此:
「复用」是中台更加关注的目标;
「可复用性」和「易复用性」是衡量中台建设好坏的重要指标;
「业务响应力」和「业务满意度」也才是考核中台建设进度的重要标准。
而实现更好的复用,经常改进的方向有两个方面:
一方面将更高抽象(例如业务模式级别)的通用业务逻辑经过抽象后下沉到中台,这样前台就会更轻,学习成本和开发维护成本更低,越能更快的适应业务变化;缺点是,抽象级别越高,越难被复用,须要架构师对于各业务有深刻的理解和很是强的抽象能力。
另外一方面就是经过对于中台能力的SaaS化包装,减小前台团队发现中台能力和使用中台能力的阻力,甚至经过自助式(Self-Service)的方式就快速定位和使用中台能力。目前不少企业在尝试的内部API集市或是数据商店就是在这方面的努力和尝试。
平台
这里的平台主要是区别于大单体的应用或是系统。传统的企业数字化规划更多的是围绕业务架构,应用架构和数据架构展开。产出也是一个个基于应用和系统的数字化建设规划,例如要采购或是自建哪些具体的系统,例如ERP、CRM等。
固然这个过程并无什么问题,能够理解此时这些独立的系统就承载了企业的各类能力,因为企业各业务线统一使用一个应用或系统,也天然实现了能力的复用。
但问题经常出如今两个方面:
一个是大单体系统的业务响应力有限,缺乏「柔性」,当业务发展到必定阶段后,必然产生大量定制化需求,随着内部定制化模块的比例逐渐上升,响应力成指数降低,成为业务的瓶颈点。
另外一个则是系统间的打统统常比较困难,容易造成业务孤岛和数据孤岛。
因此愈来愈多的企业开始像互联网学习,以平台化的方式重塑企业IT架构,从而对于业务提供足够的「柔性」,来知足对于业务的快速响应和复用的需求。
小结
「企业级能力复用平台」这个定义虽然看起来简单,但通过这么长时间对于中台的实践与思考,我以为如上文所述的这个定义背后所表明的意义是目前对中台价值的最贴切的阐释:
有了定义后,如何建中台的思路也就豁然开朗:若是说中台是「企业级能力复用平台」的话,那中台化就是「利用平台化手段发现、沉淀与复用企业级能力的过程」。