从 BIAN 银行技术框架中学到了什么

原创 大强 大强旅行分享

本文从业务人员便于理解的角度来介绍 BIAN,与 BIAN 官方对其体系的解释有一定出入,仅供参考。

什么是开放银行

开放银行 Open Banking 是一个金融服务术语,作为金融技术的一部分,指的是[1] :

  • 使用开放的 API,使第三方开发者能够围绕金融机构建立应用程序和服务;
  • 从公共数据到私人数据,为账户持有人提供更大的金融透明度选择;
  • 使用开源技术来实现上述目标;

开放银行正在全球范围内发展,许多国家都在研究如何通过 Open API 共享和管理金融数据。[2] 今天,全世界有60多个国家制定了开放银行解决方案,有一系列的产品和服务、实施时间表和数据访问范围的规定。[3]中国人民银行在 2020年发布了《商业银行应用程序接口安全管理规范》,从技术角度为开放银行监管开启了第一步,但当前尚未出台相关法律法规以明确开放银行发展模式。中国内地银行业主要基于提升自身市场竞争力和获客能力的角度,在现有监管框架下,积极寻求生态合作伙伴,借助金融科技手段,将自身金融产品嵌入场景,拓宽业务渠道,对外输出金融服务能力。以2018年为始点,浦发银行、建设银行、平安银行、微众银行和新网银行纷纷推出开放银行平台,从平台建设、场景生态合作等方面积极探索开放银行服务模式。[4]

BIAN ( The Banking Industry Architecture Network) 是一个业界多方协作的非营利性组织,由全球领先银行、技术提供商、顾问和学者组成,定义了一个用以简化和标准化核心银行体系结构的银行技术框架。这一框架基于面向服务的架构 (SOA) 原则,银行可以借助 BIAN 参考模型建立起业务能力“积木块”,通过与现有系统进行映射和对接,理清应用之间的边界,从而达成面向服务的、松耦合的未来银行架构。从架构及技术角度看, BIAN 融汇了业界关于银行业务模型和技术体系的积累、结合 SOA 架构和微服务架构理念,基于业务能力、组件及服务而形成的银行应用之间互联互通的技术标准。[5]

BIAN 的业务能力

从业务架构的角度来看,BIAN 提供了两个重要的企业架构工件,一个是业务能力地图 Business Capability Map,一个是价值链 Value Chain。

BIAN 的业务能力地图一共分为三级,呈现了银行“能做什么”。银行可以此为参考,根据自身业务情况进行对齐和调整。BIAN 业务能力地图是一个多级嵌套结构,大部分可以到三级,部分能力细分到四级,能力划分的颗粒度比 BIZBOK 的金融参考模型要细得多。第一级是能力分类,包括:

  • 企业管理与控制 Enterprise Management and Controlling
  • 产品与服务支持 Product and Service Enabling
  • 企业支持 Enterprise Enabling
  • 银行运营 Bank Operations
  • 客户与销售 Customer and Sales

BIAN 业务能力地图 Level 1 ~ Level 2

(点击图片放大)

BIAN 业务能力地图明细

BIAN 的业务能力地图构建方式与普通企业架构实践是有区别的。一般情况下,业务架构设计过程中会集中业务和分析师等人员,采用自上而下逐步分解的方式构建业务能力地图。而 BIAN 的业务能力地图,是由一系列已经构建完成的原子级能力,通过映射的方式汇总为业务能力地图。主要的目的是为了与业务架构进行对齐,以适配主流的业务架构分析方法。

服务域(BIAN 称为 Service Domain,俺称为原子能力)代表一组离散的、原子的(唯一/不重叠的)业务功能,它们构成了任何银行的功能构建块 (Functional Building Blocks),用于为解决方案的开发提供业务功能框架。服务域和业务能力为明显不同的目的而将业务区分开来。服务域是一种功能细分,旨在提供一个开发/部署框架。业务能力代表了不同的业务所拥有的能力,目的是制定和实施业务战略。[6]

