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

07 | 中台落地第二步：企业数字化全景规划（Define）

07 | 中台落地第二步：企业数字化全景规划（Define）-极客时间

07 | 中台落地第二步：企业数字化全景规划（Define）

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

讲述：王健

时长21:34大小19.74M

你好，我是王健。
上一讲，我们通过 Discovery 从三个不同的角度和方向，对企业内外部环境进行充分的信息收集之后，得到了非常多的信息。那这一讲我们就来讲一讲，如何通过对这些信息的分析和收敛，运用企业架构方法，最终分析形成企业的数字化全景规划，并最终推导出我们 PD 的一个重要产出物，也就是一个中台落地建设的演进路线图。
那首先需要给你介绍一下什么是企业级架构方法。

企业级架构方法

企业架构方法如 Zachman、TOGAF 等，最长的已经有 20 多年的历史了，可以说已经非常成熟了。其中应用最广的应该就属 TOGAF 了，在市场上占据了至少半壁江山，也最为我们所了解。TOGAF 的基本思路，就是从企业最新的愿景战略以及运营模式出发，设计企业的 To-Be 业务架构，然后依次推导，一步一步推导数据架构、应用架构、技术架构，就是这样一个过程。
我们现在在做以中台为潜在预设目标的企业数字化全景规划时，也参考了 TOGAF 的这个思路，基于 Discovery 发散收集来的各个维度的信息，在 Define 阶段结合自上而下企业战略分解的举措和自下而上现有业务架构梳理和分析的问题及痛点，重新设计新的业务架构，并进一步推导出其它的相关的架构设计。
只不过相对于传统的企业架构方法，整个过程做了剪裁和轻量化处理，引入了事件风暴、DDD 工作坊等协作互动形式，整个过程各个关键角色充分讨论，协作共创，力争在过程的轻量前提下，还能保证结果的准确与一致。
但这里有一个关键点，因为前面提到过中台从架构层面就是平台型的企业架构，那对比过去我们常做的系统型企业架构，如何从企业整体的视角，更准确地识别出多业务线之间的共性业务元素，对我们来讲也是个不小的新挑战。
为了解决这个问题，前面讲方法论概述的时候其实已经提到过，我们是在整个企业架构设计的过程中融入了领域驱动设计（DDD），结合事件风暴，对业务流程背后的问题域进行分析，以及通过不同业务线的问题域重合度分析，帮助我们透过流程洞见企业各业务的本质，寻找共性业务元素。
给这个过程做个比喻，就像是给业务照了一个 B 超一样，帮助我们更好地透过现象看到内在的实质。
对于企业架构方法，例如 TOGAF 的相关资料比较多，这里就不展开了，我在最后的总结里会给你一些参考资料，你可以进一步拓展阅读。
那利用剩下的篇幅，我想着重讲一些在企业架构设计实施过程中与中台相关的常见问题。

中台复用的能力类型到底有几种？

