金融企业数字化中台

中台这一概念提出后，迅速引起了大家的广泛关注，这一概念源起于阿里巴巴 2015 年提出的“大中台小前台”战略，让前台的一线业务会更敏捷、更快速适应瞬息万变的市场。中台集合整个集团的运营数据能力、产品技术能力，业务数据化、数据业务化，对各前台业务形成强力支撑。目前针对金融企业的中台架构规划的指导及经验总结缺较少，且在业务架构层面较少涉及。

全书分为7章，探讨金融企业实施中台的背景与要求、原则与方法、架构与技术、流程与组织等各个方面，解答这些问题：1）金融企业数字化转型的本质是什么？通过数字化转型能够金融企业带来哪些变化？2）中台架构和金融企业目前的应用架构有什么关系？如何演进？3）中台架构如何划分？有几个中台？业务中台、技术中台、数据中台有什么关系？

本书立足于对金融企业更加重要的业务中台规划，为商业银行、农村金融机构等金融企业提供中台建设参考。本书适合金融行业CIO、IT经理、业务规划人员以及中台系统研究人员。

周丹 广东农村信用社联合社银信中心副总裁

现任广东省农村信用社联合社银信中心党委委员、副总裁，中国银行业协会信息科技专业委员会副主任委员，中国计算机用户协会金融互联网分会暨中国网络金融联盟副理事长，数据中心运营管理工作组专业委员，广东银行同业公会第一届金融科技工作委员会副主任委员。曾任中国银监会银行业信息科技“十三五”发展规划农村中小金融机构编制组领导小组副组长、广东省农村合作金融机构数据大集中工程项目负责人。具有27年以上的银行业工作经验，在金融科技领域研究颇深。

对于金融科技的从业者，这是一个全新的时代。从B/S到SOA再到中台架构，标志着IT建设进入到了深水区，一方面IT系统不再是简单的信息保存，而是业务数据化，利用数据驱动业务；另一方面IT系统不再是简单的从业务需求转化为系统实现，而是需要通过可复用能力支撑甚至引导业务需求。本书通过七个部分，论述了金融企业中台的背景、目标、原则与分工、业务中台/数据中台/技术中台的实施方法、成熟度评估原则，这也是作者从SOA架构到中台架构、从平台化到中台化里程碑的总结。

前 言

中台的概念已经不需要解释来龙去脉了，它像Web、J2EE、ERP、SOA、云计算、大数据一样，已经成为企业信息化建设的一个关键里程碑节点。让我们感到高兴的是，这是一个完全国产化、原创的概念与实践，而不是一个舶来品。这说明，中国的信息化建设水平与国外相比，在经历了僵化、固化、优化国外先进经验的引进阶段，进行软件产品替换的去“IOE”阶段，发展到了可以形成自有体系架构的阶段。之所以这一概念提出后，迅速引起了大家的广泛关注，是因为它源于阿里“大中台小前台”的战略，目标是让前台的一线业务更加敏捷、更快速适应瞬息万变的市场，利用中台集合整个企业的运营数据能力、产品技术能力，通过业务数据化、数据业务化，对各前台业务形成强力支撑。这一战略目标和手段，抓住了企业数字化转型的实质，很多企业受此启发也开始了中台的探索与转型，中台架构往往被认为是企业数字化转型下重构IT的最佳选择。

但是，金融企业如何实施中台，却面临着诸多挑战。首先，目前实施中台架构的案例以电商、零售类企业为主，业务模式上主要以2C业务为主，组织模式上这些企业也相对灵活，而金融企业尤其是商业银行业务涉及对公对私等方面，组织模式上有监管要求，相对不易变动，现有案例与金融企业存在较大差异；其次，金融企业尤其是商业银行经过多年信息化建设，IT架构已经成型，基本覆盖了业务的方方面面，形成了数以百计的系统，如何引入中台架构，还缺少理论指导；最后，目前介绍中台的素材，往往在业务架构层面较少涉及，即使涉及也很少深入，大多是论述技术中台、数据中台等通用解决方案，这也可以理解，毕竟通用方案普适性强、易于总结，但是业务架构才是金融企业更加关注的问题。我们经常遇到这样的问题：