BIAN 服务域可以被认为是 “对某物做某事的能力”,专注于对一个业务对象所执行的操作。BIAN 服务域是原子性的,这意味着 “代表了可以被服务化的最小实际能力或功能分区。” 换句话讲,一个服务域将封装适合(被封装到) IT 服务中的最小实际业务功能 Business Functionality 。在某些情况下,服务域直接(或几乎)与业务能力相一致;然而,由于服务域是面向功能的,它们通常与价值流 Value Stream 有关,或者更经常地与价值流阶段 Value Stream Stage(或其一部分)有关。

BIAN 的价值链

构建业务能力地图,比想象的要难。不信?可以尝试为自己所在公司创建一张业务能力地图:第一,你会在 What 和 How 之间做很长的思想斗争;第二,到底啥是你脑海中的某个业务能力,你想的这个真的是业务能力吗?第三,在深入到 3 级以下业务能力切分的时候,业务能力已经与任务开始混杂在一起了,不好定义。

企业架构实践中有一个误解,就是在业务架构环节一定要产出业务能力地图。是否产出能力地图,这个要看企业领导和业务层的习惯,如果多数人更擅长理解价值链,那就用价值链作为沟通工具,最终目的是为了方便沟通达成共识。价值链不知道是啥?没关系,业务流程大家都懂。

BIAN 价值链(点击图片放大)

BIAN 的价值链并不是真正的价值链,因为价值链是要进行更下一步分解的,但是 BIAN 仅分解到第 2 层就戛然而止。BIAN 使用价值链视图的真正目的,是给银行另外一个看待原子业务能力的视角。注意下图中的第 3 级,已经不是呈现的活动的分解,而是服务域 Service Domain 这种原子能力。[7]

BIAN 价值链明细图(点击图片放大)

BIAN 到底是什么

经过多年积累,BIAN 为银行业务构建了一批原子业务能力,使银行在信息化建设的过程中可以利用 BIAN 的行业框架,依据自身实际情况进行调优后,便捷高效地实施数字化战略。BIAN 构建了便于业务侧理解的业务能力地图与价值链,将原子业务能力通过映射的方式与两个业务架构中的关键工件进行关联,从而实现银行的业务与 IT 对齐。原子能力便于组装的特性,极大地促进了业务侧的创新与调整;通过统一规范的接口,为银行铺就了一条互联互通的开放之路。

学会了什么

作为业务分析师,俺对业务流程分析有着天然的好感。学习 BIZBOK 后,知道业务能力地图很重要,但是它为什么重要呢?它到底决定了什么?以前没有业务能力地图,也一样把系统成功交付上线。凭什么学个业务架构,就非得去搞这个业务能力地图呢?

这是因为微服务体系结构中的服务,是围绕业务问题进行组织的——业务能力或业务子域,而非技术问题。应用分解为服务有两种方式:按业务能力分解或者按业务子域分解。前者基于业务架构设计中产出的业务能力地图,后者基于领域驱动开发的设计环节。[8]

领域驱动设计 DDD,是一种自下而上的方式。同时需要业务人员、领域专家、业务分析师、开发、架构师等共同参与。两种方式设计的结果可能极其相近,但创建业务能力地图的效率会更高,更容易被理解,更容易被业务参与。

业务能力地图设计可以脱离技术在业务端独立完成,是一种自上而下的方式,它展现了完整的业务视角。业务能力通常集中在特定的业务对象上。每个业务能力都可以被视为一种服务,但它是面向业务而非技术性的,其特性包括输入、输出和服务级别协议。一旦在业务架构分析中确定了业务能力,就可以为每个能力或一组相关能力定义一个服务。最终的成果是围绕业务概念而不是技术概念组织服务。

围绕业务能力组织服务的一个关键好处在于业务架构是相对稳定的,所以后续产生的架构设计也是相对稳定的。

业务能力产出决定了服务的设计

The End.


参考资料:

1. Wiki: Open Banking, https://en.wikipedia.org/wiki/Open_banking

