当人们谈论中台的时候,都是从自己的视角。
我见过CIO的视角,互联网产品经理的视角,中台开发人员的视角,每个角色看待中台的视角都不同。
但就像我在 白话中台战略-3:中台的定义 里提到的,中台是“企业级”的,自然也就是一个企业层面的架构问题(包含了业务,架构与组织),本质上也是一个EA(Enterprise Architecture)的问题,但从EA视角(也是我自己的原生视角)出发看中台的文章比较少,这篇算是一篇。
传统EA讲的就是架构方法,常用的包括TOGAF\ZeMACH。也就是我们熟悉常见的“几大架构”(业务架构,应用架构,技术架构,数据架构,组织架构……),各大咨询公司的企业战略规划咨询也都差不多使用类似的方法,中台无非是在企业架构规划中加入了平台的因素而已。
第一次看这篇文章的时候,觉得作者并没有完全理解中台,人家阿里明明讲的是“大中台,小前台”,怎么文章中又说阿里是“大前台、小中台、无后台”呢?第三张图(图3集团性企业业务架构与阿里巴巴业务架构对比)也不对,哪有按照用户触点-供应链-生产来划分前中后台的呢(不是应该按照抽象来划分么?)。
又看了两遍之后,方恍然大悟,不但觉得作者说的也没有错,反而很受启发性。顺带还解决了自己的一些疑问,比如为什么传统企业就是理解不了互联网企业业务中台的概念?
思考之后觉得,问题就出现在这“业务”二字上!(再一次印证了DDD统一语言的重要性)。
在传统的EA体系里,“业务”是有明确的含义的,就是文中图2所描述的业务架构,本文中对于中台的描述也都是在传统EA框架的“业务架构”下描述的。
怎么理解业务架构呢?你可以把整个社会想象成一家大的企业,那简单讲业务无非就是生产各种产品或服务(业务后台),然后通过供应链(业务中台),最终通过用户交互界面(业务前台)送达客户手中。
前者就是常说的供给侧,后者就是消费侧。
我们常说的“业务梳理”,也是在梳理类似的端到端流程。从这个角度就可以理解为什么作者说阿里在业务架构上是个“大前台、小中台、无后台”了,因为阿里确实重点不是产品的生产制造和供应链,只是在不断创(抢)造(占)各种各样的前台场景,或者说大部分互联网企业都是类似的,都是在消费互联网这波浪潮里抢占用户的前台场景(流量)而已。
而我们常说的“业务中台”,其实更多指的只是IT架构中的应用架构中的应用中台(图 2企业信息化架构体系对比)。
好,搞清楚了业务架构与IT架构的中台概念,对我们有什么用呢?用处可大了!
之前互联网企业看不懂传统企业(所以就冠了个“传统”,予以区分,本文仍使用,但不带感情色彩,只为了区分),传统企业学不会互联网企业。
互联网企业经常说中台各种好处,而且做起来感觉思路也非常清晰(无非就是……无非就是……),但是为什么传统企业怎么也搞不清中台该怎么搞呢?是不是这就是“传统”与“新兴”的实力差距呢?答案是否定的。
问题就出在“业务架构”的差异上。
在EA的体系里,应用架构不能脱离业务架构,必须由业务架构驱动,业务架构决定了应用架构(也就是我们常挂在嘴边的:业务驱动)。应用架构可以学,但前提是业务架构基本相同的前提下,但互联网企业和传统企业的业务架构是截然不同的,两种类型的企业在整个社会这个大的“业务架构”上处于不同的节点,解决的是不同的问题,按照作者说的甚至是互补的,业务架构不同,自然应用架构就不能直接照搬,照搬就会出问题。
在“业务架构”(注意是业务架构)上,互联网企业往往面对的问题是各种各样的类似的不同场景的前台(消费侧)问题,所以互联网要解决的更多是基于自己的业务模式快速创新应用场景(抢地盘)的问题。典型的像阿里要出淘宝,天猫,飞猪,背后的业务模式都是卖东西;滴滴要做出租车,专车,顺风车,豪华车,背后的业务模式也都是运东西。而业务中台作为业务模式能力复用的“锤子”,自然适合这些“钉子”。
但是回到传统企业,尤其是大型集团型,主要关注的问题不像(或还不到)互联网企业是业务“横向”的快速扩张,更多还是在供应链、生产制造这类偏供给侧的整合拉通上。追求的也还是全链路全周期的管理和打通,对比与互联网的“横向”业务扩展,传统大型集团企业更讲究“纵向”的业务打通。
所以经常会出现这种现象,一家企业看互联网建业务中台,自己也要建业务中台,结果我们梳理来梳理去,就一条主要业务线,却异常的复杂,这种情况下怎么建业务中台?或是再深一步想,希望通过建设业务中台来解决什么问题?往往客户的回答都是业务梳理,数据打通,业务联动,你看还是纵向上的打通。
这就能解释为什么互联网企业做的业务中台都更多承载了“业务模式”,而传统企业做业务中台更多承载的就是“数据”而已(形式虽然都是一个个微服务)。因为一个强调横向业务模式的复用,一个强调的是纵向数据的打通和复用,本质上还是当前阶段的“业务架构”不同。
所以业务中台的建设不能脱离开企业的业务,不能脱离开要解决的问题,要先从业务架构的梳理开始,从痛点出发,不要一头扎进IT架构里,没搞清楚业务就直接照搬别人家的“业务中台”,结果往往会非常的痛苦。
《白话中台战略》已经写了三篇,尤其是第一篇「中台是个什么鬼」收到了很多朋友的反馈。写白话这个系列主要是想通过写文章来驱动自己思考,并希望可以和更多人一起交流和探讨中台这个话题。
幸运的是,确实有很多朋友在公众号后台给我留言来表达自己的想法,我摘出来一个具有代表性的:
“互联网的企业就是爱炒概念。本来很明白的东西,被他们一包装,就变得高深莫测了。我理解中台,就是敏捷响应机制…是一种思维或者理念…企业根据自己的实际情况落实就行。”
对于这位同学的观点我很赞同,中台本身就是一个比较抽象的概念,很多时候我们被那个“中”字困住了,整天在前与中,中与后的具体差别和评判标准上纠结不已。
但是,就像「看板」不是“我们看到的那个板子”一样,「中台」也不一定就是代表“处于中间平台”,这两个字作为一个整体,代表了一种新的思维和理念。在最新一期的ThoughtWorks技术雷达讨论阶段,中国区的同学就把“ZhongTai”作为一个独立的技术点提交,并没有做意译,就像“Kanban”一样。
那这种新的思维和理念到底是什么呢?“中台”的背后到底意味着什么?有没有价值?价值何在?这也我一直在不断询问自己的问题。
要想搞清楚这些问题,我认为一个关键点就是看我们是否能够给「中台」这个相对抽象的概念找到一个清晰的定义,因为只有通过定义才能让抽象的概念清晰化,从而明确边界、体现价值。
废话不多说,回到「中台」,如果让我给出一个定义,目前我认为最贴切的应该是:
中台就是「企业级能力复用平台」
很简单,有点失望是不是?但是为了找到一个靠谱的定义,我几乎花了快两年的时间,期间有各种各样的定义曾浮现出来,但至少到目前为止,只有这个定义我觉得最贴切、最简单、也最准确,它能解释几乎所有我碰到的关于中台的问题,例如:
为什么会有那么多中台,像上文提到业务中台,数据中台,搜索中台,移动中台,哪些才是中台,哪些是蹭热点的?
中台与前台的划分原则是什么?
中台化与平台化的区别是什么?
中台化和服务化的区别是什么?
中台该怎么建设?
等等……
这9个字看起来简单,重要的是其背后对「中台」价值的阐释,下面就让我为大家一一拆解来看。
企业级
首先,中台一定是企业级的,这里的企业级不是说难度而是指范围。企业级也不一定就是一个企业的范围,甚至可以是跨企业,例如现在同样火爆的生态的概念。按照徐昊(ThoughtWorks中国区CTO)的说法,更贴切的叫法应该是「多前台产品团队」,这里为了简单我还是用企业级来代表。
当做中台建设的时候,一定是跳出单条业务线站在企业整体视角来审视业务全景,寻找可复用的能力进行沉淀,从而希望通过能力的复用一方面消除数据孤岛业务孤岛,一方面支撑企业级规模化创新,助力企业变革,滋生生态。
所以虽然中台的建设过程虽然可以自下而上,以点及面。但驱动力一定是自上而下的,全局视角的,并且需要一定的顶层设计。这也解释了为什么在企业中推动中台建设的往往都是跨业务部门,例如CIO级别领导或是企业的战略规划部门,因为只有这些横跨多条业务线的角色和组织,才会去经常反思与推动企业级的能力复用问题。
这一点也引出了中台建设的一个关键难点,就是组织架构的调整和演进以及利益的重新分配,这是技术所不能解决的,也是中台建设的最强阻力,这个我打算在后续的文章里详细阐述。
同时企业级也是区分企业中台化与应用系统服务化的关键点,简而言之中台化是企业级、是全局视角,服务化更多是系统级、是局部视角。
所以从中台的兴起与爆发可以看到一种趋势,就是越来越多的企业无论是由于企业运营效率的原因还是由于创新发展的需要,对于企业全局视角跨业务线的能力沉淀都提高到了前所未有的战略高度。
能力
提到中台,最常听到的一个词就是「能力」。可能是因为能力这个词足够简单,又有着足够的包容度与宽度。
企业的能力可能包含多个维度,常见的例如计算能力,技术能力,业务能力,数据能力,AI能力,运营能力,研发能力……其中大部分的能力还可以继续细化和二次展开,从而形成一张多维度的企业能力网。
我在上一篇白话中台战略-2 中台到底长啥样?中已经举了一些常见的例子,这里就不赘述了。
可以说,中台就是企业所有可以被「多前台产品团队」复用能力的载体。
这里有一个经常碰到的问题,就是对于某一家企业来讲,你说了有这么多种不同类型的能力,到底哪些能力才是我们企业需要的?哪些是值得中台化的?优先级又怎么划分?
这个问题比较大,也很难有一个统一的答案。我们ThoughtWorks现在的做法是通过一系列Workshop,从业务、数据、技术三个方面切入,通过一系列方法,结合企业愿景,市场定位和数字化现状,跨越多条业务线,试图将企业需要的能力和可复用的能力识别出来,并为落地做好规划和准备。
这些会在后续写到中台如何落地的文章时再详细展开。
复用
讲到这儿,相信大家一定有一个疑惑,无论是说企业级,多前台产品团队,还是讲能力沉淀,都不是什么新话题。很多企业组件化,服务化,平台化搞了好多年,那「中台」到底有哪些新的启发?
我的答案就是对于「复用」的关注被提高到了一个前所未有的高度。
虽然我们一直讲「去重复用」讲了很多年,但仔细想想,大多平台化建设会将重点放在「去重」(消除重复)上,而对于「复用」则没有足够的关注。
很多企业都号称已经建成了各种各样成熟的平台,但是我们问心自问一下,有多少平台是业务驱动的?有多少前台产品团队又是自愿将自己的产品接入到平台上的?有多少平台建设者是在真正关注前台产品团队的平台用户体验?
「去重」讲的更多是向后看,是技术驱动的;「复用」讲的更多是向前看,是业务驱动和用户驱动的。
所以「去重」与「复用」虽然经常一起出现,一起被提及,但是谈论的完全不是一件事情,目的不同,难度也不同,做到「去重」已然非常困难,关注「复用」的就更是寥寥无几,所以:
「复用」是中台更加关注的目标;
「可复用性」和「易复用性」是衡量中台建设好坏的重要指标;
「业务响应力」和「业务满意度」也才是考核中台建设进度的重要标准。
而实现更好的复用,常常改进的方向有两个方面:
一方面将更高抽象(例如业务模式级别)的通用业务逻辑通过抽象后下沉到中台,这样前台就会更轻,学习成本和开发维护成本更低,越能更快的适应业务变化;缺点是,抽象级别越高,越难被复用,需要架构师对于各业务有深入的理解和非常强的抽象能力。
另一方面就是通过对于中台能力的SaaS化包装,减少前台团队发现中台能力和使用中台能力的阻力,甚至通过自助式(Self-Service)的方式就快速定位和使用中台能力。目前很多企业在尝试的内部API集市或是数据商店就是在这方面的努力和尝试。
平台
这里的平台主要是区别于大单体的应用或是系统。
传统的企业数字化规划更多的是围绕业务架构,应用架构和数据架构展开。产出也是一个个基于应用和系统的数字化建设规划,例如要采购或是自建哪些具体的系统,例如ERP、CRM等。
当然这个过程并没有什么问题,可以理解此时这些独立的系统就承载了企业的各种能力,由于企业各业务线统一使用一个应用或系统,也自然实现了能力的复用。
但问题常常出现在两个方面:
一个是大单体系统的业务响应力有限,缺少「柔性」,当业务发展到一定阶段后,必然产生大量定制化需求,随着内部定制化模块的比例逐渐上升,响应力成指数下降,成为业务的瓶颈点。
另一个则是系统间的打通通常比较困难,容易形成业务孤岛和数据孤岛;
所以越来越多的企业开始像互联网学习,以平台化的方式重塑企业IT架构,从而对于业务提供足够的「柔性」,来满足对于业务的快速响应和复用的需求。
总结
「企业级能力复用平台」这个定义虽然看起来简单,但经过这么长时间对于中台的实践与思考,我觉得如上文所述的这个定义背后所代表的意义是目前对中台价值的最贴切的阐释:
* 「企业级」定义了中台的范围,区分开了单系统的服务化与微服务;
* 「能力」定义了中台的主要承载对象,能力的抽象解释了各种各样中台的存在;
* 「复用」定义了中台的核心价值,传统的平台化对于易复用性并没有给予足够的关注,中台的提出和兴起,让人们通过可复用性将目光更多的从平台内部转换到平台对于前台业务的支撑上;
* 「平台」定义了中台的主要形式,区别于传统的应用系统拼凑的方式,通过对于更细力度能力的识别与平台化沉淀,实现企业能力的柔性复用,对于前台业务更好的支撑。
有了定义后,如何建中台的思路也就豁然开朗:如果说中台是「企业级能力复用平台」的话,那中台化就是「利用平台化手段发现、沉淀与复用企业级能力的过程」,再回头看看这两年做的事情,确实也都在围绕着这些展开。
先进制造业+工业互联网
产业智能官 AI-CPS
加入知识星球“产业智能研究院”:先进制造业OT(自动化+机器人+工艺+精益)和工业互联网IT(云计算+大数据+物联网+区块链+人工智能)产业智能化技术深度融合,在场景中构建“状态感知-实时分析-自主决策-精准执行-学习提升”的产业智能化平台;实现产业转型升级、DT驱动业务、价值创新创造的产业互联生态链。
版权声明:产业智能官(ID:AI-CPS)推荐的文章,除非确实无法确认,我们都会注明作者和来源,涉权烦请联系协商解决,联系、投稿邮箱:erp_vip@hotmail.com。