产品战略专家梁宁确认出席AICon北京站,分享AI时代下的商业逻辑与产品需求 了解详情
写点什么

浅析银行数字化转型之二:打造金融敏捷中心

  • 2019-08-29
  • 本文字数:10431 字

    阅读完需:约 34 分钟

浅析银行数字化转型之二:打造金融敏捷中心

小蚂蚁说:

本文干货满满,建议阅读时间 30 分钟。因此先将本文目录摘录如下,建议大家先收藏转发后再阅读哦~!

一、银行的心声

二、数字化银行的终局

三、如何从《数字化 1.0》到《数字化原生 2.0》?

四、数字化 2.0 核心:业务敏捷能力

五、“蚂蚁敏捷原力”(Ant Force)核心经验

六、蚂蚁数字化“操作系统”:Ant OS

七、总结


2018 年 7 月蚂蚁发布了浅析数字化转型的第一篇万字长文《浅析银行数字化转型路径》,关于转型路径的分析。经过半年时间的等待,我们的数字化转型系列文章之二 ——《打造金融敏捷中心》,终于问世了。上一篇我们着力分析了数字化转型的不同流派以及转型中如何设计路径的原则,这一次我们更加聚焦在数字化转型中的敏捷战略。在总结分析蚂蚁自身技术锤炼的过程中,我们发现“敏捷能力”无处不在;敏捷的技术能力支撑着蚂蚁自身的普惠金融业务能够快速迭代,同样我们看到中国银行业在面向轻型银行、交易银行、数据银行、Open Bank 等新形态演变的过程当中,业务组件化的能力;人工智能技术的广泛应用,基础技术平台的重构是每一类型改变的核心支柱。今天整个中国金融行业都在面临业务和技术的重大变革时代,本文中,关于传统 Core Banking 系统未来的走势;关于敏捷能力需要的组织架构;关于业务组件化形成 Open Bank 的基础;关于系统架构的持续治理;以及我们建议的数字化转型的成熟度标准都有一定篇幅的论述,内容十分丰富。在数字化转型的路上,蚂蚁会将科技与创新实践进行到底。

银行的心声

用户已经迁徙到数字化世界,银行如何跨越“数字鸿沟”?


人流不等于客流。每天客户从我们身边经过,如何与他们发生连接、产生交互,有效地将人群转化为客群?


我们做大量的营销活动、人员地推、送油、送大米、送礼物换回客户开卡,但然后呢?………就没有然后了,大部分成为僵尸户,缺乏后续的客户运营、缺乏场景,缺乏有效的客户触达、转换和提升能力。


我们 3 年前开始了依靠网点、依靠客户经理模式的零售 1.0 的转型,但目前这种模式已经遇到天花板,很难再进一步增长,获客越来越困难,需要向依靠数字运营、场景化的零售 2.0 来换挡。


人人都拿着手机,金融服务的高频化以及移动化让服务与场景结合的越加紧密。


数字化转型需要组织架构的匹配,依然以业务线来组织配置 IT 技术人员。数字化是全行层战略,但以业务线为核心的组织和资源配置,会让银行数字化转型缺乏转型空间。


银行最大的瓶颈是不够敏捷,理所应当地认为系统应该前后台分离、各业务线分离的项目机制,敏捷化被各种裂痕完美破坏。


随着数字化进程的逐步推进,客户边界越发模糊,年轻客户、小微客户的价值潜力一路凸显。


不要让业务为技术而苟且!系统处理能力、需求开发周期很大程度限制了业务形态。

数字化银行的终局

银行正在从一个“物理的地方”,变成一种“永远在线”的服务。