2. The World of Open Banking, https://www.konsentus.com/resources/the-world-of-open-banking/

3. Open Banking Series: Market-Driven vs. Regulatory-Driven,  https://www.pymnts.com/news/digital-banking/2021/open-banking-series-market-driven-vs-regulatory-driven/

4. 中国开放银行白皮书2021-波士顿咨询公司与平安银行联合研究

5. BIAN (Banking Industry Architecture Network) —— Weaving the Value Net of Digital Banking Ecosystem,IBM,李纪华

6. Using Business Architecture in Conjunction with BIAN Service Domains to Drive Business Value, Business Architecture Guild, 2021

7. BIAN 2nd Edition, 2021

8. Microservices Patterns With Examples in Java, Chris Richardson, 2019

战略联盟

战略联盟


云原生计算基金会 (CNCF)托管全球技术基础设施的关键组件。CNCF 汇集了世界顶级的开发者、最终用户和供应商,并举办了最大的开源开发者大会。


CXL 联盟是一个开放的行业标准组织,旨在开发技术规范,以促进新兴使用模型的突破性性能,同时支持数据中心加速器和其他高速增强的开放生态系统。Compute Express Link™ (CXL™) 是行业支持的高速缓存一致性互连,适用于处理器、内存扩展和加速器。


Linux 基金会是致力于促进 Linux 发展的非营利性联盟。Linux 基金会成立于 2000 年,赞助 Linux 创造者 Linus Torvalds 的工作,并得到来自世界各地的领先技术公司和开发人员的支持。Linux 基金会通过整合其成员和开源开发社区的资源来促进、保护和推进 Linux,以确保 Linux 保持自由和技术先进。


NVM Express是一个开放的标准和信息集合,可充分展示非易失性存储器在从移动设备到数据中心的所有类型计算环境中的优势。最初的 NVM Express 工作组于 2014 年合并为 NVM Express,是负责开发 NVM Express 规范的联盟。该组织目前拥有100多家成员公司。


OpenInfra 基金会是一个开源基金会,支持一个由 100,000 人组成的全球社区来构建和运营开放基础设施软件。


OpenPOWER 基金会是一个开放的技术会员组织,旨在推广 OpenPOWER——业界最开放和高性能的处理器架构和生态系统。


Programming Protocol-independent Packet Processors (P4)是一种开源的、特定于域的编程语言,用于网络设备,指定数据平面设备(交换机、路由器、NIC、过滤器等)如何处理数据包。P4 生态系统包括范围广泛的产品、项目和服务。


PCI-SIG 或外围组件互连特别兴趣小组是一个电子行业联盟,负责指定外围组件互连、PCI-X 和 PCI Express 计算机总线。


存储网络行业协会 (SNIA)是一个非营利性组织,由几乎涵盖整个存储行业的 300 多家公司和个人组成。SNIA 成员的共同目标是推动存储网络作为完整且值得信赖的解决方案的采用。为此,SNIA 致力于提供标准、教育和服务,将开放式存储网络解决方案推向更广阔的市场。

被低估了的数字化方法论 | IBM车库方法

我在三年前的文章中就提到过IBM的数字化创新方法论“IBM车库方法”( Garage Methodology),三年过去了,在国内数字化转型领域里,这套方法论明显没有被广泛传播,我觉得它作为企业开展数字化创新,创造数字化产品的体系性、实操性的方法,在中国数字化转型界被严重低估了。

有些朋友没有理解为什么叫“车库”方法——美国人几乎家家户户都有车库,有人喜欢在车库里鼓捣各种修理工具,很多创新发明都是车库里搞出来的,例如惠普、苹果等硅谷公司都是在车库里创业的,所以“车库”就是技术创新的代名词。

