urbanisation-si

urbanisation-si

Mais que fait la "gouvernance SOA" ?

urbanisation-si-gouvernance-SOA.jpg

"La patience est clé de tous les soulagements"

 

La SOA (Service Oriented Architecture) est l'affaire de tous, la DSI mais aussi les directions métiers, les sponsors (skateholder = partie prenante dans la méthode UP Unified Process) et la direction générale qui doit montrer son implication dans le projet d'urbanisation du SI et de la mise œuvre SOA. La gouvernance SOA représente un processus formel d'un contrat entre tous les acteurs de la SOA. La gouvernance SOA spécifie les éléments d'architecture (modèles, processus métiers, objets métiers, règles métiers, cartographies, référentiel de services, schéma directeur) et les rôles de tous les acteurs. L'effort doit être progressif au début puis arriver à une certaine routine. Les bonnes pratiques et l'application des règles de la gouvernance doivent devenir naturelle, un réflexe, une seconde nature, qu'on applique sans y réfléchir, sans que ce soit une contrainte et pour cela il aura fallu auparavant une conduite du changement convenablement mené avec beaucoup de pédagogie. Comme de nombreux projets informatiques qui démarrent en trombe avec l'application de toutes les bonnes pratiques et qui plus le temps passe, plus l'effort faibli et laisse apparaître de plus de plus de  code non maintenu, on pourrait voir apparaître des modèles ou des cartographies obsolètes. La gouvernance SOA doit clairement définir les objectifs et les moyens pour y parvenir. La cible à ne pas perdre de vue est la réduction de la complexité du SI de manière continue, concevoir un modèle vertueux qui identifie et récompense la mutualisation et mettre en œuvre par des systèmes innovants le pilotage des processus, règles et objets métiers. La gouvernance SOA conçoit le processus de validation et de mise à jour des règles à respecter et c'est souvent le rôle de la cellule urbanisme et architecture de le vérifier. Les règles portent par exemple sur le référentiel des services, des droits en mise à jour, des gestion des versions, des conditions de mise production, bref du processus classique de génie logiciel (conception, réalisation, intégration, tests, mise en production, gestion des versions, maintenance). Comme on l'a déjà dit lors d'articles précédents, l'urbanisation suit les concepts de l'Orienté Objet (modularité, communication par message, encapsulation, hiérarchisation, généricité, faible couplage, forte cohérence), de même le référentiel de services doit suivre ces principes. La hiérarchie du référentiel doit être isomorphe à la structure de l'entreprise. Les accès et la visibilité des services sont restreints par des règles strictes sans quoi on se retrouverait vite fait dans un "plat de nouilles". Les évolutions du référentiel des services sont planifiées. On utilisera avantageusement la modélisation UML pour y parvenir. 

Mettre au point des règles pour diminuer la complexité, aller dans le sens de la mutualisation, de l'évolutivité et de la maintenabilié c'est bien mais les faire respecter dans la durée c'est encore mieux. Pour cela il ne faut pas hésiter à donner du pouvoir à la cellule urbanisme et architecture pour vérifier et mettre à l'amende ceux qui ne respecterait la loi. 

 

Voir aussi :  http://urbanisation-si.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://urbanisation-si.eklablog.com/

http://bonnes-pratiques-si.eklablog.com/

http://rhonamaxwel.over-blog.com/



28/09/2014
0 Poster un commentaire

A découvrir aussi


Inscrivez-vous au blog

Soyez prévenu par email des prochaines mises à jour

Rejoignez les 192 autres membres