urbanisation-si

urbanisation-si

Le diagramme de communication des applications de la phase C Architecture des Systèmes d'Information de TOGAF - étape 25 du tutoriel

Le diagramme de communication des applications a pour objet de montrer la relation entre les entités de données, les services métier et les composants applicatifs.

Le diagramme est réalisé par les architectes applicatifs avec comme référents les architectes applicatifs et les architectes techniques et à destination des analystes métier et des architectes techniques.

 

diagramme-de-communication-des-applications-phase-c-architecture-des-systemes-d-information-togaf-1.PNG

 

Pour plus de précisions sur les éléments de modélisation avec UML de la phase C Architecture des Systèmes d'Information de TOGAF, voir l’article :

 

 

Le but de ce modèle est de détailler le site « TripReservationSite » à la fois stéréotypé composant d’application d’interaction et composant d’application de processus.

 

Le composant cœur de métier de ce site est « ReserveTrip » stéréotypé lui aussi à la fois comme composant d’application d’interaction et composant d’application de processus.

Ces doubles stéréotypes UML permettent au modèle de rester à forte granularité, il sera détaillé par d’autres modèles explicitant par exemple les types d’information échangés, les services, les opérations, les entrées/sorties et les exceptions comme le traitement des erreurs.

 

« TripReservationSite » utilise, via des connecteurs reliés à des ports, directement les données métier des composants d’application d’entité : « Client », « Trip » et indirectement « Order » par l’intermédiaire de « ReserveTrip ».  

 

Notez sur les bords des composants « TripReservationSite » et « ReserveTrip » les ports fléchés orientés vers l’extérieur indiquant qu’une interface est requise et sur les bords des composants « Client », « Trip » et « Order » les ports fléchés orientés vers l’intérieur indiquant que le composant fourni (implémente) l’interface.

 

« Trip » accède au référentiel « PortfolioRepository » qui est un composant d’application de base de données. Un lien de type « flow » (flux d’information) relie l’application « TripPortfolioManager-V2 » au référentiel « PortfolioRepository ».

 

Le composant d’application de processus « Invoicing » est lié par un flux d’information à l’application « AccountingERP » qui est un ERP (Enterprise Resource Planning come SAP ou JD Edwards)) gérant la comptabilité.

 

Le concept de composant applicatif est constitué de services d’informations qui ne sont que la réalisation de services métier et permettent l’échange de messages.

 

S’il existe un projet de migration vers un changement d’ERP, l’établissement d’un référentiel centralisé ou le développement spécifique de certains composants, cette cartographie pourra y contribuer en précisant l’existant.

 

A noter le composant fédération de système « Partners » modélisant l’ensembles des systèmes des partenaires à l’entreprise et le composant utilitaire « CreditCard » fourni par la banque.

 

Conclusion

Le diagramme montre comment les entités logiques doivent être physiquement réalisées par les composants de l'application.

Cela permet d'effectuer un dimensionnement efficace de l’architecture informatique à affiner.

 

En outre, en attribuant une valeur métier aux données, il est possible d'obtenir une indication de la criticité métier des composants de l'application.

En outre, le diagramme peut afficher la réplication des données et la référence principale pour les données.

Dans ce cas, il peut afficher deux copies et la relation maître-copie entre elles.

 

Le diagramme de communication des applications est une sorte de diagramme d’architecture avec les couches interaction, processus et entité et dans lequel les entités de données sont connectées aux composants de l’application.

Les composants de services sont reliés par des connecteurs faisant correspondre les traitements (interface) requis et les traitements fournis (implémentés).

 

Il peut servir à l’établissement de la cartographie de l’existant à transformer, de l’architecture à une étape de la trajectoire pour atteindre la cible et de l’architecture cible correspondant à la stratégie de transformation numérique.

 

Rhona Maxwel

@rhona_helena

 

"Hâte-toi de bien vivre et songe que chaque jour est à lui seul une vie."

Sénèque

 

 

Annexe 1 : les précédentes étapes de notre étude de cas TOGAF

 


17/08/2018
0 Poster un commentaire

Les éléments de modélisation avec UML de la phase C Architecture des Systèmes d'Information de TOGAF - étape 24 du tutoriel

La phase C doit mettre en place l’implémentation et l’exécution des constituants métier indépendamment de la phase D technique qui doit établir la correspondance physique et technologique avec les composants des phases précédentes.

 

togaf-elements-modelisation-uml-phase-c-architecture-des-systemes-d-information.png

 

