BIAN Framework

Le « Banking Industry Association Network » (BIAN) est une association comprenant des banques, des fournisseurs de solution et des établissements d’enseignement qui a pour objectif de définir une norme de fonctionnement des services pour le secteur bancaire. L’association définit les fonctions d’affaires ainsi que l’interaction des services qui permettent de décrire le fonctionnement interne d’une banque. Le standard BIAN offre les principaux avantages suivants:

• Facilite l’intégration des solutions logiciels ;
• Permet un développement plus efficient ;
• Améliore l’efficacité opérationnelle au sein des banques ;
• Offre l’opportunité pour la mise en place de solutions plus complexe ainsi que la réutilisation des services à l’interne et entre les banques ;
• Permet une prise en charge ainsi qu’une adoption plus souple des modèles d’approvisionnement des services aux entreprises ;
• Améliore l’évolution et l’adoption de services partagés – Service d’affaire en provenance des tierces parties.

Le standard BIAN réfère à une collection de modèles comme le « BIAN  Service Landscape ». Le développement du « BIAN Service Landscape » est itératif et s’appuie sur la contribution active des participants afin d’établir un consensus et encourager son adoption. L’organisme BIAN coordonne l’évolution du « BIAN Service Landscape » au nom de ses membres et communique régulièrement de nouvelles versions tout en recevant les commentaires des membres afin d’élargir et affiner le contenu du standard.

Les principaux documents « BIAN » qui font le standard inclus :

• Cartographie de référence à haut niveau du « BIAN Service Landscape » accompagné de la définition des domaines et des services ;
• Une série de guides pratique ;
• Le métamodèle BIAN et ses définitions ;
• Scénarios d’affaires BIAN et ses définitions ;
• Les définitions des domaines de service BIAN. Cela inclus les opérations de service sémantique ;
• La norme BIAN est publié dans un référentiel UML.

Les Guides pratiques BIAN décrivent les pratiques de travail BIAN. Il sont présenté comme une série de trois documents principaux

• Principes de conception et techniques – Ce guide est destiné pour les architectes d’entreprise. Il explique la théorie et la pratique de la conception pour ceux qui souhaitent comprendre l’approche BIAN ;
• Développement de contenu – Ce guide est destiné pour les membres du groupe de travail BIAN. Il explique l’approche de travail et les différents outils et modèles utilisés pour capturer le standard de BIAN ;
• Application de la norme BIAN – Ce guide est destiné aux membres et aux institutions financières souhaitant appliquer la conception du contenu BIAN dans diverses situations de déploiement technique.

De nombreux participants de l’industrie bancaire, y compris les membres fondateurs de BIAN ont fréquemment observé un problème commun et durable: une complexité excessive dans les portefeuilles d’application de la plupart des « BIAN Service Landscape ». La complexité est en fait le résultat de systèmes inflexibles qui sont incapable de répondre aux besoins d’affaires, des coûts d’entretien et d’exploitation élevés, de l’incapacité à tirer parti de l’évolution rapide : des nouvelles solutions du marché, des technologies, des nouvelles approches et des modèles d’affaires.

BIAN à entrepris de traiter ce problème en développant une norme commune qui définit des partitions fonctionnels et des services d’opérations qui pourront être utilisés par les Banques. Cependant, l’objectif de BIAN soulève une question essentielle: pourquoi le modèle et l’approche BIAN ferait mieux que les tentatives précédentes afin d’aborder la complexité du portefeuille d’applications? Au cœur de la proposition de BIAN est l’adoption d’une approche « orientée services » afin de concevoir l’architecture des systèmes des Banques. Cette approche est fondamentalement différente de la conception en vigueur « axées sur les processus ». Pour souligner cette différence essentielle une comparaison peut être faite avec le plan d’urbanisme d’une ville qui est un problème très concret de conception par opposition à la conception beaucoup moins tangible d’une entreprise commerciale comme une Banque.

