urbanisation-si

urbanisation-si

Les règles de l'urbanisme du Système d'Information : encore une contrainte de technocrates ?

Quand les règles d'urbanisme ont été définies dans une démarche strictement top-down, il est à craindre des situations de blocage dans la mise en œuvre.

 

règles-d-urbanisme-du-système-d-information.PNG

 

Le besoin de disposer d'un ensemble de règles provient toujours de la nécessité d'introduire une cohérence dans la construction du SI :

  • pour définir un cadre normalisé de référence pour la gouvernance du Système d'Information.
  • pour homogénéiser, si nécessaires, les méthodes de développement, lorsqu'il y a plusieurs directions fonctionnelles.
  • dans le cadre de fusion de sociétés, pour définir les règles de construction des futurs systèmes communs.
  • pour pouvoir disposer d'un ensemble de règles standardisées.

 

C'est le besoin de cohérence et d'efficacité qui assurera lui-même le rôle moteur de l'urbanisation du SI.

Quand les règles d'urbanisme ont été définies dans une démarche strictement top-down, il est à craindre des situations de blocage dans la mise en œuvre.

L'adoption des règles est un mécanisme progressif et cumulatif.

 

Les principes sur lesquels sont fondés les règles d'urbanisme sont :

  • alignement sur les métiers
  • cohérence
  • modularité
  • subsidiarité
  • progressivité

 

La bonne pratique est que l'ordre de grandeur du nombre de règles soit de 30.

 

Les règles d'urbanisme vont formuler ce qui exigé et ce qui est interdit, mais trop de contraintes n'est jamais bon et il faudra laisser suffisamment de souplesse aux chefs de projet.

 

Rhona Maxwel

@rhona_helena

 

"Nul ne sait ce qu'il peut faire avant d'avoir essayé".

Publilius Syrus 

 

 

Articles conseillés :

 

Quel est le budget de l'urbanisation et urbanisme du Système d'Information ?

 

Sur quels critères doivent reposer les indicateurs d'urbanisation d'un système d'information ?

 

La méthode top-down dans l'urbanisme du Sytème d'Information

 

Dans le futur, il faudra réaliser la symbiose des méthodes et veiller à la cohérence des gouvernances SI et processus

 

Urbanisation du Système d'Information : créez l'évènement !


05/02/2017
0 Poster un commentaire

DMN ( Decision Model Notation ) : Ne serait-ce pas un langage de plus, une contrainte de plus imposée à la MOA par la MOE ?

La bonne pratique est de séparer les préoccupations et donc, en urbanisation du Système d'Information, les règles métiers doivent avoir leur langage de modélisation, c'est ce qu'a fait l'OMG ( Object Management Group ) avec DMN ( Decision Model Notation ), mais sera t'il utilisé par les experts métiers ou deviendra t'il une spécification "poussiéreuse" rangée dans les placards de l'OMG et oublié des utilisateurs ?

 

dmn-drools-table-de-decision-decision-model-notation-2.PNG

 

Ci-dessus une table de décision dans Excel, au format du moteur de règles métiers open source Drools, conforme aux spécifications de la norme DMN.

 

Après la série d’articles ( voir : 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 ) consacrés au langage de modélisations des règles métiers DMN , normalisé par l’OMG, il est légitime de se demander si c’est vraiment utilisé dans la « vraie vie » ?

 

Comme on le sait, un gouffre sépare maîtrise d'ouvrage et maîtrise d'œuvre.

Un des objectifs de l’urbanisation du Système d’Information, est justement d’estomper ce fossé.

L'urbanisme cible la réappropriation du SI par la maîtrise d'ouvrage.

Pour y arriver, une compétence plus grande en matière de SI leur est nécessaire.

Une meilleure communication maîtrise d'ouvrage - maîtrise d'œuvre pourra s'instaurer.

 

Dans le cadre de la refonte du SI d’un assureur, j’ai proposé l’intégration d’un moteur de règles ( voir nos articles dans la catégorie :  MOTEUR DE RÈGLES ). Mon équipe d’urbanistes à gérer les préoccupations techniques et métiers.

Au lancement du projet, pour moi le risque était avant tout technique à cause du contexte extrêmement contraignant et complexe.

Le domaine métier me paraissait plus maîtrisé. Les règles métiers étaient certes nombreuses, certaines très compliquées et mal formulées. Mais avec l’outil Enterprise Architect, en appliquant ses profils UML et sa méthode, j’étais plutôt confiante.

Les solutions de moteur de règles métier, proposaient tous des outils pour les experts métiers, comme la possibilité d'intégrer leur propre terminologie en concevant un DSL ( Domain Specific Language ), des assistants pour la conception et les tests des règles ainsi que des tables de décision de production avec Excel.

 