Un synoptique a été abordé dans l’article :

 

 

La phase C est divisée en 2 : l’architecture des données et l’architecture applicative.

On retrouve les mêmes principes des autres méthodes d’architecture d’entreprise comme l’urbanisation du Système d’Information ou Praxeme qui sont :

  • d’avoir une interface entre la couche métier et la couche technique, indépendante de celle ci, ce rôle est joué par la phase C.
  • de faire correspondre à chaque bloc de données un bloc applicatif qui en est l’unique propriétaire et qui est le seul à pouvoir les modifier.

 

L’objectif de la phase D est d’avoir une infrastructure et des composants logiciels cohérents qu’ils proviennent de progiciels du commerce, d’ERP ou bien de développement maison.

 

TOGAF ne préconise aucune architecture, mais ses concepts intrinsèques sont ceux de l’architecture SOA (Service Oriented Architecture).

 

La phase C est comparable à l’interface logique de service qui est la structure fondamentale du composant et qui reste inchangée quel que soit son implémentation en C, Java, SOAP, REST, … qui relève bien de la phase D.

 

L’important est de pouvoir identifier le rôle de chaque composant indépendamment des technologies employées pour leur exécution.

 

Encore une fois comme dans l’urbanisation du SI, il n’y a pas d’ordre préconisé, on peut appliquer une méthode top down c’est-à-dire commencer par spécifier l’architecture applicative puis technique ou faire l’inverse avec la méthode bottom-up.

 

Ce dilemme cornélien se solde par un mixte des 2 méthodes.

 

Voir tous nos articles consacrés à SOA à l’annexe 2 (à la fin de ce billet) : l’architecture SOA (Service Oriented Architecture)

 

Conclusion

L'EA est comme l'urbanisation du SI une méthode à la fois top-down et bottom-up avec comme objectif la modélisation globale de l'ensemble des ressources de l'entreprise (stratégie, processus métier, briques fonctionnelles et applicatives, infrastructures techniques, ...), donc la volonté de définir un référentiel d'entreprise.

Le but est d'avoir la description généralisée du fonctionnement de l'entreprise, de sa stratégie, de ses procesus métiers, ..., de l'architecture du Système Informatique, les applications, les SGBD, les machines, réseaux, ..., des relations entre les niveaux.

Les prises de décision sont ainsi facilitées en montrant les impacts potentiels sur l'organisation, les processus, le SI, ...

Toutes les parties prenantes de l'entreprise ont une vision globale, organisée des ressources de l'entreprise grace au référentiel d'entreprise.

SOA (Service Oriented Architecture) est plus une méthode de gouvernance de SI qu'une technique d'architecture, c'est ce qui explique la diminution des coûts et l'augmentation des performances.

Comme tout projet, l'architecture d'entreprise est l'affaire de tous, la DSI et les directions métiers qui ne  doivent pas considérer que ça regarde uniquement les techniciens.  

L'alignement stratégique implique forcément une collaboration entre la DSI et les directions métiers.

L'architecture est la route qui conduit à la mutualisation et à la réutilisation.

Ces concepts n'apparaissent pas spontanément, il faut utiliser des patterns et des bonnes pratiques de conception qui coûtent plus cher au début mais qui seront rentabilisés lors des évolutions futures.  

La stratégie des directions métiers doit être partagée avec la DSI pour que ces méthodes soit en adéquation avec les buts poursuivis par l'organisation.  

 

Rhona Maxwel

@rhona_helena

 

"Les femmes vont plus loin en amour que la plupart des hommes ; mais les hommes l’emportent sur elles en amitié."

La Bruyère

 

 

Annexe 1 : les précédentes étapes de notre étude de cas TOGAF

 

 

 

Annexe 2 : l’architecture SOA (Service Oriented Architecture)

 


13/08/2018
0 Poster un commentaire

Diagramme de cycle de vie des entités métier en phase B architecture métier de TOGAF - étape 23 de l'étude de cas

Le diagramme de cycle de vie des entités métier a pour objectif de modéliser tous les états et leurs transitions c'est à dire les événements et les règles métier provoquant les changements d'état.

Le diagramme est réalisé par les analystes métier avec comme référents les experts métier et à destination des responsables de domaines métier et processus métier.

 

diagramme-de-cycle-de-vie-des-entites-metier-togaf-etude-de-cas.PNG
 
