📷 📄 👩‍🍳 Modèle de référence BIAN. Quelles sont les nouveautés et l'utilité de l'architecture d'entreprise de la banque? ✍🏿 👩🏽‍🎓 📻

BIAN ... comme il y a peu dans ce son pour le coeur d'un Russe ... Oui, ce n'est pas par hasard que j'ai paraphrasé le fameux classique. La popularité du modèle de référence BIAN est encore faible en Russie, en particulier par rapport au modèle Enhanced Telecom Operations Map (eTOM), répandu dans l'industrie des télécommunications, qui est en avance sur son développement. Pendant ce temps, le modèle BIAN se développe, s'améliore et gagne en popularité en dehors de la Russie et dans la communauté internationale du secteur bancaire.

Je ne distraireai plus le lecteur avec des digressions lyriques, je dirai seulement qu'une revue du modèle BIAN et des documents d'accompagnement de la norme sont dans mon premier article sur BIAN, ici, j'essaierai de dire en quoi BIAN peut être utile aux chefs d'entreprise, aux architectes d'entreprise, aux architectes d'entreprise, aux architectes de solutions, aux spécialistes informatiques et à toutes les autres personnes intéressées par la gestion de l'architecture complète d'une entreprise financière. Et aussi à propos de ses principales transformations utiles, à mon avis.

Quoi de neuf et d'intéressant?

BIAN est devenu plus abordable

À mon avis, l'un des changements les plus importants et cardinaux qui s'est produit avec le modèle de référence BIAN a été sa traduction dans la notation Archimate . Il est devenu plus facile à lire. Les développeurs de BIAN, apparemment, ne pouvaient s'empêcher de reconnaître la nécessité d'utiliser une notation standard pour la décrire afin de la diffuser davantage dans les milieux professionnels . Le modèle de perception est devenu plus clair pour les architectes, car il est décrit dans un langage compréhensible pour les architectes. Ainsi, la version de BIAN 8.0 est présentée dans le langage d' ArchiMate 3 . Le modèle est dans le domaine public . En vous inscrivant sur www.opengroup.org , tout le monde peut indépendammentTéléchargez une description du modèle BIAN et de tous ses composants en notation Archimate.

Implémentation BIAN dans l'API

Un autre point important qui mérite d'être mentionné est que l'Association indépendante à but non lucratif des normes ( réseau de l'architecture du secteur bancaire (BIAN) ) gère et met à jour le référentiel d'API pour ses domaines d'activité paysagers.
Les développeurs de BIAN visent à créer un référentiel abordable d'API et de microservices de haute qualité pour aider les banques à effectuer une mise à niveau rapide et rentable.
Les fichiers source de l' API du référentiel sont également publiés et disponibles en téléchargement après inscription sur le portail (si quelqu'un a des difficultés à s'inscrire, essayez de vous inscrire en mode navigation privée de votre navigateur).

Ensuite, nous examinerons plus en détail le métamodèle BIAN en notation Archimate et son implémentation en tant qu'API.

Métamodèle BIAN en notation Archimate

Dans cette partie, je propose de considérer la structure actuelle du paysage BIAN en notation Archimate basée sur un document d'OpenGroup . Ce document offre des options pour un développement flexible, allégé et stable de l'architecture bancaire à l'aide des langages ArchiMate et BIAN.

Commençons donc par la description du métamodèle BIAN.

Éléments de paysage BIAN

Figure 1. Superposition du paysage de service BIAN sur le métamodèle

Le paysage de paysage de service BIAN est hiérarchiquement formé à partir des composants de base clés suivants:

Zone d'affaires - Vert
Domaine d'activité (domaine d'activité) - Orange;
Domaine de service - Bleu.

Le domaine d'activité en termes d'Archimate est exprimé par l' élément Groupement . Le domaine d'activité et le domaine de service sont reflétés dans le diagramme par l'élément Capability .
Selon les règles de notation, la capacité est utilisée pour représenter à un niveau élevé les capacités actuelles et souhaitées de l'organisation par rapport à sa stratégie.

Le Business Area (Business Area) est positionné au plus haut niveau de la hiérarchie du paysage BIAN et est utilisé pour mettre en évidence et regrouper en blocs de domaines clés de développement dans les institutions financières.
BIAN a identifié les domaines d'activité suivants dans le modèle de référence BIAN:

donnée de référence;
vente et service;
opérations et exécution;
risques et conformité (+ analytique);
soutien aux entreprises.

Les architectes des domaines d'activité (Business Domains) des entreprises bancaires définissent la décomposition de l'activité bancaire en un ensemble d'exclusivités mutuelles, dans leur totalité épuisant complètement les opportunités commerciales de l'entreprise. Les domaines d'activité déterminent les segments bancaires considérés par les architectes de l'activité bancaire d'un point de vue fonctionnel, architectural et technique.

