由广东农村信用社联合社银信中心副总裁周丹以及普元数字化金融研究院，共同通过深入的行业研究和丰富的实施经验编写而成的《金融企业数字化中台》，将于9月10日重磅发布！
本书立足于对金融企业更加重要的业务中台规划，为商业银行、农村金融机构等金融企业提供中台建设参考，适合金融行业CIO、IT经理、业务规划人员以及中台系统研究人员。
全书分为7大章节解答金融企业数字化转型本质、中台架构和金融企业目前的应用架构的关系以及如何演进、划分、配合等问题。
第1章 中台之势：金融企业数字化转型背景
以下节选部分内容供广大读者试读，希望管中窥豹带领大家了解作者思路，理解金融企业实施中台的背景与要求、原则与方法、架构与技术、流程与组织等各个方面。
金融企业数字化中台建设是建立企业级的软件可重用能力
金融企业的中台，是科技部门主导的、以可重用能力为核心的平台，那么中台建设的原则就要围绕着重用进行。重用首先要进行分类，只有通过分类进行解耦，才能明晰边界、确定职责，所谓分科而学。
金融企业可重用能力按技术维度可以分为流程与规则、信息与数据、组件与框架三大类，对应到业务中台、数据中台、技术中台三大类。
但更重要是业务维度的分解，决定中台的内涵，这些是不同行业中台建设不同的原因，即使同一行业的不同企业也会由于经营状况不同而有差异。
传统上商业银行往往将业务分为资产类、负债类和中间业务，但这是按资产负债表构成来做的分类，并不能作为能力可复用的分解。从业务的构成看，金融企业业务都会包括客户交互（渠道）、金融产品服务、产品营销、产品运营、风险控制几个部分。
1. 业务在哪些渠道完成，本渠道如何交互，跨渠道如何协作？
2. 业务由哪些产品提供，这些产品需要哪些个性化要求？
3. 该业务通过何种营销手段触达客户？
4. 渠道接受客户请求后，企业内部所需的运营流程如何？
5. 该业务有哪些风险控制因素，如何控制风险。
因此业务中台可以按照这几个方面抽象可重用的流程与规则，供前台应用快速发布业务，同时收集各种数据，供业务进行优化；数据中台根据这几个方面对数据标签化、形成模型，提供数据服务；技术中台根据不同业务类型确定技术组件、集成方式和技术框架，通过工具支持软件研发。
（1）金融企业的客户交互包括线上、线下与合作伙伴，渠道众多，客户交互要突出渠道整合、渠道协作与多渠道营销互动；
（2）金融企业的产品定义一般都相对灵活，但在个性化产品、产品组合的能力上需要加强；
（3）产品的运营以前一般都在后台系统中完成，中台建设后需要将后台的能力独立出来（例如集中作业、客服等），通过中台的流程组合后为前台应用提供柔性的、端到端的服务能力，另外，传统架构中合作伙伴的概念并不突出，耦合在交易、产品、服务、渠道等流程中，但目前金融企业生态建设过程中，期望将金融服务嵌入到生产、生活当中，有些产品运营的流程需要按照合作伙伴要求定制，因此在产品运营服务中，需要将类似客户、订单、物流、积分等能力独立出来，为合作伙伴业务提供基本的运营能力。
数字化中台建设需要从过程与方法、平台与架构、资产与知识三方面入手
基于中台进行大规模软件研发的方法论，我们建议参照“软件产品线工程”的理论，把软件研发分为领域工程与应用工程两部分，领域工程研发可复用的流程与服务，应用工程基于领域工程的流程配置新业务，或者通过领域工程的服务组合新业务。
前面提到，现实中谈到重用的时候，大家往往从技术角度从后往前看，希望做出不重复的代码，实际上的复用是从业务视角看，从使用者视角看，抽象出标准化的流程，同时抽象出这些流程上的可变点，在流程执行时通过配置和当前上下文决定流程的行为，即决定可变点的具体执行方式。这样，就可以在业务中台中预制很多标准化的流程，这些流程已经确定了业务的处理方式，新业务只需要考虑自己的特殊性即可。
例如一个线上渠道的业务受理流程一般包括客户交互（信息上传）、要素组织、信息确认、系统处理、业务交付几个环节，每个环节只是客户资料不同、确认方式不同（可以穷举）、处理交易不同（可以穷举）、业务交付内容不同（信息交付、实物交付两种方式可穷举），这个流程可以在业务中台中作为渠道流程组件提供出来，作为业务受理的标准流程。
流程包括业务流程（长交易）、操作流程、交易流程（短交易）几种类型，业务的可变性可以包括流程环节可变、业务数据可变、业务规则可变、展现形式可变、人员角色可变，业务中台的技术框架应该支持上述流程的编排、配置与运行，支持上述可变性的描述与配置。
我们总结了领域工程的分析设计方法：采用 BPMN 流程驱动的方式、DDD领域驱动的方法、四色原型方法混合完成。DDD（Domain-Driven Design，领域驱动设计）应用在领域划分、业务语言统一、对象模型建立方面，四色原型方法在数据模型建立与展现方面具备独到之处，流程驱动的方式用于分析业务流程。应用工程以领域工程可复用组件为基础，可以建立覆盖业务需求、应用开发、应用发布、应用运营的研发流程，实现配置化的软件研发过程。
基于业务中台的软件研发，可以基于低代码平台进行，根据业务类型进行抽象后的可重用能力和框架，提供配置化开发的工具，提高研发效率，例如针对线上渠道业务的合作方开发平台、针对网点渠道的网点开发平台、针对运营类业务的表单/流程/数据处理的开发平台等。
数据在企业应用的建设过程中，存在于各个不同的系统中，这些系统由不同的部门开发、维护，信息存在重复、不完整、冲突等问题，无法形成可被方便使用的资源。为了解决信息在组织内部流通不利的问题，企业往往通过建设数据仓库为代表的 OLAP 系统。
但数据仓库系统往往由专业的数据团队进行开发、维护，通过专门的技术/工具，从各个不同的系统中抽取、清洗、转换数据，建立多维的数据模型，产生业务需要的报表。逐渐地，数据团队变成了一个专业、庞大、独立的部门，专门为产生报表服务，这个团队采用了与其他系统开发不同的流程，积累了大量的业务需求，数据源头与数据使用需求不一致导致数据质量难以提高，形成了交易开发、数据开发两张皮的现象。
为了快速响应业务需求，支撑业务创新，我们希望每个团队都能够利用数据实现对业务的感知与洞察，不需要等待数据团队来响应他们的需求，能够自己发现数据、使用数据，这就是数据自服务能力，而数据团队的职责是管理数据架构、提供平台与工具、提高数据质量、支持各方对数据的使用、形成数据资产，建立企业的数据自服务能力，简而言之，这就是数据中台的初衷。
建立数据中台，需要完成如下工作：
l 转变目前数据团队的目标与组织架构，明确面向数据自服务的数据管理职能；
l 梳理现有全业务系统的数据架构，形成可逐步演进的企业元数据；
l 为数据的使用方提供数据生产线，为数据的收集/转换/存储/探索/可视化等提供方便的工具和研发过程；
l 通过数据标签化、数据关联、画像等手段，形成有重用价值的企业数据资产；基于数据安全策略，提供数据自服务能力。
技术中台的建设是对企业技术架构与研发过程进行抽象与封装，提供可复用能力，同样需要达到标准化、端到端、柔性（可变化）的要求。
技术中台包括：可复用的技术组件，提供标准化的使用方法，例如消息、缓存、持久化、前端等；集成组件，将各应用整合起来以一致的视图展现给使用者，例如门户、服务集成、统一身份/认证、对账等；技术框架，根据业务类型的不同提供标准的代码开发框架，例如联机框架、批量框架、联机小批量框架、异步处理框架、前端展现框架等；研发流程，以 DevOps 为核心建立架构、需求、开发、发布、监控、运维的流程。
金融企业一般系统很多，采用的技术也不一样，决定了技术中台的建设，同样不要追求一个大一统的平台，而是按照这样的思路循序渐进，也不要追求最先进的实现技术，为开发者提供可复用能力后，底层的技术差异应该被屏蔽掉。
我们的经验是，首先考虑的是集成组件，因为多个应用不能整合直接影响了用户的使用体验，也造成了应用间互联互通的困难，而使用集成组件进行整合也容易被不同系统的研发者接受；其次是研发流程的标准化，可以从版本管理、持续集成与发布入手，比较容易达到效果；再次是统一一些技术组件，指导系统使用这些组件，提高应用的质量，最后，在有条件的应用中定义标准化的应用技术架构。
明确了中台建设的目标、原则与方法，可以看出中台建设更多是利用可重用思想，建立标准化、端到端、柔性（可变化）的重用能力，可以从企业级中台开始，也可以从某一业务领域开始，还可以在某一系统入手进行。
因此，对金融企业中台建设成熟度的评估，我们建议从业务、架构、流程、组织几个维度入手，参考 CMMI 的成熟度模型。
其中业务考量中台建设的产品化能力，包括愿景与策略、融合与创新，是单一项目还是可管理、可度量、可优化的企业行为；架构考量中台的重用能力，是否符合标准化、端到端、柔性（可变化）的标准；过程考量企业软件研发过程，是否建立了可重用、敏捷的过程体系；组织考量金融企业科技团队组织架构与协作关系，是否建立了可重用软件研发的模式。
对于金融科技的从业者，这是一个全新的时代。从B/S 到 SOA 再到中台架构，标志着IT 建设进入到了深水区，一方面 IT 系统不再是简单的信息保存，而是业务数据化，利用数据驱动业务；另一方面IT系统不再是简单的从业务需求转化为系统实现，而是需要通过可复用能力支撑甚至引导业务需求。
本书通过七个部分，论述了金融企业中台的背景、目标、原则与分工、业务中台/数据中台/技术中台的实施方法、成熟度评估原则，这也是我们从SOA 架构到中台架构、从平台化到中台化里程碑的总结。
9月10日14:00，《金融企业数字化中台》新书重磅发布，三位作者莅临现场，共同分享关于金融企业数字化中台建设的经验方法，扫码观看直播第一时间赢取新书！
普元信息
股票代码：688118
↓↓↓ 点击"阅读原文" 【查看更多信息】