就像ERP时代,SAP ERP实施产生了“ASAP方法论”,几乎确立了大型企业软件的实施方法论标准。IBM 车库方法论是一套从数字化驱动的组织文化总体转型,到基于云的数字化产品创造的端到端方法,其特点是:

  • 基于用户体验,是企业级的设计思维方法
  • 揭示了如何紧密衔接分布式或集中式的数字化产品团队
  • 利用DEVOPS工具/技术以及云平台进行持续交付
  • 赋能站点可靠性工程(SRE)
  • 快速迭代,交付业务价值
  • 提升数字化人才和组织文化
  • 企业级(而非小组级或产品级)的数字化创新

“数字化转型”这个名词提出这么多年来,我较少看见全球技术公司提出这样体系完整、同时又完全对用户开放的方法论体系——有些国际云大厂虽然也有类似方法论,但是体系性和用户开放性都还不够,有些技术咨询公司的数字化产品方法论显得过于技术。

国内的几家云大厂更是缺乏这样完整的方法论体系,也没有把自己的云服务以及DEVOPS工具和方法论体系进行包装。中国的数字化转型口号喊得响,各种大而化之、商业化的概念包装多,而在数字化实操的方法论总结上,对于创新流程、技术工具、组织变革以及工作方式上的关注都是不够的!不得不承认,在IT产业中,中国的信息技术应用的方法论建设和国外同行相比,还有很大差距!

数字化创新之核心是创造“数字化产品”,和传统开发信息系统相比,无论是产品开发组织的工作形式、开发过程、所使用的技术工具(关键技术包括:云计算、混合云、人工智能、容器、容器管理平台、DevOps工具等),还是企业开发数字化产品的组织变革(设计师、架构师、工程师、数据科学家、业务战略师、产品经理等多专业协作,multidisciplinary expertise)、组织文化(关键组织文化特质包括敏捷组织、创新文化等)都有显著不同。

IBM车库方法是设计思维、敏捷开发以及Devops技术的整合,它包含了数字化产品开发流程、相关最佳实践:

  • 发现(discover):挖掘商业机会,确定产品开发方向
  • 展示(envision):最小可用产品(MVP)设计
  • 开发(develop)技术开发的架构、代码、测试、部署
  • 智慧(reason):大数据和人工智能应用
  • 运营(operate):高可用的数字化产品运营
  • 学习(learn):用户体验反馈和产品持续改进
  • 文化(culture):敏捷文化和敏捷组织运行

这套方法还推荐了一系列IBM自有以及第三方的数字化工具来支持这些流程和实践。以上述“文化”为例,推荐了敏捷组织常用的数字化工具:代码管理Github、协作工具Slack、白板工具Mural、看板工具Trello、存储平台Box以及电话会平台Webex等:

虽然这套方法论是IBM发明的,但是可以作为普适的数字化创新方法。推荐的工具可以使用用户自己习惯使用的工具来替代,例如:

车库方法推荐工具替代工具示例
代码管理GithubGitlab
协作工具Slack飞书, Discord
白板工具MuralMiro
电话会Webex腾讯会议, Zoom
看板工具TrelloCanny
存储Box Dropbox

IBM 车库方法论是2016年左右跟IBM云业务(IBM Cloud)同步产生的,然而IBM的公有云业务落地中国却是命运多桀,这也许是这套方法论没能在中国得以普及的重要原因。让人觉得遗憾的是,这套方法论尽管在美国已经推出了好几年了,但是IBM中文官网上仍然没有方法论文档完整的中译版本,而且中文网站上对“车库创新”的中文解释和原意也有很大偏差。

由于这套方法论的通用性,我非常希望看到中国云厂商也能够包装出类似的方法论体系,来指导中国的数字化创新。

最后特别说明,本文非IBM车库方法论的官方解释,仅为作者个人研究心得;原文请访问网站:https://www.ibm.com/garage/method

银行的数据治理方案

2018年5月21日,银保监会正式出台

《银行业金融机构数据治理指引》

  • 数据采集层

数据采集层主要是将研究院数据从源业务系统加载到数据仓库(ODS)中,作为数据仓库的基础数据,数据采集层不对数据进行任何加工,直接获取源系统未经加工的数据,以便一次抽取,多次使用。

  • 存储计算层
    • 主数据区:

