极客时间已完结课程限时免费阅读

03 | 中台定义：当我们谈中台时到底在谈些什么？

03 | 中台定义：当我们谈中台时到底在谈些什么？-极客时间

03 | 中台定义：当我们谈中台时到底在谈些什么？

2019-09-25 王健 来自北京
《说透中台》
课程介绍

讲述：王健

时长19:10大小17.54M

你好，我是王健。
前面两讲，我带你从时间维度重新走了一遍中台的发展历程，又在空间维度为你介绍了目前市面上出现过的各类中台。
估计你现在一定被这么多种类的中台搞的有点晕头转向了，这些中台都称的上是中台么？感觉和之前一直在做的平台也没有什么两样啊？
这也是我过去几年一直在内心不断问自己的问题。这一讲作为概念篇的最后一篇，我就试着带你跳出时间与空间的维度，来分析一下企业为什么要建中台？当我们谈中台时，我们到底在谈些什么？

企业为什么要建中台？

我们先来看企业为什么要建中台？想要回答这个问题，咱得先解决另一个问题，那就是企业为什么需要平台化？
企业为什么需要平台化呢？先给我的答案：
因为在当今这样一个互联网时代，用户才是商业战场的中心，为了快速响应用户的需求，借助平台化的力量可以事半功倍。
这背后的逻辑很简单，不断地快速响应、探索、挖掘、引领用户的需求，才是企业得以生存和持续发展的关键因素。
那些真正尊重用户，甚至不惜调整自己、颠覆自己来响应用户的企业，将在这场以用户为中心的商业战争中得以生存和发展。反之，那些在过去的成就上故步自封，存在侥幸心理希望用户会像之前一样继续追随自己的企业，则会被用户淘汰。
很残酷，但这就是这个时代最基本的的企业生存法则。
而平台化之所以重要，就是因为在这场以用户为中心的现代商业战争中，它赋予或加强了企业最核心的能力：用户响应力。平台化思想（Platform Thinking）恰好鼓励企业不断抽象沉淀自己核心的底层能力，通过平台化包装，得以更好地赋能前台业务，用底层的确定性来帮助企业应对前台业务以及最终用户需求的不确定性。
从结果来看，在不确定性当道的当今商业战场，真正的弄潮儿也大多是那些具备平台化思维并很早就开始发力平台建设的企业，这也在一定层面上佐证了平台化对于一家企业的重要性。
好，现在我们想明白了第一个问题，企业为什么需要平台化。但是平台化并不是一个新概念，很多企业在这个方向上已经做了多年的努力和积淀。那为什么最近几年“中台”这个相对较新的概念又会异军突起？对于企业来讲，传统的“前台 + 后台（或是平台）”的平台化架构为什么不能满足企业的要求呢?
这就引出了我们的核心问题：企业为什么要建中台？
同样，先给我的答案：
中台化是平台化的下一站，是平台不断对于自身治理演进、打破技术边界、逐渐拥抱业务、容纳业务、具备更强的业务属性的过程。中台关注为前台业务赋能，真正为前台而生。
为了能够更清楚地讲解我的观点，这里需要先定义一下，在今天我们讨论的上下文中，前台和后台分别指什么。
前台：由各类前台系统组成的前端业务平台。每个前台系统都是一个用户触点，大多是企业最终用户直接使用的系统，是企业与最终用户的交点。例如用户直接使用的网站、手机 App、微信公众号、小程序等都属于前台范畴。
后台：由后台系统组成的后端支撑平台。每个后台系统一般管理了企业的一类核心资源（数据 + 计算），例如财务系统、产品系统、客户管理系统、仓库物流管理系统等，这类系统构成了企业的后台。（在和很多互联网的朋友聊过之后，在互联网企业很多并没有后台的概念，更多直接使用平台的概念，例如分为前台层和平台层，但位置和作用与传统企业里的后台相似，我这里直接统一使用后台这个概念来代表。）
定义了前台和后台，我们再回过头来看企业为什么要建中台这个问题。
我们看到很多企业的后台，在创建之初的目标，并不是主要服务于前台系统的业务创新，而更多的是为了实现后端资源的电子化管理，解决企业管理的效率问题。这类系统要不就是当年花大价钱采购的套装软件，需要每年支付大量的服务费，并且版本有的也已经非常老旧了，定制化困难；要不就是花大价钱自建，年久失修，一身的补丁，同样变更困难，基本改不动了，也是企业所谓的“遗留系统”的重灾区。
可以这么说，大多数企业已有的后台，要么前台根本就用不了，要么不好用，要么变更速度就根本跟不上前台业务发展的节奏。总结下来就两个字“慢”和“贵”，对业务的响应慢，动不动改个小功能就还要花一大笔钱。
有人会说了，你不能拿遗留系统说事儿啊，我们可以新建后台系统啊，整个 2.0，问题不就解决了？
这是一种解决问题的思路，不过就算是新建的后台系统，因为后台管理的往往是企业的关键核心数据，考虑到企业安全、审计、合规、法律等限制，这样的系统也往往⽆法被前台系统直接使用，或是受到各类限制⽆法快速变化，不能⽀持前台快速的业务创新需求。
此时的前台和后台就像是两个不同转速的齿轮，前台由于要快速响应前端用户的需求，讲究的是快速迭代创新，所以要求转速越快越好；而后台由于面对的是相对稳定的企业核心后端资源，而且往往系统陈旧复杂，甚至还受到法律法规、审计等相关合规约束，一般是追求稳定至上，越稳定越好， 转速也自然是越慢越安全。
所以，随着企业业务的不断发展，这种“前台 + 后台”的齿轮速率“匹配失衡”的问题就逐步显现出来了。
企业业务不断发展壮大，后台修改的成本和风险越来越⾼，这就驱使我们尽量保持后台系统的稳定性，但同时还要响应用户持续不断的需求，怎么办？最自然的就是将大量的业务逻辑（业务能力）直接塞到前台系统中，因为前台离用户近，响应也相对快。
但是这样也是有代价的，这样的后果就是引入重复，同时还导致前台系统不断膨胀，变得臃肿，形成了一个个大泥球的“烟囱式单体应用”。这个局面的结果就是，前台系统的“用户响应力”被渐渐拖垮，用户满意度逐渐降低，企业竞争力也随之不断下降。
对于这样的问题，Gatner 在 2016 年发布了一份报告 Pace-Layered Application Strategy。报告中给出了一种解决方案，即按照“步速”将企业的应用系统划分为三个层次（正好契合前中后台的三个层次），不同的层次采用完全不同的策略。
而 Pace-Layered Application Strategy 也为“中台”产生的必然性，提供了理论上的支撑。
在这份报告中，Gatner 提出，企业构建的系统从 Pace-Layered 的角度来看可以划分为三类：SOR（Systems of record ），SOD（Systems of differentiation）和 SOI（Systems of innovation）。每一类的系统都有着不同的变化速率，因此也会有不同的生命周期，适合不同的技术架构和不同的开发过程，甚至是采用不同的投资模式。
回到之前说的后台与前台的两层架构，如果映射到这个模型上其实就是只有 SOR（后台）与 SOI（前台）的两层应用架构。这样的情况下，我们又要尽力保持后台（SOR）系统的稳定可靠，⼜要前台系统（SOI）能够⼩而美，快速迭代。因此就自然出现了上文提到的“齿轮匹配失衡”的问题，感觉鱼与熊掌不可兼得。
怎么办？Pace-Layered 中的 SOD 就是答案，它提供了比前台（SOI）更强的稳定性，以及比后台（SOR）更高的灵活性，在稳定与灵活之间寻找到了⼀种美妙的平衡。
中台就是 SOD。有了这层“中台”，我们既可以将早已臃肿不堪的前台系统中稳定通用的业务能力“沉降”到中台层，为前台减肥，恢复前台的响应力；又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力“提取”到中台层，赋予这些业务能力更强的灵活度和更低的变更成本；或者干脆直接对于后台进行中台化改造，通过配置化、自助化、白屏化等形式为后台加速，从而为前台提供更强大、更迅捷、更易用的“能力炮火”支援。
中台就像是在前台与后台之间添加的⼀组“变速齿轮”，将前台与后台的速率进行匹配，是前台与后台的桥梁和润滑剂。它为前台而生，易于前台使用，将后台资源顺滑地通过前台导流向用户，支撑企业更好地响应用户。
好了，现在我们可以小结一下，回答企业为什么需要建中台这个问题了。很简单，企业在平台化的过程中，为了能不断地给前台业务提供更好的服务，来支撑企业对于用户的持续响应，增加企业的用户响应力，企业需要构建自己的中台。