在用户都被数字化习惯养成的时代下,跨越“数字鸿沟”是所有银行都要面对和经历的过程。很多银行已经开启了数字化转型进程,来提升客户体验、提升业务敏捷能力、提升开放合作能力:


  1. 建立以客户体验和连接为核心的《移动数字化渠道》,重塑线上服务形态和客户体验。进行端到端数字化客户旅程改造(EdgE–End to End Digital),逐渐改善客户体验、优化流程和提升效率。

  2. 建立以敏捷为核心的《能力中心》,形成技术敏捷能力、业务敏捷能力、金融数据智能,形成科技与业务的双轮驱动模式。建立稳定与敏捷并重、AI 全流程嵌入的运营模式和 IT 能力。

  3. 建立以开放和生态合作为核心的《开放银行》,全面实现对外金融能力输出、聚合服务与极简化场景嵌入能力。开放银行以 API、SDK 等技术为核心,综合人工智能、大数据、标记化等技术,将金融服务无缝嵌入实体经济各领域,打破了银行服务门槛和壁垒,拓宽生态边界,重塑价值链,促使银行服务不再只承载于实体网点和电子渠道,有助于推动银行业转型升级。开放银行在提升银行金融服务效能的同时,也使得风险敞口更多、管控链条更长、洼地效应更明显,风险呈现出新特点、新变化。



蚂蚁金服副总裁刘伟光认为:数字化成熟度比较高的银行会率先完成“乐高式银行“,银行业务服务将从部门级、烟囱式的系统变为共享化的服务组件,并将以组件、模块的方式为第三方所调用,与第三方建立丰富的“在线连接”,形成跨机构、跨组织、跨行业的金融场景覆盖,银行正在从一个“物理的地方”,变成一种随时、随地、随需、“永远在线”的服务。

如何从《数字化 1.0》到《数字化原生 2.0》?

幸存的生物不是最强大的,也不是最聪明的,而是适应力最强的(最敏捷的)生物!——达尔文。


数字化转型已经成为金融行业最热门的话题,过去十多年里,伴随着用户行为习惯的迁徙,银行的业务形态也在不断地进化(以适应用户行为)。随着用户不断向移动端、数字化设备的迁徙,银行也纷纷开启了“移动优先”模式,迎来了以移动为核心的《数字化 1.0》时代。“移动优先”战略投入较大的银行,也在移动蓝海捕获了一连串亮眼的业务数据,以广发银行为例,采用数字化移动开发平台重构了手机银行 APP、发现精彩信用卡 APP,每秒交易请求峰值(TPS)从 2600 笔/秒提升到了 35000 笔/秒,从 APP 打开速度提高 20 倍、闪退率下降 100 倍,交易平均处理时间由 200 毫秒缩短到 60 毫秒,大幅提升客户秒杀体验。


但随着数字化技术的不断普及、面对用户更加细分化市场、场景化的需求,将传统银行存、贷、汇、理财等业务简单地“搬到” 移动 APP 的模式已经远远不能满足要求,形成了巨大的“数字鸿沟”。


但如何向数字化原生企业的业务敏捷与科技创新能力所看齐? 则需要向更深层次的《数字化 2.0》迈进(业务组件、开发敏捷、数据智能),形成 “共享化能力中心” 作为敏捷发动机。如下图的公开数据分析可以看出,完成了共享敏捷化转型的数字化企业(数字化 2.0)要相比直销银行(数字化 1.0,以移动化为核心)和传统银行,无论是获客成本、还是敏捷带来的运营成本,都有着更加显著的竞争优势。是时候要考虑将数字化进程推进到“深水区”,通过强大的“共享化能力中心”来建立敏捷化细分市场的覆盖能力,缩小“数字鸿沟”。



作为数字化原生企业代表,蚂蚁金服把自己多年的数字化的“苦与乐”,通过《金融敏捷能力中心》战略(科技+方法论)来对外开放,帮助金融机构打破企业的部门墙、数据墙、业务墙,形成可跨部门、共享化、组件化的金融敏捷能力中心,真正实现业务的可重用、可组装。


数字化转型的打怪升级之路:


  • 数字化 1.0=最佳客户连接、业务线上化、移动化

  • 数字化 2.0=共享化能力中心、业务敏捷能力

  • 数字化 3.0=开放生态、场景金融

数字化 2.0 核心:业务敏捷能力

敏捷将为业务带来无限的想象力!


