Relation entre la gouvernance TI et SOA

Aligner les stratégies métier et TI

La gouvernance des architectures orientée services est une extension de la gouvernance des TI qui se focalise sur la gestion efficace de chaque aspect lié aux services. La manière dont ces derniers doivent être gérés diffère des pratiques jusqu’à maintenant utilisées par rapport aux systèmes traditionnels dû aux changements importants induits par SOA. Par contre, il ne s’agit pas d’un projet de refonte de gouvernance mais plutôt d’une suite basée sur les piliers déjà existants dans la gouvernance des TI. Dans la Figure 18 on peut voir ces différents piliers, ou domaines d’intérêt, ainsi que leur relation dans un modèle de gouvernance TI. Ces piliers sont l’alignement des stratégies métier et TI, la valeur des livrables (Value delivery), la gestion de la performance, le management des ressources et des infrastructures et la maîtrise des risques sur le plan technologique [Mitra 2005, Governance responsibilites].

Figure 18: Les principaux domaines de la gouvernance TI [IT Governance Institute 2003, p. 20].

D’une manière générale, la demande provenant des parties prenantes (stakeholders) pousse le département TI à travailler en cohérence avec les objectifs stratégiques. Le degré d’alignement stratégique entre le métier et le TI est un paramètre fondamental pour que les TI commencent à fournir de la valeur (actifs, etc.) à l’entreprise. La valeur dérivée des TIs permet de satisfaire les besoins stratégiques et opérationnels exprimés par le niveau métier. Il s’agit de lui fournir tous les services espérés (Just-in-Time) avec l’infrastructure correcte et le personnel adéquat. Afin de permettre la continuité de l’activité TI, il est important d’effectuer une gestion proactive et réactive des risques liés aux actifs. En effet, aujourd’hui les systèmes d’information sont exposés à plusieurs dangers qui peuvent mettre en péril l’entreprise la plus solide qu’il soit. La gestion des risques permet de prévoir et d’identifier les problèmes (pannes, piratage, vols, etc.) et d’apporter des solutions temporelles ou définitives. Enfin, pour avoir une meilleure visibilité sur les opérations et la stratégie adoptée on doit mettre en place un système de mesure de la performance TI. Dans ce domaine on s’intéresse au monitoring des résultats permettant d’établir un bilan actuel de l’état du TI dans l’entreprise et de fixer des nouveaux objectifs. En principe, la mesure de la performance se réalise selon quatre perspectives différentes, à savoir les clients, les objectifs financiers, les processus métier et le capital humain [IT Governance Institute 2003, p. 29].

Dans la gouvernance SOA, l’alignement stratégique s’étend au domaine des applications orientées services ou applications composées. Il n’est concerne ni les applications orientées composants ni les architectures client-serveur traditionnels car cela est déjà pris en charge au niveau de la gouvernance TI. Il se concentre plutôt sur les questions stratégiques qui peuvent être résolues avec une approche orientée service. Par exemple, il défini et communique les niveaux d’investissements en SOA (finance, personnel, infrastructure, etc.) qui correspondent le mieux avec les besoins métier. Garanti les niveaux de service SOA adéquats pour que la stratégie métier puisse être déployée avec flexibilité et rapidité et prend des décisions sur les stratégies d’implémentation de SOA.

Tableau 3 : Relation entre les solutions métier et TI

Stratégies métier Solution métier Outils stratégiques Solutions TI

 Domination par

