随着互联网公司的崛起,“中台”这个词也进入了人们的视线。BAT 等公司纷纷推出了自己的中台系统。那么,什么是中台系统?
任何一个软件系统都是通过帮助客户解决问题来实现价值的。针对不同的需求会建立不同的软件项目。这些软件项目包含客户端的应用和后台管理配置的应用。久而久之就形成了固定的“前台”和“后台”系统,而且大家都在乐此不疲地开发着类似的业务系统。
但是,时间一长大家就发现了,这些系统中有一些部分大同小异,在做第二个项目的时候并不用将所有的功能重写,可以把之前项目中那些共有的模块拿出来,稍作修改就可以在新项目中应用了。中台系统就是将“后台”系统中那些针对技术,业务,组织的通用“模块/服务”从原来固定的项目中抽离出来,并且使之能够成为一个自治的服务提供给更多的“前台”使用。
中台是 IT 信息化过程中经验总结的产物,他是前人归纳总结出来的方法论,也是解决问题的思路。它把这些经验和方法从具体的场景中抽离出来,为的是服务于更多的场景,即能力复用。
中台的催生基石是能力共享。如果中台所提供的能力无法被共享,那就不是中台能力。如果中台只服务于一个前端应用,那就不是中台。
中台是为业务服务的,是需要根据企业业务演进逐渐积累而成的,因此中台的建设不是一蹴而就的。
要让中台模式在企业中发挥作用,对企业本身也是有一定要求的,比如企业要有一定规模,业务比较丰富,值得去提炼共性元素形成共享能力。
许多人通过阿里巴巴推出的中台战略而得知中台这一概念,其实中台是一个旧名词,在很早的时候就出现过,只不过一直没有被真正的应用起来,在2017年通过《企业IT架构转型之道:阿里巴巴中台战略思想与架构实战》一书热度上升起来,那么阿里提出的中台究竟是什么。
**阿里中台主要应用于业务种类繁杂、个人/企业会员数量庞大、不同种类业务相互交叉依赖,需要根据需求变化快速响应调整的O2O线上线下协同的电商场景。**阿里中台将技术、数据、业务能力从前台剥离,形成技术中台提供系统性的后端服务,为前台零售电商业务提供支撑,中台主要分为业务中台与数据中台两大块。
业务中台主要针对其电商交易业务,具体包括售前、售中、售后三部分,业务中台被划分为许多中心服务,即会员中心、商品中心、交易中心、评价中心、店铺中心、支付中心、营销中心、库存中心,贯穿整个电商业务流程。数据中台主要提供大数据相关的计算、存储、共享能力,将线上与线下的数据源进行连接打通,进而实现决策分析、精准营销等战略手段。
阿里提出中台战略之后,滴滴、京东等互联网厂商陆续推出对应的中台战略,同时数据中台、业务中台、技术中台、内容中台等多种形式中台出现。
中台是企业级共享能力平台,下图展示的是中台的架构体系。
业务中台泛指代表企业核心业务特征的中台结构,更多的是对业务的支持,实现后端业务资源到前台应用能力的转化,业务中台多由不同的业务板块组成。
技术中台整合和包装了云基础设施,以及在其上建设的各种技术中间件,比如微服务、分布式缓存、消息队列、搜索引擎、分布式数据库等,并在此基础上建设和封装了简单易用的能力接口。技术中台作为工具和组件,为建设前台应用和业务中台提供了基础设施重用的能力,大大缩短了它们的建设周期。
研发中台是关注系统开发效率的管理平台。软件开发和系统建设是一项工程,涉及项目管理、团队协作、流程、测试、部署、运营、监控等方面。 如何将在企业应用开发过程中的最佳实践沉淀为可重用的能力,从而更好地快速迭代开发创新型的应用,也是很多企业目前的一个关注点。
研发中台为应用开发提供了流程、质量管控和持续交付的能力,包括敏捷开发管理、开发流水线、部署流水线、持续交付。
例如开发流水线则涉及源代码的版本管理、分支的创建、合并和提交,半成品的构建、存储和使用以及产成品的构建。将产品部署到指定环境并上线运行是部署流水线的职责。
数据中台泛指通过数据处理、分析等技术,对企业内外部海量数据进行采集、计算、存储、加工、分析等一系列活动,凸显数据价值,加强企业对数据的利用。数据中台提供数据能力直接服务于业务。
以下摘自《技术人修炼之道:从程序员到百万高管的72项技能》第4章 技术人都要学的架构思维
简单的说,中台架构是解决企业复杂生态协作问题的方法论。
中台架构的目标,是通过中台治理的理念和方法,让企业降低成本,提升协作效率。是通过制定符合企业实际情况的标准和规范,来做具体的项目实施。
中台治理方法的原则:集中管控,分布式执行。
定位就是清楚的告诉别人,你有什么?你要什么?以及你不要什么?
以阿里巴巴的业务中台为例,业务中台需要收敛一些基础的业务服务,如会员、商品、交易、营销和结算等。这些基础的服务会被整个电商业务使用,所以统一管理是很有必要的。
那么业务中台还需要什么?
因为中台的目标是要向上层业务提供这些基础的服务,那自然必须能够清楚地描述自己到底有哪些服务、数据和功能,我们可以把它统称为能力。所以还需要能够定义能力(标准和规范)、能力的发现、能力的注册、能力的列表以及能力的评价和更新机制等。
业务中台也不是什么都做,除了有基本的基础服务和服务能力外,还要定义中台的边界。
业务中台有它基本的工作范围,它需要能够对接能力,同时又服务好能力使用方,而自己并不负责实现具体的业务。
前面提到了,中台架构是解决企业复杂生态协作问题的方法论。这个方法论要解决的是企业复杂生态协作的治理问题。
我们可以借鉴建筑行业、互联网行业的基础设施建设的思路。以移动互联网为例,根据QuestMobile数据显示,移动互联网月活用户规模达到11.38 亿。
那么,如此庞大的生态体系是如何运作的呢?
我们观察到,任何手机都有sim卡,每个手机的制造工艺,要求满足3G、4G、5G协议。无论是联通还是电信、移动,运营商集中控制整个网络。从移动互联网的生态治理可以看到,由三方面因素共同解决一个复杂生态的协作问题:
以上三方面因素,就是中台治理方法论的核心要素。
企业要不要上中台,不能盲目跟风。别人家上了我也要上,你不清楚别人的战略布局、核心竞争力、战术打法,盲目去学,你不死谁死?
道理都懂,那么有没有一种方法来判断一个企业需不需要上中台?
我们参照“美国国家标准技术研究院”的技术战略选择分析流程图,来给企业来做个诊断,如图所示:
中台战略选择分析流程图
图中列出了5个条件判断:
以上 5 个条件,任意满足3个及以上,我们就认为这个企业适合做中台战略升级。
分为以下三个部分:
中台建设难易度分析
企业中台建设的技术、数据、业务、组织,建设难度从易到难,总结下来就是:
阿里巴巴中台建设路径
阿里巴巴中台建设路径
阿里建议企业实施中台战略的4个升级:
第一,组织架构不匹配中台架构。
观察阿里HR组织中台,从结构来看,跟阿里的业务中台架构很像,这就是组织架构与业务架构要相匹配。
第二,需求治理缺失,大量浪费资源。
建立以价值为导向的需求治理机制,以价值为导向的需求治理机制,其目的是把有限的开发资源,投入到更有价值的项目上,该机制分成几个部分,如图
需求治理机制
建立需求管理闭环。以价值为导向的需求治理机制,是在需求提报环节,提出该需求的价值预估,即这个需求将给业务带来什么样的价值,这些价值要能够量化、能够追踪。比如,一 个结算系统需求,价值是:提升客户对账效率20%,上线后会来验证效果,看看是否达到预期。
第三,中台部渐渐脱离一线业务,成为鸡肋中台。
中台化的难度是:技术<数据<业务<组织。因为越往后,越需要业务团队的介入,越要有业务认知才能做好中台。而中台团队,天然就是离业务远的。
各公司跟中台团队的协作,都存在很大的低效问题,一线的前台业务团队,要反复与中台沟通,才能讲清楚业务需求的背景,在大公司,跨部门协作都会徒增成本。另外对于中台业务团队来说,长期离业务很远,没有成长性,在判断需求时也不准确,很难获得前台业务团队的信任。
久而久之,就变成了中台团队纯支撑、被动接需求的状态,成为“鸡肋中台”。更大的问题在于,中台团队的价值就是整合需求、抽象能力的,在对用户和业务不够了解的前提下,做起来就会特别吃力。如果是多个前台业务的需求有了冲突,中台团队未必能做好协调,多方要反复沟通扯皮。
第四,一把手不重视中台建设。
导致的问题是,未把中台建设上升到战略高度,资源投入不足,也没有决心进行组织架构变革,导致中台建设不能持之以恒。
第五,幻想着中台战略一步到位。
没有中长期投入的准备,想着怎么短平快的进行建设,或者把中台战略当成向公司要资源的新理由。
第六,认为中台包治百病。
这类企业把业务增长慢、企业运作效率低、组织架构臃肿、缺乏创新等问题,都想用一套方法来一次性解决掉,结果问题依然存在。中台建设,首先要定义问题,越聚焦越能够产生好的效果。
总之,企业是否要上中台,要根据企业的具体情况做分析,可根据上文“中台战略选择分析流程图”进行判断,不要盲目跟风,认为别人家上了中台,自己也要上。中台是一剂良药, 对症下药能治顽疾,用药不当,会送了你的命。
看了很多介绍中台的资料,发现架构的思想不是跟风而是是否可以切实解决现有的问题,但是投入下去可能短时看不出利益需要长期实践,很有可能是好的方向但是因为成本投入不大而放弃而没有达到预期,所以在进行架构设计一定要想到可以达到的效果,分析清楚其中的难点,成本,风险。大企业有很多的试错成本,但是小企业如果跟风可能人力物力下去并不会达到同样的效果,看了很多资料虽然自己是技术人,并不用考虑架构,但是可以拓宽一下自己的思维,感觉如果上中台不是大肆宣扬大改而应该小部分先进行修正看看效果,慢慢的演进,将服务数据进行共享化避免重复造轮子。