金融机构经过多年信息化建设,开发了相当多样化的应用,基本上信息化系统是“全覆盖、无死角”。为了满足银行各业务部门不同的 IT 需求,导致了大量重复建设的功能和应用充斥在系统中的各个角落,随着系统变得复杂,数据孤岛越来越多,反过来又因为数据无法共通,逐渐成为业务创新的负担和包袱。正是这种典型的业务需求驱动的项目制的 IT 系统建设方式,导致了阻止企业创新的“组织墙”与“数据墙”,也阻碍了企业走向真正的“数字化企业”。由此可见,真正的走向数字化转型,必然是企业整个技术架构的转型,绝不能再头疼医头,脚疼医脚。


毕马威发布了《助力企业数字化转型》的报告,其中的一些观点颇为值得关注。报告提到,未来企业将重点致力于解决从传统信息化到数字化的转变,包含从“烟囱系统,重复开发”到“共享沉淀服务化能力”;从“数据孤岛”到“数据智能决策”等核心 IT 能力的转变。可见,金融机构能否建立一个能力打通、组件化、服务化的“共享化敏捷中心”,将成为其数字化转型的分水岭。今天,“共享化、组件化、中心化”的思想已经成为了主流数字化转型思想。


数字化建设需求早已不再是将其简单做一些记载或者披露,更重要的是“打通”各个环节,打破过去分散系统的壁垒,形成一套支撑全局化的《敏捷能力中心》,将成为银行机构全面提升业务敏捷能力、全面数字化转型的“关键节点”。


  • 项目制=产生“烟囱”式 IT 系统=“组织墙”与“数据墙”

  • 共享敏捷中心=科技引领业务

“蚂蚁敏捷原力”(Ant Force)核心经验

技术是被“折腾”出来的!——凯文·凯利


组件化、可重用是一种敏捷架构思想,并不仅仅适用于技术领域,以丰田的 TNGA 模块化平台为例,一辆车有 2 万个零部件,其中 80%以上是通用零部件,可是适用于多种车型。丰田推崇的设计思想是基于标准化的零部件进行差异化设计,一方面提高零部件的通用性、共享性,另一方面提高设计的差异化和敏捷交付。丰田推出新产品的交付时间比其美国的竞争对手要快 2 倍。正是这种基于标准化组件、灵活的设计和组装的模式,可以最大化的降低生产和运营成本、提高灵活组装效率和敏捷能力。


蚂蚁金服从 2007 年开始服务化、共享化、平台化进程。通过系统拆分、微服务改造、单元化治理,逐渐把单个巨石系统分解为多个服务领域,形成了一整套组件化、可重用的“金融敏捷能力中心”,推进业务的灵活性、敏捷性、扩展性推进到一个前所未有的水平。这个过程并非一蹴而就的,期间有很多鲜为人知的故事,也经过了大量论证和实践:哪些先拆,哪些后拆,层次关系上下左右怎么摆放;服务粒度怎么确定?太粗不便于复用和修改,变更和隔离风险难度变大;太细的话,服务管理成本以及整合复杂度变高,服务使用方系统体感不好。“对此,我们先后划分了一级域、二级域,每个架构域都是足够闭环的领域,其中又包含了很多系统和组件,各自明确以服务的形式进行交互、管理数据且协作分工,此时领域驱动设计就已经在内部备受推崇” ……。


最终形成了以“上帝视角”的金融信息基础服务模型(飞马模型“互联网金融信息模型 Internet Finance Information Model”的简称),可以覆盖银行、证券和保险业务场景,更加容易实现“全局最优”的金融信息互通、集成标准的建立。


总结为几个核心经验的话:


第一个关键经验是:组织阵型