Toute les conceptions sont une combinaison d’ingrédients et des comportements attendus. Les ingrédients se rapportent à des éléments statiques ou persistants qui sont «déployés» et les comportements se réfèrent à des modèles dynamiques des réponses souhaitées et prévu à des événements ou des déclencheurs. Afin de réaliser une conception globale l’architecte doit comprendre comment les ingrédients doivent être configuré pour supporter les comportements désirés . Dans le cas de l’urbaniste il a pour objet de rédiger un plan d’urbanisme. Les ingrédients sont les bâtiments, les parcs et les infrastructures qui doivent être en place afin de soutenir les comportements attendus des habitants de la ville. Ces comportements pourraient être tracées sur le plan d’urbanisme de la ville comme des trajets ou des «journées dans une vie» .

Comparé l’architecture des bâtiments tel que pratiqué par l’urbaniste et l’architecture d’entreprise pour concevoir les applications d’une banque révèle une lacune importante dans l’arsenal des outils pour les architectes d’entreprise. Ceci est illustré dans le tableau 1 ci-dessous :

Tableau 1 : Comparaison de la planification d’une ville et d’une entreprise

Les ingrédients qui composent une banque sont beaucoup moins tangibles que des bâtiments et des routes. Les ingrédients d’une banque représentent en fait les capacités que l’entreprise doit établir afin d’être en mesure d’exécuter ses affaires. Dans un plan d’urbanismes les comportements sont modélisés selon les déplacements à travers la ville alors que ce sont les processus d’affaires qui modélise les comportements que la banque prendra en charge. Les architectes d’entreprises ont une vaste expérience relatif à la modélisation des processus, mais souvent cette modélisation est réalisée en silos. Pour l’architecte d’entreprise le besoin est d’être en mesure de définir des blocs de capacités génériques qu’il pourra sélectionner et configurer afin de créer l’équivalent d’un plan d’urbanisme pour la banque. Ce qui lui permettra de prendre en charge les processus pour lesquels il est plus familiers.

Construire une ville sans un plan d’urbanisme directeur donne pour résultat un bidonville – les bâtiments et les routes apparaissant comme et quand ils sont nécessaires au fil du temps. Le chaos est ainsi inévitable. Sans un plan d’architecture d’entreprise, les systèmes construits afin de répondre aux besoins immédiats des processus tels qu’ils sont aujourd’hui, conduit au fil du temps vers un chaos inévitable en termes d’applications qui se chevauchent et qui sont redondantes, comme indiqué dans le diagramme 2.

Une ville ou la construction n’est pas                               Une entreprise ou le développement des applications
coordonné selon un plan d’urbanisme                             n’as pas été coordonné à l’aide d’une architecture d’entreprise

Diagramme 2: Construire sans un plan – Bidonville et un portfolio d’applications sans plus

Le problème de la complexité des applications va plus loin que le problème évident de redondance des applications qui se chevauchent. Il est fortement aggravé par la nécessité pour les applications d’être connectés les unes aux autres. Comme chaque application possède son propre champ d’application et ses limites spécifiques, chaque point à point est unique. Il ne faut pas beaucoup d’imagination pour voir comment le portefeuille d’applications se développe à plusieurs centaines de systèmes qui se chevauchent (chacun avec leur propre ensemble de connexions point à point). C’est ainsi que l’ajout ou l’amélioration de tout système devient un exercice de traçage très complexe de dépendances.

Par le biais du découpage fonctionnel la norme BIAN définit des capacités d’affaires distincte qui ne se chevauchent pas. Le « BIAN Service Landscape » vise à identifier toutes les possibilités d’affaires »élémentaires» qui permettent de définir une banque. Un plan qui utilise en tout ou en partie le découpage BIAN fournira le même schéma d’organisation que le plan d’urbanisme d’une ville – en éliminant les chevauchements et en définissant les connexions standard. Le diagramme 3 montre comment BIAN prévoit que les banques seront en mesure de rationaliser progressivement leur portefeuille d’applications afin d’éliminer la redondance et la complexité opérationnelle qui est associée en établissant et en adoptant la norme.

                                                                   Vision                                       Réalité                                                      Future