Le Tableau 3 contient une synthèse des éléments à considérer lors de la mise en œuvre de l’alignement stratégique. En principe, il est important que la gouvernance des TI puisse établir une relation avec le niveau métier. Elle peut se faire au moyen des outils d’analyse stratégique, par exemple avec l’application des méthodes de portefeuille et d’analyse de la chaîne de valeur qui sont employées tant pour les directions métier que pour les directions des TI. Comme on peut le constater dans ce tableau il n’y a pas de relation directe entre les stratégies métier et l’infrastructure des TI. Cela s’explique en partie par le fait que les stratégies comme celle de domination par les coûts, peuvent se décliner en plusieurs solutions métier distinctes (petits prix ou cash-flow réinvestis) et ne déclarent aucun concept se référant directement aux TI. C’est ensuite que grâce aux mécanismes de gouvernance (méthodes de gestion de portefeuille, etc.) qu’il est possible de déterminer le potentiel des TI dans un contexte précis et de fournir une direction claire aux unités de gestion des TI (gestion des risques, gestion de configuration, etc.) pour l’implantation de ces solutions.

Figure 19 Structure de gouvernance TI et SOA.

Dans le contexte de SOA, la colonne « Solutions TI » du Tableau 3 est évidemment implémentée d’une autre manière. Ces solutions TI sont implémentées avec la technologie de services et demandent quelques adaptations des structures de gouvernance existantes. Comme on peut le voir dans la Figure 19, une structure de gouvernance TI se compose principalement de trois niveaux, à savoir le niveau stratégique, le centre d’excellence en gouvernance et le niveau de gestion TI. SOA introduit en plus une nouvelle entité connue sous le nom de domain ownership [Bloomberg 2004] qui permet de décomposer une entreprise en plusieurs domaines de services ayant en commun un contexte métier. A l’intérieur d’un domaine de service, les cadres métier et TI doivent assurer la qualité des applications et des services SOA en prenant en charge toutes les phases de leur cycle de vie. Ils sont responsables par exemple de maintenir les interfaces avec les services d’autres domaines et de négocier leurs propres niveaux de services (SLA). Selon [Bloomberg 2004] dans chaque domaine on doit trouver une liste de rôles comme celle qui suit :

 Développeurs de domaine : Dans cette catégorie on trouve les personnes impliquées dans le développement de services conforme aux principes de l’orientation services évoqués dans la section 2.3.

 Le propriétaire de domaine désigne la personne responsable de représenter le domaine vis-à-vis des cadres métier. Il est chargé de gérer le domaine comme une unité de service informatique fournissant des services aux unités métier et aux autres domaines de services SOA.

 Analyste fonctionnel orienté service: C’est le rôle assigné aux personnes chargées de capturer les besoins métier et d’identifier les services SOA à implémenter. Ils produisent aussi les modèles de données et travaillent en collaboration avec les différents architectes.

 Line of business representative : Responsable de capturer les services métier qui devront être supportés par l’initiative SOA. Pour ce faire il communique les besoins métier aux responsables TI.

 Service tester: C’est le rôle assigné aux développeurs ou autre personnel SOA pour définir et implémenter des tests conforme aux besoins métier.

Comme on l’a mentionné au début de ce chapitre, la gestion de la performance dans la gouvernance TI se centre sur quatre axes principaux, à savoir les rendements financiers, la satisfaction du client, les processus internes et l’acquisition des connaissances du personnel TI (innovation, formation, etc.). Chacun de ces quatre axes ont pour but de mesurer un aspect spécifique de l’efficacité des solutions TI et la valeur que celles-ci ajoutent aux affaires de l’entreprise. Ils permettent de disposer des indicateurs de performance clés permettant de savoir par exemple le ratio investissement-bénéfice dans un projet TI donné.

Gestion de la performance

La gouvernance SOA tire avantage de ce que l’on sait faire déjà au niveau de la gouvernance TI. En principe, on utilise les méthodes et les outils de mesure de la performance TI (ROI, BSC, portfolio management, etc.) pour évaluer les résultats espérés au niveau de l’architecture et des services individuels. L’élément central qui permet d’optimiser le rendement financier (performance financière) est sans doute la réutilisation des services. Pour ce faire, la gouvernance TI continue à utiliser les modèles économiques cités ci-dessus, tandis que la gouvernance SOA fourni les informations telles que les statistiques de fréquence d’utilisation des services et de chacune de ses fonctionnalités, le nombre de consommateurs par service, etc. Pour qu’un service SOA devienne effectivement rentable il faut qu’il n’existe pas en doublons, si possible, qu’il appartient à plusieurs projets à la fois (réutilisable) et qu’il ne soit pas sous-utilisé.

