华为 VS 阿里数据中台建设方法论
中台究竟是什么？它对于企业的意义又是什么？当我们谈中台时，我们到底在谈些什么？
想要找到答案，仅仅沉寂在各自“中台”之中，如同管中窥豹，身入迷阵，是很难想清楚的。不如换个⾓度，从各类的“中台迷阵”中跳脱出来，尝试以更高的视角，从企业均衡可持续发展的角度来思考中台的价值，试图反推它存在的价值。
所以，为了搞明白中台存在的价值，我们需要回答以下两个问题：
第一个问题：企业为什么要平台化？
先给答案，其实很简单：
因为在当今互联网时代，⽤户才是商业战场的中心，为了快速响应用户的需求，借助平台化的力量可以事半功倍。
不断快速响应、探索、挖掘、引领⽤户的需求，才是企业得以⽣存和持续发展的关键因素。
那些真正尊重用户，甚⾄不惜调整⾃己颠覆⾃己来响应⽤户的企业将在这场以⽤户为中心的商业战争中得以⽣存和发展；⽽反之，那些在过去的成就上故步⾃封，存在侥幸⼼理希望⽤户会像之前一样继续追随⾃己的企业则会被用户淘汰。
很残酷，但这就是这个时代最基本的企业⽣存法则。
⽽平台化之所以重要，就是因为它赋予或加强了企业在以用户为中心的现代商业战争中最核心的能力：⽤户响应力。这种能力可以帮助企业在商战上先发制⼈，始终抢得先机。
在互联网时代，商业的斗争就是对于用户响应力的比拼。
我们来看⼏个例子:
1、阿里
说起中台，最先想到的应该就属是阿里的“⼤中台，⼩前台”战略。阿里⼈通过多年不懈的努力，在业务的不断催化滋养下，将自己的技术和业务能力沉淀出一套综合能力平台，具备了对于前台业务变化及创新的快速响应能力。
2、华为
华为在几年前就提出了“⼤平台炮火支撑精兵作战”的企业战略，“让听得到炮声的人能呼唤到炮火” 这句话形象的诠释了大平台⽀撑下小前台的作战策略。这种极度灵活又威力巨⼤的战法，使之可以迅速响应瞬息万变的战场，一旦锁定目标，通过大平台的炮火群，迅速精准对于战场进行强大的火⼒支援。
可⻅，在互联⽹热火朝天，第四次工业革命的曙光即将到来的今日，企业能否真正做到“以用户为中心”，并不断提升自己的用户响应力来追随甚至引领用户的脚步，持续规模化创新，终将决定企业能否在这样充满挑战和机遇的市场上笑到最后，在商业上长久保持创新活力与竞争力。
而平台化恰好可以助力企业更快更好的做到这些，所以这回答了第一个问题，企业需要平台化。
第二个问题：企业为什么要建中台？
好，想明白了第一个问题，为什么需要平台化。但是平台化并不是一个新概念，很多企业在这个方向上已经做了多年的努力和积淀。那为什么最近几年“中台”这个相对较新的概念又会异军突起？对于企业来讲，传统的“前台+后台”的平台化架构又为什么不能满足企业的要求呢?
好，这就引出了我们的第二个问题：企业为什么要建中台？
先定义一下前台与后台
因为平台这个词过于宽泛了，为了能让大家理解我在说什么，我先定义一下本篇文章上下文下我所说的前台和后台各指什么：
前台：由各类前台系统组成的前端平台。每个前台系统就是一个用户触点，即企业的最终用户直接使用或交互的系统，是企业与最终用户的交点。例如用户直接使用的网站，手机 app，微信公众号等都属于前台范畴。
后台：由后台系统组成的后端平台。每个后台系统一般管理了企业的一类核心资源（数据+计算），例如财务系统，产品系统，客户管理系统，仓库物流管理系统等，这类系统构成了企业的后台。基础设施和计算平台作为企业的核心计算资源，也属于后台的一部分。
后台并不为前台而生
定义了前台和后台，对于第二个问题（企业为什么要建中台），同样先给出我的答案：
因为企业后台往往并不能很好的支撑前台快速创新响应用户的需求，后台更多解决的是企业管理效率问题，而中台要解决的才是前台的创新问题
大多数企业已有的后台，要么前台根本就用不了，要么不好用，要么变更速度跟不上前台的节奏。
我们看到的很多企业的后台系统，在创建之初的目标，并不是主要服务于前台系统创新，而更多的是为了实现后端资源的电子化管理，解决企业管理的效率问题。这类系统要不就是当年花大价钱外购，需要每年支付大量的服务费，并且版本老旧，定制化困难；要不就是花大价钱自建，年久失修，一身的补丁，同样变更困难，也是企业所谓的“遗留系统”的重灾区。
总结下来就两个字“慢”和“贵”，对业务的响应慢，动不动改个小功能就还要花一大笔钱。
有人会说了，你不能拿遗留系统说事儿啊，我们可以新建后台系统啊，整个2.0问题不就解决了。
但就算是新建的后台系统，因为其管理的是企业的关键核心数据，考虑到企业安全、审计、合规、法律等限制。导致其同样往往⽆法被前台系统直接使用，或是受到各类限制⽆法快速变化，以⽀持前台快速的创新需求。
此时的前台和后台就像是两个不同转速的⻮轮，前台由于要快速响应前端用户的需求，讲究的是快速创新迭代，所以要求转速越快越好；⽽后台由于⾯对的是相对稳定的后端资源，⽽且往系统陈旧复杂，甚至还受到法律法规审计等相关合规约束，所以往往是稳定至上，越稳定越好， 转速也自然是越慢越好。
所以，随着企业务的不断发展，这种“前台+后台”的⻮轮速率“匹配失衡”的问题就逐步显现出来。
随着企业业务的发展壮大，因为后台修改的成本和⻛险较⾼，所以驱使我们会尽量选择保持后台系统的稳定性，但还要响应用户持续不断的需求，自然就会将大量的业务逻辑（业务能力）直接塞到了前台系统中，引入重复的同时还会致使前台系统不断膨胀，变得臃肿，形成了一个个⼤泥球的“烟囱式单体应用”。渐渐拖垮了前台系统的“⽤户响应⼒”，用户满意度降低，企业竞争力也随之不断下降。
对于这样的问题，Gartner在2016年提出的一份《Pace-Layered Application Strategy》报告中，给出了一种解决方案，即按照“步速”将企业的应用系统划分为三个层次（正好契合前中后台的三个层次），不同的层次采用完全不同的策略。
而 Pace-Layered Application Strategy 也为“中台”产生的必然性，提供了理论上的支撑。
在这份报告中，Gartner 提出，企业构建的系统从 Pace-Layered 的⾓度来看可以划分为三类: SOR（Systems of record），SOD（Systems of differentiation）和 SOI（Systems of innovation）。
处于不同 Pace-Layered 的系统因为⽬的不同，关注点不同，要求不同，变化的“速率”自然也不同，匹配的也需要采⽤不同的技术架构，管理流程，治理架构甚至投资策略。
⽽前面章节我们提到的后台系统，例如 CRM、ERP、财务系统等，它们⼤多都处于 SOR 的 Pace-Layered。这些系统的建设之初往往是以规范处理企业底层资源和企业的核⼼可追溯单据（例如财务单据，订单单据）为主要⽬的。
它们的变更周期往往比较⻓，⽽且由于法律律审计等其他限制，导致对于它们的变更需要严谨的申报审批流程和更高级别的测试部署要求，这就导致了它们往往变化频率低，变化成本高，变化⻛险高，变化周期⻓。⽆法满⾜由⽤户驱动的快速变化的前台系统要求。
我们又要尽力保持后台（SOR）系统的稳定可靠，⼜要前台系统（SOI）能够⼩而美，快速迭代。就出现了上文提到的”齿轮匹配失衡“的问题，感觉鱼与熊掌不可兼得。
正当陷入僵局的时候，天空中飘来一声 IT 谚语：
软件开发中遇到的所有问题，都可以通过增加⼀层抽象⽽得以解决!
⾄此，⼀声惊雷滚过，“中台”脚踏七彩祥云，承载着 SOD（Systems of differentiation）的前世寄托，横空出世。
我们先试着给中台下个定义：
中台是真正为前台而生的平台（可以是技术平台，业务能力甚至是组织机构），它存在的唯一目的就是更好的服务前台规模化创新，进而更好的响应服务引领用户，使企业真正做到自身能力与用户需求的持续对接。
中台就像是在前台与后台之间添加的⼀组“变速⻮轮”，将前台与后台的速率进行匹配，是前台与后台的桥梁。它为前台而生，易于前台使用，将后台资源顺滑流向用户，响应用户。
中台很像 Pace-Layered 中的 SOD，提供了比前台（SOI）更强的稳定性，以及⽐后台（SOR）更高的灵活性，在稳定与灵活之间寻找到了⼀种美妙的平衡。中台作为变速齿轮，链接了用户与企业核心资源，并解决了配速问题。
有了“中台”这⼀新的 Pace-Layered 断层，我们即可以将早已臃肿不堪的前台系统中的稳定通用业务能力“沉降”到中台层，为前台减肥，恢复前台的响应⼒；又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力“提取”到中台层，赋予这些业务能力更强的灵活度和更低的变更成本，从而为前台提供更强大的“能力炮火”⽀援。
——这就是为什么企业在平台化的过程中，需要建设自己的中台层（同时包括技术中台，业务中台和组织中台）。
根据阿里云发布《数据中台交付标准化》白皮书，基于对数据中台交付的挑战分析和多个行业的实践经验，提出了“1+3+3+1”的交付标准参考框架、标准化技术要求和交付标准体系。
同时，白皮书详细分析了某行业客户数据中台标准化交付的典型案例，是数据中台交付的方法、工具、平台等体系建设方面的重要实践指引，同时促进数据中台交付标准持续迭代。
数据中台交付“1+3+3+1”框架
白皮书指出，数据中台是业务与技术的结合点，其基于产品化的运营思路，跑通数据流转之后，服务于业务前台，企业基于对数据的洞察优化业务方向，并通过反馈回来的业务数据再次输入数据中台，持续提升中台使用价值，实现数据和业务不断的正向循环和相互促进。数据中台需要不断的打磨、开发和持续运营，在不断实践的过程中企业也会建立起走出经验主义、走入数据管理的核心逻辑。
数据中台交付技术服务挑战
挑战1：数据中台交付专业要求高
白皮书指出，企业家面临最大的确定性是如何应对巨变时代的不确定性，未来十年全球数字经济最重要的主题之一是数字基础设施的重构、切换与迁移以及基于新型数字基础设施的商业生态再造。今天越来越多的企业因管理失衡、市场失焦、营销失语、系统失灵、增长失速等方面的风险而进行数字化转型，进行数据中台建设。
然而，实践表明，数据中台建设经常遇到客户预期过高、低估困难、押注外力等情况；客户想要服务商以标准专业的交付体系，以专业能力指导项目高质量完成，甚至是从各个维度以最佳实践和未来驱动的思想引领客户进入数据智能的全新时代。实际上，数据中台技术服务提供商因行业经验、专业人员、方案成熟度等方面的不足，导致以客户价值为中心的定制化需求服务面临巨大挑战。
挑战2：数据中台交付过程管控复
数据中台的建设是业务和技术双轮驱动的，基于业务价值需求导向，企业在进行数据中台建设时通常会以数据统一化、标准化、资产化等为手段，进而实现数据面向全业务开放赋能，所以数据中台建设内容基本都会涉及不同程度的数据治理、数据服务、数据应用、管理流程制度、数据运营及上下游业务协同等，这样以来其交付周期一般以数月为最小单位，加上以下方面原因导致交付内容和过程管控困复杂。
1）数据中台项目交付一般都要涉及咨询、业务、数据、技术、运营等，交付技术覆盖范围广、资源需求大；同时，客户服务需求的多样性及服务商专业人员储备不足，导致数据中台设计和落地实施存在诸多质量问题和不确定性；
2）在交付过程中，从需求调研、方案设计、开发实施到试运行，基本都是在线下由不同角色、甚至不同服务商完成的，缺乏项目交付全流程、全生命周期的数字化工作台承载，很难实现对项目全局掌控，各个环节都容易出现不同类型的问题与挑战；除项目前期需要充分准备与思考外，也需要项目交付人员的个人经验与能力去把控项目进度与质量；
3）交付验收周期长，根据各行业数字化转型趋势分析和阿里巴巴数据中台交付实践经验发现，数据中台技术服务从需求调研、方案规划再到实施落地的整体交付周期以数月为单位，同时交付的业务价值及质量等级很难做到在线化、可视化评估。
挑战3：数据中台交付生态协同难
一般产品交付完成产品售卖和产品部署即可，而数据中台交付是集成交付，包罗万象，软件、硬件、基础设施、大数据平台、数据资产、数据服务、数据应用、定制化开发等基本都涉及，导致交付复杂度高。
因此，数据中台服务提供商需要建设数据中台交付的生态体系作为支撑，形成合作模式，进行彼此资源整合应用，来应对日趋复杂的企业需求及规模化交付需求。
但是，数据中台服务提供商之间在能力的匹配上有很大不确定性，而造成这种不确定性的原因往往集中在伙伴间能力成长差异性、伙伴内部对员工的不同组织架构带来的不稳定性以及员工本人对职业路径规划所产生的波动性、伙伴对行业领域知识的缺乏。这些因服务提供商的知识和能力上的参差不齐，使得数据中台交付生态协同难，进而导致企业对数据中台交付的不确定性存在敏锐的感知。
数据中台交付标准化参考框架
基于对数据中台交付技术服务的挑战分析和解决思路，白皮书提出了“1+3+3+1“的交付标准参考框架。
1个目标：即以业务价值为导向，实现数据中台技术服务的标准化、在线化、规模化交付；
3个内容：即数据中台技术服务包含数据咨询规划服务、数据资产建设服务、数据应用建设服务；
3个能力支撑：即交付标准流程、交付文档集、交付工具集；
1个平台：即数字化工作台，数据中台技术服务团队和政企客户通过数字化工作台完成数据中台项目交付。
数据中台交付的标准体系
交付流程、交付文档集、交付工具集是三位一体的能力支撑体系。基于交付流程动作及产出，沉淀交付技术资产，包含交付物、过程产出物、项目评审意见、阶段性汇报总结等文档。
通过对多个项目文档的提炼抽象脱敏等手段，形成通用解决方案和行业解决方案。结合数据资产目录划分方法，进行文档集的资产目录构建，一方面做内部参考借鉴，另一方面为交付工具打造提供输入。
交付工具集，基于通用解决方案和基础产品开放能力，围绕具体交付实施场景而构建，能有效降低数据中台交付门槛，为交付动作执行提供武器弹药支持，同时倒逼交付文档集的不断迭代更新。交付技术服务团队包含业务架构师、技术架构师、数据产品经理及实施人员等，与政企客户服务对象一起，基于数字化工作台进行数据中台项目在线化交付。
数据中台交付标准化技术要求
标准，是在一定范围内获得最佳秩序，经协商一致，并经过人工机构批准，共同使用和重复使用的规范性文件”；数据中台交付标准化，为是为了在交付前、交付中、交付后获得最佳秩序，制定交付技术服务流程、业务动作、文档模板、设计规范、工具平台、服务角色、职责矩阵等的活动，以提升数据中台交付效率与质量提升，支撑标准化、在线化、规模化的服务履约，保障客户服务满意度。
数据中台交付各环节的交付任务
1、交付前阶段
交付前阶段包括交付前置环节，支持售前团队进行数据中台需求沟通及方案设计，提前识别交付风险，并提供规避建议，完成数据中台项目签约，保障项目交付履约。交付前置环节的交付任务包括需求方案、风险识别、交付评审和启动规划。
交付前置的质量管控要求包括：
1）明确交付前置的团队角色职责矩阵和分工协作；
2）提交覆盖交付全流程的交付风险说明与规避建议文档；
3）按照可交付性评审模板提交评审意见；
4）按照标准项目管理办法启动规划，并提交启动规划会议纪要；
5）基于数字化工作台进行上述交付文档的提交和管理。
2、交付中阶段
需求调研环节：需求调研环节基于工作说明书中的业务目标和范围，从业务、数据、技术等方面对客户的需求进行详细调研，为交付实施提供需求输入。需求调研环节的交付任务包括业务调研、技术调研和数据调研。
方案设计环节：方案设计环节基于需求调研环节的交付文档和交付前置环节的项目交付工作说明书文档，完成数据中台业务蓝图设计、数据产品设计、架构设计、数据模型设计及测试方案设计，为开发实施提供输入。
开发实施环节：开发实施环节基于数据中台详细设计方案，进行数据中台平台环境搭建、数据采集、代码研发、数据回刷与校验、数据服务研发与测试、数据应用研发与测试等交付实施工作。开发实施环节的交付任务包括数据集成、数据研发、应用研发、数据回刷和集成测试。
试运行环节：试运行环节确定试运行目标与范围，制定试运行方案与运行保障机制，配置监控告警，处理试运行的缺陷及需求；明确交付质量要求，便于制定正式上线运行措施和管理规范，完成知识转移，为转维和终验做准备。试运行环节的交付任务包括试运行和知识转移。
3、交付后阶段
交付后阶段包括上线维保环节，制定上线方案和运营管理规范，完成数据中台正式上线，制定维保方案，完成项目转维和验收。上线维保环节的交付任务包括正式上线、售后保障和项目验收。
上线维保的质量管控要求包括：
1）明确上线维保的团队角色职责矩阵和分工协作；
2）按照上线方案完成项目正式上线，并提交项目上线报告；
3）提交售后运维保障方案文档，按照该方案并利用数据校验工具完成交付转运维；
4）需按照项目验收管理规范完成验收，并提交项目验收签字确认单；
5）基于数字化工作台进行上述交付文档的提交和管理。
结束语
随着数据中台在行业头部及领先企业逐渐落地，服务商和生态伙伴经历了各类业务场景能力沉淀过程，产品技术和实施方法日趋成熟，需求端对数据中台的理解和信任逐步加深，行业增长势头明显，市场规模迅速扩展。
在大型、头部企业渗透率逐渐增加的同时，中小企业将成为服务商的重要增量市场。因此，提炼和总结数据中台的服务内容，沉淀行业通用能力，形成标准化的整体解决方案，以助力中小企业数字化转型，提升数据中台服务商和生态伙伴的规模化交付能力，其重要意义不言而喻。
现阶段，数据中台技术已相对成熟，在数据中台的交付实践过程中，企业自身的资源配置能力、管理经验、组织变革等成为高质量建设数据中台的关键要素，这些要素的标准能力构建也迫在眉睫。
当然，数据中台的涵义一直随着发展而改变，但无论怎么变化，数据中台交付标准化建设始终以时代发展的趋势和业务需求为出发点，继续围绕要做什么、怎么做、产出什么、怎么衡量等为主线持续迭代演进，不断将其推向新时代、新台阶、新高度。
推荐阅读：