说透中台
王健
ThoughtWorks首席咨询师
立即订阅
16504 人已学习
课程目录
已完结 13 讲
开篇词 (1讲)
开篇词 | 中台,昙花一现还是下一个风口?
免费
概念篇 (3讲)
01 | 来龙去脉:中台为什么这么火?
02 | 中台种类:你听说的中台真的是中台吗?
03 | 中台定义:当我们谈中台时到底在谈些什么?
落地篇 (7讲)
04 | 万事预则立:中台建设前必须想清楚的四个问题
05 | D4模型:中台规划建设方法论概述
06 | 中台落地第一步:企业战略分解及现状调研(Discovery)
07 | 中台落地第二步:企业数字化全景规划(Define)
08 | 中台落地第三步:中台的规划与设计(Design)
09 | 中台落地第四步:中台的建设与接入(Delivery)
10 | 总结:中台落地工具资源汇总
答疑篇 (2讲)
答疑篇(上) | 你问我答,关于中台还有哪些困惑?
答疑篇(下) | 你问我答,关于中台还有哪些困惑?
说透中台
登录|注册

08 | 中台落地第三步:中台的规划与设计(Design)

王健 2019-09-25
你好,我是王健。
前两讲我们通过 Discovery 结合 Define,完成了 D4 模型中的第一轮在企业级别的发散和收敛。我们站在企业的高度,基于企业愿景和内外部环境,通过自上而下的战略分解和自下而上的现状调研,再应用企业架构方法的分析,来确定最终的平台型企业架构,并回答到底要不要建中台、需要哪些种类的中台建设、谁先建、谁后建这些问题。
那从这一讲开始,我们就要进入 D4 模型的第二轮发散和收敛。站在一个中台产品的视角,来看看到底应该怎样对其设计并落地实施,也就是 D4 中的 Design 和 Delivery 的两个阶段。同样,本讲先从 Design 开始,我们以一个业务中台的设计和实施为样本,讲述一下这个阶段的思路和关键点。
好了,这时候还需要借用一下极客地产的例子。
我们假设,经过了第一轮企业级的的调研与架构设计,小王及其团队发现确实迫切需要构建一个极客地产自己的业务中台,来实现企业 2022 年的战略目标,也就是从重资产业务为主向轻资产的服务业务为主转型,更好地为极客地产的用户群体,即 IT 从业人员提供多场景服务。
那下一个问题就来了,这个业务中台该如何构建呢?业务中台的搭建又需要从何开始呢?
这节课我们就一起探讨下中台部分的具体设计和启动问题。在当前的这个例子,就是对于极客地产的业务中台(后续简称极客中台)的设计过程。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《说透中台》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(11)

  • 贝特
    对于中台的设计,绝大多数场景是基于现有的架构进行重构或者改造,基本上没有针对新项目直接设计中台模式,也就是说中台是软件架构发展过程中的一个迭代产品,所以满足迭代的要求也是在设计阶段必不可少的,例如要解决当前架构中的那些问题,如何兼容当前的接口,兼容当前的业务流,改造之后的中台要提供那些能力,具备那些模式,对成本、人力、技术的要求是什么,这些都需要回答清楚,并作为度量指标,确实挺难得,搞不好就是一地鸡毛。

    不知道理解是否深入,欢迎探讨。
    2019-10-07
    5
  • 业余草
    发现很多公司跟风,为了微服务而微服务,为了中台而中台。中台的劣势是什么?

    作者回复: 业余草,你好~

    好问题哈,中台的劣势比较难回答,我认为如果说中台就是平台型企业架构的话,那简单说我决定劣势有三点:
    1. 原来的一层架构,变为两层架构(中台层和前台层),所以多了一层之后会带来中台与前台两层之间的摩擦,无论是从组织还是从业务上的。

    2. 有了中台,其实会对于前台的业务会有更多的限制,毕竟不能自己爱怎么做怎么做了,需要遵循中台的一些规范或是业务模式限制,所以也会在前台业务的灵活性上受到一些局限(好处是可以借力中台赋能)。

    3. 中台还有一个劣势就是太难推进,太难建设了,我觉得一件事情太难,本身就是最大的劣势,只有容易且收益大的事情,才更容易被实施。

    所以说中台的建设是有成本和副作用的,还是要先想清楚了,自己到底需要不需要,必要不必要,再开始,但一旦开始也要有些决心和耐心,阳光总在风雨后,没有事情能随随便便成功哈~

    2019-10-11
    1
    2
  • 亚东
    突然明白为啥敏捷开发会啥会这么适用于互联网行业了,关键点就在于User Story。这就从一开始就以用户为中心。
    2019-10-09
    1
  • Farewell丶
    我们前段时间的一个项目就是个反例,在前期,由于一个业务线已经开始开发,而我们刚进入设计评审阶段,被大领导建议讨论是否能够合并到一起,做公共的部分后。没有进行充分讨论,被新来的对公司还没有很熟悉的技术总监拍板,“都可以兼容~”。做到现在项目人心低迷,一期上线BUG众多,项目内部到处都是类似IF ELSE的租户兼容逻辑。拖的所有的研发,测试,运维在后边还债。进而引发了部门间,产品和研发以及运维之间的不信任。更进一步的加重了现在整个项目的病情。技术总监已经开始隐身,准备他下一步的计划了,搞中台[捂脸],我好虚~~

    作者回复: Farewell,你好~

    又见面了哈,感谢你分享自己的实例,这样的例子见的太多了……

    中台不是简单的把“看起来差不多”的东西放到一起就可以了的,这其实特别危险,不然没法做到我们说的增加响应力,反而搞不好就会拖慢响应力,中台变成了另一个大泥球和瓶颈点。

    所以中台要做严谨的分析与设计,到底找到那些“看起来差不多”的业务功能背后到底有哪些是相同的那些是不用的,然后通过合理的抽象和设计进行分离,总结篇的滴滴和阿里交易平台都是好例子。

    而如果只是在中台里不停加IFELSE,那其实还不如把逻辑都放回前台的好,响应力可能还更强一些。

    所以我一开始就说了,我们经常把中台想简单了,轻敌了:)

    不过这也算是中台建设过程中大家都会经历的阶段,从现在开始重新做设计和治理改造,应该也还掰的回来。

    期待你的更多留言分享~

    2019-10-01
    1
  • FF
    老师你好。几个问题请教下。确定业务范围那块内容,梳理业务线的时候,没看懂如何梳理聚焦出业务的。讲得有点简单。

    问题一:什么是端到端的业务价值链?如何理解?是横向的业务链?怎样的业务链才算横向的业务链?如何分析端到端的业务链得出结果不需要纳入中台业务范围?

    问题二:与横向相对的就是纵向业务链,聚焦是不是指横、纵向相交的这些业务链?相交的话横向才需要梳理?然后纵向是按愿景来?


    感谢,盼复。因为正好我们有在梳理中台业务需求,这块内容很有价值,望老师详细展开讲讲。

    作者回复: FF,你好~

    这块用文字比较难说清楚哈,我刚在DDD-China2019上分享了一个Topic,叫做《中台规划的7种武器》,在DDD-China官网或是其公众号上应该能搜到相关的keynote下载。(我的知识星球:白话企业数字化中台 中也同步上传了PPT)。

    在PPT里对于中台的切入点选择,业务现状梳理,以及业务设计都有展开描述,感兴趣的话可以搜索下载看一下,应该对你有所帮助,也算是对于这个专栏的后续研究和展现~

    2019-11-25
  • OTM
    中台里面功能 针对不同应用差异化的如何处理,定制化、配置化?
    如果定制,是否又脱离了复用定义;这一块老师能否举个例子
    2019-11-06
  • 产品不是经理
    能不能结合具体的案例,在具体的一点,感觉整个听下来,多半是你的感受,听的云里雾里。

    作者回复: 产品不是经理,你好~

    首先感谢关注和支持哈,没有让你听的特别清楚,确实是我的问题。由于大部分内容是基于我的学习、研究和项目实际经验而来,虽然我尽力说的通用且白话,但是确实难免比较抽象。

    案例的部分,我还在整理,因为目前实际的案例都是客户的资料,就算是脱敏也会有问题,所以我正在尝试虚构出一个完整的案例来,比极客地产更全面,或是直接在极客地产的背景下,做一些包装,把之前碰到的实际问题和解决方法都揉进来。

    这块还需要一些时间,如果我有一些案例的更新,一定及时补充到专栏里,并且通知大家。

    多谢反馈,再次感谢支持和理解,有问题可以继续留言交流~

    2019-10-28
  • 吴志刚
    中台能否真正解决企业内部存在的烟囱问题。中台建设,根据企业愿景对业务进行梳理,分析,抽象,但都会有一个边界,不可能涵盖所有已有的业务线和未来可能出现的业务。那中台也只是作为企业信息化系统中的一员,无法形成大而全的平台,烟囱还是会存在,请老师指点
    2019-10-22
  • Geek_986f8b
    我们梳理业务重叠及可复用性,是不是最后我们中台的能力就是提供这部分可复用的业务接口,包括数据、功能或者流程?而没有重叠,不可复用的部分就不在中台考虑范围之内?

    作者回复: Geek_986f8b,你好~

    这个问题可以归集到什么东西放中台,什么放前台。这个问题我应该已经回答了好几个了,看来大家都比较关注。

    我的观点简单来讲,就是还得先看中台建设的愿景,愿景就决定了中台作为一个产品,做什么,不做什么。

    再基于愿景决定是把“重要的”还是“重复的”还是其他“XX的”功能、数据、流程放到中台里。

    目前大多数想通过中台解决的都是笼统的“去烟囱”,所以大家一般都会像你说的去找共性的,重复的放到中台。但我认为不一定,现在不重复的也不代表以后不重复,而且重复多少算重复,这些都不太好界定。

    所以如果说中台复用的是企业的能力,那复用到底是不是因为简单的“重复”,还得看中台建设的最终目标到底是什么。

    当然你说的也没问题,目前大多数人理解也都是这样的,我只是想在深入一下,因为面上的道理大家都懂,但是一到具体实施就会很难拿捏尺度。

    希望回复对你有所启发~

    2019-10-17
  • 李军军
    如果被复用的组件没设计到足够灵活,修改的成本应该相当可怕吧.

    作者回复: 李军军,你好~

    是的,大家更多的时候把问题想简单了,感觉看上去差不多,直接提出来大家复用,你看响应力就提升了。

    但是我们要想,为什么当时要分出来,可能就是因为“我们不一样”……所以如果把不一样的东西揉在一起,虽然从架构上是统一了,但是反而会相互影响和限制,拖慢双方的响应力。

    所以中台的难点就在于抽象和设计,通过好的分层抽象与设计,尽量好的将共性和个性需求分离开,这也是最见功夫的地方。

    同样,再推荐一下总结篇中的《滴滴出行构建业务中台应对软件复杂度的具体对策与实践》和《跳开 DDD 和中台概念看阿里巴巴交易平台的问题及解决思路》,看看人家是如果来抽象和设计复用组件的,如何实现共性与个性的分离。

    希望回复对你有帮助,如果有问题或是反馈,可以继续探讨~

    2019-09-30
  • 李伟
    企业架构层的业务梳理往往和客户的业务强相关,作为第三方中台建设方或者非业务的技术部门怎么能够理解业务,并且云业务架构的梳理呢?是否需要各个业务部门进来梳理?我感觉这块是难点?要么把业务部门的骨干拉去进来强考核,要么业务部门招聘调动到架构部门!

    作者回复: 李伟,你好~

    你说的点非常准,所有的前提都是对于业务有一个清晰、正确、全面的了解。

    但是作为第三方或是技术部门,想要了解业务必须要想办法协调业务部门的业务专家一起参与。无论是你说的直接把业务部门的骨干拉过来,还是通过内部人员调动。

    回到我们实际的情况,我们作为一个咨询师,一个你提到的第三方中台建设方(虽然我们做咨询,并不把自己当第三方看,进到了客户现场,我们就是客户团队的一员),在中台建设的过程中,一定会要求客户业务方“重度”参与(有的时候,客户的业务骨干会和我们一起封闭风暴2到3周的时间),如果客户方的业务不能协调参与,也能一定程度反映出大家对于中台的理解还有偏差,或是决心不足,我们也不会贸然开始我们的工作(因为脱离业务的业务中台建设时候没有意义的)。

    对于中台来讲,业务是关键。不能撬动业务,深刻理解业务,与业务共情,那中台的建设过程会异常的崎岖,中台的建设效果也会打折扣。

    希望我的回复能帮你理清思路,也感谢留言评论,有问题我们再继续探讨~

    2019-09-27
收起评论
11
返回
顶部