中台学习
<h2>一、背景</h2>
<p>烟囱式的系统架构，造成了大量的重复建设和资源浪费 ——> 将重复的组织和系统进行整合，将各个前台系统中的公共部分进行平台化改造。</p>
<h2>二、中台种类</h2>
<p>业务中台与数据中台相辅相成，互相支撑，互为输入输出。业务中台承载了企业的通用业务能力，为多业务线赋能；数据中台通过对于业务数据的二次加工，并反馈回业务中台，为业务进行数据和智能方面的赋能。</p>
<h4>1. 业务中台</h4>
<p>通过将不同业务线解决相同问题域的解决方案进行抽象与封装，通过配置化、插件化、服务化等机制兼顾各条业务线的特性需求，实现对于不同业务线的业务支撑。</p>
<pre><code>狭义层面的业务概念，业务中台需要具体承载支撑业务开展的必要业务元素，封装着为了保障业务可以顺利开展需要解决的必要问题空间的解决方案。</code></pre>
<h4>2. 数据中台</h4>
<p>数据中台是做数据的二次加工，并将结果再服务于业务，为业务进行数据和智能的赋能（By 谢纯良 阿里巴巴技术方案总监）</p>
<pre><code>数据中台与传统数仓和数据平台的区别，关键在于数据中台相对于数仓、大数据平台，向前台、向业务又迈出了一步，不再只是关心技术层面大数据底座的打造，同时开始更多地关注企业层面的数据治理以及数据资产化的内容：包括但不限于数据的资产化管理（质量、成本、安全），数据服务的构建，数据的体系化建设（统一模型和指标）等。</code></pre>
<h4>3. 其他中台</h4>
<ul>
<li>
<p>技术中台
将使用云或其他基础设施的能力、各种技术中间件的能力进行整合和包装。过滤掉技术细节，提供简单一致、易于使用的应用技术基础设施的能力接口，助力前台和业务中台、数据中台的快速建设</p>
</li>
<li>
<p>研发中台
关注开发效能管理的平台：将企业的开发流程、最佳实践沉淀成可重用的“能力”</p>
</li>
<li>
<p>移动中台
App开发过程中的通用技术组件进行封装沉淀，在构建新的 App 时大量复用已有组件和能力，快速构建和响应</p>
</li>
<li>
<p>管理中台
对“人”“事”“流程”“企业运营”进行平台化 / 中台化改造，加速企业管理标准化和提升运营能力</p>
</li>
<li>组织中台
为前台组织和团队构建创新型前台应用提供类似于投资评估（项目甄别）、投资管理、投后管理（孵化与风控），真正从组织和制度上支撑前台组织和应用的快速迭代和规模化创新</li>
</ul>
<h2>三、中台定义----企业级能力复用平台</h2>
<pre><code>## 前台
由各类前台系统组成的前端业务平台。每个前台系统都是一个用户触点，大多是企业最终用户直接使用的系统，是企业与最终用户的交点。例如用户直接使用的网站、手机 App、微信公众号、小程序等都属于前台范畴
##后台
由后台系统组成的后端支撑平台。每个后台系统一般管理了企业的一类核心资源（数据 + 计算），例如财务系统、产品系统、客户管理系统、仓库物流管理系统等，这类系统构成了企业的后台。</code></pre>
<p>前台和后台就像是两个不同转速的齿轮，前台由于要快速响应前端用户的需求，讲究的是快速迭代创新，所以要求转速越快越好；而后台由于面对的是相对稳定的企业核心后端资源，而且往往系统陈旧复杂，甚至还受到法律法规、审计等相关合规约束，一般是追求稳定至上，越稳定越好， 转速也自然是越慢越安全。
企业业务不断发展壮大，后台修改的成本和风险越来越⾼，这就驱使我们尽量保持后台系统的稳定性，但同时还要响应用户持续不断的需求，最自然的就是将大量的业务逻辑（业务能力）直接塞到前台系统中，因为前台离用户近，响应也相对快。但是这样也是有代价的，这样的后果就是引入重复，同时还导致前台系统不断膨胀，变得臃肿，形成了一个个大泥球的“烟囱式单体应用”。这个局面的结果就是，前台系统的“用户响应力”被渐渐拖垮，用户满意度逐渐降低，企业竞争力也随之不断下降。</p>
<h4>中台就像是在前台与后台之间添加的⼀组“变速齿轮”，将前台与后台的速率进行匹配，是前台与后台的桥梁和润滑剂。它为前台而生，易于前台使用，将后台资源顺滑地通过前台导流向用户，支撑企业更好地响应用户。</h4>
<pre><code>既可以将早已臃肿不堪的前台系统中稳定通用的业务能力“沉降”到中台层，恢复前台的响应力；又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力“提取”到中台层，赋予这些业务能力更强的灵活度和更低的变更成本；或者干脆直接对于后台进行中台化改造，通过配置化、自助化、白屏化等形式为后台加速，从而为前台提供更强大、更迅捷、更易用的“能力炮火”支援。</code></pre>
<h3>1.企业级</h3>
<h5>企业级定义了中台的范围，区分开了单系统的服务化与微服务</h5>
<ul>
<li>
<p>不是说一个企业只能有一个中台，也不代表一个中台就是只能包含一家企业，企业级更多代表的是中台处理的问题在企业级别，即至少包含多条业务线或服务多个前台产品（团队），如果一个中台只为了支持一条业务线或产品线，那就不是中台，即使它用了服务化或是大数据等技术。</p>
</li>
<li>中台建设的事情并不是一个技术问题，而是一个要上升到企业架构的问题。做中台建设的时候，一定是跳出单条业务线、站在企业整体视角来审视业务全景。</li>
</ul>
<h3>2. 能力</h3>
<h5>能力定义了中台主要承载的对象。</h5>
<ul>
<li>能力的抽象解释了为什么会有那么多种类中台的存在，也能解释为什么每家企业的中台都不一样，因为不同的企业之所以能够同时存在，就是因为其核心能力不同，可以满足用户不同层面的需求（差异化竞争力）</li>
</ul>
<h3>3. 复用</h3>
<h5>复用定义了中台的核心价值</h5>
<ul>
<li>“去重”讲的更多是向后看，是技术驱动的；“复用”讲的更多是向前看，是业务驱动和用户驱动的</li>
<li>“复用”是中台更加关注的目标；</li>
<li>“可复用性”和“易复用性”是衡量中台建设好坏的重要指标</li>
<li>“业务响应力”和“业务满意度”是考核中台建设进度的重要标准</li>
</ul>
<h3>4. 平台</h3>
<h5>平台定义了中台的主要形式，区别于传统的应用系统拼凑的方式</h5>
<ul>
<li>中台通过对于更细粒度能力的识别与平台化沉淀，实现企业能力的柔性复用，更好地支撑前台业务，来满足对于业务的快速响应和复用的需求</li>
</ul>
<h2>四、中台建设的核心目标</h2>
<h4>以用户为中心的持续规模化创新，是中台建设的核心目标。</h4>
<pre><code>中台（⽆论是技术中台、业务中台还是组织中台）的建设，根本上是为了解决企业响应力困境， 弥补创新驱动需要快速变化的前台和稳定可靠驱动需要变化周期相对较慢的后台之间的矛盾，提供⼀个中间层来适配前台与后台的配速问题，打通并顺滑链接前台需求与后台资源，帮助企业从整体上不断提升用户响应力</code></pre>
<ul>
<li>企业的用户响应能力和规模化创新能力，是企业综合竞争力的核心体现。</li>
<li>平台化包括中台化只是帮助企业达到这个目标的手段，并不是目标本身</li>
<li>中台化是利用平台化的思维和手段梳理、识别、沉淀与复用企业级核心能力的过程</li>
</ul>
<h2>五、中台落地</h2>
<h3>1. 疑问</h3>
<ul>
<li>中台建设的愿景是什么？
中台就像一个产品一样，需要一个明确的愿景，要让所有人能够清晰明确地知道，中台建设对于企业对于业务的价值，从而可以一起始终向着同一个方向持续前进。如果愿景缺失，那我们就会很容易在中台建设过程中迷失自己的方向，失去定力。</li>
</ul>
<pre><code>愿景帮助我们了解自己中台建设的目标，帮助我们判断哪些事情是符合中台建设愿景的，作为中台团队我们需要去考虑。在这之外，更重要的是帮我们判断哪些事情不是中台要去做的，为中台做减法，这点在中台的建设过程中其实更加重要。</code></pre>
<ul>
<li>
<p>中台的用户和客户是谁？
中台的建设通常都会伴随企业内的组织重构以及利益和职责的再分配。如果没有搞清楚中台建设的各个干系方关系，必然在中台的建设过程中就会四面碰壁，陷入“干系人旋涡”之中，面临多方面的阻力，陷入一个非常被动的局面。</p>
</li>
<li>
<p>中台的『钱』由谁出？
『钱』的问题往往是很多问题背后的本质，也是中台建设过程中很多矛盾的来源。
对于企业内部，『钱』代表的就是人和资源。所以，这个问题还可以引申到中台的人从哪来？从前台团队借调么？还是重新招聘新组建呢？一个中台建设往往会持续很长的时间，那这些人的成本又由谁来承担呢？如果说中台是为前台业务赋能的，是不是就应该从前台各业务的预算中划分出一部分作为中台的建设预算呢？</p>
</li>
<li>中台的目标怎么验证？
在建设前就应该思考如何验证和度量中台。通过提前考虑这个问题，可以在建设的中后期规避一些扯皮和风险。</li>
</ul>
<p>目前业界有一些中台的考核标准我们可以作为参考，例如阿里巴巴的中台考核：40%稳定性 + 25%业务创新 + 20%服务接入量 + 15%客户满意度。</p>
<p>中台建设的愿景不同，考核的方式和指标也自然不同。</p>
<p>不要等建设完了再去考虑如何度量的问题，尽量提前考虑甚至在建设之前就约定清楚，最大程度地帮助中台建设不走偏，不乱阵脚。</p>
<h3>2. 中台规划建设方法论——D4模型</h3>
<p>D4模型把中台从整体规划到落地交付的过程划分了四个不同的阶段，包含了两次发散与收敛的过程。整个 D4 过程，是一个从战略到落地，从企业架构到产品架构最终交付的过程。而且遵循敏捷与精益的思想，整个 D4 的过程也是不断迭代的。</p>
<h4>2.1 Discovery 在中台规划前先建立全局视野</h4>
<pre><code>以企业愿景和战略为输入，结合行业趋势、竞争对手分析、用户客群分析 、业务现状分析、IT 资产盘点，全方位多角度地理解企业的战略市场环境以及业务及 IT 全貌，帮助我们做出最正确的判断。</code></pre>
<p><img src="https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/f6a8f080d9f94d6d0184b342bae725f7" alt="" /></p>
<ul>
<li>由外到内：行业与竞争对手分析</li>
</ul>
<pre><code>如果有好的概念或是方法，可以借鉴过来，帮助企业在行业里取得先机。中台这个概念起始于互联网行业，目前就正在被各个行业参考和借鉴。
如果发现更好的面、更好的行业，能够实现企业跨行业的跃进，可能就抓住了走上另一个快车道的机会。目前很多企业的中台建设，目的就是识别企业核心能力，沉淀到中台，并以此为跳板和支撑，进行业务的创新和探索，想要跳到另一个更有发展的全新赛道上。</code></pre>
<ul>
<li>自上而下：企业战略分解</li>
</ul>
<pre><code>企业战略就可以简化理解成：结合企业自身的能力与其所处的环境，到底需要采取什么样的举措，才能实现企业预定的愿景和目标呢？
而企业战略分解就可以简化理解成：结合企业各部门自身的能力与其所处的环境，到底需要采取什么样的举措，才能实现企业预定的愿景和目标呢?</code></pre>
<ul>
<li>自下而上：现状调研与分析</li>
</ul>
<pre><code>一方面充分尊重过去遇到的所有问题，收集汇总痛点；
另一方面又要能跳出过去的限制，重新从业务出发，从用户出发，去重新探索基于新技术、新架构下的一些新的可能性</code></pre>
<p>总结：</p>
<ol>
<li>先完成自上而下的企业战略分解，再开展自下而上的现状调研。因为做完战略分解，已经对于公司的行业、业务、愿景、战略已经有了一些了解，再开展调研的时候就会有个全局的把控，对于粒度和深度都更容易拿捏。</li>
<li>做好充分的准备，能够提前通过阅读资料和小范围调研完成的内容就提前完成。</li>
<li>制定详细的计划，可以按照现状调研的总时间倒推梳理的范围和粒度。如果时间足够，可以用两天的时间梳理一条业务线的业务架构，这样梳理就可以深入一些。但如果只有半天，则粒度可以适当放粗，先保证有一个全局业务视图。</li>
<li>建议刚开始做的时候，可以粒度粗一些，不要过早陷入细节，不过粒度到底如何控制确实需要对于公司战略以及业务有深入理解，也是最见功夫的地方。在判断不好的时候，可以先粗一些，如果最后还有时间，也可以再做一轮调研向下再展开一层。</li>
</ol>
<h4>2.2 Define 帮助基于之前 Discovery 发散的各维度信息进行收敛与分析， 对于中台的架构进行定义。</h4>
<pre><code>通过对跨业务线的业务梳理进行重合度分析，并结合领域分析对业务表象之后的企业核心问题域做进一步展开和重合度分析，一起来收敛推导基于中台的企业架构设计，并基于多维度的打分，形成具体的实施路径规划。
说白了就是先做什么后做什么。这里需要注意一点，此时收敛的是仍是企业架构层面，像业务中台、数据中台这种级别的产品，可能只是实施路径中的一个项目。</code></pre>
<h4>2.3 Design 帮助针对实施路径中的某一个产品，例如业务中台，做详细的设计，包括产品级的业务需求分析、功能及架构设计、实施计划等。</h4>
<pre><code>例如对于业务中台产品，在 Design 阶段需要回答产品的愿景、边界、产品形态、技术架构、交付计划、成本预估等等，这个过程就是一个标准的产品设计过程，只不过在中台项目中大多是针对中台类的产品而已。</code></pre>
<ul>
<li>确定业务中台愿景和目标</li>
</ul>
<p><img src="https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/e600be720be2d931b42e2a771aadee9b" alt="" /></p>
<ul>
<li>
<p>确定业务梳理范围
在横向端到端价值链和纵向的业务线上收敛到一个聚焦的区域</p>
</li>
<li>细粒度业务梳理
基于现有的流程或系统，对现有业务的流程进行梳理 （流程图）</li>
</ul>
<p><img src="https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/c13597096b0db83c09982e243bb656ad" alt="" /></p>
<p><img src="https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/29324ae417e4f88a4dee84d0b5179d88" alt="" /></p>
<p><img src="https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/69d3e4282a465a8d0fb42c93cc928144" alt="" /></p>
<ul>
<li>确定 MVP
<pre><code>中台建设的周期越长，需求假设的风险和需要为之付出的代价就越大</code></pre></li>
</ul>
<p>引入精益创业中的 MVP 原则（Minimum Viable Product，最小可用品）
<img src="https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/aefaabb99c0556820fcb23f7d5a41019" alt="" /></p>
<ul>
<li>运营前置：制定迭代计划及接入计划</li>
</ul>
<p><img src="https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/34802e666a91ab9314f7ea72b393c7a5" alt="" /></p>
<ul>
<li>度量前置：定义验证指标</li>
</ul>
<p>产品度量指标
<img src="https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/544997903058cbb588fe76ebd75a7317" alt="" /></p>
<pre><code>对于中台来讲，难就难在与市场和用户之间还隔着一层前台，所以在度量上就不如直接接触用户的前台系统这么清晰。但是中台是为前台业务赋能的，又不能脱离开业务，单纯只在技术上做一些度量，例如接口稳定性和接口数量等，这样也不符合中台对于业务支撑赋能的定位和价值。</code></pre>
<p>一般在考虑中台的度量指标的时候，还是把战略价值和业务价值作为出发点，开始拆解和推导，并且按照干系人关注点的不同，用多维度、多层次的指标设计来审视中台建设的效果.
<img src="https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/f08e52f31c52c85f973b138108a72bac" alt="" /></p>
<h4>2.4 Delivery 针对一个设计好的中台，开始具体的交付过程。</h4>
<pre><code>采用的是敏捷开发的方式，用快速迭代和基于反馈的调整，最大程度地弥补由中台建设本身的复杂度带来的设计偏差和其他的交付问题，并且注重架构的治理与守护，减少实现与设计的偏离。</code></pre>
<h5>2.4.1 组建一支成型的中台建设团队</h5>
<p>中台人员能力模型
<img src="https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/359daa04111ee5a73b8406501d2e6a44" alt="" /></p>
<h5>2.4.2 精益产品研发流程</h5>
<pre><code>小步迭代、快速建设、快速度量、快速反馈、快速调整的流程，保证中台建设是一个持续演进和被业务驱动的过程</code></pre>
<p>面对中台建设过程中的不确定性，引入精益思想来实现价值的定义和快速流动及度量，再结合敏捷开发实践，让整个软件开发过程轻量、迅速、敏捷、价值驱动。</p>
<pre><code>敏捷关注的是价值确定的情况下，如何通过小步快跑的迭代方式按节奏交付价值；而精益关注的则是在价值并不确定的情况下，如何用最小成本，快速定位到真正价值点。</code></pre>
<p><img src="https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/490b112728437c510ada91b1c5afa701" alt="" />
整个过程是一个复杂的系统性工程，一般都会涉及到像云化工程，微服务及服务化能力构建，Devops 相关能力构建，数据运营能力构建，敏捷精益过程改进，遗留系统服务化改造，架构守护与演进，以及与中台相关的治理与运营架构构建等工程。</p>
<h5>2.4.5 中台的运营、治理与演进</h5>
<ul>
<li>三层用户划分机制</li>
</ul>
<pre><code>通过对于前台用户的分层，我们就可以为不同层次的用户指定不同的需求响应机制、不同的沟通管理机制、不同的服务质量控制机制、不同的问题处理及升级机制等等。自然不同的服务类型作为前台用户也需要付出不同的成本或是资源（人或钱），甚至前台与中台可以通过签署 SLA 来实现对于前台用户的服务承诺。</code></pre>
<p><img src="https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/580941a159b4075c4ee029d86558c0ae" alt="" /></p>
<h2>六、中台实践</h2>
<ol>
<li>
<p>网关 + 灰度</p>
</li>
<li>
<p>有风用户中心（鉴权中心、品牌管理）</p>
</li>
<li>
<p>微信服务中心（基础服务、广告回传服务、通用授权服务、通用接口api服务）</p>
</li>
<li>
<p>企业微信服务中心（基础服务、通用接口API服务、通用授权服务）</p>
</li>
<li>
<p>触点管理中心</p>
</li>
<li>
<p>日志处理中心（日志封装、日志推送控制、通知响应）</p>
</li>
<li>监控预警中心（ELK、Pinpoint、Sentry）</li>
</ol>