前 言
中台的概念已经不需要解释来龙去脉了，它像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月