Diagramme 3: Migration vers une plan d’applications bien architecturé

L’approche de BIAN est orienté sur le service d’architectures (SOA) et les banques peuvent adopter cette approche basée sur les services de façon incrémentielle, en ciblant les secteurs de l’entreprise où la complexité est la plus contraignante pour celle-ci, ou des systèmes plus souples et adaptés sont nécessaires pour exploiter de nouvelles opportunités.

Les trois documents de la série sont maintenant décrits . Dans chaque cas, il y’a un schéma récapitulatif suivies de brèves descriptions pour les principales sections du document et sous-sections.

Principes et technique de conception

BIAN a développé une approche de l’architecture d’entreprise qui identifie les capacités d’affaires ainsi que les opérations de services qui permettent de définir une banque ou une institution financière. Le modèle BIAN est «canonique» ce qui signifie qu’il peut être interprétés de manière cohérente par une banque dans de nombreuses situations de mise en œuvre. Afin de définir un modèle canonique l’approche BIAN devait être fondamentalement différente des techniques plus traditionnelles qui ont tendance à suivre une organisation fondée sur les processus et qui sont portés vers un niveau de mise en œuvre plus détaillé. BIAN utilise un type spécifique de Service Oriented Architecture (SOA). Ce document décrit les concepts et les techniques de conception clés utilisées par l’approche BIAN comme indiqué dans le diagramme 4

Diagramme 4 : Concepts et techniques de conception

La norme BIAN permet de modéliser la couche de service à haut niveau de l’activité bancaire. Lorsque les banques adoptent ce modèle de services dans leurs environnements d’affaires actuel, ils ont besoin des couches intermédiaires plus détaillées afin de connecter l’architecture BIAN à leurs services d’affaires. Une exigence clé est le mapping de la cartographie sémantique de haut niveau de l’architecture BIAN aux messages du système. Chaque composant métier (appelée «service de domaine ») du  » Service Landsape » communique avec les autres composants métiers connexes, en fonction de leur processus d’affaires (appelé «Operation Service »). En technologie de l’information les processus d’affaires sont représentés par la communication des messages entre les systèmes.

Diagramme 5: BIAN Architecture – Message standards

L’architecture BIAN est une définition standard constitué de fonctions d’affaires et de service d’interactions qui décrivent toutes les fonctions exercées au sein d’une banque. Il permet de développer une conception à haut niveau d’une solution et peut être utilisé afin d’élaborer un « blueprint » d’une entreprise pour une planification opérationnelle et technique. Le modèle peut être appliqué à différents environnements techniques. Les avantages d’avoir une norme de l’industrie vs des conceptions propriétaires sont:

• développement réel et efficace maîtrisée ;
• facilité d’entretien ;
• intégration de solutions logicielles « simplifié », permet de réaliser du « plug and play »;
  
• possibilité de réutiliser les solutions déjà en place et d’améliorer l’efficacité opérationnelle au sein des banques ;
  
• intégration flexible avec des services d’affaires tiers partagées et des modèles de service d’entreprise.

Exemple :

BIAN a identifé 20 Patrons fonctionnels générique. Chacune des « Service Domain » est associé avec l’un des 20 Patrons fonctionnels identifiés.

• Les « Service Domains » (SD) sont regroupés en « Business Domains » (BD) et ceux-ci sont catégorisé en « Business Areas »(BA) ;
• Les « Services Operations » (SO) sont les moyens par lesquels les « Service Domains » interagissent les uns avec les autres dans un scénario d’entreprise ;
• Les « Service Domains » offrent et consomment des services d’opérations. Ceci assure que la spécification de mise en œuvre BIAN est agnostique ;

Les dépendances opérationnelles de communication entre les « Service domains » peuvent être classés selon quatre types :