敏捷能力建设需要敏捷的阵型,建立独立于业务线的中台技术团队和 KPI 机制。以前蚂蚁的 IT 系统建设是业务驱动的、是被动型的,IT 技术是业务线相匹配的支撑部门,业务部门提出需求,IT 技术部门进行项目式的流水线模式开发,因为“屁股决定脑袋”,IT 技术人员的 KPI 与各自业务部门 KPI 相绑定,缺乏全局统筹规划,所以天然形成各自业务的“组织墙”,初始起步建设快、但后续发展却异常复杂、代价极大,这种模式属于“局部最优、但全局未必最优”。蚂蚁在多年的共享服务建设经验中一条就是,IT 部门不能完全被业务绑架,需要有独立的思考,不但要有局部的“战斗视角”(支撑短期业务,业务驱动科技),还要有全局的“上帝视角”(给未来发展提供持续动力,做到科技驱动业务),所以从组织阵型上需要配套的中台技术团队建设,将中台技术团队的 KPI 与业务 KPI 分离。形成一个强大而独立于业务线的中台技术组织,负责进行全局化、公共服务的沉淀和建设。技术中台团队要对不同前端业务中的公共和通用业务有深刻的理解,还要时刻掌握技术发展趋势,这样就能不断从不同前端业务中抽象出可以沉淀到共享业务中的业务点,还能前瞻性从共享业务层面提出业务创新方向再反哺给前端业务。


第二个关键经验是:架构持续治理


需要长期治理,边污染、边治理。在迪士尼有一句话被奉为经典“艺术挑战技术、技术启发业务”,这就是业务和技术互相驱动的经典。在蚂蚁的业务快速发展过程中,业务不可能因为技术而停顿,组件化共享服务中心可以最大程度地减少重复开发、快速业务配置化,实现 80%业务需求的敏捷上线,但永远无法预测所有未来业务需求。在共享服务中心无法满足配置化、快速上线的情况下,业务线 IT 人员也会在共享中心域外构建一些业务域烟囱,所以业务域与共享域的架构治理是一个长期持续的过程,一边污染、一边治理。共享中心和业务域的架构师会定期进行领域范围的架构评估,评估业务烟囱是否有通用性和共性,进行中台化提炼和沉淀。共享中心域建设并非一蹴而就,需要不断从业务域来吸取营养、反过来再放大化滋润业务发展。蚂蚁发展到今天,经历过数代技术架构的更迭,每一代架构更迭中最重要的第一件事情就是盘点烟囱和拆烟囱。保证了有价值的业务能力被不断沉淀、被复用、避免重复建设、让科技来启发(驱动)其他业务。


第三个关键经验是:采用“四眼原则”,打破业务与技术的隔阂


采用 “四眼原则”,通过“一横多纵” (共享中心域+业务域)来进行需求结构化分解,识别结构化需求中已有哪些端产品/行业产品/平台产品、业务流程、配置能力等能够在运营中台显性的看到并有保鲜机制,这样会极大的降低互相学习和沟通成本,进而通过领域建模、业务规范、技术规范、流程组装进一步进行各自领域的分工建设,实现快速标准化、图纸化开发,大家从原来“无组织化的各扫门前雪” 到 “分工合作式各扫门前雪”。各个小开发团队按照图纸式完成高内聚、低耦合的“合约化”的服务开发,将原来复杂系统的大闭环(开发-测试-上线)变为松耦合的小闭环,提高多团队分工协作、敏捷开发效率。所以中台提供越好的抽象和领域原语,就越能发挥前台人员的业务优势和主观能动性,极大地提升了沟通效率。共享技术团队有个重要命题需要考虑:自己的服务和技术应该如何合理抽象,将业务和底层尽可能隔离开来?这套领域特定语言(DSL)应该如何设计,才能让业务方也能看得懂,用得好?


第四个关键经验是:原子级服务发展到复合服务(走向 BPaaS)


随着越来越多的高内聚、低耦合的原子级服务沉淀多了后,带来了新的问题:服务油腻。前端业务方需要理解和感知大量的原子级服务。参数和配置驱动很早就成为了蚂蚁金服系统的基本设计原则,至此也诞生了类似资产交换、产品工厂,用来快速组合复用原子能力,为前端业务提供轻量化接入。例如:业务端有 M 个业务渠道,资产端有N种原子化资产服务,那么每个业务渠道需要对接和集成所有原子化资产服务,虽然原子服务的重复开发减少了,但依然存在一个复杂的 M * N 集成配置。通过梳理和收敛所有资产关系,建立统一资产交换业务服务(BPaaS—业务级服务),面向业务视角来编排和组装业务级服务,屏蔽底层原子服务复杂性,整体工作量从 M * N 降低至 M + N,效率和灵活性均大幅提升。建立让业务人员满意的共享服务平台一个非常重要的经验就是,不但要有面向业务领域架构师的基础原子组件服务(细颗粒度、原始材料),还需要提炼面向业务用户的业务服务(带有业务语义的 BPaaS 业务 服务层、粗颗粒度、半成品),通过一系列带有最佳实践、带有业务语义的 BPaaS 业务级服务,让用户只关心自己所需要的服务,避免服务爆炸、服务油腻。



