数字化时代再提业务平台化 | IDCF

2020年，受到“黑天鹅”事件的影响，数字化加速进入各行业、企业的战略主航道。通过数字化进行业务重塑和创新，成为企业新的发力点和主战场。ThoughtWorks作为一家数字原生型咨询公司，在广泛的实践中，洞察出“业务平台化”再次成为企业数字化建设中的关键领域之一。

一、中台催生出新一轮数字化建设中“业务平台化”的趋势

1.1 互联网巨头中台化辐射到零售、金融、电信等传统行业，中台实践进入深水区

从2015年开始，以阿里巴巴为代表的互联网巨头们，陆续开启中台化进程（如图1）。随后，中台理念和实践开始快速向各行业渗透。

（图1 互联网企业的中台化大事件（参考文献1））

• 零售行业

得益于阿里在零售行业的渗透和影响，及电商在过去十年的深度发展，零售行业最先试水中台。一方面，阿里将中台实践结合云服务向各行业输出，零售行业因业务模式的相似性，从而有较好的适配基础。另一方面，围绕电商业务模式，一系列厂商将其中标准化程度较高的部分快速“中心化”，如“商品中心”，“订单中心”，“支付中心”等，以中台的形态进行实施，也在一定程度上促进了中台在零售行业的推广。而零售行业的中台模型，因其本质是对于交易合同及履约的业务抽象，具备较广的适用性，也常常被其他行业借鉴和扩展。

• 金融行业

金融行业中对于中台能力的打造，无论在银行、证券或是保险等细分行业，均已是战略举措之一（参考文献2、3）。当行业越来越重视客户一致性体验，开始打造开放银行并深度运营客户，长期以来掣肘金融行业发展的历史遗留问题的解决已迫在眉睫，如庞大的遗留系统难以响应前端快速的业务创新、客户和业务数据孤岛、组织架构壁垒等，中台建设是行业普遍认同的求解之道。根据恒生调研，半数金融机构正在考虑建设业务中台，90%金融机构认为未来两至三年会建设业务中台。（参考文献2、3）

• 电信行业

以IT基础设施作为重要支柱的电信行业，始终保持对IT新技术与工程实践的关注和引入。过去5年，伴随通信技术的快速换代所带来的新的市场特征，围绕业务响应力提升和研发效能改进，电信行业IT基础设施经历了新一轮的翻新和升级：研发体系的敏捷转型、DevOps体系搭建、大型核心系统的容器化及服务化改造。而在“新基建”顶层设计的加持下，行业整体的IT基础设施进一步深化，中台建设作为突破点和抓手之一，在营销、服务、网运等多层面展开，并不断取得进展。

1.2 中台不是目的而是手段，本质是“平台化”再向业务演进

回顾ThoughtWorks对于中台的探索，我们持续向行业输出一系列思考和洞见的同时，也广泛且深入参与到各行业领跑者、尤其是以上三大行业的中台建设过程中。

在我们的经验中，中台之于不同的行业，有着不同的最佳适配领域，这里我们从前面提到的三大行业中列举一些：

• 零售多品牌集团型企业：通过中台建设，实现集中管控前提下营销能力在多品牌复用。
• 跨国零售企业：通过中台建设，实现全球统一运营下的核心业务能力针对中国市场的复用与差异化适配，以适应中国特有的业务场景和业务发展。
• 商业银行与金融机构：在特定业务(如信贷、资管)场景下的能力抽取与模式复用，实现对于金融产品创新的加速，及金融电商化渠道能力运营的加强，为生态建设奠定基础。
• 通信企业：跨业务线之间的公共能力的识别、沉淀，形成统一管控及支撑，实现产品平台化，更灵活地适配不同场景的需求与快速响应。

这些领域中，中台的差异化适配和建设，印证了中台实践已进入深水区。

而与此同时，行业中中台实施“失败”的案例也不绝于耳，以至行业中对中台的观点，出现清晰的分化。这里，我们将不展开中台实施失败案例的讨论，也并不是要在不同观点中做出选择。
在我们看来，中台建设的成功，或者失败，甚至“去中台化”声音背后，本质上是一致的商业逻辑：