给中台下个定义

讲了这么关于中台的来龙去脉，以及种种表现形式，也讲了我对于企业平台化与中台化的理解，但你可能仍然会觉得比较抽象，所以我想，一定要试着给中台下个定义。
为什么需要一个定义呢？倒不是因为别的原因，我是觉得需要给自己一把简单的尺子，让我能轻易记住中台的特性，并能用它来快速判断一个所谓的中台是不是满足我对于中台的理解，所以我给中台的定义就是：
企业级能力复用平台。
很简单，是不是有点失望？但是为了找到一个我觉得还靠谱的定义，我几乎花了快两年的时间，期间有各种各样的定义曾浮现出来，但至少到目前为止，我觉得只有这个定义最贴切、最简单、也最准确，它能解释几乎所有我碰到的关于中台的问题，例如：
为什么会有那么多中台？
中台化与平台化的区别是什么？
中台化和服务化的区别是什么？
中台该怎么建设？
……
这 9 个字看起来简单，重要的是其背后对“中台”价值的阐释，下面就让我为你一一拆解来看。
1. 企业级
企业级定义了中台的范围。不是说一个企业只能有一个中台，也不代表一个中台就是只能包含一家企业，企业级更多代表的是中台处理的问题在企业级别，即至少包含多条业务线或服务多个前台产品（团队），如果一个中台只为了支持一条业务线或产品线，那就不是中台，即使它用了服务化或是大数据等技术。
企业级这一点非常非常重要。它让我想清楚了，中台建设的事情并不是一个技术问题，而是一个要上升到企业架构的问题。做中台建设的时候，一定是跳出单条业务线、站在企业整体视角来审视业务全景。
想清楚了这一点，我对中台的理解就有了一次质的变化，也终于知道为什么一开始用做系统服务化的方式做中台会面临那么多的问题，比如最常见的组织和干系方以及利益再分配的问题。
从中台的兴起与爆发我们也能看到一个趋势，就是越来越多的企业，无论是想提升自身的运营效率，还是出于业务创新发展的需求，都已经把企业全局视角、跨业务线的能力沉淀，提到了前所未有的战略高度。
2. 能力
提到中台，最常听到的一个词就是“能力”。可能是因为能力这个词足够简单，又有着足够的包容度与宽度。
能力定义了中台主要承载的对象。
能力的抽象解释了为什么会有那么多种类中台的存在，也能解释为什么每家企业的中台都不一样，因为不同的企业之所以能够同时存在，就是因为其核心能力不同，可以满足用户不同层面的需求，也就是我们常说的差异化竞争力。
3. 复用
复用定义了中台的核心价值，也承载了上面讲到的从平台化到中台化的演进过程。传统的平台化对于“可复用性”和“易复用性”并没有给予足够的关注，更多关注的是如何消除掉重复的能力建设，既所谓的“去重”。
但中台的提出和兴起，体现出一种对于前台业务的使用体验更加关注的趋势。让人们通过对于“可复用性”和“易复用性”的关注，将目光更多地从平台内部的建设转换到平台对于前台业务的支撑上。这里有一个从治理到赋能的视角转换，既从“去重”到“复用”的关注上。
“去重”与“复用”虽然经常一起出现，一起被提及，但是谈论的完全不是一件事情，目的不同，难度也不同。“去重”讲的更多是向后看，是技术驱动的；“复用”讲的更多是向前看，是业务驱动和用户驱动的。而正这个视角的转变，我认为是理解中台概念的关键，所以
“复用”是中台更加关注的目标；
“可复用性”和“易复用性”是衡量中台建设好坏的重要指标；
“业务响应力”和“业务满意度”是考核中台建设进度的重要标准。
这也能解释为什么很多互联网企业，将对于平台的治理，通过业务抽象以及可配置化和白屏化的改造升级，把这个过程称之为对于平台的中台化改造过程。
4. 平台
平台定义了中台的主要形式。区别于传统应用系统拼凑的方式，中台通过对于更细粒度能力的识别与平台化沉淀，实现企业能力的柔性复用，更好地支撑前台业务，来满足对于业务的快速响应和复用的需求。
“企业级能力复用平台”这个定义虽然看起来简单，但经过这么长时间对于中台的实践与思考，我觉得这个定义背后所代表的意义是目前对中台价值的最贴切的阐释。
“企业级”定义了中台的范围，区分开了单系统的服务化与微服务；
“能力”定义了中台的主要承载对象，能力的抽象解释了各种各样中台的存在；
“复用”定义了中台的核心价值，传统的平台化对于易复用性和前台的用户体验并没有给予足够的关注，中台的提出和兴起，让人们通过可复用性将目光更多的从平台内部设计转换到平台对于前台业务的支撑上；
“平台”定义了中台的主要形式，区别于传统的应用系统拼凑的方式，通过对于更细粒度能力的识别与平台化沉淀，实现企业能力的柔性复用，更好地支撑前台业务。

