🧑🏿‍🤝‍🧑🏽 🧓🏾 🚪 参考模型BIAN。它为银行的企业架构提供了哪些新的有用的功能？ 📶 🧗 🏗️

BIAN ...对于俄罗斯人来说，这种声音几乎没有。。。是的，我对这个著名的经典作了解释并不是偶然。 BIAN参考模型在俄罗斯的普及率仍然很低，尤其是与增强型电信运营图（eTOM）模型相比，该模型在电信行业中很先进，并且已经超前发展。同时，BIAN模型正在俄罗斯以外和国际银行业社区中发展，完善和赢得欢迎。

我不会再因为抒情偏离而使读者分心，我只会说，在我的第一篇关于BIAN的文章中，对BIAN模型和该标准的随附文件进行了回顾。，在这里我将尝试说明BIAN如何对业务经理，业务架构师，公司架构师，解决方案架构师，IT专家以及对管理金融企业的整个架构感兴趣的所有其他人员有用。在我看来，还有关于他的重要有用转变的信息。

有什么新鲜有趣的东西？

BIAN变得更加负担得起

在我看来，BIAN参考模型发生的最重要，最重要的变化之一就是将其转换为Archimate表示法。它变得更容易阅读。显然，BIAN的开发者不禁意识到使用标准符号来描述它的必要性，以便在专业领域进一步传播它。感知模型对于建筑师而言已经变得更加清晰，因为它以一种对于建筑师而言可以理解的语言进行了描述。因此，以ArchiMate 3的语言呈现了BIAN 8.0的版本。该模型是公共领域的。通过在www.opengroup.org上注册，每个人都可以独立进行以Archimate表示法下载 BIAN模型及其所有组件的描述。

API中的BIAN实现

值得一提的另一个重要点是，独立非营利标准协会（Banking Industry Architecture Network，简称BIAN）维护和更新了其景观业务领域的API存储库。
BIAN开发人员旨在创建负担得起的高质量API和微服务存储库，以帮助银行快速，经济地进行升级。在门户网站上注册后，还会发布存储库中API
的源文件，并可供下载（如果有人难以注册，请尝试以浏览器的隐身模式注册）。

接下来，我们将更详细地研究Archimate表示法中的BIAN元模型及其作为API的实现。

Archimate表示法中的BIAN元模型

在这一部分中，我建议根据OpenGroup的文档来考虑Archimate表示法中BIAN景观的当前结构。本文档提供了使用ArchiMate和BIAN语言灵活，精简和稳定地开发银行体系结构的选项。因此，让我们从BIAN 元模型的描述开始。

景观元素B

图1.的叠加边服务景观上的元模型

的边服务景观景观分层从以下项基本组分形成：

商业区-绿色
业务领域（业务领域）-橙色；
服务域-蓝色。

用Archimate表示的业务领域由分组元素表示。业务域和服务域通过Capability元素反映在图中。
根据表示法规则，能力用于高层表示组织相对于其战略的当前和期望的能力。

该商务区（商务区）位于边景观的层次结构的最高水平，是用来突出和集团的金融机构发展的关键领域块。
BIAN在BIAN参考模型中确定了以下业务领域：

参考数据；
销售和服务；
操作和执行；
风险与合规（+分析）；
贸易支持。

银行企业的业务领域（业务领域）架构师定义为将银行业务分解为相互排斥的集合，它们的整体完全耗尽了企业的商机。业务领域从功能，体系结构和技术的角度确定银行业务架构师考虑的银行部门。

甲服务域是卞风景内的基本或功能原子积木。
每个服务域都提供一组服务（服务组）。该集合包括服务操作。服务域是一组服务操作，这些服务操作共同管理资产（资产类型）的整个生命周期。

2. BIAN

Functional Pattern, Asset Type Action Term

用来“分离物”的边服务域（即，将其区分作为风景的原子，不可分的单元）的主要技术是应用一个功能性图案的资源（资产类型）。
如果查看Archimate元素的定义，我们将看到Business Interaction用于Functional Pattern ，而Business Object用于Asset Type 。

资产类型 -银行拥有所有权和/或影响力，并具有创造商业价值的一个或多个整体用途或目的的任何有形或无形资产。
功能模式-在执行商业活动时可以应用于任何资源的行为或机制（例如，设计，指导，管理，注册等）。

图3.专用功能模板

BIAN还定义了一组标准动作（“动作项”）表征各种类型的服务运营。每个服务操作仅执行一个动作。下面给出
了操作术语（表示为ArchiMate业务功能）的完整列表。

图4.标准动作集（动作项）

一组动作（动作项）一起构成重复的行为类型，称为功能模板。
扁标准提供功能图形和标准操作之间通信的非常方便和直观的矩阵：

图5的功能性图案的通信和标准操作

即主要思想是什么？我们可以通过给定的，有限的一组操作来设计和实施几乎任何银行活动！
每个服务域在同一时间仅包含具有一种资源类型的一个主要功能模板。我们获得了可以应用此模板或该模板的资源。而且，与景观中的业务领域相比，模板的数量当然也不是很多！
此外，从BIAN元模型中，我们看到了一个功能模板，该模板聚集了一组标准操作并实现了服务操作（下图中以紫色表示），该模板也包含在服务组中，该服务组还实现了服务域功能：