Ce modèle est un diagramme d'état UML ou automate à états finis
Pour chaque entité métier, l’expert métier specifie quels sont les états stables et quelles actions ou quels événements vont provoquer les transitions d'état. Ces règles font partie du référentiel des règles métier.
 
La bonne pratique est pour une entité métier, de réaliser un diagramme d'état UML seulement à partir de 3 ou 4 états avec des combinaisons complexes comme des annulations ou des abandons d'actions nécessitant par exemple des états composites permettant de factoriser une action (par exemple annuler) sur un ensemble d'états. 
 
S’il existe un tel automate pour une entité métier, alors tous processus métier où traitements intervenant sur cette entité doivent respecter son fonctionnement.
 
Voir à la fin de cet article l'annexe 2 concernant les articles sur le diagramme de classe, d’état et de package UML et sur la dérivation de modèles.
 

Pour plus de précisions sur les éléments de modélisation de la phase B architecture métier de TOGAF, voir l’article :

 

 

Conclusion

Le diagramme de cycle de vie des entités métier constitue l’ensemble des règles pour les changements d’etat indépendamment de tous processus métier qui devront impérativement les respecter.
 
Rhona Maxwel
@rhona_helena
 
"La vie ce n'est pas d'attendre que les orages passent, c'est d'apprendre comment danser sous la pluie."
Sénèque
 
 
Annexe 1 : les précédentes étapes de notre étude de cas TOGAF
 
 
  
Annexe 2 : articles sur le diagramme de classe, d’état et de package UML et sur la dérivation de modèles
 

29/07/2018
0 Poster un commentaire

Diagramme des entités métier en phase B architecture métier de TOGAF - étape 22 du didacticiel

Le diagramme des entités métier a pour objectif de modéliser les entités cœur de métier en faisant attention à rester au niveau macroscopique. Cela signifie de ne s'intéresser qu'aux concepts primaires en faisant abstraction de toutes considérations techniques. Plusieurs niveaux d’échelle pourront être réalisés : 1 - uniquement les entités/relations, 2 - ajout des propriétés et 3 - regroupement en domaines.

Le diagramme est réalisé par les analystes métier avec comme référents les experts métier et à destination des administrateurs données et des architectes applicatifs.

1 - uniquement les entités/relations

diagramme-entites-metier-togaf-principales-associations-du-domaine-didacticiel-0.PNG

 

Ce modèle à « grosses mailles » utilise :

  • le stéréotype normalisé « entity », appliqué à l’artefact « classe » d’UML et signifiant un concept métier,
  • les associations et les compositions UML en précisant les cardinalités et le nom du rôle joué par l’entité dans l’association.

La mise au point de ce modèle est itérative, il doit être documenté de manière textuelle et pédagogique, expliqué aux parties prenantes et validé.

A ce stade, ce modèle ne doit comporter aucun aspect applicatif voir technique comme par exemple la persistance, l’historique, …

 

Le piège est d'être trop technique d’un point de vue modélisation.

Comme les utilisateurs ont souvent des préjugés erronés dans certains domaines, la clé de la réussite passera par l'omission des termes à connotation technique (UML, classe, objet, attribut, ...) et par leurs remplacements par des termes plus neutres et proches du jargon métier (cadre, entité, valeur, donnée, ...).

 

2 - ajout des propriétés

diagramme-entites-metier-togaf-vue-detaillee-avec-attributs-tutorial-1.PNG

 

De manière similaire à un cartographe qui augment l’échelle pour avoir une nouvelle carte avec plus de détails (mais avec moins de couverture), on reprend le modèle précédent en précisant les propriétés (attributs UML) significatives pour le métier.

 

C’est dans la phase suivante « phase C : Architecture des systèmes d’information », dans la modélisation de l’architecture des données que seront réalisés les diagrammes logiques de données concernant les données persistantes et ajoutant bon nombre de précisions sur les entités secondaires et autres raffinements UML.

Avec des outils MDA (Model Driven Architecture), ces modèles logiques et physiques pourront être obtenus automatiquement en dérivant les modèles conceptuels.

 

Voir à la fin de cet article l'annexe 2 concernant les articles sur le diagramme de classe, d’état et de package UML et sur la dérivation de modèles

 

Si vous appartenez à cette première génération d’informaticiens, vous connaissez surement cette méthode française désuète qu’était « Merise » avec son MCD (Modèle Conceptuel de Données), MLD (Modèle Logique de Données) et MPD (Modèle Physique de Données).

 