Un domaine de service est un bloc fonctionnel élémentaire ou atomique dans le paysage BIAN.
Chaque domaine de services propose un ensemble de services (groupe de services). Cet ensemble comprend les opérations de service. Un domaine de service est un ensemble d'opérations de service qui gèrent ensemble le cycle de vie complet d'un actif (type d'actif).

2. BIAN

Functional Pattern, Asset Type Action Term

La principale technique utilisée pour «isoler» le domaine de service BIAN (c'est-à-dire le distinguer comme une unité atomique indivisible du paysage) consiste à appliquer un modèle fonctionnel à une ressource (type d'actif).
Si nous regardons la définition des éléments Archimate, nous verrons que Business Interaction est utilisé pour le modèle fonctionnel , et un objet métier est utilisé pour le type d'actif .

Type d'actif - toute chose tangible ou intangible sur laquelle la banque a le droit de propriété et / ou d'influence, et a une ou plusieurs utilisations ou fins intégrales qui créent de la valeur commerciale.
Schéma fonctionnel- un comportement ou un mécanisme qui peut être appliqué à n'importe quelle ressource dans la réalisation d'activités commerciales (par exemple, concevoir, diriger, gérer, enregistrer, etc.)

Figure 3. Modèles fonctionnels dédiés

BIAN a également défini un ensemble standard d'actions ( Terme d'action ) caractérisant différents types d'opérations de service. Chaque opération de service effectue exactement une action.
Une liste complète des termes d'action (représentés comme des fonctions commerciales ArchiMate) est donnée ci-dessous.

Figure 4. Ensemble standard d'actions ( terme d'action )

Un ensemble d'actions (terme d'action), qui forment ensemble un type de comportement répétitif, est appelé un modèle fonctionnel.
La norme BIAN fournit une matrice très pratique et intuitive de la communication entre les modèles fonctionnels et des opérations standard:

Figure 5. Communication des modèles fonctionnels et des opérations standard

C'est quelle est l'idée principale? Nous pouvons concevoir et mettre en œuvre presque toutes les activités bancaires à travers un ensemble d'opérations donné et limité!
Chaque domaine de service contient en même temps un seul modèle fonctionnel principal avec un type de ressource. Et nous obtenons une ressource à laquelle nous pouvons appliquer tel ou tel modèle. De plus, le nombre de modèles n'est certainement pas très important par rapport au nombre de domaines d'activité dans le paysage!
De plus, nous voyons dans le métamodèle BIAN qu'un modèle fonctionnel qui agrège un certain ensemble d'opérations standard et implémente les opérations de service (en violet est indiqué dans la figure ci-dessous), inclus dans le groupe de services qui implémente également la fonctionnalité de domaine de service:

Figure 6. Relation entre les modèles fonctionnels et opérations de service
Et, comme nous l'avons déjà expliqué ci-dessus, un ensemble d'opérations de service contrôle conjointement l'ensemble du cycle de vie d'une certaine ressource ( type d'actif ).
Au total, nous obtenons la connexion: Domaine de service - domaine de service (la fonctionnalité dont nous avons besoin pour les entreprises) -> Type d'actif - la ressource spécifiée du domaine de service (avec laquelle nous travaillerons pour mettre en œuvre notre tâche, par exemple, le prêt hypothécaire) -> Modèle fonctionnel - modèle fonctionnel (comportement caractérisant les actions avec notre ressource). "

Dossier générique d'artefact et de contrôle

Considérons maintenant un autre groupe d'éléments de métamodèle, indiqué dans la figure ci-dessous en surlignant.

Figure 7. Artefact général et enregistrement de contrôle
Un modèle fonctionnel est un niveau d'abstraction assez élevé (il ressort également du métamodèle qu'il est implémenté par des opérations de service plus spécifiques, mais j'en parlerai plus tard lorsque nous considérons la connexion à l'aide d'un exemple spécifique).
Et donc l'artefact qu'il affecte directement est également abstrait. Il s'agit d'un artefact générique (artefact générique ). Pour chaque modèle fonctionnel, BIAN a identifié un artefact commun, comme illustré ci-dessous:

Figure 8. Un ensemble d'artefacts courants

Entrée de contrôle ( enregistrement de contrôle)) sont les informations nécessaires pour résoudre les problèmes internes du domaine de service. Il s'agit d'une sorte de journal d'informations sur le cycle de vie d'une ressource accessible par un modèle fonctionnel conformément à une instance d'un artefact commun ou à la suite de laquelle il est créé.
Si, par exemple, la ressource est "compte courant", le modèle fonctionnel est " exécution " et l'artefact commun associé est " Obligation ", alors l'enregistrement d'audit spécifique est "Obligation de remplir (tâches pour) le compte courant".
Le nom de l'enregistrement d'audit est une combinaison du nom la ressource et le nom de l'artefact commun. Le domaine de service "compte courant" fournira des services liés à "l'organisation de l'exécution du compte courant".
Un enregistrement de contrôle peut être considéré comme une information sur le cycle de vie d'une «ressource qualifiée», où le qualificatif est un artefact courant.

Figure 9. Exemple de domaine " compte courant "

Opérations de service