La performance Run-Time est aussi un sujet très important dans l’approche orienté services.

Comme on peut voir dans le Tableau 4, les données comme le temps qui prend un service pour retourner une réponse au consommateur (important dans le mode synchrone) et l’indisponibilité sont des données liées à la performance. Dans le cas des services web, le temps de réponse est un paramètre à surveiller de près car l’un des inconvénients de XML/SOAP est qu’il est effectivement plus lent par rapport aux données en format binaire [Pulier and Taylor 2006, p. 46]. D’autres éléments sont aussi susceptibles de gêner la performance SOA, notamment le niveau de granularité des fonctionnalités, des messages et du service et les opérations de transformation effectués par les « nodes » de traitement de messages.

Tableau 4: Quelques paramètres utilisés pour mesurer la performance des services.

Performance Run-Time Performance Design-Time Indicateurs clés de performance (KPI)

La gestion de la qualité du service (QoS) représente un autre aspect de la gestion de la performance SOA. La qualité des services est une question qui touche aussi bien la performance Run-Time que celle de Design-Time. Quoi qu’il en soit, la gestion des QoS est souvent implémentée à l’aide d’outils d’administration de service qui permettent de définir des paramètres de qualité et de les comparer avec ceux définis au niveau des SLAs. Au design-time il existe des principes et des patterns orientés service qui permet de garantir la qualité en fonction du modèle de service que l’on veut développer. Les grandes lignes de la QoS sont fournies principalement par les contrats de services comme le SLA qui établit les niveaux de services attendus par les consommateurs du service en question.

Comme SOA et la gestion de processus métier sont très liés l’une à l’autre, on peut citer le management des processus métier comme une des facettes de la gestion de la performance SOA. En effet, les services de processus supportent les processus métier qui eux à leurs tours sont gérés au niveau de la couche BPM. Lorsque les indicateurs clés de performances (KPI) d’un processus métier montrent que ce dernier ne correspond plus aux besoins métier, le BPM permet de changer d’une manière dynamique le flux des opérations afin d’optimiser les résultats. Parallèlement au module de gestion de processus, les outils BPM fournissent un module d’orchestration [Arch2Arch 2006c, p. 23] pour répercuter rapidement les changements effectués au niveau des processus sur les services. Donc, les mesures relevées au niveau des processus métier supportés par SOA permettent aussi de faire une analyse de corrélation entre les performances du processus et celle des services qui l’implémentent.

La gestion du risque

Aussi bien la gouvernance TI comme la gouvernance SOA s’intéressent toutes les deux au domaine de la gestion des risques. Dans le contexte général des technologies de l’information, la gouvernance s’est focalisée sur trois aspects principaux, à savoir les investissements financiers en TI, la sécurité de l’information et les risques opérationnels. Pour mettre en place un système de gestion, que ce soit au niveau SOA ou au niveau TI, le principe reste le même, c’est-à-dire, on doit commencer par définir le profil de risque (aversion, goût, etc.) auquel l’entreprise correspond le plus. Cette étape d’analyse comportementale permet de comprendre jusqu’à quel point les systèmes d’information peuvent rester protégés des éléments internes et externes à l’entreprise.

En principe, la gestion des risques comprend les activités suivantes :

 L’analyse des risquesqui permet d’identifier les événements représentant une menace pour un projet TI et SOA. A partir de cette analyse l’entreprise est en mesure d’estimer en termes de probabilité la réalisation d’un risque et les conséquences possibles.

 L’analyse de l’impactqui est une méthode permettant de capturer les pertes potentielles (totales et partielles) suite à l’occurrence d’un risque. Elle fourni une description détaillée sur la nature de dommages, les ressources nécessaires pour les contrôler et les délais toléré pour que les services soient rétablis.

 La gestion de la continuité des services permet d’établir un plan de conduite des affaires dans tous les cas de figure [Descloux 2004, Chap. Plan de sécurité]. Dans le cas du rétablissement de la continuité après un sinistre, il fait référence au plan de reprise graduelle, intermédiaire ou immédiate.