Et puis au fil du temps, après consultation des éditeurs et experts techniques en BRMS ( Business Rules Management System ) et BPM ( Business Process Managment ), les exigences techniques ont toutes été satisfaites, un « Proof Of Concept ( POC )» a été réalisé avec succès sur un vrai cas métier simplifié.

 

Restait à convaincre les experts métiers d’utiliser la méthode et les outils orientés utilisateur ( DSL Domain Specific Language = langage utilisant les concepts et la terminologie métier de l’assureur, fichiers Excel pour les tables de décision, tests utilisateur, …).

Et la patatras !

Malgré des présentations, puis des formations spécialement conçues pour eux avec un prototype qui s’exécutait et qui leur permettait de voir réellement les apports, d’une gestion des règles métiers bien à part, l’intégration dans un processus métier et l’automatisation dans un moteur de processus exécutables couplé à un moteur de règles métiers, les utilisateurs ont refusé d’avoir à faire l’effort d’intégrer cette nouvelle méthodes et ces nouveaux outils.

 

En ce qui concerne DMN, pour ne rien arranger, il existe très peu d’outils conviviaux destinés aux utilisateurs et aucun ne s'interface avec par exemple Drools.

 

L’outil Sirius ( l’open source Obeo Designer Community basé sur la plateforme standard Eclipse ) de la société Obeo, permet de créer son propre langage de modélisation et donc DMN. En plus, le métamodèle ( la grammaire du langage ) en UML ( Unified Modeling Language ) est bien spécifié par l’OMG et donc peut être injecté dans l’outil.

Cela sera peut-être possible dans certaines organisations comme dans le domaine de l'aéronautique par exemple, mais pour d’autres ( mutuelles, ... ) cela ne fera pas partie de leurs préoccupations et restera l’affaire d’experts en ingénierie dirigée par les modèles et de passionnés de méthodes et autres théories, certes très intéressantes intellectuellement parlant, mais qui n’a rien à voir avec la liquidation de garantie d’un capital décès.

 

Le point critique d’un projet BRMS concerne le développement de tout ce qui va être exposé aux utilisateurs « métier », c’est à dire :

  • Le langage « métier » utilisé,
  • L’élaboration de modèles et d’autres fonctions connexes comme des tests de non-régression ou des aides au débogage.

 

La criticité vient principalement du niveau technique des utilisateurs « métier » concernés.

 

Si trop de liberté est laissée et que les utilisateurs ne sont pas assez formés, le système peut devenir instable, incompréhensible et donc ne pas remplir du tous ses objectifs d’amélioration de l’évolutivité du système, les utilisateurs ayant systématiquement besoin de l’assistance de l’équipe informatique.

 

À l’inverse, si le système est trop contraint, les utilisateurs ne pourront pas forcement exprimer toutes les règles qu’ils souhaiteraient.

Dans ce cas, soit les utilisateurs cessent d’utiliser le système, soit les demandes à l’équipe informatique se multiplient.

 

Un bon conseil, n'hésitez pas à réaliser un POC avec comme objectifs de concevoir la méthode, les modèles et la granularité des règles, de former quelques développeurs et experts métiers, de communiquer avec pédagogie a l'ensemble des acteurs projet y compris la direction générale et la DSI.

 

Et puis très important, faites une première itération ou seul les développeurs vont écrire les règles. Les processus d'intégration, d'exploitation, de tests et de cycle de vie des règles doivent être validés.

Profitez-en pour mesurer les temps de développement et autres charges pour affiner votre retour sur investissement.

 

dmn-les-raisons-d-utiliser-decision-model-notation.PNG

 