• 中台建设不是广义软件套件实施。中台以“复用”之名起源，因此，一些案例中，很容易走回从前软件套件实施的思路，中台以“产品化”、“套件化”的模式，加上一定程度的开放和定制，实现“复制”。“复制”、“复用”一字之差，却意味着从规划到落地截然不同的方法和实现。由此这带来的问题是，曾经软件套件实施过程中因“削足适履”出现过的问题、走过的弯路，在中台“套件”实施过程中，会不可避免的再一次出现。
• 中台建设是对于企业业务模式端到端的深度分析、建模与复用。中台究竟在复用什么? 我们给出的答案是:中台是针对于“商业模式”和“业务模式”的抽象与复用。背后体现的是企业希望通过对于自身商业模式的 不断思考与认知，再通过自身业务模式的抽象与沉淀，实现跨地域、跨用户、 跨场景、跨领域的扩展与复用，支撑企业业务的快速拓展与创新，也体现并契合了平台向业务的再演进过程。

借用我们一位咨询师的话：“看上去的能力复用是乐高组装，真实的能力复用其实是器官移植，需要的是一场外科手术。”

因此，我们认为且认同这样的观点，中台本身是手段、过程，不是目的。回归本源，其本质是“平台化”再一次向业务演进。

二、新问题将业务平台化内涵向前演进

从信息化到数字化，是“平台化”每一轮 IT 建设都会提及的主题之一。而当平台沿着历史发展的趋势继续向业务的“逼近”的过程中，对于平台抽象和建设的难度也成指数型增加，涌现出了一系列新问题。

对于这些问题的思考和解决方案的探索，也将赋予业务平台化这个趋势以新的内涵和意义，同时也是我们设计和发布新的企业架构框架的起心动念。而这些问题的“新”意，也体现在深水区实践中从“what”向“how”的转变，所以我们以“如何”的句式来逐一总结和简述：

2.1 如何抽离多业务线共享的能力，集中管控和演进，以避免重复投资？新业务如何基于企业能力快速组装上线，以支撑业务快速迭代创新？

今天，业务发展和IT建设的绑定比以往任何时间都更加紧密，而当大型企业的业务涉猎已足够广泛，多条业务线、或者多个业务单元并行发展，IT建设会不可避免的随着业务边界、组织边界进一步分化，也加剧了IT部门进行统一管控的困难。

一方面，在很多场景中，这样的分化带来双重投资甚至多重投资的浪费，另一方面，也在加剧本就存在的用户或者客户体验的割裂、数据孤岛、IT翻新周期长等固有问题。

同时，当业务前线不断尝试新的业务模式，或对于已 有模式进行更快的试验、调整与扩展时，对IT支撑的响应力也提出了更高的要求。固有的系统搭建或者产品部署模式，越来越不足以提供及时的响应，且在“快速试错”、“小步快跑”的创新场景下，成本高昂。

因此，如何抽离多业务线共享的能力，集中管控和演进，以避免重复投资？新业务如何基于企业能力快速组装上线，以支撑业务快速迭代创新？成为亟待解决的问题，进一步拆解，我们认为需要回答：

• 针对不同的业务深度，如何设计“模式”与“能力”模型，以对业务进行合理的抽象，进而识 别相似度，抽象与提炼可复用的业务模式，而针对不同业务的差异性，如何在“模式”和“能 力”基础上进行扩展?
• 抽象并沉淀了业务能力之后，如何在新的业务场景中，识别、复用已有能力，应用、数据、技术及组织应该如何予以支撑?

以上的工作过程，是否有较好的工作实践和参考模型?

2.2 如何合理地划分IT系统边界，以得到随“需”而变的响应力

除了能力复用外，另一个提升IT支撑响应力的关键是，提升IT系统各组成部分的自治性，使得变化能够相对独立的、在更小的边界范围内，以小步快跑的方式发生；同时还需要保持一定的一致性，使整体架构做到“形散神聚”。

因为不管是创新也好，集中管控也好，虽然变化速率不同，但变化始终存在，既然变化不可避免，我们应将精力投入到应对变化上。而一个清晰的应用 边界划分，可以对于业务能力通过对于知识边界的 解耦，实现知识的黑盒复用，对于变化的响应非常有帮助。