第一个问题，如果说中台就是企业级能力复用平台，那在做企业架构设计的过程中：
我们到底要在不同业务线中寻找哪几类共性能力？
我们经常讲的业务中台中的业务到底又具体指的是什么呢？
那为什么中台一般都是业务、数据、技术这三者的组合呢？
为了回答这几个问题，先来给你看一个模型：
这是哈佛大学出版社 2006 年出版的一本讲企业架构战略的书里提到的一个商业运营模型（Business Operating Model），它提出两个象限：
横轴代表标准化（Standardization），标准化越高，你可以简单理解成企业就是通过业务模式（业务功能 + 业务流程）的复用实现业务线的扩展。比如像电商网站的各个垂直网站，或是全球化，都是通过将电商的业务模式复用，通过复用到不同的垂直领域，或是不同的地区来实现不同业务线的扩展。
纵轴代表集成（Integration），也可以理解成数据集成，这种运营模式的企业就是通过对数据的复用，来实现业务线的扩展的。比如最常见的像腾讯，通过对微信用户数据的集成和复用（导流），来帮助新的业务线（例如游戏）快速扩展。
那为什么要提到这个模型呢，因为这里的“商业运营模型”就很像我们中台里的能力复用方式，即你复用的到底是业务模式；还是复用的是业务数据；还是两者都不是，只是复用了更底层的技术部分。
我来稍微解释一下。
如果两条业务线，数据也是一套，业务流程也一模一样，那很简单，它们其实就可以共用一套系统，这也就是我们最常见的大单体系统。但这越来越成为一个反模式，除非在一些标准化极高的场景，例如核心财务系统。
如果两个不同的业务线之间，业务模式很相似，但是数据反而需要隔离开，那就是右下的区域。一般可以通过业务中台来沉淀通用抽象的业务流程，或者直接使用多租户的企业内部 SaaS 来实现业务模式的复用。在这个象限，业务中台与 SaaS 的区别只是抽象粒度和层次的不同，本质上要解决的问题都是一样的，即业务模式复用。
SaaS 抽象层次高，更靠近业务，但对于业务的标准化要求高，灵活度小。业务中台正好反之，抽象层次较 SaaS 低，介于 PaaS 和 SaaS 之间（所以很多企业管业务中台叫 ApplicationPaaS，或是 BussinessPaaS），离业务较 SaaS 远一些，但更灵活。这也回答了很多人困扰的业务中台与 SaaS 的区别问题。
这里可以多说一句，国外最近出现了一种 Headless Commerce（无头电商），去年也出现过 Headless CMS。我认为这波国外 Headless 的趋势，就很像是国内的中台一样，也是在 PaaS 和 SaaS 之间在找到一个新的抽象层次而已。
好，说完了右下，再来说左上，指的是那些虽然业务模式不同，但是可以通过数据的集成、打通与复用来实现业务线扩展的场景，一般也可以通过业务中台和数据中台来解决。因为业务中台里承载的也有数据，或是说业务中台生产的就是业务数据。
而前面提到过，数据中台则是对于业务中台生产的数据，进行二次加工，例如一些大数据计算、跨域的业务数据整合计算或是一些 AI 赋能场景。
好了，希望通过上述的分析，能帮你理解这些不同中台（包括业务中台，数据中台，技术中台，以及业务中台与 SaaS，业务中台与数据中台）的概念和差别。
而回到一开始的问题，我们到底要在不同业务线中寻找哪几类共性能力？现在也非常清晰了，总结下来基本上就是四类：业务数据、业务功能、业务流程以及通用的技术能力。

通过领域分析识别共性能力

既然企业可复用的能力就是以上这四大类，那抛开相对独立的技术能力不谈，对于剩下的业务数据、业务功能和业务流程三类共性业务能力，具体来说，我们要如何识别呢？
还是举极客地产的例子，对于物业业务线和长租公寓业务线这两条业务线，表面上看起来解决的是完全不同的问题。但是这并不能代表这两条业务线之间没有业务数据、业务功能或是业务流程复用的场景呀，比如最直接的就是打通连接物业的业主数据和长租公寓的用户数据，通过例如最简单的积分机制共享，来实现物业业主向长租公寓用户的转化，实现用户的导流和新业务热启动，加速新兴业务的快速发展。
那到底怎么才能透过业务流程识别出有哪些类似的能力复用场景呢？没错，就是领域驱动设计（DDD）。
我们就是对于已经梳理的业务，又深入了一层，使用领域驱动设计结合事件风暴（EventStorming）这两个工具，通过工作坊的形式来对业务流程背后的问题空间和解空间做进一步的分析，识别出关键聚合，再通过跨业务线的问题域叠加投影，找出大家共同关注的问题空间和聚合，从而继续扩展来做共性场景和能力识别。
这里我说了很多词，像问题空间、解空间、问题域、聚合，这些都是 DDD 的常用术语，很好理解。如果你还不熟悉 DDD，建议先自己查一查再回来看。当然了，专栏最后的总结部分我也会给你推荐一些相关的学习资料。
而整个过程也是采用头脑风暴和工作坊的形式。
回到极客地产的例子，大家在一起充分讨论，展开对物业业务线和长租公寓业务线的事件风暴，结合领域驱动设计战略部分的问题域分析以及聚合分析，我们就能知道这两个不同的业务线，有哪些问题空间是重合的，比如客户域或是运营域的部分。
然后再对问题域展开，就能识别到在这些重合的问题空间下，到底有哪些共性的业务数据、业务功能和业务流程，从而完成复用能力的识别。