第五个关键经验是:主动“找麻烦”,给系统打疫苗


“要获得成功、靠朋友,要获得巨大成功,靠敌人”。当技术平台变为分布式架构、微服务体系后,业务架构将变得异常复杂, 一个系统往往有成千上万个依赖对象,为了应对复杂系统的可用性、对各类故障的免疫,只有通过问题才能提升系统可靠性能力,但却不能被动等待各类故障和意外的发生。所以,我们除了系统测试、压测、灾备等防范策略外,还需要人为制造“麻烦”、创造“敌人”,来模仿各类意外发生,给系统打疫苗,让问题和故障来考验系统的可靠性、发现及时性、自愈性能力。正是不断主动制造敌人来锻炼,通过不断攻防来提高系统的“耐撕性”(可靠性、稳定性),将系统不确定的技术问题和风险,通过技术风险管理来控制在确定的范围内,系统就是这样高强度被“折腾”出来的,将不确定性变为确定性。


经过多年业务的摸索与实践,蚂蚁最终打磨成型了一套《金融敏捷能力中心》,有效地整合整个公司的业务能力、数据能力、技术能力,形成灵动的应用以及坚实的底盘。对前台形成强支撑,让一线的前台业务更为敏捷,让科技能够引领业务创新。例如通过一套敏捷中心,快速支撑支付宝、网商银行、蚂蚁森林、蚂蚁农场、蚂蚁公益、蚂蚁保险、城市服务、免押业务等一系列敏捷创新服务。


蚂蚁数字化“操作系统”:Ant OS

“May The Force be with you!”——Master Yoda


蚂蚁金服的金融科技开放战略已经越来越清晰,形成以蚂蚁 BASIC(Blockchain-区块链、AI-人工智能、Security-安全、IoT-物联网、Compute-分布式计算)为基础,打造了一套带有金融业务平台服务(bPaaS)和最佳实践的金融敏捷服务框架,将蚂蚁金融科技以更加立体和多维方式展现出来,让金融机构可以快速搭建完整的金融中台,引入最佳技术产品和最佳实践,充分获取营养,避免走弯路(“重新发明轮子”)。


蚂蚁金服副总裁刘伟光指出,银行数字化转型是一个逐步递进的旅程,敏捷能力中心的打造如同建设下一代数字银行“操作系统”,OS 可以提供金融业务的标准化、组件化能力,OS 同时蕴含“Open and Share”(开放和共享)的理念。在银行数字化之旅中具有里程碑意义。 “从根本上解决数据墙、组织墙的孤岛,打破前后台隔离、业务线的隔离,完成对内部、对外部的标准化和开放,实现业务组装和业务敏捷交付能力。”


蚂蚁将自身最佳实践的《金融敏捷中心》进行全面开放,框架包含:业务敏捷中心 + 技术敏捷中心 + 数据智能中心 + 最佳实践 。



金融业务敏捷中心:业务组件化、共享化本身不是目的,业务敏捷是目的。《金融业务敏捷中心》提供一套标准化、共享化、可编排、可视化的领域中心化的服务(一类服务组成一个 Domain 中心,例如: 订单中心,消息中心,账户中心,各类资产中心、产品中心……)。金融机构可以借助这些带有业务语义的业务服务组件,让前端业务部门可以像搭积木一样调用平台上的业务组件来编排业务模块,创新业务就是这样“乐高式”地搭建起来的,实现业务敏捷的核心目的。正如以往 IaaS 虚拟化实现了计算资源的标准化(屏蔽底层复杂性)、可组装、快速敏捷开通; PaaS 实现了平台软件层资源的标准化、可组装、快速敏捷开通;现在 bPaaS 业务组件定位就是实现业务应用层的可组装、敏捷化。