（1）金融企业数字化转型的本质是什么，通过数字化转型能够给金融企业带来哪些变化？

（2）数字化转型为什么需要中台架构？实施中台架构为IT带来哪些变化？

（3）中台架构和金融企业目前的应用架构有什么关系？如何演进？

（4）中台架构与分布式、微服务架构是什么关系？

（5）中台架构如何划分，有几个中台？业务中台、技术中台、数据中台有什么关系？

（6）中台实施的方法论是什么？实施中台后软件研发的流程有哪些变化？

（7）实施中台需要组织架构改变做配合吗？如果需要组织架构应该如何变化？

这些问题的根源在于，每个企业中台的实施与企业自身的 IT 状况密切相关。本书希望能够和大家一起探讨金融企业实施中台的背景与要求、原则与方法、架构与技术、流程与组织等各个方面。

1. 金融企业数字化转型的本质是通过数字化手段实现“研产供销服”各环节的全面提升，以适应千人千面的“个性化需求”

金融企业数字化转型是在“深化金融供给侧改革，增强金融服务实体经济能力”的大趋势下开展的，需要“以市场需求为导向，积极开发个性化、差异化、定制化金融产品”，金融企业一般都具有较完善的网点渠道、广泛的客户基础、坚实的业务积累，但是组织决策和业务流程相对比较复杂冗长。数字化转型就是希望通过数字化、智能化手段，实现组织和流程的高效运转，满足客户与合作伙伴个性化、差异化、定制化需求，将金融服务嵌入到客户的生产、生活之中。从其他行业的经验看，数字化转型是企业通过“研产供销服”各环节的数字化，实现大规模的个性化产品制造，即通过市场数字化手段与产品数字化手段，洞察客户需求，快速完成产品的定义与验证，缩短产品研发时间，减少试错成本；通过生产过程的数字化，实现制造的横向集成与纵向集成，提高个性化生产的能力，提高产品质量；通过供应链的数字化，建立完备、高效的物流与供应链体系，实现资源整合，提高效率防止风险；通过营销的数字化，连接客户与企业，构建客户的全渠道触达，实现精准互动与交易，让营销资源的利用更加高效，推广成本降低；通过客户服务的数字化，优化内部服务能力，提升客户体验。金融企业的数字化转型，同样应该在产品设计、产品生产、产品运营、产品营销、渠道接触等五个方面的数字化入手：

（1）通过市场数字化明确客户需求与产品差异化，利用配置化手段快速推出产品，建立统一的产品视图和生命周期管理；

（2）金融企业的产品生产即 IT 系统的建设，通过低代码平台、微服务、DevOps 等手段，建立数字化的应用研发体系，提高应用研发的效率与质量；

（3）实现全渠道的营销覆盖，支持多样化的营销场景，建设丰富的营销运营组件，快速组合营销流程，实时监控营销成果并快速试错；

（4）建设标准化、数字化、配置化的运营流程与运营组件，提高运营流程的定制化能力，通过流程挖掘与员工行为数字化，优化内部运营流程，通过数字化减少员工重复劳动，为一线减负；

（5）整合员工渠道、线上渠道、线下渠道和合作渠道，完善渠道协作体系与营销互动，提高渠道服务体验。

2. 金融企业数字化中台建设是科技部门主导的，是科技建设的抓手

阿里中台建设是“业务变革、机制变革、组织变革、技术架构变革”的全面转型，这种模式的要求较高，实际上这种模式实施失败的例子也不少。金融企业对 IT 的依赖度远远高于其他行业，因此金融企业的中台建设是从 IT 建设的转型与重构开始，由科技部门驱动：