3 - regroupement en domaines

diagramme-domaines-d-information-metier-togaf-etude-de-cas-complete-2.PNG

 

Après avoir réalisé le modèle macroscopique entités/relations, on regroupe les entités par affinités fonctionnelles en domaines (package UML).

Ceci permet d’avoir une vue globale et synthétique des familles d’entités.

En « zoomant » sur un domaine on obtient le diagramme entités/relations correspondant.

On voit qu’un outil de modélisation est indispensable pour réaliser cette traçabilité et assurer la fonction de référentiel des données métier.

 

Pour plus de précisions sur les éléments de modélisation de la phase B architecture métier de TOGAF, voir l’article :

 

 

Conclusion

Le diagramme des entités métier permet d’être dérivé afin d’obtenir le modèle logique de données et les composants applicatifs « entité ».

Le modèle des processus métier et des services l’utilise pour représenter les données en entrée/sortie des activités.

L’outil de modélisation doit intégrer entre autres la gestion du référentiel, la traçabilité et la dérivation des modèles.

 

Rhona Maxwel

@rhona_helena

 

"Le progrès n’est que l’accomplissement des utopies."

Oscar Wilde

 

 

Annexe 1 : les précédentes étapes de notre étude de cas TOGAF

 

 

  

Annexe 2 : articles sur le diagramme de classe, d’état et de package UML et sur la dérivation de modèles

 


27/07/2018
0 Poster un commentaire

Diagramme supervision métier en phase B architecture métier de TOGAF – étape 21 de l’exemple complet emprunté à Modelio

Le diagramme supervision métier a pour objectif de montrer à la direction générale la chaîne des constituants de l’architecture d’entreprise, en prenant comme point de départ les objectifs métier en passant par les fonctions métier, unités organisationnelles, processus métier, services métier pour finir aux composants techniques.

Le diagramme est réalisé par les analystes métier avec comme référents les experts métier et les architectes applicatifs et à destination de la direction générale.

 

diagramme-supervision-metier-togaf-phase-b-architecture-metier-exemple-complet.PNG

 

Ce modèle assure la traçabilité des composants techniques jusqu’aux objectifs métier et identifie les responsables et propriétaires des services métier.

La bonne pratique est de représenter uniquement les artefacts primordiaux liés aux besoins usuels métier.

Cette cartographie globale sera détaillée par une analyse ultérieure explicitant chaque domaine.

 

Pour plus de précisions sur les éléments de modélisation de la phase B architecture métier de TOGAF, voir l’article :

 

 

Conclusion

Le diagramme de supervision métier représente les différents types de dépendances (<<Trace>>, <<participates in>>, <<supports>> et <<realizes>>) intervenant entre les objectifs métier, les fonctions métier, les unités organisationnelles, les processus métier, les services métier et les composants techniques.

La direction générale peut alors voir les composants applicatifs qu’il est nécessaire de réaliser ou de modifier et vérifier à quels objectifs métier ils sont liés en remontant la chaîne de traçabilité.

 

Rhona Maxwel

@rhona_helena

 

"Il n’y a qu’une route vers le bonheur, c’est de renoncer aux choses qui ne dépendent pas de notre volonté."

Épictète (50-125)

 

 

Annexe 1 : les précédentes étapes de notre étude de cas TOGAF

 


24/07/2018
0 Poster un commentaire

Diagramme information - service métier en phase B architecture métier de TOGAF - étape 20 de l’étude de cas Modelio

Le diagramme information - service métier a pour objectif de modéliser les entités métier utilisées en entrée et produites en sortie par les services métier. Ces modèles constitueront une aide précieuse pour représenter l’architecture des données en phase C architecture des systèmes d’information.

Le diagramme est réalisé par les analystes métier avec comme référents les experts métier et à destination des analystes métier et architectes applicatifs.

 

diagramme-information-service-metier-togaf-phase-b-architecture-metier.PNG

 

Ce modèle représente les flux de données entre les composants dynamiques comme les services métier ou processus métier et les constituants statiques, structurels comme les entités métier.

 

Pour plus de précisions sur les éléments de modélisation de la phase B architecture métier de TOGAF, voir l’article :

 

 

Conclusion

Pour préparer l’architecture des données et l’architecture applicative de la phase C architecture des systèmes d’information, il est nécessaire d’analyser les flux de données en entrée/sortie des services et processus métier.

