中台详解(下)-怎么搭建中台

本文详细介绍了如何构建中台,从如何划分中台职能,领域驱动设计在中台建模中的应用,到数据治理方案,模块建设顺序,对外服务要点,以及中台的迭代和对企业组织架构的影响。通过专业化分工原则,结合业务目标和领域驱动设计,提供了一套中台建设的实践建议和流程。
摘要由CSDN通过智能技术生成

提示:《中台详解系列》共分上下两篇,本文为下篇,总计约12000字,因为文中涉及知识体系较为广泛,建议预留30-50分钟进行阅读。阅读本文前建议阅读系列上篇——《中台详解(上)-什么是中台?》,点击下方链接即可阅读。

摘要:目前市场仅对“中台”和“平台”间的继承和发展关系有一定共识,“中台”的定义及建设规范尚未有明确定论。本系列文章旨在基于“以终为始”的思维模式,及“软件对现实世界建模”的基础条件,梳理传统软件“平台”所面临的问题,并以此为起点,结合经济学中专业化分工协作理论,为“中台”进行职能定义,再通过“中台”的职能定义给出“中台”建设的建议方案。

阿里云在提出“中台”战略后,仅在一定程度上给出了“数据中台”的建设规范,同时市面上关于“中台”的介绍性文章也都避而不谈“中台”的落地方案,想是仍未统一。本文中,我将主要介绍基于我个人对于“中台”的定义及在“中台”建设方面的经验,总结得出的“中台”总体建设建议方案,不过因为篇幅原因可能不会过于细致,也不会探讨“业务中台”、“数据中台”、“技术中台”在细节上的差别。相关内容主要包括以下几个章节:

  1. 如何划分“中台”
  2. “中台”领域内建模要点
  3. “中台”数据治理方案
  4. “中台”模块间建设顺序
  5. “中台”对外服务要点
  6. “中台”迭代要点
  7. “中台”对组织架构及其协作关系的影响

第一章:如何划分“中台”

要做“中台”,首先自然就是得梳理清楚可以有哪些“中台”。

1.1.原理说明:

我对于“中台”的划分方法是基于“以终为始”的原则及我个人对“中台”的定义总结的,其细则如下:

  • “中台”需要通过专业化分工来解决“软件平台间职能边界划分问题”,专业化分工的本质是一种分类规则,要想分类我们就先得梳理自己有哪些业务功能以及要做哪些业务功能。
  • 所有的软件及其背后的理论、原理、概念、技术都是为了解决业务问题而产生的,所以在梳理“自己有哪些业务功能以及要做哪些业务功能”之前,需要先梳理清楚业务目标,这可以帮助我们评估业务功能梳理及其他工作的合理性。
  • “软件平台”的专业化职能分工所需采用的“能力专业化”的原则,有着“多同一不”的特点(上篇文章有说明),所以建议提炼业务功能中的实体作为后续业务功能“分类”的“锚点”。
  • 将业务功能转化为类图等直观可视的静态模型,可以有效降低思维难度。
  • “中台”的构建需要在企业层面拉通。

1.2.方法选择:领域驱动设计

因为“中台”背负着解决“软件平台间职能边界划分问题”的使命,从这个角度出发,我认为最适合应用于“中台”职能边界梳理的方法是“领域驱动设计”,因为从“领域”这俩字就可以看出来,“领域驱动设计”是为定义职能边界而生的。

不过目前“领域驱动设计”的落地实施方案是由技术人员总结的,主要应用于某个既定领域内的建模,如果我们直接用来进行“中台”的“专业化分工”和“数据唯一性建模”可能不太行。所以针对“中台”的目标特征,我这里借助“领域驱动设计”思想,魔改了一套经验证可行的方案。大家可以简单了解一下。(由于“领域驱动设计”是基于面向对象思想衍生出来的一种建模方法,如果对于面向对象不太熟悉,可能不太看得懂,所以如果实在看不懂建议先跳过本段。)

1.3.人员分工:产品经理主导

基于前文的分析,“平台”间的职能边界划分需要遵循专业化分工原则,所以建议增设“业务架构师”岗主导相关工作,除技术“中台”外,包括“业务中台”、“数据中台”的职能边界划分工作均由产品经理担任“业务架构师”。

1.4.操作方案:

在用本方案进行“中台”划分时,我们大致需要经过两个阶段,共计8个步骤:

(1)第一阶段:

第1-3步为第一个阶段,是由“领域驱动设计”原落地方案中的“事件风暴”环节演变而来。分别为“企业全量业务目标分解”、“企业全量业务功能风暴”和“企业全量业务功能拓展”。

①目标:梳理清楚“中台”所需支持的业务功能边界。

②输出物:企业全量业务功能蓝图(ER图或类图)。

在这里插入图片描述
业务功能版图示例,图片来自网络

③具体流程

1.第一步:企业全量业务目标分解。

(1)在进行业务目标分解时需要优先关心其在商业上的横向拓展。以下为我个人总结的几个拓展点:

  • 上下游业务拓展:比如犀牛制造和菜鸟物流之于淘宝 。
  • 资源变现:比如滴滴搞外卖 。
  • 数据变现:比如抖音、微信的用户标签等 。
  • 流量变现:比如抖音、微信的引流服务等 。

(2)具体到某个业务线、或体系下,业务功能都是通过解决一个一个小问题再最终解决小问题背后的大问题的,所以这里业务目标最好是采用金字塔模型来进行梳理。以营销体系为例:

①营销的最终目标是“卖更多的东西”,其子目标可以分为“让更多人买东西”、“让人买更多东西”;
②“让更多人买东西”的子目标可以继续分为“拉新”、“给用户洗脑”、“推荐合适的商品”;“让人买更多东西”的子目标可以继续分为“给用户洗脑”、“推荐合适的商品”;
③ “给用户洗脑”的子目标又可以继续分为“提升品牌好感度”、“提升产品认知度”、“提升购物积极性”等…
在这里插入图片描述
虽然我们在“中台”设计过程中,业务目标划分的越细越好,不过业务子目标的分解也不是无限制的,最终状态的子目标会有着鲜明的场景化特征,大致可以用以下模型表示。比如:连锁零售商总部营销部门在“女性用户”“非首次”情况下通过“APP”购买“任意”商品时向其发放“肯德基10代金券”,以提高用户通过APP下单的积极性 。 在这里插入图片描述

2.第二步:企业全量业务功能风暴

即对照“业务目标金字塔模型”对已有业务功能进行梳理,输出已有全量业务功能版图。要求精确到实体,在操作本环节时,以下几点需要注意:

在这里插入图片描述
(1)前文说明“数据孤岛”问题时提到过关系数据的重要性,所以在进行已有全量业务功能版图梳理时,关系型实体或字段务必要梳理清楚,不能遗漏,比如订单触发积分发放的记录等。
(2)一般来说因为缺乏专业化职能分工设计,业务系统中会出现大量以下类型的临时方案:
人机交互型临时方案:比如业务场景没有定义好,在使用某服务时由人工录入

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值