总结思考

今天我们从企业为什么需要平台化入手，讨论了企业又为什么需要建中台。结合前两讲的内容给出了我的观点，不知道对你有没有启发，让我最后再来总结一下。
以用户为中心的持续规模化创新，是中台建设的核心目标。企业的用户响应能力和规模化创新能力，是互联网时代企业综合竞争力的核心体现。平台化包括中台化只是帮助企业达到这个目标的手段，并不是目标本身。
中台（⽆论是技术中台、业务中台还是组织中台）的建设，根本上是为了解决企业响应力困境， 弥补创新驱动需要快速变化的前台和稳定可靠驱动需要变化周期相对较慢的后台之间的矛盾，提供⼀个中间层来适配前台与后台的配速问题，打通并顺滑链接前台需求与后台资源，帮助企业从整体上不断提升用户响应力。
所以，中台到底是什么根本不重要，如何想方设法持续提高企业对于用户的响应力才是最重要的。而平台化或是中台化，只是恰巧走在了这条正确的大道上。
最后我们给中台下了一个定义，既“企业级能力复用平台”。有了这个定义后，我们不仅可以把它当作一把尺子来丈量一个中台是否货真价实，对于如何建中台的思路也能豁然开朗。
因为如果说“中台就是企业级能力复用平台”的话，那“中台化”也就是“利用平台化的思维和手段梳理、识别、沉淀与复用企业级核心能力的过程”。
好了，从下一讲开始我们就正式进入落地篇，一起来看看我们是如何规划与落地实施中台的。
最后，给你留几个思考题：
你的企业真的需要中台吗？
如果让你用一句话来给中台下个定义，你会怎么讲？
在你所在的企业，中台是解决方案还是问题本身？
期待你在留言区分享自己的想法，也欢迎你把今天的内容分享给朋友，和他一起学习讨论。我们下一讲见！
分享给需要的人，Ta购买本课程，你将得9元
生成海报并分享