Ci-dessus, un exemple de règle métier ( le fameux "Hello world" pour les apprentis d'un langage ) écrite en DRL ( Drools Rules Language ) , le langage standard du moteur de règles métiers open source Drools, adopté par l'industrie et copié par d'autres éditeurs comme IBM.

Le moteur de règles métier open source Drools ( voir nos articles dans la catégorie : DROOLS ), est le standard choisi par l'industrie. 

Son langage a été repris par la plupart des autres éditeurs.

La spécification des tables de décision a même été repris par l'OMG ! 

Drools s'intègre parfaitement avec le moteur de processus métiers exécutables open source jBPM ( voir nos articles dans la catégorie :  JBPM ) de la même société.

Tous les acteurs du domaine d'urbanisation du SI des règles métiers ont leurs outils, cela va du développeur avec des plugins Eclipse, en passant par l'administrateur pour la gestion et le cycle de vie des règles métiers jusqu'à l'expert métier avec des applications web permettant la conception avec leurs propres DSL reprenant leur jargon métier.

On peut donc avec une telle plate-forme, se passer aisément de DMN.

 

En conclusion, DMN n'est t'il pas un DSL ( Domain Specific Language ) pour "savants fous", méthodologues et autres théoriciens de l'IDM ( Ingénierie Dirigée par les Modèles voir nos articles : INGÉNIERIE DIRIGÉE PAR LES MODÈLES (IDM) ), épris uniquement de concepts abstraits et éloignés des préoccupations pratiques de la vraie vie des experts métiers qui ont d'autres choses à faire que d'apprendre un langage et des outils techniques ? 

 

"Le danger, ce n'est pas ce qu'on ignore, c'est ce que l'on tient pour certain et qui ne l'est pas."

Mark Twain

 

 Rhona Maxwel

@rhona_helena

 

 

Articles conseillés :

 

Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : le processus métier BPMN

 

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

 

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

 

DMN


21/01/2017
0 Poster un commentaire

Quel est le budget de l'urbanisation et urbanisme du Système d'Information ?

Le niveau d'investissement en urbanisme peut se mesure par un indicateur simple.

 

budget-urbanisation-urbanisme-systeme-d-information.png

 

L'urbanisme se développe par cycles.

L'investissement dans une nouvelle infrastructure d'urbanisme est obligatoire lorsqu'il y a des dysfonctionnements, des surcoûts, des blocages ou des constats de déphasage par rapport à la stratégie.

La mise en place de cette infrastructure est progressive, car l'urbanisme ne crée pas de rupture.

 

Des investissements pour la création ou le développement d'un service d'urbanistes et les réalisations techniques sont nécessaires.

L'étape suivante est la mise en œuvre de l'urbanisme dans les projets IT, véritable consolidation de la nouvelle politique d'urbanisme.

Cette infrastructure est conçue pour une durée de vie longue, plus longue que celle des systèmes d'information qui la prennent pour base.

Un jour, il faudra la remettre en cause, pour faire face aux enjeux futurs.

 

Une nouvelle période d'investissement sera engagée, modifiant tout ou partie des bases précédentes.

Ces cycles, générations successives de politiques d'urbanisme, sont des avancées dans la maîtrise des SI.

L'urbanisme gagne en maturité :

  • 1ère étape, on se limite à cartographier le patrimoine d'un SI mal connu. Ceci permet d'éviter l'empilement systématique des composants applicatifs issus de projets opportunistes. L'urbanisme est préventif, limite la complexité, les redondances et incohérences.
  • 2ème étape, l'urbanisme, ayant gagné en crédibilité auprès des maîtres d'œuvre, peut engager la promotion des référentiels.
  • 3ème étape de maturité, l'urbanisme espère à la mise en ordre des processus, et à un meilleur alignement stratégique.

 

Les efforts budgétaires dans l'urbanisme suivent des fluctuations périodiques :

  • Instabilité incitant à privilégier le simple et jetable
  • Nécessité d'aller au plus vite pour gagner des parts de marché en phase de croissance extensive
  • Période de consolidation
  • Année de restrictions financières

 

La difficulté analytique existe car la fonction urbanisme n'a pas un périmètre immuable :

  • D'une entreprise à l'autre, il existe des variantes dans les définitions (urbaniste, architecte fonctionnel, architecte d'entreprise), dans l'organisation, dans les rôles des processus de l'urbanisme.
  • Au sein des grands groupes, des variantes existent aussi entre les diverses entités, leur organisation, et la subsidiarité ajoute un niveau de complexité pour une comptabilité analytique.
  • Les entreprises ne mettent pas en œuvre tous les processus de l'urbanisme, cela dépend du contexte et du schéma de gouvernance.

 

Un indice de maturité basé sur une échelle unique serait réducteur, car l'objectif n'est pas d'appliquer tous les processus.

Au cas par cas, l'entreprise arbitre et choisit le panier de processus pertinents.

L'indice d'urbanisation restitue mieux cette approche multiple, et ne livre aucune préconisation.

 

Le niveau d'investissement en urbanisme peut se mesurer par un indicateur simple : le rapport entre cet investissement et celui constaté dans les projets de Systèmes d'Information.

L'urbanisme ayant une nature d'infrastructure pour les Systèmes d'Information, le dénominateur est constitué uniquement du coût d'étude, de développement, de test, à l'exclusion des coûts de maintenance, et de ceux de maîtrise d'ouvrage. Il s'agit de comparer des coûts d'investissement de même nature.

 
Le ratio d'urbanisme est donc le rapport entre d'une part, les investissements en conception, développement, test dans l'urbanisme des Systèmes d'Information et, d'autre part, les frais de même type dans les projets de SI.
La fourchette est comprise entre 1 % et 5 %.

 

L'effet de levier de l'urbanisme porte sur la création de valeur.

Par son action vertueuse sur la flexibilité, la réactivité, il contribue alors directement à la stratégie.

L'urbanisme révèle et positionne certains composants du SI et objective les scénarios répondant aux aléas et stratégies du métier.

 

Si tel est le cas, un ratio d'urbanisme durablement faible, une fonction sous-configurée et incapable de répondre, en qualité, aux enjeux, pourra mettre en péril l'entreprise, bien au-delà de la performance des processus.

 

Rhona Maxwel

@rhona_helena

 

« Le courage est la première des qualités humaines car elle garantit toutes les autres. »

Aristote

 

 

Articles conseillés :

 

En Urbanisation SI, les constructions/destructions et l’entretien du POS sont réglementés

 

Urbanisme SI : les objectifs en moins de 20 lignes !

 

Urbanisation du Système d'Information : Ne vous perdez pas dans les typologies de référentiel !

 

Urbanisation du Système d'Information : créez l'évènement !

 

Dans le futur, il faudra réaliser la symbiose des méthodes et veiller à la cohérence des gouvernances SI et processus


14/01/2017
0 Poster un commentaire

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

Un scénario pour tester notre modèle DMN de règles métiers

 

Un premier article :

Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : le processus métier BPMN

vous a présenté le processus métier BPMN utilisé pour ce tutoriel sur DMN et qui comporte des tâches de type décisions ou règles métiers.

 

Le deuxième article :

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

propose le DRG ( Decision Requirement Graph )

 

Le troisième article :

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

détaille le modèle précédent en montrant les tables de décision et les règles métiers. 

 

L'objectif de cet article est d'illustrer par un exemple de données en entrée, le fonctionnement du modèle de décisions.

 

Exemple de données en entrée : « Applicant Data »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-95.PNG

 

Exemple de données en entrée : «  Requested Product »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-96.PNG

 

Exemple de données en entrée : «  Bureau Data »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-97.PNG

 

Résultat du service de décision : «  Bureau Strategy »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-98.PNG

 

Résultat du service de décision : «  Routing  »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-99.PNG

 

Ce scénario de test, termine notre série d'articles sur la norme de modélisation des règles métiers DMN.

 

Rhona Maxwel

@rhona_helena

 

"Je veux être tout ce que je peux devenir."

Katherine Mansfield

 

 

Articles conseillés :

 

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

 

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

 

Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : le processus métier BPMN


02/01/2017
0 Poster un commentaire

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

Exemple de tables de décision liées à un DRG ( Decision Requirement Graph )

 

Le DRG de notre article précédent : 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 est complété en détail par les expressions associées aux décisions et modèles de connaissances :

 

« Strategy decision » défini une table de decision déduite de « Strategy » allant de « Eligibility » et « Bureau Call Type »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-76.PNG

 

« Bureau Call Type » décision invoque la table « Bureau call type », passant la sortie de « Pre-bureau risk category » décision comme le paramètre « Pre-Bureau Risk Category ».

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-77.PNG

 

La table de décision « Bureau call type ».

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-78.PNG

 

« Eligibility » invoque la règle métier « Eligibility », passant « Applicant data », le paramètre « Age » , la sortie de la décision « Pre-bureau risk category » comme le paramètre « Pre-Bureau Risk Category », et la sortie de la décision « Pre-bureau affordability » comme le paramètre « Pre-Bureau Affordability ».

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-79.PNG

 

« Eligibility Rules »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-80.PNG

 

« Pre-Bureau Risk Category »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-81.PNG

 

La table de décision « Pre-Bureau Risk Category »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-82.PNG

 

« Application Risk Score »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-83.PNG

 

« Application Risk Score Model »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-84.PNG

 

« Routing decision »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-85.PNG

 

« Routing Rules »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-86.PNG

 

« Post-Bureau Risk Category »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-87.PNG

 

La table de décision « Post-bureau risk category »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-88.PNG

 

« Pre-bureau Affordability »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-89.PNG

 

« Post-bureau affordability »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-90.PNG

 

« Affordability calculation »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-91.PNG

 

La table de décision « Credit contingency factor »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-92.PNG

 

« Required monthly installment »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-93.PNG

 

 

« Installment calculation »

 

dmn-decision-model-notation-tutoriel-didacticiel-exemple-complet-94.PNG

 

Rhona Maxwel

@rhona_helena

 

"Nul ne peut atteindre l'aube sans passer par le chemin de la nuit."

Khalil Gibran

 

 

Articles conseillés :

 

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

 

Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : le processus métier BPMN

 

La norme DMN ( Decision Model and Notation ) pour les tables de décision


02/01/2017
0 Poster un commentaire