La gouvernance TI et SOA doit choisir parmi les stratégies de gestion de risque telles que la mitigation, le transfert et l’acceptation du risque [IT Governance Institute 2003, p. 27].

 La mitigation est une stratégie consistant à minimiser les risques par la mise en place d’une infrastructure de protection caractérisée par des mécanismes de contrôles internes et des plateformes de sécurité informatique.

 Le transfert du risque est stratégie permettant de partager les risques encourus ou de les transférer à une entreprise spécialisée comme les compagnies d’assurances.

 Enfin, la stratégie d’acceptation consistant à accepter le risque parce qu’il ne peut pas être réduit, ou par d’autres raisons, et qu’il faut le surveiller de près pour éviter des problèmes majeurs.

Dans le contexte de SOA, la gestion des risques vise le cycle de vie des services pour réduire et contrôler les risques associés à la conception, l’utilisation et l’administration des services.

Voici quatre exemples des risques qui peuvent survenir dans le cycle de vie des services [Brown 2007, p. 215] :

 Services ill-defined: Les services dont les fonctionnalités ne correspondent pas aux besoins métier car elles ne peuvent pas supporter le flux de travail comment on aurait voulu. Mais aussi, lorsque l’équipe de développement consomme des ressources (temps, argent, etc.) en ajoutant des artefacts qui ne sont pas nécessaires, comme c’est le cas de fonctionnalités et de la documentation en trop.

 Services disposable: Les services développés dans le but de servir dans un seul et unique projet ne sont pas convenables pour SOA car toute possibilité de réutilisation est supprimée et il est très difficile de retirer de bénéfices concrets dans le long terme.

Cela revient à implémenter des services jetables qui ne servent qu’à un projet seulement et dont les caractéristiques ne s’ajustent pas aux utilisations futures.

 Conception incomplète: Lorsque seulement une partie du service est achevée, comme par exemple quelques une de ses fonctionnalités, il y a un risque potentiel de devoir revenir sur les étapes de conception pour effectuer les « derniers changements ».

Malgré qu’il soit possible de laisser l’implémentation du service pour plus tard, toutes les détailles de conception devraient être terminés pour éviter que l’apparition des nouveaux concepts métier ne demandent des changements importants et coûteux.

 Service sous-utilisé: Le risque d’avoir « oublié » qu’un service déterminé existe est tout à fait réel. Des problèmes liés à la gestion des registres de services et à la politique de communication sont souvent la cause des services peu utilisés.

Chacun des projets d’implémentation doit être évalué depuis la perspective de la gestion des risques, aussi bien sur le plan financier qu’opérationnel. Au niveau financier, une politique

continuelle de surinvestissement ou de sous-investissement dans le développement des services peut poser des problèmes de rentabilité et pousser l’initiative SOA vers l’échec définitif. Au niveau opérationnel, la gouvernance SOA peut réduire les risques en développant un équilibre entre les stratégies de formation et « enforcement ». D’une part, une politique de formation efficace garantie que les procédures et les standards d’opération sont connus des utilisateurs et que ces derniers sont en mesure de travailler correctement. La formation est un mécanisme simple nécessitant un certain investissement en « training », « mentoring » et

« lecture » [Brown 2007, p. 219] mais qui permet d’éviter que des erreurs prévisibles se produisent et causent des dommages répétés. D’autre part, une stratégie de « enforcement » permet de capturer les erreurs avant que ces derniers ne deviennent plus sérieux. Grâce aux

« check point » périodiques défini il est possible de déceler les erreurs en Design-time et en Run-Timeet de les solutionner avant qu’il ne soit trop tard.