赞 25

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
02 | 中台种类：你听说的中台真的是中台吗？
下一篇
04 | 万事预则立：中台建设前必须想清楚的四个问题
unpreview
 写留言

精选留言(86)

  • 笑若海
    置顶
    2019-10-06
    我觉得平台与后台的关系可以借助System of systems的概念来理解，后台对应systems，对应于企业建立的各种职能IT系统（如CRM ERP OA 库存管理 采购 供应链 研发 制造等）；平台对应system，将职能IT系统有机集成起来，作为一个整体对前台服务，而不是各个职能系统之间的点到点集成对前台提供服务。 平台层在互联网企业中兴起前已经存在，只是传统企业中IT部门作为辅助职能部门，缺少话语权和主导性，没能上升到企业级高度。而互联网企业敏捷、快速响应用户的企业文化将平台化做到了新的企业级高度。 平台与中台的异同——“中台是企业级能力复用平台”这一概念解释的非常准确，平台化刚被互联网企业喊出时，侧重于IT能力去重，是cost saving，中台则侧重业务能力灵活复用，是value add。 平台化/中台化本质上就是企业IT系统集成的一种设计理念，以高效的价值创造和成本控制为目标。
    展开
    66
  • XuToTo
    2019-09-25
    那么所谓的 BFF 是否算是一种「中台」呢？

    作者回复: XuToTo，你好～ 好问题哈，不回答都睡不着觉了…… 首先这两者不在一个抽象层次上，解决的问题也不同，BFF更多是技术架构层面，中台更多是在应用架构层面。 但是，我之前也用BFF来类比过中台，主要为了让技术同学们理解“向前看”这个概念。 不过后来觉得还是有一些不同，主要在于BFF和中台虽然都强调“向前看”，但BFF往往是专注于服务一个前台；而中台的特点就是通过抽象后可以同时服务多个前台。 如果非要类比的话，更像是由GraphQL实现的统一BFF层，不知道你是不是也能理解～

    共 6 条评论
    37
  • MG
    2019-10-01
    老师您好，请问“复用”和“去重”有什么区别呢？我能理解“去重”，即是“去掉重复的”，那么既然“去掉”了“重复的”了，不就是在“复用”了么？请老师指教，谢谢！

    作者回复: MG，你好～ 我在文中也提到了一些，可能没有讲的特别清晰。我举个例子，例如你和我，咱们是两个业务线，都有重复的用户数据，后边有一个用户中台说要整合我们两方的用户信息和用户处理逻辑。 如果对于中台来讲，只要去重就好了，那它会更多考虑你我两边有哪些数据或是功能是重复的，然后拿走，统一在用户中台里管理，只要你我没有重复中台就完成任务了，但是你我的数据被拿走了，再拿回来或是做一些调整可能就费劲了，因为中台关注的只是重复有没有消除，并不关心前台是不是可以继续很好的使用这些被“去重”的数据和功能。 所以我觉得“复用”这个词在去重的前提下，还有更多的“用户视角”，从用户的使用体验出发，关注“可复用”和“易复用”性，也就是你不能光去重把数据和功能拿走，还得提高复用性，让我前台业务还能很好的复用这些数据和功能。 去重向后，复用向前，这个视角的变化我认为也是中台的根本价值。 希望回复能帮你理解，有问题可以继续留言我们再探讨～

    共 3 条评论
    20
  • 业余草
    2019-09-26
    中台化是平台化的下一站，是平台不断对于自身治理演进、打破技术边界、逐渐拥抱业务、容纳业务、具备更强的业务属性的过程。中台关注为前台业务赋能，真正为前台而生。

    作者回复: 业余草，你好~ 这段，尤其是中台化与平台化的区别，困扰了我很久，算是我最近几个月，通过跟各位前辈学习到的一个我认为对我非常有关键的点。 以前我一直在试着找这两者之前的区别，并没与把它们放到一条线上来按照阶段去理解，很高兴也你也能认同~ 有问题可以继续留言，我么继续交流~

    共 2 条评论
    13
  • vkingnew
    2019-09-26
    中台 个人的理解，承上（前台）启下（后台），提高数据等公共资源的复用能力，提高开发和服务的效率，对前中后台来说即高内聚低耦合，各司专职。

    作者回复: vkingnew，你好~ 感谢再次留言：） 概括的很到位哈~

    10
  • rexzhao
    2019-09-30
    老师你在文中说，中台关注为前台业务赋能，真正为前台而生。如果前台的概念是最终用户直接使用的系统，而后台则是企业内部的财务管理系统，资源管理系统。 那为什么中台不能也为后台赋能呢？我们之前给客户做的系统或服务就是在用户之前的HR管理或财务管理系统上做很多的报表的制作和修改，中台能帮到这类系统吗？谢谢。

    作者回复: rexzhao，你好～ 好问题哈，我划分前后台其实主要还是从SOR，SOD和SOI出发分析的，如果一个后台就是纯的SOR，那最核心的目标就是管理好自己该管理的企业最核心的数据，功能可能也就是简单的CRUD。 这时候其实也并不需要什么中台赋能，但是像你说的实际中我们看到的一些后台系统，本身除了对于核心数据（人力，财务）的管理外，还有很多的其他功能，例如报表之类的。 那可以理解这时候，这个后台系统已经不是单纯的SOR了，还包含了一些SOI的属性，当然中台作为SOD也可以对其赋能，例如通过数据中台对于财务数据进行二次加工，再返回到财务系统中。 不过总感觉有点奇怪，如果是我，我还是建议将这部分SOI的部分（报表）与SOD的部分（核心财务管理）分离开，这样也减少了对于SOR部分（核心财务管理）的频繁变动，增加其稳定性；又能对于SOI（报表）部分快速变化，不受核心财务模块的限制；中间再通过一层中台的SOD赋能，感觉这样整体架构更顺一些。 不过回到你具体的例子，在不了解上下文的前提下，我这也只能算是纸上谈兵，还得要看具体的情况，只是希望回复对你有所启发，更多从从解决问题的角度出发，活学活用。 感谢你的留言，有问题可以继续留言探讨～

    10
  • hanbing
    2019-09-28
    前台和中台的边界应该如何准确的界定？公司也在建中台，前台和中台经常因为边界问题该你做还是我做产生争执，应该如何准确的定义边界呢？

    作者回复: hanbing，你好~ 好问题哈，也算是经典问题之一了。 不过我看了一下评论区，其实问到的并不多，正好借这个机会展开聊一聊我的理解。 对于前台和中台的界定，我们在不同的时间尝试过很多种不同的划分方式，但总觉得有局限。例如，如果最简单按照是否重复来划分，重复的放中台，特性的放前台，先不说是否重复就很难掰扯清楚，而且放到时间线上，现在一样的可能以后会不同，现在不同的难免以后也可能会相同，这本身又很难扯清楚，更别提局部重复等情况。 其他的分法，也会有同样的问题，例如按照业务重要性，那怎么判断重要性高低，这些都是问题。 我觉得要想想通这个问题，需要几个关键点： 1. 还是要想清楚，中台建设的愿景是什么（会在下一节04中展开），想好中台自己的方向和产品定位，一个清晰的愿景往往就代表了一个好的边界，这个边界能帮我们判断哪些该做哪些不该做，先做什么，后做什么。 2. 要想清楚，就像本文提到的，中台是企业级的问题，中台与前台的划分边界，其实本质上就是企业内横向的平台类组织和纵向的业务类组织的划分边界，也就是组织责任与利益的划分边界。在最后一篇总结篇里，我也会讲到，中台的核心价值就在于企业对于经济性和灵活性的平衡，而组织的碰撞（像你所描述的部门之间的争执），在我看来反而正是企业在不断追求这种平衡的“动作”，是正常的，也是必须的，我甚至认为中台与前台的边界，也只能靠不断的组织碰撞，才能找到一个最佳的平衡点，而这往往也是针对于这家企业整体经济性和灵活性的最佳平衡点。而我们要做的，就是设计一套机制，例如冲突处理升级机制，来正确的引导这种碰撞向解决问题的方向，而不是相反的方向前进。 3. 用演进的眼光来看待，不要奢望，一次想对，一次分对，一次做对，尊重变化，承认自己的弱小，追求变化响应over追求一次做对。 我现在就是用这几个角度来思考，中台与前台的边界的，具体到Action上，就是：想好愿景，合理引导组织碰撞，演进式思维。 希望我的回复，对你有启发和帮组，有问题欢迎继续留言，我们再做深入探讨~

    共 2 条评论
    6
  • Mr_杨
    2019-09-30
    一直关注中台相关的内容，但一直无法准确制定中台，平台，微服务这几个关系和边界。 说说我的理解，比如交易平台，提供的只是交易的通用服务，比如成单，查询，改单，可以认为这是微服务(不知是否准确)。这种服务只是抽象了功能，和交易行为，无法区分不同业务线的交易，这时候就需要中台将业务抽象化，比如外卖，线上，线下交易所需要的流程不同，(线上和外卖需要履约流程），这时候就需要中台将交易业务流程进行组合抽象，对外提供不同业务的执行流程。 总结一下就是微服务或者平台是对功能的抽象，中台是对业务的抽象，欢迎大家给不同意见
    展开

    作者回复: Mr_杨，你好～ 微服务、平台、中台这三个概念确实比较容易混淆，也是大家最关心的问题。 我在本篇中，简单讲了一下我对于平台和中台区别的看法，在07中简单讲了一下微服务和业务中台的区别。 简单讲，从企业架构层面，微服务是技术架构层面的事情，不一定解决的就是业务中台要解决的复用的问题，一个系统为了一些原因例如模块弹性，也可以是微服务架构的。平台和中台都是应用架构层面的事情，中台是平台的发展的下一站，是平台为了更好的赋能前台业务，通过对于自身的不断治理演进，向业务不断靠近，包含更多业务元素业务属性的产物。 这是我到目前的理解，在文中也展开分析和介绍了，希望对你和其他朋友区分开这这几个概念有帮助～

    共 2 条评论
    4
  • Darren
    2019-09-26
    一个中台的构建过程是：功能->系统->平台->中台，我觉得老师的定义特别的棒，看到后恍然大悟，我在上节课的留言虽然和老师定义的‘企业级服用能力’有点类似，但是没有老师的清晰明了，最后稍微补充下，企业级的复用能力，可能各个能力在被复用的时候，或多或少有稍许不同，在中台化实现的时候们，可以通过扩展点去实现。

    作者回复: Darren，你好~ 又见面了哈，感谢你的肯定，尤其是最后的补充，确实非常关键，我看到也有朋友提问问到了如何在复用的时候处理特性需求。 确实一般都是通过业务抽象，加扩展点（SPI，FPI等机制）来实现的，具体的案例我觉得总结篇里我推荐的滴滴的案例讲的非常好，也非常详细，大家感兴趣可以作为扩展阅读。 感谢留言，有好的想法或是反馈可以继续交流~ 下次见。

    4
  • zart
    2019-10-10
    请问老师，白屏化是指啥？

    作者回复: zart，你好~ 可以参考一下10总结篇中分享的《从平台到中台 | Elaticsearch 在蚂蚁金服的实践...》，可以简单理解成给平台类产品做一个配置界面，实现自助式（Self-Service）服务，因为很多平台类的产品都是企业内部使用，所以对于界面没有很强的UI要求，大家一般都是一个白页面，加一些配置项，所以叫白屏哈~

    3
  • 未未的未来
    2019-09-28
    个人理解，中台：满足业务需求的即开即用的工具箱。

    作者回复: 未来的未来，你好～ 我看到这篇留言里，大家都给出了自己对于中台的理解，都非常棒～ 感谢你的分享，你的这个理解很形象哈～ 对于中台，因为其包含的范围太大了，我觉得也很难或是也没必要非要找到一个唯一的理解，在不同的上下文下有不同的解读只要能帮助我们大家对齐共识，朝着同一个方向前进，规避一些问题都是好的。 感谢你的分享，有好的想法还希望能分享出来，我们大家一起学习探讨～

    3
  • Pantheon
    2019-09-28
    平台感觉是可以和业务无关性,比如搭建一个hadoop平台,平台的抽象应该更高,提供这样的一个东西,具体怎么用是使用者的事情,中台的概念是业务相关性,中台是需要承载业务的,比如我现在是在教育公司,也有多个业务线,每条业务线都离不开直播上课的概念,那中台可以下沉上课系统和课表系统,不知道这样理解对不对
    3
  • 水源
    2019-09-26
    我认为某些项目驱动型企业在刚开始的阶段，并不会从全局视角体识别出自己具备哪些可以复用的的“能力”，因为烟囱建的太多了。项目负责人、技术负责人都在围绕各类需求修补烟囱。这时开展中台策略，由于人手问题、项目进度问题，会另大家无从下手。而系统服务化，应该是比较好的切入点，对于烟囱中存在一个或者两个主要通病（痛点）的部分，抓出来进行服务化尝试，使他逐渐演化为中台的一部分，在不影响项目进度的前提下，体会到“能力”的存在。然后再对烟囱逐步拆分，中台化。
    展开

    作者回复: 水源，你好~ 同意你的观点，原来我也认为只有已经烟囱林立的企业，有了痛点，才会意识到全局的治理，也只有这样的企业才需要建中台。 不过后来跟很多产品型互联网企业聊过之后，发现有一些非常有战略思维，对自己的业务和核心竞争力非常清楚的企业，一开始建第一个产品就是用中台的思路去做的，确实令人钦佩，对团队要求也极高，很容易做Over。 而中台的建设思路，一开始一步到位大而全确实比较难，我一般是分成三步：“系统服务化，服务共享化，企业中台化”，以点及面，找到不同干系方的利益结合点，快速见效，逐步推广，产品化运营。 09的时候聊了一些中台运营的思路，也是在想如何通过有限的资源，平滑的在企业内建设与运营推广中台，同时避开组织与利益等相关敏感的问题。 可以到时候有问题再展开交流~感谢留言分享。

    共 3 条评论
    3
  • 108
    2020-08-20
    如果说中台是因为前台和后台之间齿轮速率不匹配导致，而中台是在中间加了一个“变速齿轮”，理论上解决了该问题。 但是随着企业业务发展，中台这个中间件也可能慢慢老化成中后台，后台，如果企业不是因为中台而建设的中台，不把中台概念理解清楚，就还是可能重蹈覆辙。 或者说，中台也只是企业走一步看一步的尝试，到时候中台老化了，再建一个中台，手动狗头。
    展开
    2
  • xiaosui1209
    2019-10-14
    业务中台和数据中台的意义很清晰，但是技术中台呢？企业的技术架构一直以来就是向着平台化组件化演进的，技术架构提供的能力也本来就是企业级可复用的，那么我们为什么要说技术中台这个词，它和企业传统的技术架构的本质区别在哪里？

    作者回复: xiaosui1209，你好～ 就像我文章提到的，技术中台目前还有一些争议，我看到很多的企业在做技术中台和原来的中间件平台本身上也没有太大的区别，所以常被人说只是贴个概念而已…… 但是，如果我觉得中台相比与平台的价值，就是其更贴近业务，从业务视角而不是技术视角出发的话，那如果能通过中台这个概念为驱动力，促使企业的内部技术平台再像业务走出一步，无论是针对用户体验做优化，还是通过产品化，让业务可以自助式（Self-Service）地使用企业技术组件的能力，如果能做到这些或是起到这样的驱动力，我觉得在我眼中技术中台这个概念才有价值。 这里有个好例子就是在10总结篇里我推荐的蚂蚁金服搜索中台的案例，可以下载PPT看一下，他们对于技术平台和技术中台的区分原则。 希望回复能帮助到你，感谢关注，有问题继续交流～

    2
  • 钱
    2020-02-04
    小结： 1：中台 企业级能力复用平台 2：中台建设三部曲 系统服务化，服务共享化，企业中台化 3：中台建设经典问题 把什么放入中台——可复用能力 前中后台的边界——想好愿景，合理引导组织碰撞，演进式思维，感觉这个很难，不由上往下推几无可能，另外，一件事都获益好说，有人获益有人受损，免不了撕逼使绊子，人基本以自身利益最大化为主。 感觉老师说的在理，不过理论归理论，知易行难，大环境或企业文化决定公司运转的效率。成本最小化，价值最大化，是驱动企业更是驱动个人行事的动力，不同的位置一旦利益有冲突，可能出现各种奇葩的事情！这块怎么解决呢？
    展开
    2
  • at三月
    2019-12-20
    # 03 | 中台定义：当我们谈中台时到底在谈些什么？# 『中台就是企业级能力复用平台』——这是我听到最概括、但又是最准确的对中台的定义。原先困扰自己很久的平台和中台的关系，到此刻终于明白：平台只是中台的存在的形式，只要满足企业级、能力复用的基础要求，就能被称为中台，而不管是什么类型的平台。有时越精炼的语言越能直击要点，使人豁然开朗。

    作者回复: at三月，你好~ 看到了你每篇的留言哈，真的是很用心在看，也非常感谢，后边如果有什么问题或是自己的想法也可以留言下来，分享给大家，我们继续交流哈~

    1
  • Peanut
    2019-10-25
    你的企业真的需要中台吗？ --我所在的企业真的很需要中台，比如同一款产品，公司有两个部分在做，也就是两个团队两拨人做同样功能的产品，等到客户需要时，即使整合两款产品，也不能进行数据打通；所以中台不仅仅是解决企业技术架构的问题，还能对公司产品管理起到一些帮助。 如果让你用一句话来给中台下个定义，你会怎么讲？ --老师短短的几个字定义的非常精辟，“企业级能力复用平台” 在你所在的企业，中台是解决方案还是问题本身？ --中台很难在企业推进，如果不是公司自上而下高效的变化，真的很难推进，这涉及到公司组织架构的调整，也涉及到去哪个团队保哪个团队的问题，也就是人的问题其实是推动组织或者技术变革的主要原因。
    展开
    1
  • 文西
    2019-10-13
    老师，我们是一家做外包项目的公司，很多小项目可能功能都差不多，但是每次都是拿之前的代码复制一套再改改，这种需要中台吗？

    作者回复: 文西，你好～ 你觉得这样拿之前的复制一套再改一改会有什么问题么？如果每一个项目都是独立的，这样的方式也是最简单直接有效的方式，那我认为也没有上中台的必要。 如果假设你们的问题是可能之前的代码有bug，一改都得改，那其实把一些组件沉淀下来成为独立的jar就够了，只要做个修改，所有的项目一更新组件版本就可以解决这个问题。 如果假设你的问题是每次再改改的工作是重复的，那也可以看看是不是想办法把这个过程抽象一下，通过一些配置点来实现业务的灵活配置与生成。 而这个平台可能就是你们企业的“中台”，或是其他，都不重要。还是我说的，还是要回到你的问题，去找解决方案。 希望我的回复对你有所帮助～

    共 2 条评论
    1
  • Gopher
    2019-09-30
    老师的见解很深刻、全面，大赞，感谢解惑！～ 花了2个小时来学习这篇文章、查资料、做笔记～如获至宝🤪🤣

    作者回复: Gopher，你好～ 感谢你的肯定，主要是很高兴看到我的内容确实对你有帮助，期待更多分享～ ：）

    1