（1）首先，金融企业传统架构上也会分为前后台，前台是渠道层，后台对应账务、产品、风控、人力资源、经营分析，等等，中间一般有控制层，但是我们会发现，一般中间的控制层都很薄，往往被前端渠道和后端产品服务所剥离，因为相关业务在前端和后台都能做，不需要中间层做什么事。不过，后台往往具备稳定的模型、固化的流程，强调自身运转的效率，当数字化转型需要业务更加个性化时，需要与营销、合作伙伴、多渠道互动的时候，就与后台系统的初衷相违背了，造成大量的业务堆积在前台，随着业务增长，前台应用往往变成了牵一发而动全身，因此失去了敏捷性。针对这种情况就需要将中间层做厚，通过中间层将后台系统整合起来，交通银行信用卡中心的大运营平台前端打通了APP、网银、微信等各个渠道，后端衔接了催收、客服、理财、贷款、支付等系统，就取得了良好的效果。

（2）其次，中台是科技部门快速响应业务需求、引领业务需求的抓手，强调在科技部门建立可复用能力的平台。SOA 架构标准化、服务化的要求仍然是需要遵守这个基本原则，同时中台的服务更加强调端到端和柔性（可变性）。所谓端到端是指服务提供者能够尽可能提供一个完整的业务流程供调用者使用，而不是仅仅提供一些细粒度的 API 供调用者组装（虽然这种情况不可避免），复用不是从实现层面来把类似的功能用一段代码完成，而是从使用者的角度出发，为使用者提供一种标准化的使用模式。既然端到端，就更加强调柔性（可变性），也就是适应变化的能力，中台服务需要像接口的标准化一样将服务的可变性透明化提供出来，让使用者可以在固定范围内通过配置化决定服务的行为，而不是依赖接口参数，最后这一点也是最关键的一点。

（3）最后，中台的建设未必一定在企业级，其实这种思路也可以在具体应用建设中采用，把应用按前中后层分离，后端是基础服务，中间层提供可复用、可变化的框架，快速适应前台业务的变化。实际上，中台化是平台化的一个延伸，可以在现有平台的基础上进行中台化的改造。

所以，我们说前台要极致的个性化，要有小惊喜，后台要极致的效率化，要有小感动，而中台要极致的标准化（标准化的接口、标准化的端到端能力、标准化的可变性），要有小确幸。

3. 金融企业数字化中台建设是建立企业级的软件可重用能力

金融企业的中台，是科技部门主导的、以可重用能力为核心的平台，那么中台建设的原则就要围绕着重用进行。重用首先要进行分类，只有通过分类进行解耦，才能明晰边界、确定职责，所谓分科而学。金融企业可重用能力按技术维度可以分为流程与规则、信息与数据、组件与框架三大类，对应到业务中台、数据中台、技术中台三大类。但更重要是业务维度的分解，决定中台的内涵，这些是不同行业中台建设不同的原因，即使同一行业的不同企业也会由于经营状况不同而有差异。传统上商业银行往往将业务分为资产类、负债类和中间业务，但这是按资产负债表构成来做的分类，并不能作为能力可复用的分解。从业务的构成看，金融企业业务都会包括客户交互（渠道）、金融产品服务、产品营销、产品运营、风险控制几个部分，当一个业务方案提出后，可以分解为：

（1）业务在哪些渠道完成，本渠道如何交互，跨渠道如何协作？

（2）业务由哪些产品提供，这些产品需要哪些个性化要求？

（3）该业务通过何种营销手段触达客户？

（4）渠道接受客户请求后，企业内部所需的运营流程如何？

（5）该业务有哪些风险控制因素，如何控制风险。

因此业务中台可以按照这几个方面抽象可重用的流程与规则，供前台应用快速发布业务，同时收集各种数据，供业务进行优化；数据中台根据这几个方面对数据标签化、形成模型，提供数据服务；技术中台根据不同业务类型确定技术组件、集成方式和技术框架，通过工具支持软件研发。需要注意的是：