中台与微服务有什么区别和联系?

说完了业务，我们再来谈谈在技术架构设计中，大家最关心也是同样感到困扰的另外一个问题，就是业务中台与微服务架构有什么关系？这也是谈及中台时经常会被问到的问题，至少能排到 Top5 里，正好讲到技术架构部分，我稍微谈一下我的理解。
先给出我的答案：这俩没关系！
是不是有点反直觉，毕竟这两个概念经常被一起提，很多讲业务中台的书讲到技术架构也都在讲微服务，你怎么说这俩没关系呢？
别急，且听我慢慢道来。
总的来说，业务中台与微服务解决的是不同的问题，也处于不同的抽象层次。
前面提到了业务中台解决的是业务领域的业务（数据、功能、流程）复用的问题，而微服务架构作为一种轻量级分布式技术架构，解决的是技术领域的“组件编译时依赖”造成的问题。
而且业务中台不一定是微服务架构的，微服务架构也不一定是为了解决能力复用的问题。
首先来看业务中台。业务中台要解决的是业务能力如何快速复用的问题，就算背后是一个大单体，只要暴露出来的 API 能够满足业务能力快速复用的目的也是可以的。这个很容易理解，那我就着重解释一下我对于微服务架构的看法。
提到微服务，不得不说目前被业界普遍接受并采用的我司首席科学家 Martin Fowler 给微服务下的定义：
这里边有个关键点，我认为没有引起大家足够的重视，以致于我认为目前市面上绝大多数的号称微服务架构的系统从老马的定义上来看，都是伪微服务架构。这个关键点就是“能够被独立地部署”，我认为翻译成“能够被独立地交付”更贴切，而这点也是我认为评判一个微服务架构是否能发挥其价值的关键因素。
这也是我前边提到的“组件编译时依赖”的问题。其实组件化一直是大家都追求的，例如我们常见的 jar 包和各种开源的组件本身就是很好的组件化封装。微服务从技术上看无非是将组件间的依赖点从“编译时”推后到了“运行时”而已。
不要小看这一点变化，带来的好处是非常多的。因为依赖被推迟到了“运行时”，才可能实现类似于“组件独立交付”、“组件运行时动态扩展”、“组件技术异构”等好处，但同样也需要承担分布式架构带来的复杂度作为代价。
那为什么说大多数的微服务架构都是伪的呢？因为有集成测试或其他因素存在，导致实际上并没有做到真正的独立交付（注意不是部署）。为此我还写过一篇文章《你的微服务敢独立交付么？》，讲的就是如何在不需要集成测试的情况下，利用契约测试的策略设计真正实现微服务的独立交付，充分释放微服务架构的价值，有兴趣的话可以看一看。
还有微服务架构要想真正发挥价值，主要一点就是其中的“服务”要做到足够稳定（说来容易做起来具难）。
所以，业务中台与微服务架构并没有啥直接关系，只是因为微服务架构运行时依赖的低耦合特性，通常被用于实现业务中台中不同能力单元的团队分离、技术分离、交付周期分离等特性而已，只能算是一对好搭档。

平台型企业架构设计概览

