| 编辑推荐: |
本文主要介绍了什么是中台、为什么建设中台、银行业务中台架构设计、及作者在银行的实践经验分享。
来自于微信公众号架构师社区，由火龙果软件Linda编辑、推荐。 |
|
前言：什么是中台？
开始正题之前，首先要讨论下什么是中台。按网上搜集到的信息，有些人说中台是技术中台，像微服务开发框架、Devops平台、PaaS平台，容器云之类的；有些人说中台就是微服务业务平台，像最常见的什么用户中心、订单中心，各种微服务集散地，叫做”业务中台“；还有人说中台是组织的事情，组织架构有调整的话，
也可以叫”组织中台“；也有人说中台是一种思想，一种体系，可以快速聚合后台的数据与能力。因此不同的人对中台有不同的理解。
在三湘银行去年做中台项目的时候，我们在网上找到了一个定义：中台是企业级能力复用平台。这是我们去年比较认同的概念，理由是：
企业级定义了中台的范围，区分开了单系统的服务化与微服务；
能力定义了中台的主要承载对象，能力的抽象解释了各种各样中台的存在；
复用定义了中台的核心价值，传统的平台化对于易复用性并没有给予足够的关注，中台的提出和兴起，让人们通过可复用性将目光更多的从平台内部转换到平台对于前台业务的支撑上；
平台定义了中台的主要形式，区别于传统的应用系统拼凑的方式，通过对于更细力度能力的识别与平台化沉淀，实现企业能力的柔性复用，对于前台业务更好的支撑。
在去年我们主要使用此定义描述对中台的理解。
但是上面这些概念是否能真正解释中台？在中台项目完成后，我又重新做了思考。如果按照上面的定义，并不能完全清晰说明什么是中台。因为传统的SOA架构、微服务架构、标准化和平台化的一些改造都可称之为”中台“，所以中台的概念感觉还不是太清晰。
我们看一个中台的演变示例，它是参考了阿里架构的演变。假设有一家电商公司，一开始创建了中间蓝色这块食品电商平台，实现了一些订单、商品、用户、支付的功能。食品电商平台对应的业务部门是食品业务部。
后来随着公司业务发展，又成立了药品业务部，通过复制食品电商平台的模式创建了对应的药品电商平台，其实这个新平台用到的功能类似于食品电商平台。但由于这两个平台售卖的货物存在差异，两个平台并没有结合。公司再大点，就汽车电商平台。最后，三个平台各自独立发展自己的服务架构和内部的业务管理。
在支付功能层面，这个公司的不同电商平台可能会跟不同的支付机构进行合作来实现交易功能。三个电商平台都有对应的用户管理和支付功能。由于三者处于竞争关系，导致支付通道不能实现统一。
基于这些问题，公司不得不开始建中台。把三个电商平台负责用户管理的人力集中起来，成立用户拓展部，创建起用户中台，实现用户的管理和营销功能；同理公司又成立了支付结算部，创建支付中台。当公司建立起用户中台和支付中台，它的用户管理和支付管理能力就能统一起来，整合了资源，这就是中台的大致的演变示例。
根据这个示例我提出了一个新中台概念，中台是基于企业资源整合的需要，通过运营模式变革、组织架构调整、IT架构重构等方式形成的企业级服务复用能力。
中台的战略目标是实现企业资源整合；
中台的能力体现在企业级的能力复用；
中台的实现手段是运营模式变革、组织架构调整、IT架构重构，且运营模式变革是重点；
中台可以解决一些问题：突破组织壁垒，不会因为组织间的竞争关系导致资源只能服务某一个部门；统一公司内部资源，实现资源共享；快速支持业务创新。
一、为什么建中台？
讲完中台的概念，我们想想银行为什么要建中台。
大部分银行的组织架构和图类似，银行组织架构本身已经区分出前中后台的体系：像营业部、分支行、金融市场部等做具体对客业务拓展的部门属于银行前台部门；对于一些做业务管理和产品设计的部门，像风险管理部、信贷审批部属于银行的中台部门；而银行内部的管理机构，像办公室、人力资源部等服务于银行经营的部门则属于银行的后台部门。
再看看传统银行的IT架构设计。最上面的是银行的渠道端，就是对客部分的系统和一些整合服务平台；中间部分属于银行金融产品运营类的系统，由于银行的金融产品种类特别多，所以对应系统也非常多；在后台，会有银行核心系统，包括互联网核心系统、银行核心系统和账户系统；最下面的是BI类的系统。从架构图可以看出，银行的系统数量非常之多。就拿三湘银行这样小的银行来讲，系统数量其实也有140多个。
正因为银行IT系统数量众多，通常银行都会存在以下几个问题：
能力重复建设：不同系统基础能力重复建设，例如客户信息管理、账户管理,新建系统或优化规则时造成整体成本的浪费和项目周期的增加；
系统调用复杂：新产品的实施会涉及多个关联系统共同改造，导致改造成本高且实施周期长；
产品/账户/交易/核算紧耦合：产品与账号、交易与核算的处理放在同一个模块中实现，当需要产品支持不同的账号类型、交易需支持不同核算规则时，则必须通过修改代码逻辑或接入相应的新系统才能实现相应功能；
架构复杂难以重构：调整架构所需的成本、周期、业务影响和风险，因此多数采取局部优化的方式，难以一次性完成整体架构重构。
从推出一个全新产品的实施周期来看，银行跟新兴互联网公司会有不少差距。金融科技公司一般在1个月以下，传统商业银行通常要3个月以上，大行可能需要半年到一年时间。
到这里我们已经看出为什么银行要建业务中台，其实银行建业务中台的驱动力不是来自业务部门。对于商业银行来说，它的业务运营和组织架构本身就是前中后台的模式，本身就切合中台的设计理念。业务部门对中台的建设并没有太急迫的需求，动力不足，即使不建中台，其业务的流转还算顺畅。实际上银行的中台项目的发起都是由科技驱动力为主。随着互联网金融竞争加剧，业务对需求的响应时间要求逐渐向互联网企业看齐。而传统银行应用架构难以支持这种快速响应、快速上线的改变，因此科技部门迫切期望通过中台项目改变IT的交付效率，这就是银行建中台最大的驱动力。
二、银行业务中台架构设计
对于中台的建设，会有很多种不同的设计。主要以三湘银行中台设计为示例供大家参考。
首先我们讲下建业务中台要解决的问题。银行建中台最大的问题主要解决新产品上线成本高、周期长这两个问题。
该图是银行某个简单产品的流转示意图，左边是渠道系统，中间两个是产品系统A和产品系统B，负责提供产品的服务；右边是银行账户类的系统，像传统核心和互联网核心，还有涉及第三方支付系统。大家可以看到，我们如果要做一个产品的购买，渠道系统要对接到每个产品系统来实现产品的展示，以及发起一个产品的购买交易。通常银行会把一些产品的扣款，以及支付的一些功能落在产品系统上，由产品系统去对接银行的核心，以及银行相应的支付系统实行资金扣划。
每创建一个产品，每个渠道系统要实现同样的一套接口对接。看图右边列出了主要的五个接口，实际上真实情况下接口数量会比图中的更多。
对于产品系统来说，除了要提供渠道系统要访问的接口以外，还要实现跟行内核心系统以及支付系统对接的一些功能。大家可以看到，当产品系统越多，那渠道系统要实现对接的接口数就越多。
另外产品系统也需要对接行内的一些系统，以接入核心系统系统为例，假设我们有两个核心系统，一是银行核心，二是互联网核心，那么产品系统就要实现两个核心系统的对接。如果是支付系统的话，每一个支付通道就要接一次，比如人行系就有大额支付、小额支付、超级网银这三种支付通道，再加上微信、支付宝等等其他第三方支付通道。同时，产品系统还要实现记账和支付的异常处理的功能，这些规则如果没处理好，也会容易造成银行的短款和账务问题。这就是为什么银行在现有传统架构下创建一个新产品成本高和周期长的原因。建中台的目的就是为了解决这么一个问题。
那针对上述问题，就有了四个对应的业务中台设计目标：
快速创新，这是最主要的目标，支持创新产品的快速实施，并能有效降低整体成本和实施周期；
系统复用：不推翻现有银行的整体应用架构，已有系统可以得到有效复用，无需重构现有系统；
全业务支持：支持银行现有业务场景在新架构的落地；
平滑过渡：支持现有业务场景的新老架构并行和逐步迁移，实现业务的平滑过渡，降低中台建设过程的实施风险。
基于以上四个目标，三湘银行在去年建业务中台的时候，挑选了银行六个最基本的业务能力去建对应中台，也是第一期业务中台建设项目中六个最核心的功能：用户中心、账户中心、支付中心、核算中心、交易中心、产品中心。
我们认为业务中台的定位为：作为产品系统与渠道系统、账户系统、支付系统、核算系统之间的桥梁，利用传统银行应用架构中已有的系统，通过标准业务模型来实现系统间的解耦。这个业务中台的理念其实跟平台标准化、或者SOA的理念很相近，不过还涉及到业务模型的调整。所以三湘银行的业务中台跟一个纯IT项目还是有所区别的。
1、用户中心
首先讲用户中心。那用户中心要解决的其实有五个问题：客户管理、生命周期管理、电子渠道互通、客户信息整合、签约管理。
设计用户中心就是要解决这些上面五个问题。
对于用户中心来说，首先要解决的就是用户生命周期的问题。可能大家也会有疑问，为什么会叫做用户中心，而不把它称为客户中心？
在做用户中心设计的时候，我们有思考过这个问题，实际上用户和客户的定义是有所区别的。在传统银行来说，它通常会把开了账户的客户才叫客户，对其他用户银行基本上是不管的。就像游客，银行基本上是不登记游客的信息。但是互联网公司就不一样了，互联网公司会收集游客、注册用户、实名用户、实体用户的信息进行管理，包括登录信息、浏览信息，目的是为了更好去做客户的营销，以及提升客户体验。我们把互联网公司这套设计模式放到用户中心里面。
我们要求把从游客开始到实体用户这四类型的用户都要管起来。
第一类游客，纯过来浏览，但是没有做过任何注册，也没有留下任何联系方式的。但实际游客还有一个关键信息我们可以保留，那就是游客的设备号，就是他通过某个手机访问，后期可以通过这个设备号就能找到这个游客是谁；
第二类是注册用户，只要他在银行渠道或系统留下了联系方式，像手机号、微信号、邮箱，就认为他是一个注册用户，这代表我们可以联系到客户；
第三类就是实名用户，实名用户顾名思义就是客户在银行系统中通过了实名认证，比如通过了身份证认证、人脸识别。这类用户就叫实名用户；
第四类实体用户跟传统银行的概念一致，就是在银行开过户的客户。
对于这四类用户，在用户中心都需要统一进行管理，包括用户信息管理、用户行为登记等等。
在用户中心里面，还会设计统一登录的功能，比如说用户能够在三湘银行所有的电子渠道上支持用户名这种方式登录，或者手机号登录，或者账号邮箱登录，就是在各个电子渠道都是一致的。同时，也可以通过一些设备的验证方式，比如说人脸登录、指纹登录、手势、扫码这些登录方式，也能支持一些第三方的登录方式，像微信、支付宝授权登录，这些登录模式我们的用户中心上面都能支持。
第二块就是统一签约。统一签约这块我们会把用户所有签约的数据，都会在用户中心有管理起来，同时所有的签约和解约的动作，都会在用户中心上支持，这样保证能在用户中心查到用户所有的签约内容，以及实现所有用户的签约解约的动作。
第三块就是统一视图，把所有跟客户相关的信息，包括客户的基本信息，客户的私有资产、负债的信息，客户的交易流水还有一些行为，都会统一在用户中心对外展示。这就是统一视图的概念。
实际上用户中心的整体功能包括六部分：
下面这个图是用户中心大体功能示意图，除了刚才介绍的客户管理、统一视图等功能以外，还有关联管理能力，无非就是把客户的收藏夹、收款人名册、收件人地址类似这些信息在所有渠道上共享，这样使用户在银行所有的终端都能获取到他的信息，提升客户的体验。
所以说整个用户中心等同于传统银行几个系统的集合，一个就是ECIF，其次就是实时CRM，实时能获取用户360°的视图，再加上对于用户在所有渠道端操作和体验的渠道支持，这就是对于传统银行用户管理能力的整合。
2、产品中心
产品中心需要解决的问题有以下四点：产品目录、产品管理、产品查询、产品上下架。
对于产品中心，我还想解释几个概念：
我们做的产品中心就属于狭义上的产品管理类系统。
上图是我们产品中心整体的功能架构。
左边是管理产品的基本属性，包含产品的基本信息、销售属性，比如它在哪个渠道销售、销售额；促销信息，某个产品在某个期限可以打折，或者通过优惠券减免手续费等；收费信息，购买某个产品所需要收取的对应手续费，类似以上这些就是产品基本信息的管理。
但其实还会存在某些信息需要从各个产品系统上同步过来。相当于产品中心一方面会从传统核心系统把产品同步回来，另外在产品中心维护好某些产品信息，也可以反向把这些信息同步到产品系统，实现对应的产品的创建。这是产品中心里面产品属性管理的一个功能。
在产品中心那块，属于产品渠道和店铺的管理，其实在做产品中心设计的时候，就考虑到把产品中心作为统一销售管理的功能。在产品渠道里面，我们设计了店铺和机构的概念，在店铺（机构）底下设置了分类，那对于所有的产品，就会上下架到所有的分类里面。
比如说在分类里面会有一个推荐或热销的产品分类，那可以在产品中心进行配置把产品上架到对应的产品分类。那对于渠道系统来说，就能直接看到这些分类上面的产品清单和产品的信息。同时产品中心会实现所有产品信息的缓存，所以它能支持一个高并发的产品查询。所以说所有的渠道系统不用再去访问一个具体的产品运营系统，相当于手机银行就不用再去访问核心系统就能获取对应的产品信息。所有要销售的产品都从产品中心直接获取就可以了。
同时产品中心还会有个功能——实现产品的过滤。渠道系统可以把查询产品对应的渠道和客户标签送给产品中心，产品中心可以通过产品所设置的可销售渠道以及可销售客群来决定哪些产品能够在渠道上能看到。
比如说有个客户登录了手机银行，他查看他能购买的产品时候，产品中心就会根据该客户能看到的产品返回对应的产品信息，不需要渠道系统再去做对应的产品信息过滤，从而实现千人千面的产品销售展示功能。
3、核算中心
三湘银行今年才开始建核算中心，去年建业务中台的时候还没有把核算中心建起来。
这是建核算中心要解决的4个问题。要理解这4个核算中心的问题，先讲下银行的账务处理流程。其实银行的账务处理通常是这样：客户在银行的交易系统上可能产生了一笔交易，这个交易可能是一个产品的购买，那这笔交易实际上会实时的输送到核心系统来进行产品的扣账，以及对客户产品账户的入账。
比如说一个理财产品的购买，客户就需要实时把他理财购买所花的钱扣下来，同时对客户生成一个理财产品的分户，把他所持有的理财产品份额送入他的分户里面。这部分交易需要实时实现，在我们银行内称为“客户账”，就是跟客户相关的账。
其实银行里面还有另外一部分账，叫做总账，就是银行账。银行账一般来说属于银行内部使用，用于实现银行核算报表，资产负债报表等信息。这些账没有要求一定要实时，所以通常在银行里面夜间通过批次的方式进行记账处理。
所以建核算中心就是为了要解决刚才说的4个问题，分成核算规则配置、批量过账、实时过账3个功能：
这是我们设计核算中心的一个大的流程图：
大家可以看左边，当你实时处理一笔交易的时候，交易系统是不需要再产生银行核算的这部分账户。它也不需要关心银行核算的规则，只需要实现银行客户账的扣钱，以及产品的入账。把这个做了就行了。然后交易系统就可以把这个交易数据，和它的交易流水直接送到核算引擎里面，那核算引擎会把交易流水的接口映射成银行内部的标准交易格式，再关联上配置好的记账账套。比如说一笔交易流水会有多少借贷的分录，以及借贷的金额该怎么计算，这些都是通过对应的配置实现，最终核算引擎会生成具体的银行账的借贷分录，再把该分录实时送给总账记账。这就形成我们实时记账的功能。
同时对于批量来说，它其实跟实时记账很像。批量的话，可能该系统通过准实时模式集合了一批的账户，或者说每天夜间集合了所有的账户，送给核算引擎，核算引擎也是用刚才处理的这些方式，把生成对应的这些交易数据快速登录送到总账去进行批量计算。这是一个核算大的流程设计。
4、账户中心
账户中心要解决的问题有四个：账户能力重复建设、跨系统记账复杂、账户能力参差不齐、缺乏统一账户视图。
在账户中心的设计里面，我们提出了三个概念：产品与账户分离、介质与账户分离、账户与账户分离。
刚才在讲到产品中心的时候，其实讲到产品的概念，产品属于一些运营规则集合。把产品跟它的账户分开有什么好处呢？举个例子，在传统的核心系统上，有一个产品已经实现了一套规则，这个规则假设放在I类户里是可以用的，但放在II类户是用不了的。如果要实现同样的产品规则，那必须要花时间重新进行开发，又比如未来遇到积分系统要实现类似的功能，我们又要去积分系统上实现对应的规则。
如果能把账户和产品剥离开，自然而然一套的产品规则可以应用在不同的账户上，就像刚才说的存款取利息的功能就可以放到I类户也行，II类户也可以，甚至像一些积分账户也能做到对应规则的处理。
第二块概念就是介质与账户分离。这里面主要还是区分介质的概念。介质是由银行提供给客户，用于证明客户身份的凭证，介质本身不具备金融属性。真正具备金融属性的是介质所绑定的账户。把介质跟账户区分开有很多好处，比如说客户的卡丢了，他换卡只是换介质，只需要重新绑定原来的账号，另外账户和介质分离后也能支持一个账户绑定多个介质。
最后一个概念是账户与账户分离，这其实相当于在设计上把所有的账户放在同一个层级中，而账户和账户之间的关系是通过账户中心的合约管理来去实现这些账户之间的关系。通过账户之间的合约可以实现各种各样的账户层级关系支持，扩展性也会比较高。这也是账户中心的设计理念。
我们在设计账户中心的时候，也设计了账户的基本模型：
这个账户基本模型包括了账户的基本信息，账单信息，冻结/止付信息，余额信息，扩展信息，合约关系，介质绑定。我们把所有的账户都统一抽象为这样的一个模型，对所有的账户都会按照这个模型做管理和访问。对账户来说，我们还会提供一些标准的基础功能，比如说账户的限额管理、合约管理、智能路由、睡眠户管理这些基本的账户功能。
其次我们还把账户的基础功能标准化成几个最基础的原子服务：所有账户的操作无非都是开户、销户记账（存/取/冲正）、冻结解冻/止付解止、挂失、查询、信息变更。这些功能对于所有的账户都是一样的。把账户服务都标准化以后，在银行里面进行账户的处理，包括记账、冻结等操作，都可以沿用这个统一模型去做处理。
对账户中心里面刚才说的合约概念，大家可能不清晰。其实我们把合约认定为账户和账户之间的关系，并且通过合约可以实现账户和账户之间一个资金流向的管理。这个图提出了5个账户流向的管理：
资金流转合约：进行账户之间的资金流向限定，即限制账户资金只能向签订了合约的账户转入；
虚拟子账户合约：账户上实下虚，将结算户与虚拟户结合形成类似会员卡性质的资金台账管理，虚拟户的动账联动执行结算户的动账；
虚户资金归集合约：账户上虚下实，将多个结算户资金归集到一个虚拟户统一展示，结算账户的动账联动执行虚拟户的动账；
资金归集合约：将多个产品户与结算账户关联，通过产品户控制结算账户的资金用途，产品户的动账联动执行结算户的动账；
集团账户合约：通过合约将集团公司之间的账户关系关联起来，供业务应用进行集团账户的操作和管理。
各种各样的账户关系其实都是通过合约类型去支持，而且合约类型未来还可以不断拓展。
在账户中心的建设里面，我们也考虑到成本的问题。不可能说建一个账户中心就把原来的账户系统全部干掉，把账户都迁移过来，所以在建账户中心的时候，要考虑账户中心本身有账户功，能但同时也能实现把原有的账户系统直接对接过来。比如说我们要把传统核心的I类户接入进来，可以通过一个适配接口把传统核心接入账户中心。
那对于外围的产品系统，它以后不会再直接去访问传统核心，而是所有对账户中心操作的处理都通过账户中心的标准服务去访问，来实现对所有账户的处理。通过这种模式，可以让所有渠道、产品系统对账户的操作都可以采取同一个模型，而且都通过账户中心来实行。那未来假设有某些系统我们要重构的时候，这时候自然而然就可以把对应的账户迁移到账户中心实现。这个模式可以极大地减少数据迁移的成本，以及避免了比较大的实施风险。
5、支付中心
所有银行都有统一支付的概念。支付中心要解决的问题其实跟统一支付的概念类似：
对支付中心的设计我们提了一些概念：
我们把银行的I类户的扣账也放到支付中心处理，并且将所有涉及的资产的动账我们都放到支付中心去实现。
以下这个图就是刚才说的支付中心的大致功能图。
其实我们把三块支付、记账、产品通道都交给统一支付去实现。这个支付模式和我们后面讲的支付订单模式会有关系。支付概念的变化是我们这次做中台一个比较大的特点。
6、交易中心
交易中心原来在银行基本不怎么提到，交易中心主要解决的问题有：
那基于刚才那几个问题，我们在建中台提到一个订单的概念，就相当于我们利用了一个电商的订单模型来去创建银行的一个交易过程，大家可以看到现在这个图，是我们交易中心里面的订单模型。
对于渠道系统来说，它每次发起一个产品购买行为，其实就是创建了一个订单，然后呢订单里面有的信息跟电商很类似，第一会有订单最基本的信息——订单日期、币种、总金额、执行参数等信息；第二个就是产品的交付清单信息——产品信息、购买数量、支付金额、扩展信息，这个交付清单可以放多个产品在里面；第三个的话就有费用调整清单，涉及到我在处理这张订单需要收费或者促销、优惠的调整，调整整体上要支付的金额，这个可以通过费用调整这块实现；最后就是对于这个订单通过什么样的支付工具去进行支付，比如通过I类户还是II类户，或者通过第三方的账户去支付。可以支持在订单里放进去多个支付工具，相当于多个支付方式来同时对一张订单进行支付。
这个就是一个订单的模型，跟电商的模型是非常类似的。
下面这个图是一个订单的处理过程：
一开始在渠道系统，我们会给客户创建一个订单，会包含刚才说的支付和交付的信息，然后走到一个支付流程。支付流程也是通过统一支付进行对应的支付动作。支付的内容其实可支持很多种类，比如说客户可以通过资金支付，也可以通过权益支付。比如说积分就是一种权益，代金券也是一种权益。甚至说客户可以通过持有的产品去支付订单。比如说客户手上有一个理财的产品，那他可以通过理财产品的份额去支付订单。当支付成功以后，就到了银行把资产交付给客户的过程。
那交付的话，其实跟刚才类似，像贷款类交易，银行就会把钱交付给客户；对于某些交易会产生权益的，银行就会把权益交付给客户；比如说产品购买，银行就会把钱交易给客户。其实大家可以看到支付和交付都是通过统一支付实现，这也是为什么我们刚才提支付中心时候提到三块：包括记账、产品、第三方支付，其实都统一放在统一支付，也是这个原因。通过统一支付支持的所有资产动账类型，可以保证我们整个模型的简单化。
同时对于订单模式，我们也做过了一些演练，其实订单模式在设计里面可以支持银行所有产品的处理，也包括一些特殊场景。
对于贷款类的交易，也可以通过订单模型去实现。像我们贷款的放款，这在我们这属于采购订单。那客户支付给银行的实际上是一笔负债，客户给银行支付的你可以理解为一笔借据，然后银行交付给客户的是资金，就把贷款的钱给到客户。还款情况就是刚好相反。
所以银行所有业务都可以基于这个订单模型去处理。
基于刚才我们讲到的六个中心，这个图就解释了我们为什么通过这6个中心能够让银行的一些产品都快速上线，然后能够降低我们开发的量。
最左边的渠道系统不会直接跟产品系统产生对接，渠道系统只要需要按照这里面的用户中心、产品中心、交易中心这三个中心进行一次标准的接口对接，对接完以后不需要再去改造。假设我们现在新建了一个产品系统，产品系统只要按照六个中心的标准接口，实现对应产品信息的同步，实现对应的交付接口，实现对应的核算功能，这时候这个产品系统就能嵌入我们的整个业务中台的体系里面。这时候渠道系统就可以原生的访问到这个产品的功能，实现对应的产品的销售和运营的管理。所以，整体上要上新一个新的产品特别快。
这个图算是业务中台的一个整体的描述。这里面最大的点就是可以看到，业务中台最重要是解决了渠道系统和产品系统解耦的问题。
我们再回顾一下最早时候提的中台的概念，中台通过运营模式变革、组织架构调整、IT架构重构等方式形成的企业级服务复用能力。在我们这次的业务中台建设里面，除了组织架构调整我们没有做以外，我们的运营模式也发生了一些变化。当然这个运营模式指的是IT层面对业务处理的运营模式。其次也做了一个IT方面架构的重构。所以在这个业务中台建设里面，我们其实是通过我们三个模型，货架模型、订单模型、支付模型，来实现渠道系统与产品系统的解耦，产品系统只需实现产品规则，无需处理支付；渠道系统无需改造；中台业务系统配置或轻量级改造支持新功能，就可以支持一个产品的新上线。这就是一个业务中台建设后的效果。
三、三湘实践经验分享
讲完中台的整体架构，接下来分享一下三湘银行在去年建设中台的大致经验和情况吧。
三湘去年的中台项目总共建了22个系统，但这22个系统不是全都是业务中台，实际上业务中台只占了其中的六个系统，其他系统包含渠道中台、数据中台以及公共服务这些系统。
整体的项目从去年的3月份开始启动，5月我们完成总体设计，6月完成招标工作，8月就完成了开发，9月完成测试和上线，10月份完成第二期，算是三湘银行历史以来最大的项目。这个项目建设了我们行的业务中台，虽然在项目里只占了6个系统，却是最核心的业务系统。另外项目也建设了我们行的数据中台、渠道中台和公共服务，同时我们也跟阿里合作部署了飞天私有云。这中间我们做了很多事情，整体投入相比大行来说不多，但是对于小的银行来说，这个投入算是特别大的。大家可以通过这个案例可以看到建设中台并不见得要花特别长的时间和周期，也不见得投入是特别大，同时也不见得一定说需要行方的人员充足情况下才能建。以外包的方式也可以去做一个相应的中台建设。
但是在这个中台建设的过程中，确实存在很多问题或者困难，是一步步克服过来的。我有一些经验可以跟大家分享一下：
1、发起中台建设项目
业务部门不会有动力去建设中台，通常都是由IT部门发起，那么IT部门要怎么去说服行里面去做中台的项目呢？当时我们做了几个事情：
第一，我们是联合了一些专业机构共同去开展评估工作。有句话说得好，“外来和尚好念经”，找专业机构可以让银行内部去信服我们的评估结果。如果是由行方人员评估，那么行里很可能会认为我们是出于做项目的目的而得出的结果。
第二，评估的过程中必须要进行高层和业务的访谈。在这个访谈的过程中，让高层和业务理解建中台能带来什么好处，建中台的理念是什么样的。
第三，报行里面去审批，像三湘当时是报了行办会、董事会汇报批准以后才开始建中台。
评估环节主要出的是两份报告：第一份报告就是一个应用架构现状评估。第二份就是应用架构整体的建设方案。这个整体的建设方案实际上就是中台的整体框架。
2、建立开发规范
在建中台的时候，会涉及到非常多的人，非常多的厂商。中台为了实行解耦，我们还分拆了很多的功能系统去建设。那对于这么大面积的改动，一定需要一些公共的开发规范来去限制大家。不能各做各的，不然很难去整合。在建中台的时候一定要规范先行。我们制定了好几个规范，而且特别严格去实行。
这些都要求整个中台建设过程中，所有人都必须严格执行规范，来保证我们系统建设不会出现偏差。
3、坚持自主设计、严守架构定位
这点对于城商行来说有一定的借鉴意义。
在建设中台的时候我们是一直坚持自主设计。虽然我们当时的人员并不多，但是所有的高阶设计都是我们行方自主完成的，并且是行方内部通过的。当然过程中也会和跟厂商的人员一起评审，不过最终所有的设计都是由行方的同事提出。
坚持自主完成高阶设计，包括功能设计（需求分析）、详细接口设计，并要求厂商严格按照设计进行实施。
厂商的产品可以拿进来，但必须严格执行由厂商适配我们的设计的要求，而不是我们根据厂商的产品来调整设计。这是银行在建中台必须明确的做法。如果把设计交给厂商，很容易出现厂商按照原生产品设计，最终出来的不是我们想要的效果。
同时在中台建设中一定要严守架构设计定位。严守架构设计中每个系统的功能定位，并按定位落地系统功能，当出现定位模糊的情况快速进行明确和调整。已经明确的定位不接受任何开发人员的挑战。不能因为某些开发人员或者厂商觉得这个定位不合理，我们就会为此放弃定位。
这么短时间能把中台建设起来，我觉得这两个坚持是很重要的，这样到最后系统整合测试的时候才不会出现那么多问题。
4、“架构并行，平滑过渡”
这点是为了说服业务的。在建业务中台过程中，当时我们没有停止任何的业务需求，科技部一边接常规的业务需求，一边在建新的业务中台。基于这种情况，要保证两种架构是能平滑过渡。为此提出了三点：
旁路架构：整体架构不阻断原有交易，而是在原架构基础上新增旁路架构，交易在两个架构上可以正常处理；
复用已有系统：尽量复用原有系统功能，原有系统按照中台标准新增接入接口，并保留原接口，兼容两套接口模式并行，无需进行数据迁移；
逐步迁移：按产品逐个分批进行业务迁移，降低整体迁移的风险，出现问题影响范围减少。
上面就是我在做业务中台时总结出来的关键经验，希望能给到大家一些参考。
>>>>
Q&A
Q1：请问中台建好后，效果达到预期了吗？
A：三湘的业务中台的建设效果基本达到，新产品需求的实施周期平均缩减了60%，业务中台5个系统的全部外包开发人员少于10个人。
Q2：怎么看中台对中小银行的价值？
A：中小银行没有大行那么足的的网点资源和开发预算，同时也存在互联网金融公司的竞争压力，只有做到快速响应、低成本才能在竞争中生存，而业务中台的方案就是以产品快速上线和降低成本为目标的，对中小银行应该有实现的价值。
Q3：你们实时数据处理这块，架构是怎么做的？实时计算引擎用的是什么？
A：三湘的实时数据处理采取的是OGG（Oracle Golden Gate）+ Kafka + Flink
+ Oracle/HBase的处理方案，利用OGG数据同步功能准实时获取业务系统的数据变化，同时无需业务系统配合改造。
Q4：能简单介绍一下数据中台建设经验？
A：如果按照我的观点，目前银行的数据能力建设在严格意义上并不能称之为中台，因为在数据运营模式和架构上与传统BI并没有太大的区别，只是将传统的能力合在一起称为数据中台。数据中台在数据标准、数据管控、数据仓库、数据应用的开发模式和架构没有太大的变化，只是建设前要充分考虑海量数据处理、实时数据服务的需求，同时一些互联网企业也会将决策引擎纳入数据中台的范围中，所以在数据中台建设上是一个混合型的技术架构，需要充分利用传统数据库、大数据平台、实时计算等技术特点实现所需的能力。
Q5：用户中心与ECIF的功能边界划分？
A：在三湘的业务中台里ECIF的功能是用户中心的一部分，也就是用户中心是完全替代ECIF的，具有ECIF的完整功能并扩充了其他用户相关的功能。
Q6：业务架构后面会考虑结合微服务吗？
A：三湘在建设业务中台的技术选型上本身就采用了分布式的架构（阿里的SOFA），实际上也可以将每个中心视为一个微服务，只是微服务划分的粒度比较粗，未来如果要支撑更大的业务并发量，会考虑将每个中心的服务能再拆分为更细粒度的微服务。
Q7：请问什么是系统流水号？
A：三湘流水号规范规定有3个流水号：统一流水号、系统流水号、接口流水号。统一流水号贯穿交易的全流程，由业务最前端的系统生成，整改交易流程的各个系统环节都必须保持不变；系统流水号（也可以叫业务流水号），用于每个系统确定交易在自身的唯一性，同一笔交易在当前系统重复处理时的系统流水号不允许改变（例如交易失败重做），以保证业务不出现重复；接口流水号在每次接口调用的时候产生，用于控制网络上的接口调用不会重复。
Q8：旁路架构是不是要做很多接口？但是原系统也没有优化呀？
A：业务中台方案为了业务的平滑过渡，要求原系统的业务处理流程和模式不改变，所以原系统的接口是需要保持不变的；业务中台作为旁路架构实际上进行了接口的标准化整合，整个中台系统对外的标准接口并不多，以记账接口为例，账户中心仅提供了一个标准的通用记账接口，而原来的核心系统对外提供有十几个不同类型的记账接口。
Q9：账务和核算的区别是什么？
A：按面对对象不同可以区分：账务一般指客户账，是银行客户需要看到的账务，需要实时记账，比如客户的活期账户的资金入账和扣款、理财产品账户的份额增加和减少；核算一般指银行账，是银行自身经营管理的会计账，用于管理银行内部资金及产生资产负债表，银行账不被客户使用，因此无需实时记账，通常通过夜间批次在总账系统统一进行记账处理。
Q10：中台系统里有哪些开源框架？
A：三湘在中台建设上使用的是阿里的SOFA分布式框架以及各个合作厂商自身的开发框架，厂商框架里面实际上也会用到一些开源中间件，考虑到技术风险及当前人员技术能力的限制，在开发框架上并没有使用纯开源框架。
Q11：除了这六个业务中台，还有啥中台准备做？
A：业务中台并没有限定范围，只是初期先把最核心的基础能力形成了业务中台的框架，后续计划要实现的业务中台包括权益中心和营销中心。
Q12：你们分布式事务、分布式数据库都用了吗？
A：目前的业务中台架构并没有使用分布式事务（技术不成熟），而是采用了更为稳妥的接口层业务一致性机制，即通过异常业务逻辑发起业务交易冲正保障业务一致性；没有使用分布式数据库，仅使用了分库分表的技术。
Q13：大行的业务模型更复杂，大型银行做业务中台有什么建议？
A：个人认为无论银行大小，业务模型都是类似的，只是大行的业务审批更复杂，牵涉的业务部门更多；因此对于大型银行，在建设业务中台更应该考虑风险问题，一次性进行全部业务的切换对大行来说更不现实，建议采用旁路架构的模式进行业务的平滑过渡，这样可以降低风险并减少建设中台的阻力。
Q14：你们用什么分库分表？
A：目前使用的是阿里的DBP中间件实现分库分表，不过听说阿里已经准备放弃掉这个中间件的后续研发计划。
Q15：数据中台和业务中台如何互动的？
A：数据中台主要为业务中台提供实时的数据访问需求，主要在客户的统一视图方面，供渠道系统实时获取到资产、交易流水等信息；由于数据中台是通过数据库底层抽取数据的方式实现的数据同步，因此业务中台不需要与数据中台进行直接对接，仅用户中心负责将数据中心的用户视图相关接口进行封装并对渠道系统发布。
|