（1）金融企业的客户交互包括线上、线下与合作伙伴，渠道众多，客户交互要突出渠道整合、渠道协作与多渠道营销互动；

（2）金融企业的产品定义一般都相对灵活，但在个性化产品、产品组合的能力上需要加强；

（3）产品的运营以前一般都在后台系统中完成，中台建设后需要将后台的能力独立出来（例如集中作业、客服等），通过中台的流程组合后为前台应用提供柔性的、端到端的服务能力，另外，传统架构中合作伙伴的概念并不突出，耦合在交易、产品、服务、渠道等流程中，但目前金融企业生态建设过程中，期望将金融服务嵌入到生产、生活当中，有些产品运营的流程需要按照合作伙伴要求定制，因此在产品运营服务中，需要将类似客户、订单、物流、积分等能力独立出来，为合作伙伴业务提供基本的运营能力。

4. 数字化中台建设需要从过程与方法、平台与架构、资产与知识三方面入手

基于中台进行大规模软件研发的方法论，我们建议参照“软件产品线工程”的理论，把软件研发分为领域工程与应用工程两部分，领域工程研发可复用的流程与服务，应用工程基于领域工程的流程配置新业务，或者通过领域工程的服务组合新业务。前面提到，现实中谈到重用的时候，大家往往从技术角度从后往前看，希望做出不重复的代码，实际上的复用是从业务视角看，从使用者视角看，抽象出标准化的流程，同时抽象出这些流程上的可变点，在流程执行时通过配置和当前上下文决定流程的行为，即决定可变点的具体执行方式。这样，就可以在业务中台中预制很多标准化的流程，这些流程已经确定了业务的处理方式，新业务只需要考虑自己的特殊性即可，例如一个线上渠道的业务受理流程一般包括客户交互（信息上传）、要素组织、信息确认、系统处理、业务交付几个环节，每个环节只是客户资料不同、确认方式不同（可以穷举）、处理交易不同（可以穷举）、业务交付内容不同（信息交付、实物交付两种方式可穷举），这个流程可以在业务中台中作为渠道流程组件提供出来，作为业务受理的标准流程。流程包括业务流程（长交易）、操作流程、交易流程（短交易）几种类型，业务的可变性可以包括流程环节可变、业务数据可变、业务规则可变、展现形式可变、人员角色可变，业务中台的技术框架应该支持上述流程的编排、配置与运行，支持上述可变性的描述与配置。我们总结了领域工程的分析设计方法：采用 BPMN 流程驱动的方式、DDD领域驱动的方法、四色原型方法混合完成。DDD（Domain-Driven Design，领域驱动设计）应用在领域划分、业务语言统一、对象模型建立方面，四色原型方法在数据模型建立与展现方面具备独到之处，流程驱动的方式用于分析业务流程。应用工程以领域工程可复用组件为基础，可以建立覆盖业务需求、应用开发、应用发布、应用运营的研发流程，实现配置化的软件研发过程。基于业务中台的软件研发，可以基于低代码平台进行，根据业务类型进行抽象后的可重用能力和框架，提供配置化开发的工具，提高研发效率，例如针对线上渠道业务的合作方开发平台、针对网点渠道的网点开发平台、针对运营类业务的表单/流程/数据处理的开发平台等。

