BIAN ( The Banking Industry Architecture Network) 是一个业界多方协作的非营利性组织，由全球领先银行、技术提供商、顾问和学者组成，定义了一个用以简化和标准化核心银行体系结构的银行技术框架。这一框架基于面向服务的架构 (SOA) 原则，银行可以借助 BIAN 参考模型建立起业务能力“积木块”，通过与现有系统进行映射和对接，理清应用之间的边界，从而达成面向服务的、松耦合的未来银行架构。从架构及技术角度看， BIAN 融汇了业界关于银行业务模型和技术体系的积累、结合 SOA 架构和微服务架构理念，基于业务能力、组件及服务而形成的银行应用之间互联互通的技术标准。
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），用于为解决方案的开发提供业务功能框架。服务域和业务能力为明显不同的目的而将业务区分开来。服务域是一种功能细分，旨在提供一个开发/部署框架。业务能力代表了不同的业务所拥有的能力，目的是制定和实施业务战略。
BIAN 服务域可以被认为是 “对某物做某事的能力”，专注于对一个业务对象所执行的操作。BIAN 服务域是原子性的，这意味着 “代表了可以被服务化的最小实际能力或功能分区。” 换句话讲，一个服务域将封装适合（被封装到） IT 服务中的最小实际业务功能 Business Functionality 。在某些情况下，服务域直接（或几乎）与业务能力相一致；然而，由于服务域是面向功能的，它们通常与价值流 Value Stream 有关，或者更经常地与价值流阶段 Value Stream Stage（或其一部分）有关。
BIAN 的价值链
构建业务能力地图，比想象的要难。不信？可以尝试为自己所在公司创建一张业务能力地图：第一，你会在 What 和 How 之间做很长的思想斗争；第二，到底啥是你脑海中的某个业务能力，你想的这个真的是业务能力吗？第三，在深入到 3 级以下业务能力切分的时候，业务能力已经与任务开始混杂在一起了，不好定义。
企业架构实践中有一个误解，就是在业务架构环节一定要产出业务能力地图。是否产出能力地图，这个要看企业领导和业务层的习惯，如果多数人更擅长理解价值链，那就用价值链作为沟通工具，最终目的是为了方便沟通达成共识。价值链不知道是啥？没关系，业务流程大家都懂。
BIAN 价值链（点击图片放大）
BIAN 的价值链并不是真正的价值链，因为价值链是要进行更下一步分解的，但是 BIAN 仅分解到第 2 层就戛然而止。BIAN 使用价值链视图的真正目的，是给银行另外一个看待原子业务能力的视角。注意下图中的第 3 级，已经不是呈现的活动的分解，而是服务域 Service Domain 这种原子能力。
BIAN 价值链明细图（点击图片放大）
BIAN 到底是什么
经过多年积累，BIAN 为银行业务构建了一批原子业务能力，使银行在信息化建设的过程中可以利用 BIAN 的行业框架，依据自身实际情况进行调优后，便捷高效地实施数字化战略。BIAN 构建了便于业务侧理解的业务能力地图与价值链，将原子业务能力通过映射的方式与两个业务架构中的关键工件进行关联，从而实现银行的业务与 IT 对齐。原子能力便于组装的特性，极大地促进了业务侧的创新与调整；通过统一规范的接口，为银行铺就了一条互联互通的开放之路。
学会了什么
作为业务分析师，俺对业务流程分析有着天然的好感。学习 BIZBOK 后，知道业务能力地图很重要，但是它为什么重要呢？它到底决定了什么？以前没有业务能力地图，也一样把系统成功交付上线。凭什么学个业务架构，就非得去搞这个业务能力地图呢？
这是因为微服务体系结构中的服务，是围绕业务问题进行组织的——业务能力或业务子域，而非技术问题。应用分解为服务有两种方式：按业务能力分解或者按业务子域分解。前者基于业务架构设计中产出的业务能力地图，后者基于领域驱动开发的设计环节。
领域驱动设计 DDD，是一种自下而上的方式。同时需要业务人员、领域专家、业务分析师、开发、架构师等共同参与。两种方式设计的结果可能极其相近，但创建业务能力地图的效率会更高，更容易被理解，更容易被业务参与。
业务能力地图设计可以脱离技术在业务端独立完成，是一种自上而下的方式，它展现了完整的业务视角。业务能力通常集中在特定的业务对象上。每个业务能力都可以被视为一种服务，但它是面向业务而非技术性的，其特性包括输入、输出和服务级别协议。一旦在业务架构分析中确定了业务能力，就可以为每个能力或一组相关能力定义一个服务。最终的成果是围绕业务概念而不是技术概念组织服务。
围绕业务能力组织服务的一个关键好处在于业务架构是相对稳定的，所以后续产生的架构设计也是相对稳定的。
业务能力产出决定了服务的设计
1 前言
长期以来银行在追求业务敏捷性的转型过程中会在维护现有系统的同时不断接收到各 种冲击， 除了市场与竞争对手的冲击，还包括各种转型技术、方法和方向的冲击。突 进式转型还是渐进式转型，科技如何和业务协作进行转型， 银行内外如何布局和循序 渐进提升，这些都是需要结合行业和企业实际情况切实思考的问题。与互联网企业不 同，银行长期以来积累了大量已有系统， 而且“竖井”林立，数据不一致，功能与数 据冗余， 应用边界不清等问题长期存在， 而且所有这些都通过大量的“点对点”接口 进行连接。这一切都给如何改善现有资源的重用性，提升业务敏捷性带来了困难。
近些年来，随着一些驱动力的变化，银行业已经启动了新一轮数字化转型过程。这些 驱动力包括：
. 业务设计技术方面的进步，企业架构从偏重技术逐渐走向业务为要，业务架构 及业务模型越来越受到企业的重视。
. 技术平台的进步，以云为代表的技术平台逐渐成熟，带动了 ABCDEI(人工智能 AI, 区块链 Blockchain, 云 Cloud, 大数据 Data, 边缘计算 Edge Computing, 物联网 IoT)及 5G 的全面技术进步。
. 业务管理意识的提升， IT 与业务的不断融合， IT 也是业务。IT 自身也开始思 考结合开发运营一体化 DevOps 来逐步贯通。
. 银行在向 Bank 4.0 演进，在 API 经济互联互通下展开生态业务。 银行和多个 行业纵横交错形成了“涌现”创新局面。 不少银行已经展开了开放银行之旅。
银行业架构网络（BIAN）正是在这一背景下应运而生的。 BIAN 是一个业界多方协作的 非营利性组织(bian.org)，由全球领先银行，技术提供商， 顾问和学者组成。这个专 业人员网络共同致力于降低银行业务成本，并加快行业创新速度。 成员结合他们的行 业专业知识，定义了一个用以简化和标准化核心银行体系结构的银行技术框架。 同时 这一框架基于面向服务的架构(SOA)原则， 所形成的整合模型为银行提供了面向未来的 解决方案，以促进 API 经济下的行业协作。
借助 BIAN 参考模型，银行可以建立起业务能力“积木块”，通过与现有系统进行映射 和对接， 理清应用之间的边界。依托业界标准(如 ISO20022、FIBO 等)统一信息定义和 数据标准。参 BIAN 服务操作规范 API 的消息交互，从而达成面向服务的、松耦合的 未来银行架构。以此达成业务敏捷性的终极目标。这也是目前国内银行纷纷建设业务 中台、服务中台的目的。
从架构及技术角度看， BIAN 融汇了业界关于银行业务模型(如 IBM IFW)和技术体系(如 API 和云)的积累、结合 SOA 架构和微服务架构理念，基于业务能力、组件及服务而形 成的银行应用之间互联互通的技术标准。在过去近五年时间 BIAN 差不多以每年一个版本的速度在进行演进， 截至到 2020 年初最新版本为 v8.0
(https://bian.org/deliverables/bian-standards/bian-service-landscape-8-0/)，BIAN v9.0 计划 2020 年 Q3 发布。国内一些银行也开始加入 BIAN 并结合 BIAN 来打造更为服 务化和生态化的银行系统。
2 BIAN 理论基础
BIAN 是企业架构思想在银行的延伸， BIAN 一直致力于开发出一种用于企业架构设计， 业务能力(Business Capabilities)和相关服务操作(Service Operations)的方法。通 过选择并组装这些不同层面的“积木块”来对银行（或金融机构） 进行建模。由于BIAN 的设计是“规范的 ”，这意味着面向任何金融组织的不同实施情况，它们可以以 一致方式进行诠释。考虑到规范性设计定义以及松耦合架构，BIAN 方法采用了面向服 务的架构(SOA)方法。
2.1 BIAN 基于 SOA 体系架构的优点
盛行于本世纪初的 SOA 面向服务架构体系在系统设计和实现方面的优点已经有很多文 档进行了充分论述。但是，随着领域驱动设计(DDD-Domain Driven Design)，微服务 架构(Microservice Architecture)的不断流行， 很多用户将 SOA 逐渐打入“遗留”系 统或方法之列。更有甚者，认为 SOA 就是单体(monolithic)架构的代名词。实际上 SOA 用“服务”一致性贯穿业务和技术的思路仍然是适用的，只是技术上的局限性， SOA 在 早期阶段把更多重点放到了应用整合服务整合以及流程整合方面。随着技术的不断进 步特别是随着微服务、云原生技术以及 PaaS 平台云的不断成熟， 我们需要对 SOA 理论 体系 “温故而知新”。结合目前这些前言技术更好地将“服务”理念向业务延伸， 真 正落实 SOA 的核心理念。笔者将一些关系较为密切的方法体系进行了比较，供大家快 速参考。关于方法体系会在方法专题专门展开讨论。
面向服务架构 SOA 则通过“服务 ”概念贯穿业务与 IT，打通了长期以来相对 隔离的三大领域：业务流程改进、应用设计与开发以及软件的运维。通过软件 架构及策略来支持业务的面向服务特征， 通过服务统一企业内的业务能力，对 接现有 IT 系统的服务能力。 SOA 横贯业务、 IT 及运维，必须以业务模型为中 心来一致性执行，否则会偏离业务本质， 影响企业级实施效果。本质上 SOA 更 多强调自顶向下的思路，也会结合自底向上这一方向。另外 SOA 继承了面向对象 (OO-Object Oriented) 及组件设计的很多理论体系，这些均体现在 SOA 设 计模式中。SOA 承接了业务架构和业务模型，并渗透到应用、技术以及运维架 构层面。
. 领域驱动设计(DDD-Domain Driven Design) 在贯彻企业架构(业务架构)建立 通用语言的前提下，针对特定业务领域自始至终贯彻领域(业务)驱动理念。将 业务模型(实体模型)与设计模式以及代码有机紧密衔接在一起，更多采取了自 底向上的思路。在向整个企业级推广时如果有企业业务架构及业务模型的有力 支持，会产生更好的推广效果。DDD 是 SOA 思想在某个业务领域的细化和延伸，适合应用项目级来切入。
. 微服务架构则是在数字化转型下催生的新型分布式架构，强调服务的职责单一、自治性和独立演进，业务上承接了 SOA 服务理念，但在技术上与分布式技 术、云、容器等紧密结合。因此微服务需要从 XYZ 三个维度全方位考虑， 即微 服务本身自治性的业务服务属性、横向扩展属性、数据分片属性。 如果片面从技术角度看待微服务的技术特性， 会使微服务的效果大打折扣，例如微服务的 业务切分合理性。
因此有必要重新回顾 SOA 方法体系的要点，指导 IT 解决方案乃至“中台”体系的设 计：
. 服务。通过服务贯穿业务和 IT 系统架构， 通过对功能的封装和暴露提升信息 流动性，以及更好的组织灵活性。
. 服务重用和共享。基于服务的软件设计和架构可以有效减少开发和管理(运维) 成本。
. 消息。基于消息的通信机制可以带来广泛的积极效应，包括配置灵活性， 更易 于监控和获取洞察，更好的控制和安全性等。
. 复杂性。服务可以简化软件的复杂度，使得复杂性高的软件更具适应性， 也更 容易进行方案整合。
自然， SOA 更为重要的理念在于贯穿业务和 IT。下图示出了 BIAN 的基于 SOA 的业务设 计原则和技术 。
BIAN 的整个理论体系是基于 SOA 的，将“服务”向业务架构层面进行了延伸。通过对 银行运营服务能力的组件式切分和能力组件之间交互的定义，刻画了银行业务运营实 践。
. BIAN 的服务能力组件是松耦合且独立的 - BIAN 最核心的一个概念是服务域 (Service Domain) 。 服务域是业务能力的划分单元，同时也是业务服务的封 装单元。服务域之间相互独立、松散且唯一，互不重叠，因此通过服务域中的 业务服务之间的协作可以进行真实业务场景建模。
. BIAN 服务域是完整全面的 - BIAN 立足于定义一个完整的银行服务组件集 合，所有可能的业务活动都可以通过服务域之间的协作来完成。
. BIAN 服务域是基本的(原子性的) - 服务域仅支持单一的业务目的。服务域是 业务服务的最小封装单位，不包含更小更细的服务域，多个识别出的服务域可 能构成服务域协作集群。
. BIAN 服务域封装了业务行为和业务对象 - 服务域是银行系统“动态”行为模 式与“静态”业务对象的一个结合体，进一步对这些动态行为和静态对象进行 了标准化语义层面定义，从而可以准确一致地对银行业务进行描述。
基于上面的业务运营设计理念，BIAN SOA 在进行应用调整时提供了更多可能性:
. 运营能力重用 – 每个服务域构成的独立且唯一的运营能力可以在企业范围内 进行广泛使用， 这提升了运营能力的重用，将精力放到更需要资源的专业领域，改进资源利用率和水平。
. 运营灵活度提升 – 随着更多业务功能通过共享服务方式对外可用，业务需求 和业务模式的变化可以通过服务的调整或重用来更容易地得到支持。在适当的 情况下， 可以通过生态协作由外部合作方也可以及时提供这些能力。
. 减少信息碎片化和不一致性 – 服务域作为一种 SOA 能力组件成为其所管控的 业务信息的单一来源。由于服务域对其自身所管控的信息进行了封装，维护了 一个自治疆域。这一特性可以减少数据不一致性和碎片化。
. 性能优化 – 每个服务域都肩负或实现了一个明确定义的业务目的，其内部能 力可以针对某个具体操作进行优化。
. 对分布式系统方案的支撑 – 基于围绕服务域的设计框架，BIAN 可以将业务和 技术实现串接起来。因为服务域所定义的业务能力划分是独立且唯一的， 实现 了与其所封装的业务角色相关的业务实体的全生命周期管理。基于这一自治理 念， 这些能力组件可以和分布式环境(如云和微服务)很好配合在一起。
. 渐进式演进 - 通过 BIAN 服务域可以建立全局统一的服务目录，这样可以将现 有银行技术体系(如主机系统和企业服务总线 ESB)和新型的云及微服务体系从 整体上进行映射。这样便于企业从全局从业务高度进行应用布局和技术架构演 进和治理。
2.2 面向流程与面向组件的方法
谈及 SOA 体系架构的优点有一点需要延伸说明一下。也就是面向流程与面向组件的方 法差异和各自的适用场景。
可以说处理逻辑与信息是应用的两大支柱，长期以来传统银行应用更多采取了面向流 程的方法，围绕流程或交易进行相关业务信息的准备和访问。这样做有不少优点：
. 业务信息围绕流程逻辑精确定义，相关信息专注在对流程及交易的支持上。
. 业务信息可以加以结构化以确保高效访问，可以为了性能对信息组织方式进行加 工，这在主机应用上很普遍。
. 通用的企业参考业务信息可以在可用的地方轻松整合。
然而，随着此类应用的长期演变， 多种流程和交易会交织在一起。相关信息结构如果 缺乏数据治理也会重重叠叠，越滚越大， 也就是耦合性越来越高。这会造成：
. 跨企业模型逻辑业务信息视图的碎片化， 从而导致处理及数据的不一致性。
. 不能轻易对设计进行改变和增强以适应变化。
随着数字化转型对应用交付时间和频度的要求不断提升，上述面向流程这一体系架构 的弱点逐步凸显。而采取面向组件的方法可以较好应对这一需求：
. 所有的业务信息治理管控功能都唯一地分配到相关的责任实体中， 分而 治之， 各行其责。
. 信息的业务上下文定义良好， 避免错误的推断，即在不同的业务环境中使用的类 似类型的信息必须始终共享相同的信息值。
. 对信息完整的生命周期进行管理， 确保执行适当的动作以维护信息的完整性和 流转。
当然， 面向组件甚至当下较为流行的微服务方法也有其弱点：
. 提供对单一受管信息的访问会带来延迟或延迟的可能性，以及可能的访问限制 和约束。为了改善这一点，从技术架构层面会通过多种手段加以改善，如读写 分离，但这又会引入数据一致性和补偿机制等复杂问题。
因此，两种方法有着各自的适合场景，可以在加强治理的前提下结合使用。
流程信息模型最有可能适用于可以优化信息访问性能的后台应用。应用程序之间的链 接和边界比较稳定，而且它们所引用的信息集中聚焦，这意味着业务信息的本地访问 和共享通常可以在单体信息体系结构中实现。在后台应用开发中也可以引入组件治理模型，这可能有助于协调应用程序之间的公共信息关联，以限制遗留应用程序中的流 程和信息碎片。
组件信息模型最有可能适合前台应用。 前台应用可能访问更广泛的信息来源和服务。 所管控的信息模型支持在需要时灵活地以任意组合方式进行连接和访问。由于交换的 信息由每个服务域自主管理，因此可以根据需要确保其完整性。 组件信息模型所维护 的清晰的信息上下文、定义和属性还可以跨业务地对所交换的信息值进行正确解读。
BIAN 更多采用了面向组件的方法，并在具体实施时和现有技术进行了映射。当然， 在 实践过程中特别是近些年来微服务实践过程中还有很多问题值得深入探讨，如服务的 粒度问题，数据一致性问题等。这些从宏观角度仍然需要两种方法的结合来考虑。
2.3 BIAN 体系结构
BIAN 可以与企业已经或行将采用的企业架构体系结合起来，丰富企业架构的内涵和具体可操作性。 BIAN 的整体架构如下图所示 。
可以看到，BIAN的整个服务全景视图涵盖了企业架构的很多内容， 形成了一整套架构 资产，包括：
. BIAN 元模型 (Meta Model)，基于ISO 20022元模型;
. BIAN 业务术语 (Business Vocabulary);
. BIAN 高阶参考地图: BIAN服务全景视图 (BIAN Service Landscape);
. BIAN 业务架构 (Business Architecture);
. BIAN 业务能力模型 (Business Capability Model);
. BIAN 服务域定义 (Service Domain Definitions);
. BIAN 服务操作定义 (Service Operations Definitions);
. BIAN 业务场景定义 (Business Scenario Definitions);
. BIAN 应用程序接口/消息定义 (API/Message Definitions);
. BIAN 信息架构 (Information Architecture);
. BIAN 业务对象模型 (Business Object Model), 完全与 ISO 20022一致
BIAN 以UML模型库的形式进行发布，同时也以 HTML 格式提供只读版本。大家可以访 问 BIAN website (https://www.bian.org/)来进行访问， 后面的介绍所引用的模型快 照均来自这一网站。另外，每一个BIAN标准的发布版本还带有相应的支持文档并随版 本演进而进行维护。
2.4 BIAN 在线资源
BIAN是一个开放模型体系，一个不错的学习方式是直接访问 bian.org 网站，另外一 个方法是从网站下载相关文档来学习。下面我们结合实际网站 bian.org 浏览一下
BIAN的模型体系和文档体系。
通过bian.org主页下的 DELIVERABLE 入口进入BIAN交付件入口，然后选择 BIAN STANDARDS 进入BIAN的标准。在DIGITAL REPOSITORY 即可进入BIAN在线模型库。
在BIAN STANDARDS 下的“BIAN HOW TO GUIDE”是BIAN 文档的一个完整集合。其目标 读者主要是技术架构师，BIAN成员及其他金融机构。这些指南文档对于细化BIAN全景 视图背后的理论体系并进行设计实践很有帮助。这些文档包括：
. “BIAN How-to Guide – INTRODUCTION TO BIAN V7.0”是一个整体How-to 文档指南
. “BIAN How-to Guide – DESIGN PRINCIPLES TECHNIQUES V7.0”介绍了 BIAN的设计原则及技术
. “BIAN How-to Guide – DEVELOPING CONTENT V7.0”介绍了BIAN标准体系 的开发
. “BIAN How-to Guide – APPLYING THE BIAN STANDARD V7.0”简要描述了 如何运用BIAN
. “BIAN How-to Guide – SEMANTIC API V7.0”是介绍BIAN API体系的文档
大家可以利用这组“How-to Guide” 作为在自己企业实施BIAN模型的工具。本文也会 简要回顾一下这些文档中的要点。
下面先简单浏览一下BIAN的在线模型库 InSite 。下图 的模型体系总图中包含了三条主线：其中中轴线是BIAN的主线，包括了服务域及服务 操作、贯穿服务域的业务场景以及业务对象模型BOM。另外两条线是近期BIAN标准的演 进方向， 包括业务能力模型以及价值链模型。
在下面的概念说明中会结合这里的模型体系进行说明。
3 BIAN 关键概念
除了服务域(Service Domain)，BIAN 基于业界标准，如 ISO20022， SWIFT，IFX(Interactive Financial eXchange)，FIBO(Financial Industry Business Ontology, EDM Council 与 OMG 联合提出的金融业务本体模型)等引入了一组概念， 这 些概念或多或少与其他方法如企业架构、面向服务架构 SOA 有着映射关系。企业在参 照 BIAN 时可以结合企业现有的架构体系概念进行映射。下面我们结合 BIAN 的在线模 型库展开分析和说明一下这些概念。
3.1 应用对应用(APPLICATION 2 APPLICATION)
也称企业应用整合(EAI-Enterprise Application Integration)。使用软件及计算机 系统的架构原则来进行企业计算机应用的整合。下图清晰地说明了BIAN与几个业务标 准以及A2A/B2B的相关关系。
另外，上图很清晰地阐明了BIAN的关键侧重点：
. 侧重应用到应用 (A2A)，与IFX和SWIFT侧重B2B形成互补。近些年来随着欧盟 PSD2(支付服务指令 Payment Service Directive 2)，TPP(Third Party Provider第三方提供商)以及开放银行API体系的整体发展态势， BIAN的整体重 心也逐渐从A2A转向A2A/B2B兼顾。
. 重心完全放在语义定义上 – 技术定义不包括在正式工作产品中， 这样有助于 平衡其他已经开展的行业工作。
. BIAN遵循IFX， 以及OMG(Object Management Group)，ISO 20022和SWIFT标 准，与这些标准保持一致和沟通。
. 面向服务，而IFX， SWIFT，以及 ISO 20022 都是面向消息的。
. UML(Unified Modeling Language) 是基础技术， 在金融服务业使用广泛。
3.2 服务全景视图 (SERVICE LANDSCAPE)
是涵盖了每个已标识服务域的参考模型， 300多个服务域以分组形式进行组织，帮助从 全局角度来理解、识别和选择。
3.3 业务区域 (BUSINESS AREA)
BIAN中的最高阶分类， 业务区域将广泛的业务能力组合在一起。 就BIAN服务全景视图 而言， 业务区域从一个侧面定义了具有相似的应用支持和特定信息需求的业务活动。
BIAN的业务区域分为： 参照数据(Reference Data)，销售和服务(Sales and Service)，运营和执行(Operation and Execution)，风险和监管合规(Risk and Compliance)，业务支撑(Business Support)5个。
3.4 服务域 (SERVICE DOMAIN)
服务域封装了服务操作(Service Operation)或者业务服务，服务操作则定义了业务能 力积木块之间的交互。服务域进而在组织，过程和支持它们的相关信息系统方面进行 了更为全面的定义。 尽管通常会将注意力集中在IT系统和系统接口上，但是这种关注 不应掩盖一个事实，即服务域代表了一种业务能力划分， 企业可以将其人员，流程和 系统从业务层面一致性地进行整合封装。
3.5 业务领域 (BUSINESS DOMAIN)
是介于业务区域(Business Area)和服务域(Service Domain)之间的一个层级，业务领 域(Business Domain)在更广泛的业务区域中定义了一系列一致的能力。 在BIAN服务 全景视图中，业务领域与金融服务业务中可识别的技能和知识相关。例如在销售和服 务(Sales and Service)业务区域下包含了一系列与销售和服务相关能力：具体渠道(Channel Specific)，跨渠道(Cross Channel)，市场营销(Marketing)，销售(Sales)，客户关系管理(Customer Relationship Management)，服务(Serving)。下 图示出了BIAN服务全景视图中的层次结构：业务区域、业务领域和服务域。
结合服务领域的概念， 可以进一步进行深入拆分银行业务能力。例如客户管理 (Customer Management)这一业务领域进一步包含了12个服务领域：
. 客户关系管理(Customer Relationship Management)
. 客户产品/服务资质(Customer Product/Service Eligibility)
. 客户协议(Customer Agreement)
. 销售产品协议(Sales Product Agreement)
. 客户访问权限(Customer Access Entitlement)
. 客户行为洞察(Customer B