图6.功能模式与服务操作
而且，如上所述，一组服务操作共同控制特定资源（资产类型）的整个生命周期。
总体而言，我们获得了以下连接：服务域-服务域（我们需要的业务功能）->资产类型-服务域的指定资源（我们将通过该资源来执行我们的任务，例如抵押贷款）->功能模式-功能模板（使用我们的资源来描述操作的行为）。”

通用工件和控制记录

现在考虑下图突出显示的另一组元模型元素。

图7.通用工件和控制记录
功能模板是一个相当高的抽象级别（从元模型中也可以明显看出，它是由更具体的服务操作实现的，但是稍后我们将通过一个具体示例考虑连接时，将对此进行讨论）。
因此，它直接影响的工件也是抽象的。它称为通用工件（Generic Artifact）。 BIAN为每个功能模板标识了一个通用工件，如下所示：

图8. 一组通用工件

Control Entry（控制记录））是解决服务域内部问题所需的信息。这是一种有关资源生命周期的信息日志，功能模板根据公共工件的实例或由此创建的结果来访问该资源的生命周期。
例如，如果资源是“经常账户”，功能模板是“ 履行 ”，并且相关的通用工件是“ 义务 ”，则特定的审核记录是“履行（执行）当前账户的义务”
。审核记录的名称是名称的组合服务域“当前帐户”将提供与“当前帐户的执行组织”相关的服务。
控制记录可以看作是有关“合格资源”生命周期的信息，其中限定符是常见的工件。

图9.示例域“ 当前帐户 ”

服务运营

“服务操作”是对给定资源执行的特定操作。这是一项基本服务。
在服务帐户“ 经常帐户 ” 示例中，服务域能够执行“ intiateCurrentAccountFulfillment”，“ executeCurrentAccountFulfillment”等，它们是功能模板中汇总并应用于控制记录的操作项。
那些。如果我们将服务组与操作叠加在一个矩阵上，则很清楚我们需要对资源执行哪些操作：

图10.在服务组上叠加操作项的示例
用于执行“经常账户”的服务操作是从功能模板的条件中得出的。服务操作分为服务组。

讯息及条件

只有通过明确定义的接口才能进行服务操作。每个服务操作都需要一个事件才能“交付”服务。此事件将是一种称为“ 传入消息”的消息。服务操作将通过一些内部处理来实现，可能将某些任务委派给其他服务操作。结果，该服务将发出响应作为外发消息。作为用于一个维护操作的输入消息的消息可以是用于另一维护操作的输出消息。

图11.传入/传出消息和服务执行条件

服务域还描述了对其他域的现有依赖关系。
特别是，一个我们希望从中接收到传入消息的服务域列表的示例：

图12.与“经常账户”

总计与其他域进行通信的示例，我们检查了BIAN元模型的所有元素。现在是时候继续在API上实现BIAN模型了。但是在进行此操作之前，我想提请注意以下事实：该模型包含其描述的更多表示形式。既有对象说明，又有时序图，线框图等。
我邀请读者通过参考熟悉它们。
并与Togaf模型和框架进行了比较。

通过API实现BIAN模型

如上所述，BIAN开发人员社区开发并定期补充符合BIAN标准原则的REST服务库。
为了解起见，有必要在门户网站上注册，进入资源库并下载源文件，或者进入控制台进行熟悉。

图13.在存储库API BIAN中导航的示例

在控制台模式下，可以阅读Swagger中的文档：

图14.用于服务域Current Account的导航API BIAN存储库的示例
可与代码一起使用：

图15.访问原始API文件存储BIAN

进行简化了解如何使用API，您可以阅读文档。我邀请读者和开发人员已经掌握了与BIAN独立工作的这一部分，或者参加了将在不久的将来举行的网络研讨会，届时将有机会获得第一手信息并在网络研讨会结束时提出问题。
主要内容将在网络研讨会上介绍，并将重点介绍最新版本中BIAN标准引入的更改，改进和扩展。

适用标准的可能方法

我将描述使用BIAN参考模型的顶级方法：
您应注意的主要事情是该模型建议不要使用过程方法，而应使用微服务方法。

那些。景观是一组特定的高级砖（服务域），
每个域都有自己的一套工具（服务运营）
使用某些工件（资源）。

而且我们已经在用这些积木组装所需的过程。但是，已经设计好的一组时序图，线框和对象模型也为我们提供了帮助。
那些。通过这些表示，已经设计了许多通信过程。

公司有可能：
1.详细研究景观，以视觉方式（以颜色，框架或其他方式）突出显示其功能目的所需的那些领域（可以叠加和理解在其中复制数据的系统级别的系统，例如，在我看来，这是设计微服务架构时出现的难题之一，而BIAN模型建议我们在业务级别上进行思考。
2.研究BIAN元模型以了解每个域的工作原理（希望这对我在上面对元模型所做的评论有所帮助）。
3.从门户下载必要的API（或首先确保所需的集合已存在）。
4.探索BIAN模型的其他表示形式。
4.绘制迁移图，其中要考虑到公司向微服务过渡的当前架构。

系统架构师，
©Irina Blazhina

参考模型BIAN。它为银行的企业架构提供了哪些新的有用的功能？