ODS作为研究院结构化数据的主数据区,大数据平台作为外部结构化数据的主数据区,这两部分数据包括了所有的基础明细数据、历史数据以及监管部门的风险、征信数据,其它区域的结构化数据都是由主数据区数据加工而来。

主数据区主要有两种模型:近源模型层和整合模型层。这两个区的数据都通过历史拉链或历史流水的方式保留历史数据,这两个区的数据按数据标准进行字段属性如代码值、长度、精度的标准化,这两个区的数据主要在模型设计方面有所不同:

  • 近源模型区:表结构设计和源系统一样,在源系统表基础上增加标准化字段以及历史数据保存算法的数据日期字段,近源模型层的特点是保留源系统表所有信息,在建模和运行效率上比较高,但数据整合性不高。
  • 整合模型区:整合模型区按主题进行数据整合、表设计以三范式为主,数据冗余少,只要实体之间关系和属性不变,那整合模型也可以保持基本不变。模型稳定的一个好处就是可以屏蔽源系统变化,避免下游应用系统重复改造。
    • 指标数据汇总区:

由于主数据区的数据并不合适直接提供给数据系统分析使用,因此指标汇总区是整合各数据应用的加工需求,按事实表(宽表)和维度表进行模型设计,对主数据区数据进行关联、公共指标加工,提供给多个数据应用、报表使用,那指标汇总区可按协议(账户)、产品、客户、科目、机构等逐层汇总,指标汇总区可以消除各系统对于同一个指标分别加工导致的口径差异。

  • 集市区(仓内)

集市主要指和数据仓库在同一个物理平台中的集市,可以直接访问主数据区,指标汇总区数据、减少数据批量转移的成本,利用ODS数据仓库分析性能快速进行数据加工,数据集市的划分可按业务部门或下游系统关联度进行集市划分,目前研究院ODS数据库上有风险数据集市、监管数据集市。监管数据集市通过自主研发主要面向给人行、银监进行监管报送报表的加工,涉及多个业务管理部门;风险数据集市主要面向风险管理部提供风险指标数据加工。

  • 集市区(仓外):

仓外数据集市和仓内数据集市区别只是和数据仓库不在同一物理平台,但同样面向特定的数据应用进行加工分析;研究院目前正在仓外搭建全面风险数据集市及信用卡业务数据分析集市,分别面向不同的业务条线/场景,提供指标分析、加工处理。

针对数据集市将根据不同的场景选择仓外或仓内。

  • 批量数据接口区:

批量数据接口区即ODS给各下游数据应用系统、仓外集市提供的数据接口加工区,按双方约定的数据格式提供给数据应用系统,批量数据接口区按接口协议做简单关联,不做复杂加工,目前主要是以ODS共享库作为批量数据接口区。

  • 非结构化数据存储计算区:

非结构化数据存储主要以内容管理平台、生物识别平台、影像平台为基础平台,对非结构化数据进行存储计算,按一定的数据类型、来源、用途进行区域划分,方便实时查看和分析。

2021年我部对内容管理平台进行优化改造,作为影像文件归档存储平台使用,并作为大数据平台后期非结构化数据分析数据源;将影像平台作为业务系统实施对接系统使用。

目前研究院在数据中台建设方面主要完成了以下内容:

数据采集既面向各源系统,同时面向后续的数据清洗加工,为数据统一接入提供离线数据和(准)实时数据,一般采用的技术ETL和FLINK,。ETL数据采集研究院已经完成40多套系统数据的接入,Flink数据采集目前研究院只完成了146号文项目中风险检测类指标的数据采集。

数据加工调度负责将贴源数据进行清洗加工,形成可以直接面向应用的数据结构。此项工作分别由ODS计算存储层和大数据计算存储层进行完成,对于准实时数据加工及实时外部数据加工由外部服务平台和大数据平台共同实现。

数据共享目前研究院数据共享有两种方式:共享库和外部服务平台,共享库主要针对T+1数据,外部服务平台则面向实时数据服务,还无法达到开放型数据服务的能力。