Le diagramme information - service métier représente ces flux et servira d’ébauche de réflexion pour les modèles suivants.

 

Rhona Maxwel

@rhona_helena

 

"La seule façon de comprendre une nouvelle culture et de nouveaux comportements est de devenir natif. Devenir natif est un processus d’observation, d’apprentissage et d’approfondissement, pratiqué tel un anthropologiste, impliqué directement sur le terrain et en participant étroitement avec ses hôtes à leurs cultures."

Brian Solis

 

 

Annexe 1 : les précédentes étapes de notre étude de cas TOGAF

 

 

 

Annexe 2 : les articles relatifs à l'architecture orientée services SOA (Services Oriented Architecture)

 


01/07/2018
0 Poster un commentaire

Diagramme de cas d’utilisation métier en phase B architecture métier de TOGAF – étape 19 de l’étude de cas Modelio

Le diagramme de cas d’utilisation métier a pour objectif de modéliser les communications entre les acteurs (consommateurs) externes ou internes et les services métier.

Le diagramme est réalisé par les analystes métier avec comme référents les experts métier et à destination des analystes métier, responsables métier et architectes applicatifs.

 

diagramme-de-cas-d-utilisation-metier-togaf-etude-de-cas-architecture-d-entreprise.PNG

 

TOGAF distingue les cas d’utilisation métier et les cas d’utilisation système.
Les premiers détaillent les tâches métier/services métier réalisées/consommés par un acteur externe (pool BPMN) ou interne (lane BPMN) des processus métier.
Les deuxièmes sont situés au niveau applicatif et permettent de décrire les interactions entre consommateurs et producteurs de services applicatifs.

 

Si vous n’êtes pas familier avec le concept de cas d’utilisation, vous pouvez vous référer aux articles déjà publiés dans ce blog.

Voir à la fin de cet article, l’annexe 2 sur les articles relatifs aux cas d’utilisation.

 

L’acteur interne "Account manager" déclenche dans un but métier précis les cas d’utilisation "Initiate file", "Check availabiliti" et "Reserve Trip". Son intention est de pouvoir créer un dossier, vérifier les disponibilités et de réserver un voyage.

L’acteur externe "Client" déclenche le cas d’utilisation "Reserve Trip" pour réserver son voyage.

L’acteur interne "Invoicing officer" déclenche les cas d’utilisation "Check solvency" et "Invoice" avec comme objectif métier de contrôler la solvabilité d'un client avant de donner son accord pour la validation définitive du séjour et créer la facture.

 

Pour plus de précisions sur les éléments de modélisation de la phase B architecture métier de TOGAF, voir l’article :

 

 

Conclusion

Le diagramme de cas d'utilisation (use case)  métier TOGAF décrit les communications entre les acteurs et les services métier qu'ils consomment pour atteindre leur but métier grâce aux résultats produits par ces services.

Investir sur la méthode et la modélisation des Use Case permet d'avoir de solides fondations pour les phases à venir.

Le concept de Use Case a été créé pour renforcer la communication entre MOA et MOE.

Son objectif est de formaliser des besoins métier en actions exécutées par les acteurs.

La modélisation des processus métier (BPMN Business Process Modeling Notation) facilite grandement l'identification des Use Case, si on est descendu à une granularité assez fine.

 

Rhona Maxwel

@rhona_helena

 

"La plus grande difficulté de la transformation numérique, c’est de changer la roue de la voiture sans l’arrêter."

Éric Blot

 

 

Annexe 1 : les précédentes étapes de notre étude de cas TOGAF

 

 

 

Annexe 2 : les articles relatifs aux cas d’utilisation

 


30/06/2018
0 Poster un commentaire

Les règles métier en phase B architecture métier de TOGAF – étape 18 avec l’outil Enterprise Architect de Sparx Systems

Le diagramme de règles métier a pour objectif de modéliser les exigences de prise de décisions (par ex. les tables et arbres de décisions) et leurs logiques (par ex. formules de calculs) qui constituent le cœur de métier d’une entreprise et qui doivent obligatoirement être modélisées avec la norme OMG (Object Management Group), DMN (Decision Model and Notation). Cette norme a été conçue pour être utilisable avec la norme de modélisation des processus métiers BPMN ( Business Process Model and Notation ).

Le diagramme est réalisé par les analystes métier avec comme référents les experts métier et à destination des analystes métier, responsables métier et architectes applicatifs.

 

diagramme-regles-metier-togaf-DMN-etude-de-cas.PNG

 