最后我们还是快速过一遍，一个完整的平台型企业架构的规划过程。
1. 首先通过各条业务线的现有业务架构分析，再结合识别的痛点做的根因分析，做业务架构上的改进与设计，从而对于现有的业务架构进行改进，设计出新的改进后的业务架构，解决现在痛点背后的问题。
2. 同时还要参考战略分解后对于各条业务线的目标和举措，融入 To-Be 业务架构的设计当中，使新的业务架构设计同时匹配企业战略要求以及解决短期战术痛点。
3. 对于改进后的业务架构，做跨业务线的比对和分析，就能帮助我们发现不同业务线的业务功能及业务流程的重叠情况，为后续中台建设的必要性判断提供业务层面上的支撑和输入。
4. 使用领域驱动设计（DDD）的战略部分，针对于每条业务线，做问题域和限界上下文分析，以及关键聚合的识别，从而试图穿越流程，从领域的角度深入一层审视业务的本质，到底是在解决哪些问题空间的问题，并通过问题域的划分（核心、通用、支撑），区分问题空间对于企业的重要性。
5. 类似于业务架构，同样对于各条业务线分析出来的领域分析视图，做横向比对和投影，从领域层识别不同的业务线中的问题域、限界上下文以及聚合的重合度。这么可能比较抽象，你可以理解成类似于将几张半透明的画摞在一起，来找相交部分一样。帮助我们识别业务数据以及业务模式（功能 + 流程）上的深层次共性能力。
6. 结合现有的业务架构及应用架构，做各条线的应用架构设计改进，并通过 As-is 和 To-Be 的应用架构做 Gap 分析，产出 IT 建设的具体机会点，这样的机会点就类似于新建一个 CRM 系统之类的。
7. 再基于跨域的业务架构分析和跨域的领域分析，讨论判断多条业务线的业务重合度，并详细识别重合更多是在业务模式级别的重合（出行、电商）、业务功能级别的重合（登录，购物车）、还是业务领域（用户数据打通）级别的重合。基于讨论结果，决定是否有必要引入中台层建设，以及根据重合情况，详细展开规划中台层的应用架构。
8. 最后再分析当前现状与 To-Be 的最终规划之间的差距，产出具体的机会点列表，并且基于多维度（常见的例如战略重要性、紧急程度、成本、资源就绪情况、技术就绪情况、风险、痛点 Mapping 等）做优先级排序，产生最终的路线图。

总结思考

通过本讲与上一讲对于一个完整 Discovery 和 Define 过程的讲解，我们就完成了一个从行业和企业战略目标及愿景出发，到最终形成基于中台的企业级架构的完整过程。当然这个过程要比文字描述的复杂得多，不过通过讲述，希望你能建立一个平台型企业级架构梳理的全貌。
看到此时，你可能会问，我只是想做个中台，需要搞这么麻烦的战略规划吗？
我的回答非常肯定：非常必要。
因为从我经历的很多实际的中台建设案例来看，很多都是因为缺少了这样一个 Discovery 和 Define 的过程，导致中台的建设目标非常模糊，只有一些高大上的口号，并没有想清楚到底需不需要建设中台，以及中台建设到底对于企业代表着什么。
还有些情况，当我们最后收敛后，发现虽然中台建设的必要性是存在的，但是对于当前企业和行业的现状，并不是优先级最高的事情，或是并不具备相关条件，这个时候贸然开展中台建设也是非常危险的。
只有到这里，通过 Discovery 和 Define 的分析，得出我们确实需要一个业务中台，并且优先级也非常高，那接下来如何建设业务中台呢？下一讲我继续为你带来第二层的发散（Design）与收敛（Delivery）。
最后给你留几个思考题：
你之前听说、了解或使用过企业架构方法吗？
你有使用企业架构的方法来做中台的整体规划吗？
在企业级的中台规划层面你有什么问题和经验可以分享吗？
欢迎在留言区发表你的观点，也欢迎你把今天的内容分享给身边的朋友，我们下一讲见！
分享给需要的人，Ta购买本课程，你将得9元
生成海报并分享

赞 4

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
06 | 中台落地第一步：企业战略分解及现状调研（Discovery）
下一篇
08 | 中台落地第三步：中台的规划与设计（Design）
unpreview
 写留言