«Opération de service» est une action spécifique effectuée sur une ressource donnée. Il s'agit d'un service élémentaire.
Dans l'exemple de compte de service "compte courant ", le domaine de service est capable d'exécuter "intiateCurrentAccountFulfillment", "executeCurrentAccountFulfillment", etc., qui sont les termes d'action agrégés dans le modèle fonctionnel et appliqués à l'enregistrement de contrôle.
Ceux. si nous superposons des groupes de services sur une matrice avec des opérations, il sera clair quelles actions nous devons effectuer avec notre ressource:

Figure 10. Exemple de superposition de terme d'action sur un groupe de
services Les opérations de service pour exécuter un «compte courant» sont dérivées des conditions du modèle fonctionnel. Les opérations de service sont organisées en groupes de services.

Message et condition

Les opérations de service ne sont possibles que via des interfaces clairement définies. Chaque opération de service nécessite un événement pour pouvoir «fournir» le service. Cet événement sera un type de message appelé message entrant . Une opération de service sera mise en œuvre par le biais d'un traitement interne, en déléguant éventuellement certaines tâches à d'autres opérations de service. Par conséquent, le service émettra une réponse en tant que message sortant. Un message qui est un message d'entrée pour une opération de maintenance peut être un message de sortie pour une autre opération de maintenance.

Figure 11. Messages entrants / sortants et conditions d'exécution du service

Le domaine de service décrit également les dépendances existantes sur d'autres domaines.
En particulier, un exemple de liste de domaines de services dont nous attendons de recevoir un message entrant:

Figure 12. Exemple de communication avec d'autres domaines pour le

total «Compte courant» , nous avons examiné tous les éléments du métamodèle BIAN. Et il est temps de passer à l'implémentation du modèle BIAN sur l'API. Mais avant de faire cela, je veux attirer l'attention sur le fait que le modèle contient beaucoup plus de représentations de sa description. Il existe à la fois une description d'objet, des diagrammes de séquence, des wireframes et autres.
J'invite les lecteurs à se familiariser avec eux par référence .
Et aussi avec une comparaison du modèle et du cadre Togaf .

Implémentation du modèle BIAN via l'API

Comme mentionné ci-dessus, la communauté des développeurs BIAN développe et réapprovisionne régulièrement le référentiel des services REST qui sont conformes aux principes de la norme BIAN.
Pour vous familiariser, il est nécessaire de vous inscrire sur le portail , d'aller dans le référentiel et de télécharger les fichiers source ou de vous rendre sur la console pour vous familiariser.

Figure 13. Exemple de navigation dans l'API BIAN du référentiel

En mode console, vous pouvez lire la documentation dans Swagger:

Figure 14. Exemple de référentiel BIAN de l'API de navigation pour le compte de domaine de service Compte courant
pour travailler avec du code:

Figure 15. Accès au stockage de fichier API d'origine BIAN

Pour simplifier comprendre comment utiliser les API, vous pouvez lire le document. J'invite les lecteurs et les développeurs à maîtriser déjà cette partie du travail avec BIAN de manière indépendante, ou à participer à un webinaire, qui se tiendra dans un proche avenir, où il sera possible d'obtenir des informations de première main et de poser des questions à la fin du webinaire .
Le contenu principal sera présenté lors du webinaire et les changements, améliorations et extensions introduits dans la norme BIAN dans la dernière édition seront mis en évidence.

Approche possible de l'application de la norme

Je décrirai l'approche de haut niveau de l'utilisation du modèle de référence BIAN:
La principale chose à laquelle vous devez faire attention est que le modèle suggère de ne pas utiliser une approche de processus, mais une approche de microservice.

Ceux. le paysage est un certain ensemble de briques de haut niveau (domaines de service),
chaque domaine possède son propre ensemble d'outils (opérations de service)
pour travailler avec certains artefacts (ressources).

Et nous assemblons déjà le processus dont nous avons besoin à partir de ces briques. Mais nous sommes également aidés en cela par l'ensemble déjà conçu de diagrammes de séquence, de wireframes, de modèle d'objet.
Ceux. à travers ces représentations, de nombreux processus de communication ont déjà été conçus.

Il est possible pour l'entreprise:
1. d'étudier le paysage en détail, de le mettre en évidence visuellement (en couleur, cadres ou d'une autre manière) les domaines dont il a besoin pour son objectif fonctionnel (il est possible de superposer et de comprendre le niveau du système dans lequel les systèmes les données sont dupliquées, Par exemple, c'est une des questions difficiles, à mon avis, qui se pose lors de la conception d'une architecture de microservices, et le modèle BIAN suggère que nous y réfléchissions au niveau de l'entreprise).
2. Étudier le métamodèle BIAN pour comprendre le fonctionnement de chaque domaine (j'espère que cela aidera ma revue, ce que j'ai fait plus haut sur le métamodèle).
3. Téléchargez les API nécessaires depuis le portail (ou assurez-vous d'abord que l'ensemble requis est déjà présent).
4. Explorez d'autres représentations du modèle BIAN.
4. Tracer une carte de migration prenant en compte l'architecture actuelle de l'entreprise pour sa transition vers le microservice.

Architecte système,
© Irina Blazhina

Modèle de référence BIAN. Quelles sont les nouveautés et l'utilité de l'architecture d'entreprise de la banque?