深入探讨中台的思想

我的痛点

相信大部分的研发和架构师都有类似的痛点：
痛点: 产品和项目经理经常问我：为啥类似的业务或者业务场景，代码为啥不能复用，为啥那个逻辑不能平移过来，为啥在设计维度没有考虑到这些，为啥原有业务的逻辑加个小功能影响范围这么大。
研发的思维：时间紧任务重 怎么可能考虑到那么通用 多个不同产品怎么可能达到快速复用
结果：造成产品和项目经理嫌弃研发效率，研发觉得都是压榨，上层压根不懂下层

我的思维

我是技术出身，在作为研发时候我完全是上面的研发思维，觉得做到功能级别复用已经很不容易，当自己做到研发经理的初期：我还是一直保持这这种思维模式。
当我看到DDD和中台的概念之后，我的思维模式发生质的变化
思维的改变：
DDD：可以让我的业务领域化，收敛我们的核心领域(业务) 达到业务维度的共识
中台：基于敏捷，精益开发，DDD 做到企业级能力复用平台 (这也为我们 不同产品核心或者相近业务领域 复用成为可能)

阐述中台的概念

DDD 之前也是有文章分享过的，下面主要介绍中台概念 和落地

1. 中台的概念首先是源自于阿里 现在阿里也是大幅度招聘国际化中台的人才，目标是解决烟囱式的系统架构 (重复 无法重构升级的系统架构)
2. 中台分为主流和非主流
   主流: 业务数据双中台
   

• 业务中台
  我们常提到的业务中台，可以理解成狭义的业务中台，通过将不同业务线解决相同问题域的解决方案进行抽象与封装，通过配置化、插件化、服务化等机制兼顾各条业务线的特性需求，实现对于不同业务线的业务支撑。
• 数据中台
  业务中台就是在产生数据，数据中台是做数据的二次加工，并将结果再服务于业务，为业务进行数据和智能的赋能。

非主流

• 技术中台
  将使用云或其他基础设施的能力、各种技术中间件的能力进行整合和包装。过滤掉技术细节，提供简单一致、易于使用的应用技术基础设施的能力接口，助力前台和业务中台、数据中台的快速建设

• 研发中台

  关注开发效能管理的平台叫作研发中台

• 移动中台
  在移动互联网时代，移动优先的原则已经成为不争的事实，将 App 开发过程中的通用技术组件进行封装沉淀到移动中台中，就可以在构建新的 App 时大量复用已有组件和能力，快速构建和响应。管理中台

• 管理中台
  最近很多企业开始尝试把中台思维应用到企业内部，重新对“人”“事”“流程”“企业运营”进行平台化 / 中台化改造。

• 组织中台
  真正从组织和制度上支撑前台组织和应用的快速迭代和规模化创新。

严格来说只有业务中台；但凡没有业务场景只提供IT能力的，类似技术，研发，算法这类服务不能称为中台，中台是为解决前台创新速度和重复造轮子的问题，是否业务复用是一个很重要的判断标准；

主要解决的问题是：了解决“齿轮匹配失衡”的问题 前台变化创新速度 和 后台变化速度慢 不匹配问题

作为研发经理，很有这种感受，每次前端开发进度都是100% 而后端还是在开发中，导致整体的进度严重阻塞。中台就是将后端核心业务复用 达到快速匹配前端，同样在不同的产品线类似的业务中 中台作用十分巨大

对中台的定义:企业级能力复用平台

• 企业级”定义了中台的范围，区分开了单系统的服务化与微服务； “能力”定义了中台的主要承载对象，能力的抽象解释了各种各样中台的存在；
• “复用”定义了中台的核心价值，传统的平台化对于易复用性和前台的用户体验并没有给予足够的关注，中台的提出和兴起，让人们通过可复用性将目光更多的从平台内部设计转换到平台对于前台业务的支撑上；
• “平台”定义了中台的主要形式，区别于传统的应用系统拼凑的方式，通过对于更细粒度能力的识别与平台化沉淀，实现企业能力的柔性复用，更好地支撑前台业务。

落地的问题

例子：我们做云平台，需要上线 各种数据库产品，每种产品有很多相似和不同的地方，就是说每个产品有共同性和特性，怎么运用中台的思想，提取出来我们共性的业务特性，中台化。 -- 注：我这里只是用部分中台的概念，并没有达到解决企业级问题的例子

1. 如何建设: 了解产品的愿景
   
   我上述愿景：能提供新的产品线在云平台快速上线的能力，并且可以高度复用已有的核心业务
   参考的是ThoughtWorks的D4模型，下面先介绍D4模型，有点偏理论，需要大家自己按照自己特点进行改造
   中台规划建设方法论：D4 模型

• 第一个阶段是Discovery，帮助我们在中台规划前先建立全局视野。在这个过程中我们以企业愿景和战略为输入，结合行业趋势、竞争对手分析、用户客群分析 、业务现状分析、IT 资产盘点，全方位多角度地理解企业的战略市场环境以及业务及 IT 全貌，帮助我们做出最正确的判断。

• 第二个阶段是Define，帮助我们基于之前 Discovery 发散的各维度信息进行收敛与分析， 对于中台的架构进行定义。通过对跨业务线的业务梳理进行重合度分析，并结合领域分析对业务表象之后的企业核心问题域做进一步展开和重合度分析，一起来收敛推导基于中台的企业架构设计。并基于多维度的打分，形成具体的实施路径规划，说白了就是先做什么后做什么。这里需要注意一点，此时收敛的是仍是企业架构层面，像业务中台、数据中台这种级别的产品，可能只是实施路径中的一个项目，在这个阶段也可以回答那个我们关心的问题，我们到底需不需要中台，需要哪些中台？

– 上面2个阶段是判断是否需要建设中台 建设哪些中台

• 第三个阶段是Design，帮助我们针对实施路径中的某一个产品，例如业务中台，做详细的设计，包括产品级的业务需求分析、功能及架构设计、实施计划等。例如对于业务中台产品，在 Design 阶段我们需要回答产品的愿景、边界、产品形态、技术架构、交付计划、成本预估等等，这个过程就是一个标准的产品设计过程，只不过在中台项目中大多是针对中台类的产品而已。

电梯演讲 – 主要是限定了几个产品最关键因素，比如用户是谁，解决什么问题，差异化特点是什么等等。

• 第四个阶段就是Delivery，这个时候我们就可以针对一个设计好的中台，开始具体的交付过程，我们采用的是敏捷结合精益软件开发的方式，用快速迭代和基于反馈的调整，最大程度地弥补由中台建设本身的复杂度带来的设计偏差和其他的交付问题，并且注重架构的治理与守护，减少实现与设计的偏离。