精选留言(28)

  • 阿神
    置顶
    2019-10-10
    我目前在一个化妆品企业，产品在各大电商平台销售，同时也有自建电商平台（app），我们在18年底开始中台化建设，走了一些弯路，这里分享下经验。在中台化改造之前，我们已经搭建了微服务开发平台，并在团队引入了领域驱动设计的理念。然后我们期望设计一套中台，再来改造遗留系统，但我们设计中台时对中台理解不够，对一些企业内部的业务系统，比如OMS也进行中台服务的拆解，这样导致设计的一些中台服务就这个OMS使用，能力上是不需要复用的，也就是并没有多个产品线来使用（未来也不会），辛亏这些设计还没有进入开发阶段，及时刹车，调整设计方案，把不需要服用的功能合并，实际上OMS本身就是一个中台应用，根本不需要拆细了；同时我们重点对于多个前台应用的能力进行分析和服务拆分（利用DDD方法拆分），最终我们的中台服务是满足多套前台应用使用的。所以我对中台是企业级能力复用这个很有感触，同时中台一定是考虑服务前台应用的，因为前台应用才可能有多套产品线，企业内部的业务系统一般是不需要基于现有的中台来搭建，因为这类系统就一个，本身属于一个中台应用，能够被前台应用来使用。当前企业内部的业务系统是可以基于技术中台来搭建，这个是没问题的，技术中台会提供开发平台，登录服务，短信服务等一些业务无关的组件，不论是前台应用还是内部业务系统都能使用。
    展开
    共 1 条评论
    32
  • 槿
    2019-09-30
    中台跟平台到底什么区别，这个概念感觉很模糊

    作者回复: 槿，你好～ 这是个好问题，这两个概念也确实模糊，很多企业做的中台和之前做平台也没什么两样。但我觉得还是有些区别的，我先引用阿里行癫在一次采访中对于这个问题的解释： 行癫：原来阿里是个平台，我也做过两年中台，我一直在琢磨中台跟平台到底有什么区别。像阿里巴巴、淘宝、天猫这种平台只要搭好了，客户直接开店就可以了，不需要关心任何事情，但我觉得中台不一样，中台自己单独的产品不能直接产生价值、不能直接对外服务，一定要变成别人产品的一部分，让别人的产品提供更好的服务，这是我理解的中台。 当然这个解释也有很多的背景和上下文，就是阿里刚提出的“被集成”。 但我觉得这个解释也能一定程度上区分出这两个概念，这也是为什么我觉得平台更多是去重，是整合，是你不要做了，来我这儿做；而中台更多是复用，是赋能，是被集成，是你还是自己做吧，但我有这些能力能帮到你，你要不试试？ 也正是因为视角的变化，为了争取更多的“用户”，更好的为前台服务，也让中台更多从前台出发，从业务出发，也自然会包含更多的业务属性和业务封装。 所以我认为平台和中台的区别不再表现形式上，而主要在视角的区别上，视角的不同也会导致边界的不同，走上完全不同的道路。 不知道说的是否清楚，是否能解答你心中的疑惑。如果还有问题，欢迎继续留言，我们继续探讨～

    共 2 条评论
    34
  • 雪飞
    2019-10-11
    老师，您好，是否可以提供一些每个阶段的成果产出物示例，这样方便我们理解每一个阶段具体要做的事情，谢谢！
    8
  • 每天晒白牙
    2019-09-26
    我以为我做的就是中台，看完感觉不是

    作者回复: 每天晒白牙，你好~ 是不是中台不重要哈，解决没解决问题才重要，在我看来中台解决的是企业级能力复用的问题，但是反过来不一定成立，企业级的能力复用也不一定只能通过平台化或是中台化来解决，可能有更简单的方式，例如集成在某些情况下可能是更有效率的解决方式，活学活用：）

    6
  • 下一道彩虹
    2019-09-29
    王健老师好。在本节中，我有两个问题想与老师请教一下。一、本节标题“企业数字化全景规划” 与本节总结前的一个主题“平台型企业架构设计”是什么关系？个人感觉是说的同一过程，但又好像后者更具体一些，是前者的一个显相化裁剪落地版本。还请老师点拨点拨。二、“平台型企来架构设计”过程的第5步和第7步的看起来很相似，其区别和联系又是什么呢？

    作者回复: 下一道彩虹，你好~ 感谢评论留言，您看的很细哈。针对问题我试着回复一下： 一、可以做个类比，清楚一些。如果说TOGAF是“企业架构的设计方法”（EA）的话；那D4就是我们裁剪改良版的“平台型企业架构设计方法”（PBEA）。而本节，既“企业数字化全景规划”主要是在讲第二个D，Define的过程，也就是基于上一节收集的信息做一次收敛，形成业务架构、应用架构、技术架构…的过程。 二、如果您指的第五步和第七部就是“IT资产盘点”和“企业架构设计”的话，那第五步更多调研的是现状（As-Is）；而第七部更多设计的是蓝图（To-Be），需要结合前六步的所有信息，而IT现状只是参考信息的一个方面而已。 希望回复对您理解有帮助，如果我理解错了问题，或是还是没有讲清楚，您可以继续留言，我们再深入探讨~

    4
  • Jade
    2019-12-27
    SaaS 抽象层次高，更靠近业务，但对于业务的标准化要求高，灵活度小。业务中台正好反之，抽象层次较 SaaS 低，介于 PaaS 和 SaaS 之间（所以很多企业管业务中台叫 ApplicationPaaS，或是 BussinessPaaS），离业务较 SaaS 远一些，但更灵活。这也回答了很多人困扰的业务中台与 SaaS 的区别问题。 这部分是不是说反了？ SAAS应该是业务的具体实现，更加细节具体一些；而中台各业务线通用的部分，更加抽象，具体实现交给应用去组合和编排。
    展开
    3
  • 清风逸
    2021-04-27
    银行业务核心系统也是能力的复用，请问和中台有什么区别？
  • 大漠孤烟
    2020-03-19
    微服务的架构很适合做中台，但做中台不一定非要用微服务。
    共 1 条评论
    1
  • Jeremy King
    2019-10-14
    你好，文中提到微服务是由单一应用划分成很多小服务，而我们常见的一个应用能提供多个微服务（）请问微服务到底是指一个应用，还是应用里面的某个服务？

    作者回复: Jeremy King，你好～ 一般一个微服务指的是应用中的某个服务，是一系列API（广义）的集合，多个应用也可以share一个或多个服务～

    共 2 条评论
    1
  • 电光火石
    2019-10-11
    一看完之后最直观的感受中台不是解决技术问题，而是解决业务问题，抽取企业不同业务线的共同点，形成中台，为业务的快速推进服务
    1
  • 睁眼看世界
    2019-10-11
    感觉做一个好的中台离不开好的项目管理

    作者回复: 守候，你好~ 说的是，我看了一些回复，也发现，我讲的更多是从项目管理，产品管理，企业架构的层面来谈中台，可能是因为我决定中台就应该落在这个层面上。 而且不光是项目管理，甚至需要跳出项目内，从更高一个维度，比如项目间协调，产品间协调的角度来看待，如果只是从技术出发，很容易陷入到管理和组织旋涡里。 感谢你的分享，随时继续探讨~

    2
  • ちよくん
    2021-09-14
    谁是对谁是错？中台只是一个名词，一千个人理解都有一千个答案，只是你对中台的理解是这样，难道就是标准答案？
  • 极客侠女
    2021-09-07
    中台的技术实现，不一定是云架构，对吗？即使是单体分层架构，只要暴露的API能够满足业务能力快速复用就可以嘛？即，在单体分层架构下，将模型的能力通过RESTful API暴露。
  • 海牛
    2021-08-25
    老师，中台到底是企业架构的全部，还是其中的应用架构或者技术架构呢？我理解是用企业架构方法去规划和设计，然后最终它是应用架构，然后用技术架构来实现？
  • lorexiao
    2020-11-27
    现在讲中台，总会带上数据治理。请问二者关系如何
  • 风
    2020-11-07
    企业架构方法第一次听到，知识还真是太匮乏啦
  • 直念去
    2020-08-04
    干货满满, 赞【表情】一个!
  • .
    2020-02-27
    业务功能和业务副用如何理解？
  • 钱
    2020-02-05
    微服务从技术上看无非是将组件间的依赖点从“编译时”推后到了“运行时”而已——这个诠释，很经典。 回想自己做的事情，核心就是一些基础的微服务，具体他们的价值几何，完全不是我来决定的，看调用方是谁？看调用量多少？看服务了多少订单？只要涉及商祥、结算以及覆盖了足够多的订单类型，那对应的微服务就是有价值的，否则就无关紧要了，从这一点出发，我们确实有些像中台了，我们需要被集成，需要被各个流量入口复用，我们的价值由集成者决定。
    展开
  • 文正
    2019-11-20
    服务的技术实现其实很简单，难的是这个思想的运用，业务的隔离程度有多深，我觉得极端点的就是通过数据库是否独立来判断。