Le but principal de DMN est de fournir une notation commune qui est aisément compréhensible par la maîtrise d'ouvrage, les experts métiers devant créer des règles métiers ainsi que des tables de décision, puis affiner ces règles pour les livrer aux développeurs responsables d'automatiser ces règles métiers dans des processus métiers et finalement, aux utilisateurs qui géreront et contrôleront ces règles.

 

DMN est une norme de l'OMG (Object Management Group, l'organisation qui a créé les normes UML, SysML, BPMN, MDA, MOF, ...) représentant une passerelle entre la conception des règles métiers et la mise en œuvre de ces règles.

 

Le diagramme ci-dessus a été réalisé avec l’outil Enterprise Architect version 14 de Sparx Systems :

 

 

En effet l’outil Modelio n’intègre pas la norme DMN.

 

Voir nos articles sur les meilleurs outils de modélisation, avec les prix « Modsars » de « urbanisation-si.com » récompensant les plus innovants, décernés en 2016 et 2017 :

 

  

Dans ce blog, nous avons beaucoup écrit sur la définition et la méthodologie de conception des règles métier, sur les moteurs de règles métier ainsi que sur la norme DMN de modélisation des règles et ce de manière pédagogique avec de nombreux exemples.
 

Voir à la fin de cet article, l’annexe 2 sur les articles relatifs aux règles métier et à DMN.

 

En annexe 3, vous trouverez la liste des règles métier de l’étude de cas Modelio avec leur description et en annexe 1 toutes les étapes précédentes de l'étude de cas.

 

Dans le diagramme réalisé, la règle (Decision) "Maximum discount" prend comme donnée en entrée (Input Date) "Trip" et s’appuie sur la connaissance métier (Business Knowledge Model) "Application discount score model".

 

Pour une bonne gouvernance des règles métiers, dans le référentiel de règles, on doit avoir pour chacune d’elle, les propriétés suivantes :

  • Identifiant unique
  • Nom
  • Description sous forme de conditions et d’actions (when … then …)
  • Priorité
  • Cycle de vie et états de la règle (en cours de conception, proposée, validée, implémentée, retirée, archivée)
  • Propriétaire de la règle
  • Traçabilité avec les processus métier et les cas d’utilisation métier

 

Conclusion

Même la méthode française concurrentes de TOGAF, l’urbanisation des SI avec le Plan d'Occupation des Sols (POS), considère les règles métier comme un quartier à part entière dans la zone des référentiels de la cartographie fonctionnelle.

 

En effet, la formalisation sous forme de règles permet de capitaliser le savoir-faire des experts.

 

Elle apporte aussi une standardisation et une auditabilité de ces règles « métier », facilitant leur consultation et leur maintenance par le plus grand nombre.

 

De plus si vous décidez dans l'architecture technique d'intégrer un BRMS (Business Rule Management System intégrant un moteur de règles) permettant d'automatiser l'exécution et l'enchaînement des règles, l'étape de "phase de conception / paramétrage du BRMS" est déjà réalisée.

 

Rhona Maxwel

@rhona_helena

 

"De nouveaux développements de systèmes intelligents nous rendrons tous beaucoup, beaucoup plus intelligent. Et cela est rendu possible grâce aux téléphones intelligents qui sont de vrais ordinateurs. […] Chacun de nous peut devenir plus intelligent avec cette technologie … et l’augmentation des capacités des personnes est le secret de ce progrès technologique."

Eric Schmidt

 

 

Annexe 1 : les précédentes étapes de notre étude de cas TOGAF

 

 

 

Annexe 2 : les articles relatifs aux règles métier et à DMN

Si vous n’êtes pas familier avec DMN (Decision Model and Notation) :

 

 

Pour tout comprendre, voici un exemple complet montrant un processus métier modélisé avec BPMN et incluant des règles métiers modélisées avec DMN. Cet exemple va des modèles jusqu’à leur exécution :

 

  1. Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : le processus métier BPMN
     
  2. Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : La vue des exigences des décisions
     
  3. Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : Le niveau logique de décision
     
  4. Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : Exemple d'exécution du modèle de décisions
     
  5. DMN ( Decision Model Notation ) : Ne serait-ce pas un langage de plus, une contrainte de plus imposée à la MOA par la MOE ?
     