1. Échange bidirectionnel – la réponse est envoyée immédiatement au « Service domain » appelant ;
2. Requête avec un retard anticipé dans la réponse – Le « Service domain » appelant poursuit ses travaux tout en anticipant la réponse après un certain temps. Appel le « Service domain » et surveille pour la réponse attendue ;
3. Notification  – Aucune réponse est attendue par le « Service domain » appelant à l’exception d’un accusé de réception du dit « service domain ». Appel d’un « service domain » pour lequel il n’y a aucun intérêt opérationnel suite au passage des détails de l’appel au « Service domain » appelé.
4. Souscription à une mise à jour – le « Service domain » appelant souscrit à des mises à jour du « Service domain » appelé à un moment donné.

SCÉNARIOS D’AFFAIRES
En tout ou en partie les activités d’affaires peuvent être modélisées en utilisant les « Service Domains ». BIAN a définit des scénarios d’affaires, qui sont des archétypes de la façon dont les « Service Domains » peuvent interagir afin d‘aborder les événements d’affaires. Le but des scénarios d’affaires proposés est de permettre la découverte et la clarification du fonctionnement des services d’opérations qui sont échangées entre les domaines de services impliqués dans une activité d’affaire. Les scénarios d’affaires ne sont pas prescriptifs ou canonique. Ils sont des exemples pour fournir un contexte et une explication du rôle et des comportements du « Service Domain ». Ils ne représentent pas précisément la logique et la séquence des tâches étroitement couplées comme dans le cas de la représentation de processus. Ils identifient plutôt les « Service Domains » concernés et présentent les échanges de services possibles à haut niveau entre ces « Service Domains ».

BIAN Service Landscape – Voir diagramme 5

• Business Area : Sales & Services
• Business Domain : Customer Mgmt
• Service Domain : Customer Relation Mgmt

Décomposition des types d’actifs – Voir Diagramme 6

• Asset : Customer Relationship

Patron Fonctionnel – Voir Diagramme 7

• Function : Management

Chiffrier Excel SD & SO – Voir Diagramme 8

• Control : CustomerRelationshipManagement

• Service operations : 7 service operations
  • configureCustomerRelationshipManagement ;
  • recordCustomerRelationshipManagement ;
  • requestCustomerRelationshipManagement ;
  • terminateCustomerRelationshipManagement ;
  • notifyCustomerRelationshipManagement ;
  • activateCustomerRelationshipManagement ;
  • retrieveCustomerRelationshipManagement.

Diagramme 5 : BIAN Service Landscape v4.0

Diagramme 6: Décomposition des types d’actifs

Diagramme 7: Patron fonctionnel (Functional Pattern)

Diagramme 8 : Chiffrier Excel Service Domains & Service Operations

L’application d’un patron fonctionnel sur un type d’actif permet de définir une capacité d’entreprise unique qui est supporté par les « Service Domains ». Un type d’actif peut être sollicité par de nombreux patrons fonctionnels avec différents « Service Domains ». Les « Services Domains » de BIAN ont les caractéristiques suivantes:

• objectif d’affaire unique – le « Service Domain » représente une activitée bancaire unique ;
  
• élémentaire – Ces fonctions unique ne chevauche pas un rôle, un objectif d’affaire. Il peut y avoir un traitement interne complexe afin de remplir ce rôle élémentaire, mais dans une perspective de concept d’entreprise, ils remplissent une fonction unique ;
• Collectivement complet – l’ensemble des « Service Domains » couvre toutes les activités effectuées dans le secteur bancaire. N’importe qu’elle activitée peut être modélisée à l’aide de l’interaction entre deux ou plusieurs « Service Domains » ;
• L’enregistrement de contrôle – définit le rôle de l’activité d’affaire ou le but du « Service Domain ».

Découpage des capacités d’entreprise
L’approche de BIAN est basée sur le découpage de l’ensemble des activités bancaire en une collection de capacités commerciales distinctes appelé « Service Domains ». La collection « Service Domains » est destiné à être exhaustive afin que tout les activités de l’entreprise puissent être prise en charge par un choix approprié des « Service Domains » interagissant à l’aide des « Service Operations » associés.