金融核心套件就是《金融业务敏捷中心》的重要组成部分,依托蚂蚁金服的金融领域建模和应用架构经验,形成一个高度聚合的 Core Banking 核心能力引擎,提供标准化、可重用的金融核心领域服务能力。


  • 资金平台:资金平台囊括了存款、贷款、理财、权益等多种核心业务。向上对业务产品层提供统一的资金处理服务,内部封装账务、清算、核算等原子能力。通过资金交换发起分布式事务,保障各个资金在交换过程中的事务一致性,业务系统无需感知复杂的处理逻辑。

  • 客户平台:贯彻“以客户为中心”的理念,提供统一定义客户、统一管理客户信息、统一身份识别、统一认证授权、客户视图等基础服务。

  • 产品平台:通过对产品要素及处理流程控制的抽象形成产品模型,提供各种产品的灵活定义及配置组装能力。



在复杂的金融消费场景下,不同支付工具(贷记卡,借记卡等)和营销工具(红包、代金券、积分等)的快速组装生成,向业务层屏蔽底层交易和操作复杂性,并且可以与场景端无缝对接,以满足市场多元化、快速响应业务发展的需求。通过这些引擎,金融机构可以实现统一资金交换,交易核算分离,热点帐户智能策略,多层次帐户体系、快速产品组合、灵活产品工厂、离在线一体化等传统系统中最具挑战的需求。《业务敏捷中心》另一个重要的优点在于将核心业务能力组件与技术平台能力融于一体,可有效解决金融机构应用研发效能、数据治理和运营、全域风控管理、技术架构升级等问题。


金融技术敏捷中心:数字化银行是以数字化手段来直接面向海量用户提供服务(直销银行、线上消费贷、秒批秒贷、在线支付、场景金融等),在《金融业务敏捷中心》能够快速满足业务需求时,技术方是否能够有能力承载海量用户高并发需求(双 11、618 等海量交易)?《金融技术敏捷中心》的核心目的就是解决海量交易支持、技术敏捷性。蚂蚁的《技术敏捷中心》以分布式数据库、分布式中间件、DevOps 为核心,形成敏捷开发、持续集成、海量交易支持为核心能力的《技术敏捷平台》。以中国人保健康险平台为例,借助蚂蚁的分布式技术架构,其互联网保险云核心业务处理能力提升了上千倍,并支持弹性扩容,出单时间达到每秒 1000 单,外部渠道产品接入效率提升 6 倍,新产品上线时间缩短 80%以上。



分布式架构、微服务已经成为新一代系统架构的基石,面对大量的管理对象,传统大机/小机时代的“宠物式运维模式”难以为继(昂贵的硬件、人肉运维、一个人负责几个管理对象、系统故障影响巨大),需要更加高效和低成本的“牲畜式管理模式”(通用低成本硬件、自动化问题发现、故障自愈、故障影响非常小),将硬件故障视为常态化。Facebook 号称 1 个运维工程师可以管理到 2 万台服务器,只需要进行硬件更换,会自动化调配资源、保证业务平稳运行。


银行要做的不是保障单个系统或某几个系统的性能和可用性,而是全链路,关键链路的评估,越真实、越精准,最好是用实际场景来检验。如何能够很好地防范各类技术风险,对于各类问题能够及时发现、隔离、恢复和自愈,来保证业务的平稳运行? 因此《技术敏捷中台》还包含了一套技术风险管理平台,来实现三地五中心灾备架构、免疫架构、主动故障注入、防御资金安全和不断的、自动发现故障等对技术风险进行立体防控。就像往系统中丢入了一个“小怪物”来主动制造破坏,来检查破坏的影响和范围,例如,每天不间断的系统压测、修复、再压测、再修复以及总结提炼方法;每个月数次的主动化故障注入、通宵容灾演练、系统自愈性检测、……如此反复。这些技术能力体现蚂蚁金融科技不断追求极致,“将不确定性变为确定性”。