数据中台的建设不同于传统数据仓库的建设：数据在企业应用的建设过程中，存在于各个不同的系统中，这些系统由不同的部门开发、维护，信息存在重复、不完整、冲突等问题，无法形成可被方便使用的资源。为了解决信息在组织内部流通不利的问题，企业往往通过建设数据仓库为代表的 OLAP 系统。但数据仓库系统往往由专业的数据团队进行开发、维护，通过专门的技术/工具，从各个不同的系统中抽取、清洗、转换数据，建立多维的数据模型，产生业务需要的报表。逐渐地，数据团队变成了一个专业、庞大、独立的部门，专门为产生报表服务，这个团队采用了与其他系统开发不同的流程，积累了大量的业务需求，数据源头与数据使用需求不一致导致数据质量难以提高，形成了交易开发、数据开发两张皮的现象。为了快速响应业务需求，支撑业务创新，我们希望每个团队都能够利用数据实现对业务的感知与洞察，不需要等待数据团队来响应他们的需求，能够自己发现数据、使用数据，这就是数据自服务能力，而数据团队的职责是管理数据架构、提供平台与工具、提高数据质量、支持各方对数据的使用、形成数据资产，建立企业的数据自服务能力，简而言之，这就是数据中台的初衷。建立数据中台，需要完成如下工作：

? 转变目前数据团队的目标与组织架构，明确面向数据自服务的数据管理职能；

? 梳理现有全业务系统的数据架构，形成可逐步演进的企业元数据；

? 为数据的使用方提供数据生产线，为数据的收集/转换/存储/探索/可视化等提供方便的工具和研发过程；

? 通过数据标签化、数据关联、画像等手段，形成有重用价值的企业数据资产；基于数据安全策略，提供数据自服务能力。

技术中台的建设是对企业技术架构与研发过程进行抽象与封装，提供可复用能力，同样需要达到标准化、端到端、柔性（可变化）的要求。技术中台包括：可复用的技术组件，提供标准化的使用方法，例如消息、缓存、持久化、前端等；集成组件，将各应用整合起来以一致的视图展现给使用者，例如门户、服务集成、统一身份/认证、对账等；技术框架，根据业务类型的不同提供标准的代码开发框架，例如联机框架、批量框架、联机小批量框架、异步处理框架、前端展现框架等；研发流程，以 DevOps 为核心建立架构、需求、开发、发布、监控、运维的流程。金融企业一般系统很多，采用的技术也不一样，决定了技术中台的建设，同样不要追求一个大一统的平台，而是按照这样的思路循序渐进，也不要追求最先进的实现技术，为开发者提供可复用能力后，底层的技术差异应该被屏蔽掉。我们的经验是，首先考虑的是集成组件，因为多个应用不能整合直接影响了用户的使用体验，也造成了应用间互联互通的困难，而使用集成组件进行整合也容易被不同系统的研发者接受；其次是研发流程的标准化，可以从版本管理、持续集成与发布入手，比较容易达到效果；再次是统一一些技术组件，指导系统使用这些组件，提高应用的质量，最后，在有条件的应用中定义标准化的应用技术架构。

明确了中台建设的目标、原则与方法，可以看出中台建设更多是利用可重用思想，建立标准化、端到端、柔性（可变化）的重用能力，可以从企业级中台开始，也可以从某一业务领域开始，还可以在某一系统入手进行，因此，对金融企业中台建设成熟度的评估，我们建议从业务、架构、流程、组织几个维度入手，参考 CMMI 的成熟度模型。其中业务考量中台建设的产品化能力，包括愿景与策略、融合与创新，是单一项目还是可管理、可度量、可优化的企业行为；架构考量中台的重用能力，是否符合标准化、端到端、柔性（可变化）的标准；过程考量企业软件研发过程，是否建立了可重用、敏捷的过程体系；组织考量金融企业科技团队组织架构与协作关系，是否建立了可重用软件研发的模式。

对于金融科技的从业者，这是一个全新的时代。从B/S 到 SOA 再到中台架构，标志着IT 建设进入到了深水区，一方面 IT 系统不再是简单的信息保存，而是业务数据化，利用数据驱动业务；另一方面IT系统不再是简单的从业务需求转化为系统实现，而是需要通过可复用能力支撑甚至引导业务需求。本书通过七个部分，论述了金融企业中台的背景、目标、原则与分工、业务中台/数据中台/技术中台的实施方法、成熟度评估原则，这也是我们从SOA 架构到中台架构、从平台化到中台化里程碑的总结。