Comparer une vue de capacité BIAN’s d’une représentation des processus

Les modèles d’affaires conventionnels décrivent une activité d’affaires par une série d’étapes liées ou de tâches prédéfinis qui sont agencés afin d’arriver à un objectif spécifique. Lorsque l’on modélise la même activité d’affaire avec l’aide de BIAN on procède en identifiant chacune des capacités d’affaires distinctes qui doivent être impliqués afin d’atteindre l’objectif, sans prescrire une séquence spécifique d’interaction. Une analogie peut être faite entre la route et l’urbanisme d’une ville – la description d’un processus d’affaire est analogue à tracer un itinéraire à travers la ville. Alors que les capacités d’affaires de BIAN équivaut à un plan de la ville montrant les différents types de bâtiments et d’infrastructures qui pourraient être «visités» ou «impliqués» lors du voyage.

Le domaine de service BIAN combine un actif et une utilisation

BIAN a définit les capacité d’affaire comme étant la combinaison d’un type d’action ou d’utilisation appliquée à un type d’actif ou d’entité. Pour ce faire BIAN a identifié une liste standard des usages (appelé des schémas fonctionnels) et a développé une décomposition hiérarchique des actifs ou des entités (corporels et incorporels) qui permettent de définir une banque. Chaque domaine de service combine ainsi un schéma primaire unique et fonctionnel (par exemple «maintenir le détails des références», «définir et exécuter un plan») avec un actif ou un type d’entité (par exemple,« une pièce d’équipement »,« une relation client»).

Les domaines de service BIAN sont élémentaire en porté

Afin de définir les capacités canonique chaque domaine de service doit remplir un seul rôle d’affaires élémentaire. Si un domaine de service couvrirait de multiples fonctions alors différentes combinaisons pourraient s’appliquer dans différentes situations de déploiement et les comportements cesserait d’être canonique/standard. Les schémas fonctionnels et la décomposition des actifs mentionné dans la section précédente aide à identifier les rôles d’entreprise «élémentaires», mais certaines considérations supplémentaires sont nécessaires pour s’assurer que les modèles sont canonique pour toute les activités bancaires.

Modélisation du comportement du monde réel

La spécification « BIAN Service Domains » est testé et affiné par la modélisation des comportements d’affaires en utilisant les « BIAN Business Scenarios ». Cette façon de faire permet de vérifier que la fonction d’affaire réalisé par chacun des « Service Domain » est unique et bien définis et permet de révéler les interactions entre les « Service Operations » qui permettent de définir les échanges.

Les « Services de domaines BIAN » partagent une structure commune – Chaque service correspond à un besoin d’affaire unique qui peut-être représenté comme étant un «centre de service» qui offre ses capacité d’affaires par le biais de ses services opérationnel tout en tirant partie des autre services dont il aurait besoin. Chaque domaine de service offre un « patron » de fonctionnement caractérisé par la manipulation de son «enregistrement de contrôle».

Tous les domaines de service s’alignent sur les deux aspects de la définition suivante

• Entité – C’est l’objet sollicité par le domaine de service. Il peut être un actif tangible comme une pièce d’équipement ou une immobilisation incorporelle comme la relation client. Le domaine de service gère toutes les activités de l’actif tout au long de son cycle de vie.
• Patron fonctionnel – Permet de définir le type d’action qui peut être effectuée sur l’actif. Le framework BIAN fournit une liste standard des modèles qui représentent ces actions primaires ou ces modèles fonctionnels.

Un enregistrement de contrôle reflète la combinaison entre l’entité et le patron fonctionnel. Une instance d’enregistrement de contrôle est créé chaque fois qu’un Domaine de Service remplit son rôle et ce du début à la fin. Ainsi par exemple le domaine de service représenté par le patron fonctionnel « maintenir les détails de référence» pour l’actif/type d’entité « Customer Relationship » permet de maintenir une instance d’enregistrement du contrôle détaillant les informations de référence pour chaque client aussi longtemps qu’ils sont actif à la banque.