金融数据智能中心:“数据是业务的血液”,一个公司如果只有数据技术,缺乏深度的业务理解,缺少不断地业务对数据的应用和反哺,是无法帮助银行来实现金融智能化突破的。最终还是建立了大量的单点数据系统,建立多个数据烟囱而已,银行也因此走了很多数据弯路、浪费了宝贵的时间窗口。所以我们普遍看到,几乎没有银行的大数据平台是非常成功的。数据仓库、ODS、数据集市、大数据平台、实时数据平台…这些不同名字的数据平台几乎成了所有银行的标配,但没有一个银行的业务方认为数据是好用的,易用的。


真正的金融智能只能诞生于既有数据技术,又有业务土壤的环境,形成一个从业务->数据->技术->价值的闭环,通过金融智能工厂不断地让数据更加标准化、实时化、智能化在业务中循环,蚂蚁的金融智能中心,就是让客户可以构建一个既有统一化数据技术平台、又有业务能力的数据平台,可以让银行进行数据架构统一、数据治理规范化、数据应用智能化,让数据与业务充分连接,获得“数据聚变”式的业务价值。


《金融数据智能中心》打破了不同业务部门之间的烟囱式 IT 架构,从而打通了数据孤岛,让数据给业务赋能,实现了“一切业务数据化”的目标。数据智能中心的核心思想:1)统一数据入口:形成统一数据集成(数据湖),把不同结构的数据统一存储,使不同数据有一致的存储方式,在使用时方便连接,真正解决数据集成问题。2)统一数据过程:形成在线、离线一体化的数据研发体系;3)统一数据出口:形成标准化数据资产管理。4)智能应用中心:形成数据智能分析、智能营销等智能应用。利用智能化技术形成一系列的产品和解决方案逐步渗入到业务场景中。蚂蚁目前将数据智能应用已经普及到每一个业务场景中,智能客服自动化处理 98%以上的客服请求,智能风控、智能营销、智能推荐……。大量繁杂业务交互和人工任务由金融智能来自动化完成,避免人工瓶颈,提升客户体验。



最佳实践+规范标准:数字化转型中除了技术产品之外,将技术实施相配套的技术标准、最佳实践落实是一个关键。例如:高铁建设中除了高铁本身技术之外,高铁的信号、调度、通信、运营等一系列配套和标准是至关重要的软实力。在分布式敏捷中心的建设,相应的软实力配套也同样重要,领域模型 DDD、飞马模型、两码一号、分库分表、服务拆分原则、单元化原则、灰度发布规范、……




数字化方法论:数字化成熟度评估、EdgE(End-to-End Digital)客户数字化旅程分析、数字化风险评估、建立匹配数字化转型的数字化 KPI……



总结

传统的前台和后台就像是两个不同转速的齿轮,前台由于要快速响应前端用户的需求,讲究的是快速创新迭代,所以要求转速越快越好;⽽后台由于⾯对的是相对稳定的后端资源,⽽且往系统陈旧复杂,甚至还受到法律法规审计等相关合规约束,所以往往是稳定至上,越稳定越好,转速也自然是越慢越好。所以,随着企业业务的不断发展,这种“前台+后台”的齿轮速率“匹配失衡”的问题就逐步显现出来。共享化敏捷中心的出现正是为了解决这种”齿轮匹配失衡“的问题应运而生的。这也与 Gartner 提出的三层 Pace-Layered(不同步速)的企业系统架构相吻合。处于共享化敏捷中心的系统(SOD)能够既兼顾前台系统(SOI)⼩而美、快速迭代,又保持了后台系统(SOR)的稳定可靠,做到鱼与熊掌兼得。发展共享化敏捷型系统才是面向未来的数字化企业关键战役。


蚂蚁金融科技早已超越了传统单纯技术产品输出的概念,囊括了完整的《金融敏捷中心》建设框架,让金融机构从技术、数据、业务,到组织、规划、最佳实践等全面系统化地提升数字化敏捷能力,不但可以自己快速构建敏捷型应用,还可以进一步形成生态开放市场(开放银行),让各种创新想法、各个行业开发者都可以调用和消费银行的技术能力、业务组件、数据资产,形成以银行为核心的多样化的场景金融形态,帮助银行从 Bank(物理地点)走向无处不在的 Banking(永远在线、无界化的金融服务)。