抛砖引玉，是为序。

著者

2020年6月

目 录

第1章 中台之势：金融企业数字化转型背景 1

1.1 数字化经济浪潮下，颠覆与被颠覆成新常态 1

1.1.1 这是一个多变的、敏捷创新的时代 1

1.1.2 数字化经济时代，金融业正在经历着历史性巨变 3

1.2 Bank 4.0时代，敏捷银行已来 4

1.2.1 体验场景化 5

1.2.2 服务生态化 6

1.2.3 运营数字化 8

1.2.4 产品个性化 9

1.2.5 业务敏捷化 9

1.3 当前金融企业的创新举措：加速数字化转型 10

1.3.1 技术融合场景，体验创新 11

1.3.2 技术架构升级，科技创新 12

1.3.3 探索银行开放，生态创新 13

1.3.4 加大科技投入，组织创新 13

1.4 数字化转型的本质：“研产供销服”各环节的敏捷化 15

1.4.1 数字化研发：数据驱动的产品工厂，缩短产品研发时间 16

1.4.2 数字化生产：敏捷化的系统建设模式，个性化业务的批量化生产 17

1.4.3 数字化运营：集中化、自动化的交付，流程再造助力运营效率持续提升 19

1.4.4 数字化营销：场景驱动的智能营销，精准互动交易 20

1.4.5 数字化渠道：全渠道协作无缝衔接，提升客户体验 21

1.5 金融企业数字化转型的关键：中台战略 23

第2章 中台之殇：金融企业中台建设的本质 25

2.1 中台的本质：企业IT架构的一种形式 25

2.1.1 中台概念：为前台而生，提供能力复用 25

2.1.2 中台架构：IT架构发展的必然 26

2.1.3 中台是企业数字化转型下重构IT的最佳选择 28

2.1.4 中台是平台建设的自然延伸 30

2.2 中台之殇，金融中台建设何去何从 31

2.2.1 盲目跟风，奔着中台做中台 31

2.2.2 对中台定位不清，期望包治百病 32

2.2.3 实施中台所需的组织架构不清晰 32

2.3 个性化前台、标准化中台、效率化后台 33

2.3.1 前台要有小惊喜：极致的个性化 34

2.3.2 中台要有小确幸：极致的标准化 35

2.3.3 后台要有小感动：极致的效率化 36

第3章 中台之道：金融企业中台建设方法论 38

3.1 全面解读科技部门主导的金融企业数字化中台 38

3.1.1 企业级可重用能力的建设，是金融企业数字化中台建设的主要手段 38

3.1.2 金融企业数字化中台建设全景图 40

3.1.3 典型的可重用中台架构模式 42

3.2 金融企业数字化中台建设的过程与方法 43

3.2.1 研发过程 44

3.2.2 研发方法 47

3.2.3 评估方法 51

3.3 业务中台架构原则 53

3.3.1 顶层设计，明确业务中台在应用架构中的定位 54

3.3.2 按价值链理论，进行业务中台可重用能力的领域划分 54

3.3.3 能力中心，以形成可独立运营单元为划分原则 56

3.3.4 流程建模，抽象端到端、柔性的可重用流程 58

3.3.5 产品中台：产品工厂与业务中台的关系 61

3.3.6 渠道中台：体验整合、流程整合、数据整合、营销整合 63

3.3.7 运营中台：打造标准化运营流程，支持新业态 65

3.3.8 营销中台建设原则 69

3.3.9 业务中台与低代码平台 71

3.4 数据中台设计原则 73

3.4.1 数据中台建设的价值架构 73

3.4.2 金融机构数据中台架构 74

3.4.3 数据中台必备的5大核心能力 76

3.5 技术中台架构原则 77

3.5.1 通过“5S管理”的思路，建立柔性的软件生产线 78

3.5.2 建立标准化的企业集成架构与应用技术架构 82