Pour aller plus loin avec DMN, un tutorial complet sur comment concevoir un outil de modélisation DMN :

  1. DMN ( Decision Model and Notation ) : comment concevoir son propre outil de modélisation DMN ? [1/4]
     
  2. Le métamodèle Eclipse Ecore DMN ( Decision Model and Notation ) : comment concevoir son propre outil de modélisation DMN ? [2/4]
     
  3. Tutorial Obeo Designer Community : comment concevoir son propre outil de modélisation DMN ? [3/4]
     
  4. Améliorations et notions avancées Eclipse Sirius, suite et fin de notre saga : comment concevoir son propre outil de modélisation DMN ? [4/4]

 

Les moteurs de règles métier BRMS :

 

  

Annexe 3 : la liste des règles métier de l’étude de cas Modelio avec leur description.

  

liste-regles-metier-togaf-DMN-etude-de-cas-modelio.PNG

  

 edition-regles-metier-togaf-DMN-etude-de-cas-modelio.PNG

  

Maximum discount

The discount accorded can go up to 50% of the public price normally used by travel agents.

 

Trip localization

The trip always takes place within a single country.

 

Service uniqueness

There exists only one accommodation service for the entire trip.

 

Hotel/holiday link

Where the trip includes a "hotel" service, the trip can concern several hotels, with each notel being occupied during one (or several) periods of the trip.

 

Hotel identification

Each hotel is identified by a sequential  number within a country.

 

Car service

Where the trip includes a "car" service, this only concerns one vehicle category and one car rental company only has been retained for the trip.

 

Trip availability

A travel agency is obliged to inform DISCOUNT TRAVEL when there are no places left for a given trip. A trip is then considered to be full. The same is true when the departure date has passed. A trip can therefore have two statuses: available trip or closed trip.

 

Client payment

When a client reserves a trip, his/her bank card number is required, and a file number is attributed. The file is considered to be pending until the solvency of the bank account has been verified. If the account is not solvent, the reservation request is abandonned and the file deleted.

 

Trip reservation in agencies

DISCOUNT TRAVEL then consults the agency concerned by the trip ordered. If the number of available places is sufficient, DISCOUNT TRAVEL reserves the places requested by its client and debits his/her bank account by the amount indicated. If the number of remaining places is insufficient, the order placed is purely and simply cancelled, and the client informed of this cancellation.

 

Client information

The client is of course kept informed of the acceptance or refusal of his/her order.

 

Confirmed order

All orders placed by a client are considered to be firm and definitive.

 

Identitification Accompagnant

Each participant, client or accompanying person is identified by a sequential number.

 

Reduced prices for children

Children under twelve benefit from a reduced price, corresponding to 60% of the price of the trip.

 

Client solvency

When a client places an order, his/her bank card number and bank account solvency are checked. If the result is negative, the order is purely and simply refused. Otherwise, DISCOUNT TRAVEL contacts the agency who proposed the trip to check that the number of available places is sufficient to satisfy the order.

 

Order processing

As soon as the agency has given its response, DISCOUNT TRAVEL processes the order. If the number of places is sufficient, the order is accepted and the client bank account debited by the amount indicated. If the number of places available is insufficient, the order is cancelled. Furthermore, if the agency indicates that there are no places left for the trip, the corresponding offer is withdrawn.

 

Cancellation management

An accepted order can be cancelled by the client. In this case, DISCOUNT TRAVEL informs the travel agency of this cancellation and pays a fixed amount of compensation. The client file is then closed. If the client had opted for cancellation insurance, he/she is refunded the entire cost of the trip.

 

File closure

Finally, when an accepted order has not been cancelled by the client before the departure of the trip, DISCOUNT TRAVEL closes the corresponding file and pays the agreed price to the travel agency (this is, of course, less than the price paid by the client).


29/06/2018
0 Poster un commentaire

Diagramme de processus métier en phase B architecture métier de TOGAF – étape 17 de l’étude de cas

Le diagramme de processus métier a pour objectif de modéliser la séquence ou un flux d'activités qu’une organisation opère dans le but de l'accomplissement d’un travail.

La norme OMG (Object Management Group) de modélisation des processus métier est BPMN (Business Process Model and Notation) qui est unanimement reconnue sur le marché, je vous recommande vivement de l'utiliser.

Le diagramme est réalisé par les analystes métier avec comme référents les experts métier et à destination des analystes métier, responsables métier et architectes applicatifs.

 

diagramme-de-processus-metier-BPMN-TOGAF.PNG
 

 