在我们的经验中，应用边界划分不合理会致使应对变化产生明显的负面作用。一般来说，边界的粒度过粗，容易产生功能、运行层面的变更冲突，而边界的粒度过细，则带来了额外的变更成本和性能开销，这里对各种负面作用暂不作展开，但它们的共同点是都会拖慢IT支撑的响应力或稳定性。

因此，“如何划分IT系统的边界，以合理的布局更好地应对变化”是需要解决的问题。进一步拆解，我们认为需要回答：

• 如何划分应用构建块的逻辑边界，使其尽可能职责单一、接口规范明确，容易变更和组装？
• 如何组合应用构建块成为合适粒度的独立可部署单元，尽可能减少功能、运行层面的变更冲突？
• 如何描述、留存以上决策的结果和依据，当变化发生时，通过溯源做出优质的新应对？

2.3 如何适当拆分过于集中的分析类数据处理职责，以缓解规模化瓶颈？

长久以来，业界对数据架构达成共识是：对于运行类(Operational)和分析类(Analytical)场景，应该使用不同的设计方法和技术支撑。

运行类场景以业务事务为主线，关注点在于业务事务运作证据的完整性和一致性，以及确保各类数据在各业务单元间高效、准确地传递，实现跨业务单元的事务推进及对于业务溯源的支撑。
分析类场景则需要对内、外部数据进行收集和加工，用来度量业务运行表现、尝试分析产生偏差的原因，甚至给出预测，或者结合机器学习技术得出专业结论。

数据想要形成分析类价值，背后需要经过摄取（Ingest）-加工（Process）-能力包装（Serve）三大工序，其又可以进一步分为数据仓库、数据湖两种设计方法和技术栈，它们有各自不同的适用场景和技术栈，它们的差异我们暂不作展开。

由于分析类场景所要求的方法和技术与事务类场景有显著的不同，许多企业组建了专职的数据团队，将分析类数据处理工作和其背后的复杂性打包成为一个黑盒，提供端到端的数据服务。

这个模式对于业务场景可适用于简单的企业环境，但难以满足多业务线、业务平台化的企业环境。一方面，随着IT建设加速，数据源和分析类场景的数量激增，对数据服务的响应力提出了更高要求。另一方面，想要提供高质量的数据服务，除了分析类数据的专业技能，还要求对于业务场景、现有应用软件的深入理解。如果所有工作仍然只由专职的集中式团队一肩挑，团队带宽的限制必然会拖慢响应力。

因此，我们认为需要探索的是如何适当拆分过于集中的分析类数据处理职责，为集中式的数据团队减负，使其可以将精力投入到高价值的分析类场景中。

2.4 如何在富技术时代进行平台型技术架构选型及设计？

受益于云原生架构的兴起与发展，新技术的涌现和不断成熟，以及技术工具的极大丰富，技术架构设计的灵活度和效率都得到了显著提升。

而另一方面，在平台型技术架构的设计中，作为多业务条线、多应用、多数据场景落地的技术基座，技术架构设计所需覆盖的规模、应对的复杂度今非昔比。加之“富”技术条件的加持，一个好的技术架构设计的困难度实际上指数级增加。一直以来，技术架构设计的方法和过程是强依赖于架构师的经验和能力的，而“富”技术环境让一系列挑战和问题再次凸显：

• 对于架构需求把握不足或者没有架构需求的分析意识，过早的进入架构设计，导致系统复杂度变高甚至过度设计，为开发落地带来额外的研发成本。
• 架构设计采用的技术和工具过于超前，超出团队成员技术水平，造成落地难度高，新成员上手速度慢，进而对整体进度和实施效果造成影响。架构设计过程时间长，完成后团队就不再愿意对设计方案继续调整和迭代，当技术发展变化很快时，技术架构方案容易进入“完成即落伍” 的困局。

因此，我们认为相比以往，架构师们更需要这样一个体系：

• 系统性的分析架构需求；
• 结构化的设计架构方案；
• 沉淀可复用的架构经验。

三、经典的企业架构框架已不足够应对业务平台化中的新问题

3.1 以企业架构框架进行业务平台设计，各主流方法各有侧重

业内越来越普遍的采用企业架构框架作为业务平台化整体规划指导和方法，这是有效的。因为各类企业架构框架的元模型，大体都可以归结为四类视图，即业务架构，应用架构、数据架构和技术架构，尽管不同框架在具体的层级划分、及各层结构下的内容涵盖可能会略有不同。这样的结构较好的匹配业务平台设计的问题域。