Comme on l’a mentionné auparavant, la gestion des risques concerne aussi les aspects de sécurité de l’information et à ce niveau il n’existe pas beaucoup de différence entre la gouvernance TI et SOA. En effet, les services web, ou toute autre implémentation SOA, peuvent être gérés en utilisant les mêmes méthodes de gestion de risque utilisés depuis des années par les responsables TI. Qu’il s’agit d’une architecture traditionnelle ou SOA, la gouvernance doit pouvoir établir une stratégie de sécurité, définir des contrôles, des politiques, des standards technologiques ayant une portée globale dans leur application. Elles doivent aussi implémenter un cadre de gestion permettant définir les actions à mener en cas d’occurrence de ces risques.

Pour montrer la manière dont la sécurité pose des problèmes de gestion à SOA, on va utiliser comme exemple les services web. En effet, le premier risque de sécurité est celui lié à l’utilisation même des standards qui malgré leurs nombreux avantages d’interopérabilité amènent aussi certains risques. Surtout parce que leurs détails de spécification (vulnérabilités, etc.) sont aussi connus de tous les éventuels pirates informatiques inclus. Dans le cas des technologies propriétaires, il est plus difficile de connaître leur vulnérabilité car leurs interfaces ne sont pas connues de tous. A cela s’ajoute le fait que les services web ont été conçus dans le but de passer facilement les frontières organisationnelles pour faciliter l’échange d’information.

Figure 20: Communication non sécurisée entre le fournisseur et le consommateur de service [Cf. Ultes-Nitches 2006, p. 15-19]

Dans un contexte d’utilisation simple tel que celui illustré dans Figure 20, un fournisseur et un consommateur de service échangent des informations qui ne sont pas protégées contre les risques de déni de service (DoS), sniffing, modification et usurpation d’identités. Dans le premier cas de figure, un service non sécurisé peut facilement être la cible d’attaques de déni de service car une des faiblesses des WS est qu’ils manquent de mécanismes d’authentification et autorisation pouvant identifier les clients ainsi que l’usage qu’ils font du service. Comme résultat, il est tout à fait possible de submerger le service en augmentant le volume du trafic réseau au moyen de requêtes persistantes et d’une grande quantité d’information en attachement. La plupart des services ont la caractéristique d’être sans état mais ceux comme les services de processus peuvent être l’objet d’une attaque de type buffer overflow en modifiant les informations d’état qu’il conserve dans une session. L’absence de contrôle d’accès permet aussi de déclencher des opérations et d’accéder aux sections privilégiées sans y avoir droit.

Dans le deuxième cas, l’attaque appeléeeavesdroppingest une technique d’écoute passive des messages transitant dans un réseau. Souvent, les WS communiquent en passant par plusieurs intermédiaires qui routent le message à l’intermédiaire suivant dans la chaîne. Cette situation est idéale pour intercepter les messages et lire son contenu. Sachant que la plupart des attaques viennent de l’intérieur, le message peut être lu après avoir entré dans la zone de confiance ou de destination, cet à dire, au conteneur du service. La cause de cette vulnérabilité se trouve dans l’absence de mécanismes de cryptage au niveau des messages (faisant abstraction de la pile WS-Security) qui laisse leur contenu circuler en clair à l’intérieur du

Dans le deuxième cas, l’attaque appeléeeavesdroppingest une technique d’écoute passive des messages transitant dans un réseau. Souvent, les WS communiquent en passant par plusieurs intermédiaires qui routent le message à l’intermédiaire suivant dans la chaîne. Cette situation est idéale pour intercepter les messages et lire son contenu. Sachant que la plupart des attaques viennent de l’intérieur, le message peut être lu après avoir entré dans la zone de confiance ou de destination, cet à dire, au conteneur du service. La cause de cette vulnérabilité se trouve dans l’absence de mécanismes de cryptage au niveau des messages (faisant abstraction de la pile WS-Security) qui laisse leur contenu circuler en clair à l’intérieur du