Dans ce blog, nous avons détaillé de manière pédagogique avec de nombreux exemples la totalité de la norme BPMN, ainsi que les méthodes d’identification des processus métier.

Voir à la fin de cet article, l’annexe 2 sur les articles relatifs aux processus métier et à BPMN.

 

Les 2 départements "Sales department" et "Administration department" sont représentés par 2 lanes.

  1. Le processus démarre avec l’événement arrivée du message "Trip request".
  2. S’enchaîne l’activité "Initiate file" produisant en sortie l'entité "Order" qui est initialisée.
  3. 2 activités "Check" vont s’exécuter en parallèle (gateway).
  4. Une fois ces 2 activités terminées, la séquence continue avec l’activité "Reserve trip" avec "Order" qui est finalisée et complète.
  5. Le processus se termine avec l’activité "Invoice".

Ce modèle est à grosse maille, comme dans toute cartographie, on pourrait affiner l’échelle et détailler le diagramme.

Mais attention à ne pas tomber dans le piège classique de la modélisation consistant à vouloir trop détailler ce qui risque de rendre le modèle illisible et donc inutilisable, trop d’informations tue l’information.

 

Pour plus de précisions sur les éléments de modélisation de la phase B architecture métier de TOGAF, voir l’article :

 

  

Conclusion

Ne subissez plus les changements extérieurs, mais soyez en mesure de les accueillir à tout instant !

Les plus performants d’entre nous sont conscients du fait qu'avantage concurrentiel et service de premier ordre ne résultent pas de ce qu’on fait, mais de la manière de le faire.

Et que les positions de force peuvent s’inverser rapidement du fait de l’évolution constante des environnements financier, réglementaire et métier.

Modéliser les processus métier permet de :

  • les documenter,
  • alimenter le référentiel de processus,
  • les optimiser,
  • faciliter les évolutions, les mesures d’impact en cas de changement,
  • faire des analyses de performances,
  • les automatiser,
  • faciliter leur gouvernance.

Le BPM (Business Process Management) permet une amélioration notable du retour sur investissement :

  • amélioration de la productivité,
  • amélioration de la qualité de service,
  • réduction des coûts d’exploitation,
  • réduction de la durée des cycles de traitement.

Les processus métier sont les rouages centraux de l’efficience de l’entreprise et donc la base de l’architecture d’entreprise.

 

Rhona Maxwel

@rhona_helena

 

"Il n'y a jamais eu une telle période de promesses et de menaces [...] Nous devons développer une lecture claire et globale quant à l'impact des technologies sur nos vies et comment elles reconditionnent noare environnement économique, social, culturel et humain."

Klaus Schwab

 

 

Annexe 1 : les précédentes étapes de notre étude de cas TOGAF

 

 

 

Annexe 2 : articles relatifs aux processus métier et à BPMN

 


27/06/2018
0 Poster un commentaire

Diagramme objectifs-services métier en phase B architecture métier de TOGAF – étape 16 de l’étude de cas

Le diagramme objectifs-services métier a pour objectif d’aider à la préparation aux indicateurs de performance des services métier en représentant les objectifs stratégiques ou opérationnels auxquels ils sont assignés.

Le diagramme est réalisé par les analystes métier avec comme référents les experts métier et à destination des analystes métier et architectes applicatifs.

 

diagramme-objectifs-services-metier-togaf-exemple-etude-de-cas.PNG

 

Les services métier sont assignés avec des dépendances UML <<Trace>> aux objectifs

Le service métier "Order management" contribue à la réalisation des objectifs "Reduce file processing times", "Reservation via the internet" et "Optimize client transformation rate".

 

Pour plus de précisions sur les éléments de modélisation de la phase B architecture métier de TOGAF, voir l’article :

 

  

Conclusion

Le diagramme objectifs-services métier en phase B architecture métier de TOGAF décrit les liens de traçabilité entre les services métiers et les objectifs stratégiques.

Ce diagramme permet :

  • d'établir la cartographie des services contribuant à l'atteinte des objectifs,
  • de mesurer les impacts en cas de changement d'un objectif
  • de servir de base aux indicateurs de performances

 

Rhona Maxwel

@rhona_helena

 

"Le client n’est pas la source de l’innovation."

Joseph Schumpeter

 

 

Annexe 1 : les précédentes étapes de notre étude de cas TOGAF

 

 

 

Annexe 2 : L’architecture orientée services SOA (Services Oriented Architecture)

 


26/06/2018
0 Poster un commentaire