同时，各类企业架构框架的工作逻辑相似，均是从愿景与业务目标出发自顶向下的贯穿设计，并保持从业务到技术的一致性，这样的工作逻辑与业务平台从设计到落地的逻辑一致。

在此基础上，不同的企业架构框架，由于产生的背景和发展过程的不同，形成各自的侧重点或者行业属性，这也从另外一个方面加强了适用性。例如：

• Zachman：侧重从利益相关者的六个视角来描述企业。
• TOGAF：强调企业架构全生命周期治理。
• DoDAF/FEAF-II：面向政府机构的投资组合管理，注重ViewPoint。
• BIAN: 面向银行业，有银行业开箱即用参考模型。

需要说明的是，以上的侧重总结，仅代表我们在项目操作中的理解，实际上，每一种框架都是完备的，在各自的领域和适用场景中也得到广泛的应用。

3.2 经典框架对业务平台化的新问题没有特定的设计和考虑

下面这张表格，体系化的从系统的概念、建模、流程的角度，对若干经典企业架构方法进行对比，从中我们可以解读出，在Concept（概念）层面的各项评估中，各框架普遍的评定都在H（高）和M（中），而从Modeling（建模）开始，到Process（流程），评定开始从M(中)转向L（低），其中，和落地的相关性越高的评估项，普遍的评定都位于L（低）。

（图2 企业架构框架对比 参考文献 4）

这张表格出自2015年（参考文献 4），在这之后的5年时间里，各框架均不同程度对实操内容进行了补充和增强。但从我们的跟进研究和项目经验来看，各经典框架在项目工程实操性中仍显不足。这可能也与经典框架的定位相关，大都定位于战略规划和组织治理，对于架构的具体设计和建模层面都没有细粒度展开。

同时，在第二小节中所提及的，业务平台化趋势下我们所面临的新问题，可以较好的映射进企业架构框架元模型的四个层次中：

• 业务架构层：如何抽离多业务线共享的能力，以避免重复投资？新业务如何基于企业能力快速组装上线，以支撑业务快速迭代创新？
• 应用架构层：在宏观规划层面，如何划分IT系统的物理边界，以合理的布局更好地应对变化，在局部设计层面，如何在最大化复用效果的同时，保障对差异化需求的响应力？
• 数据架构层：如何适当拆分过于集中的分析类数据处理职责，缓解规模化瓶颈？
• 技术架构层：如何在富技术时代进行平台型技术架构设计？

而这些问题，从各经典企业架构框架中很难直接找到针对性的设计参考和考量依据，需要我们进一步思考、实践与提炼。

参考文献：

• 参考文献1：《从技术走向商业看中台 投资机会》 中银国际证券
• 参考文献2：《中国行业趋势报告-2020年度特别报告》 罗兰贝格
• 参考文献3：2019恒生电子技术开放日
• 参考文献4：A Framework for Evaluation of Enterprise World Academy of Science, Babak Darvish Rouhani, Mohd Naz’ri Mahrin, Fatemeh Nikpay, Maryam Khanian Najafabadi, Pourya Nikfard，Engineering and Technology International Journal of Economics and Management Engineering Vol:9, No:1, 2015

来源：ThoughtWorks洞见
作者：ThoughtWorks
声明：文章获得作者授权在IDCF社区公众号（devopshub）转发。优质内容共享给思否平台的技术同伴，如原作者有其他考虑请联系小编删除，致谢。

7月每周四晚8点，【冬哥有话说】研发效能工具专场，公众号留言“效能”可获取地址

• 7月8日，LEANSOFT-周文洋《微软DevOps工具链的 "爱恨情仇"（Azure DevOps）》
• 7月15日，阿里云智能高级产品专家-陈逊《复杂型研发协作模式下的效能提升实践》
• 7月22日，极狐(GitLab)解决⽅案架构师-张扬分享《基础设施即代码的⾃动化测试探索》
• 7月29日，字节跳动产品经理-胡贤彬分享《自动化测试，如何做到「攻防兼备」？》
• 8月5日，声网 AgoraCICD System负责人-王志分享《从0到1打造软件交付质量保证的闭环》