作者介绍:


刘伟光,蚂蚁金服副总裁,目前致力于蚂蚁金服技术的商业推广和生态建设。在加入蚂蚁金服前,他在企业软件市场深耕多年,创建 Pivotal 软件大中华区分公司,开创了企业级大数据以及企业级云计算 PaaS 平台的市场先河。在创建 Pivotal 中国软件公司之前,刘伟光曾经担任 EMC 大中国区数据计算事业部总经理,并在甲骨文中国公司工作多年,曾经创建了 Exadata 大中国区的产品事业部。


本文转载自公众号蚂蚁金服科技(ID:Ant-Techfin)。


原文链接:


https://mp.weixin.qq.com/s/3d9GYf0-edTarFp9wcgCkw


2019-08-29 17:281328
用户头像

发布了 150 篇内容, 共 34.4 次阅读, 收获喜欢 38 次。

关注

评论

发布
暂无评论
发现更多内容

OpenCloudOS WOW 活动上线啦!千份社区好礼等你来拿!

OpenCloudOS

操作系统

数据库变革:HashData云数仓实现事务级实时性

酷克数据HashData

TestNG 与 Junit如何选择

霍格沃兹测试开发学社

java 程序启动后cpu高怎么办?

摸鱼编程

JVM JIT jfr pgo

从新学习String和StringBuilder,让面试官虎躯一震

摸鱼编程

Java 面试 string StringBuilder

智能多通道系统实现消息推送更智能更高效

MobTech袤博科技

前端 前端开发 消息推送 APP开发

Appium WebView 技术原理

霍格沃兹测试开发学社

APP自动化之Toast识别

霍格沃兹测试开发学社

k8s中无声的性能杀手:cpu thorttling(限流)

摸鱼编程

k8s 性能 高并发

自动化测试之模拟器控制

霍格沃兹测试开发学社

APP自动化如何使用参数化用例

霍格沃兹测试开发学社

Docker 搭建Web服务器nginx

霍格沃兹测试开发学社

小灯塔系列-中小企业数字化转型系列研究——MICE测评报告

向量智库

google borg(k8s亲爹) 论文读后感

摸鱼编程

k8s Google borg

快手公布自研大模型最新进展:“快手AI对话”已开放内测

Geek老T

AI Codec 大语言模型

使用appuploader工具发布证书和描述性文件教程

雪奈椰子

计算机网络知识,一文搞定

霍格沃兹测试开发学社

Andriod微信小程序自动化测试

霍格沃兹测试开发学社

App自动化控件定位

霍格沃兹测试开发学社

Docker 容器技术与常用命令

霍格沃兹测试开发学社

Serverless 应用托管助力企业加速创新

阿里巴巴云原生

阿里云 Serverless 云原生

LCR 089. 打家劫舍

红袖添香

动态规划 力扣 打家劫舍

腾讯云 CODING 荣获 TiD 质量竞争力大会 2023 软件研发优秀案例

CODING DevOps

开放原子开源基金会六、七月新增捐赠人

开放原子开源基金会

开源

web自动化解决文件上传和弹框

霍格沃兹测试开发学社

Docker 搭建性能监控平台

霍格沃兹测试开发学社

Go 语言中排序的 3 种方法

AlwaysBeta

Go

LLM 落地电商行业的最佳实践来了?Zilliz X AWS 有话说

Zilliz

AWS Zilliz 向量数据库 电商行业 大模型落地

gitlab 服务端 hook, 拦截糟糕的提交到仓库

霍格沃兹测试开发学社

Postman做 接口自动化测试

霍格沃兹测试开发学社

java程序员应该知道的k8s容器资源申请攻略

摸鱼编程

Java 容器 k8s JVM

浅析银行数字化转型之二:打造金融敏捷中心_文化 & 方法_Geek_cb7643_InfoQ精选文章