urbanisation-si.com

urbanisation-si.com

Cycle de vie SOA

urbanisation-si-cycle-vie-soa.jpg

 

La première phase concerne le lancement de l’initiative où l’on analyse la pertinence du projet par rapport aux critères de l’entreprise.
Du point de vue de la gestion de projet, cette phase implique
  • des activités d’initialisation et d’étude préalable qui sont propres à un projet traditionnel, à savoir la proposition de SOA (proposal),
  • l’analyse des risques et des enjeux métier,
  • l’établissement des estimations budgétaires et des perspectives de retour sur investissement,
  • les délais prévus et les recommandations de faisabilité.
Après la phase d’initialisation, le cycle génère une série de livrables qui seront appelés dans les phases restantes.
Il s’agit d’un ensemble de documents qui permettent aux cadres supérieurs d’avoir une idée globale sur les coûts et bénéfices attendus et, par la suite, décider de l’avenir de SOA.
La composition des équipes de travail fait aussi partie des activités d’initialisation car elle permet de mettre en place une structure ordonnée de professionnels qui seront chargés de diriger et de mettre en place l’architecture et ses composants.
Cette structure organisationnelle est composée des deux dimensions fondamentales de SOA :
  • Le groupe métier constitué de plusieurs représentants provenant des niveaux stratégiques et opérationnel tels que le conseil d’administration, le PDG, et responsables des unités d’affaires.
  • Le groupe des TI doit être représenté par le responsable des systèmes d’information (DSI), les architectes et développeurs, etc.
Le plan de gouvernance pourrait avoir lieu avant ou en parallèle à la conception des premiers services SOA bien que certaines entreprises attendent (préfère) un niveau de maturité plus avancé pour le faire.
Dans touts les cas, il est plus avantageux de commencer le plus tôt possible avec les questions gouvernance pour éviter que l’implantation et évolution de SOA ne deviennent pas un incontrôlée.•Pour s’en convaincre il suffit d’imaginer le scénario où les droits et obligations de chacun ne sont pas clairement définis.
  • Si l’un des services en opération pose des problèmes à l’entreprise ou à une de ses unités d’affaire, il devient impossible de trouver un responsable capable de corriger la situation et l’on se retrouve bloqué jusqu’à qu’une solution ne soit trouvée.
  • Par contre, si la gouvernance était déjà en place, une procédure de correction prédéfinie aurait été lancée permettant de reprendre les affaires les plus vite possible.
Cette deuxième phase peut être assimilée au début de la gouvernance SOA car elle est orientée vers les processus de planification et de normalisation.
En effet, pour définir les principes SOA et des TI ainsi que l’architecture de référence il faut que l’on a déjà établi les règles du jeu et les rôles des participants, à savoir les personnes responsables des architectures de données, d’information et d’entreprise, les analystes fonctionnels, les directives et exigences métier, etc.
Parmi les livrables obtenus à la fin de cette phase se trouvent l’architecture de référence et les modèles de maturité et de gouvernance SOA.
Pour atteindre les objectifs définis dans l’architecture de référence on peut construire un modèle de maturité constituée d’un ensemble d’étapes clés qui permettront d’évaluer l’état dans lequel se trouve l’organisation par rapport à SOA.
Les indicateurs d’une échelle de maturité sont en quelque sorte les premiers indicateurs de performance dont dispose la gouvernance SOA pour évaluer l’avancement du projet à échelle de l’entreprise.
Le premier niveau de maturité correspond à une entreprise qui s’est limité au développement des services d’application.
  • Pour qu’une entreprise atteigne le niveau fondamental de SOA il faut qu’elle soit en mesure de mettre en place une architecture constituée des services de base comme ceux utilisés pour accéder aux sources de données.
  • C’est le niveau d’exigence minimale qui consiste à exposer les fonctionnalités dont on dispose déjà dans les systèmes « backend » sous forme de services de bas niveau.
Lors du deuxième niveau de maturité on doit mettre en place des services plus élaborés et complexes.
  • Ils représentant des tâches ou des entités appartenant à des différents domaines de l’entreprise.
  • Ce niveau est supérieur à celui des services d’application car il s’adresse aux services contenant la logique métier d’une tâche, d’une activité ou d’un processus métier. Dans certains modèles, ces services peuvent aussi encapsuler la logique spécifique à une entité de type consommateur ou employé.
Le dernier niveau de maturité ajoute une couche supplémentaire qui est celle des services de processus.
  • Ce type de service est très différent des services concertés ou composés développé dans le niveau précédent. Ces derniers ne maintiennent aucun état conversationnel tandis que les services de processus doivent conserver l’état des informations propres à un client tout au long de leur utilisation.

"Exige beaucoup de toi même et attends peu des autres. Ainsibeaucoup d'ennuis te seront épargnés."
 


29/09/2014
0 Poster un commentaire

A découvrir aussi


Inscrivez-vous au site

Soyez prévenu par email des prochaines mises à jour

Rejoignez les 718 autres membres