3.5.3 利用“端到端”的思路，沉淀业务组件与技术组件 84

3.6 中台建设的组织保障 86

3.6.1 中台组织架构模式：科技双模 87

3.6.2 产品/需求/架构角色分离 88

3.6.3 敏捷团队转型，从小团队模式开始 90

3.6.4 建立对齐业务的科技部落 91

第4章 中台之法一：金融企业业务中台建设 92

4.1 业务中台建设的相关方法 92

4.1.1 需求的结构化描述方法 92

4.1.2 可重用体系架构的设计方法 113

4.1.3 业务可变性设计方法 125

4.2 业务可变性技术框架 134

4.2.1 技术框架解决可变性问题 134

4.2.2 从技术框架角度看可变性 136

4.2.3 技术框架的运行机理 143

4.3 业务中台关键设计 146

4.3.1 产品中台，产品工厂在业务中台的实现 146

4.3.2 渠道中台，线上线下一体化服务流程的通用性与可变性分析 151

4.3.3 运营中台，产品服务流程的标准化与柔性 156

4.3.4 营销中台，精准营销的标准化与柔性 172

4.4 低代码平台，高效率创建新应用 179

4.4.1 基于可重用的业务组件支撑业务需求快速落地 180

4.4.2 整体的可扩展性是平台可持续发展的保障 189

4.4.3 平台需要全面支撑应用的生命周期 191

第5章 中台之法二：金融企业数据中台建设 194

5.1 数据中台之认知篇 194

5.1.1 金融企业数据中台的挑战 194

5.1.2 什么是数据中台 195

5.1.3 数据中台vs数据仓库 196

5.1.4 数据中台vs业务中台 197

5.2 数据中台之方法篇 197

5.2.1 数据中台之“盘”，关键是盘活数据 198

5.2.2 数据中台之“规”，重点在标签体系 200

5.2.3 数据中台之“整”，难点在数据治理 211

5.2.4 数据中台之“用”，体现在数据服务 217

5.3 数据中台之应用篇 218

5.3.1 银行网点绩效优化 219

5.3.2 精准营销 221

5.3.3 风险管控 224

第6章 中台之法三：金融企业技术中台建设 227

6.1 应用集成架构，提高企业应用的整合能力 227

6.1.1 统一身份认证 228

6.1.2 统一组织机构用户数据 231

6.1.3 统一应用门户 234

6.1.4 统一任务中心 237

6.1.5 服务集成平台 239

6.1.6 文件传输 246

6.1.7 作业调度 248

6.2 DevOps，建立数字化的软件生产线 250

6.2.1 软件生产过程中的十四大浪费 250

6.2.2 建立数字化生产线的软件生产全流程 257

6.2.3 打造数字生产线需要做到的五个统一 259

6.2.4 度量与引领性指标必不可少 261

6.2.5 金融企业引入以DevOps为基础的数字化生产线的五点建议 264

6.3 微服务化的应用技术架构与技术组件 265

6.3.1 从业务发展来看应用技术架构的变迁 265

6.3.2 从技术发展来看应用技术架构的变迁 266

6.3.3 当前应用技术架构微服务化出现的问题与解决原则 267

6.3.4 服务分布，流程聚合的服务设计原则 269

6.3.5 数据分布与信息聚合的设计模式 274

6.3.6 感觉分布与知觉聚合 280

第7章 中台之术：金融企业中台成熟度模型 286

7.1 基于业务、架构、软件过程和组织保障的多维成熟度模型简介 286

7.2 成熟度分级模型评估框架 288

7.2.1 业务成熟度模型 288

7.2.2 架构成熟度模型 291

7.2.3 软件过程成熟度模型 293

7.2.4 组织保障成熟度模型 294

7.3 成熟度评估流程 296

7.3.1 评估准备 297

7.3.2 执行评估 297

7.3.3 分析评估 299

7.3.4 报告结论 299