jump to navigation

Intégration d’applications ou intégration ontologique ? janvier 9, 2006

Posted by vincent poncet in Architecture.
1 comment so far

L’intégration du SI passe par l’intégration des briques le composant étant présent à un moment donné. Aujourd’hui, la brique élémentaire du SI est l’application. C’est donc tout logiquement que l’intégration du SI est considérée comme l’intégration des applications qui le composent. Néanmoins, il ne suffit pas de connecter les applications entre elles selon les besoins en information de telle ou telle application pour dire que l’on fait de l’intégration de SI. Il ne faut pas prendre l’application comme un élément stable et autonome qu’il faudrait connecter à d’autres éléments stables et autonomes. Il faut plutôt intégrer ce pourquoi les applications ont été conçues. Il faut donc revenir à leur processus de conception afin de définir l’objet de l’intégration de SI.

Le processus de conception de l'application comme source du problème d'intégration

Une application est conçue pour répondre à des besoins métiers au périmètre bien circonscrit. En effet, chaque application est généralement considérée comme propriété de la branche métier commanditaire. C'est, en effet, elle qui a ouvert une ligne budgétaire afin de payer la DSI pour la conception de l’application correspondant à son besoin. Cette relation de propriété entre la branche métier et l’application conduit nécessairement à la limitation du périmètre de l’application aux besoins de la branche commanditaire. Pour la branche métier commanditaire et utilisatrice de l’application, cette application lui sert à automatiser un certain nombre de tâches relatives aux sous-processus dont elle a la charge dans l’entreprise et d’en suivre l’exécution. Ainsi, cette application servira à manipuler un certain nombre d’objets en vue de leur appliquer les traitements appropriés. Par exemple, la branche « Commercial » souhaite une application de gestion des ventes. Pour cela, devront être définis l’objet métier « Vente » ainsi que les différents traitements qui feront évoluer son cycle de vie. Ces différents traitements seront définis en accord avec les sous-processus méties relatifs au processus métier « Vente » dont elle a la charge.

Les applications sont définies par rapport à des besoins au périmètre restreint. On comprend donc que la définition des objets et des traitements relatifs à ces objets présents dans l’application ne recouvrent qu’une vision parcellaire et non globale de l’entreprise. Une application manipulant des sous-processus et des objets métiers, elle porte en elle une représentation du monde du point de vue de son commandiataire. Une application porte donc l’ontologie relative à la branche métier commanditaire et non l’ontologie globale de l’entreprise. Or, un même objet métier peut se retrouver dans différents processus métiers. Par exemple, l’objet « Vente » est autant présent pour la branche métier « Commercial » que pour celle de « Gestion des stocks ». Sa définition au sens de l’entreprise sera donc portée par au moins deux applications. De même, les sous-processus réalisés dans différentes applications participent aux mêmes processus globaux. Les définitions des objets métiers et des processus globaux sont donc disséminées dans tout le système d’information. Toute la difficulté de l'intégration du SI consiste donc à recréer une homogénéité globale alors que les parties à intégrer n’ont pas été conçues dans cette optique.

Le but de l’intégration du Système d’Information : l’intégration ontologique

La problématique d’intégration du système d’information prend donc sa source dans cette dissémination des définitions des objets métiers et des processus globaux de l’entreprise dans toutes les applications du système d’information. L’intégration de SI ne vise qu’à rassembler tous les sous-processus et les objets métiers parcellaires portées par toutes les applications du SI afin de reformer les processus métiers de bout en bout de l’entreprise et les objets métiers du point de vue global de l’entreprise. En un mot, l’intégration du système d’information vise à faire émerger l’ontologie de l’entreprise à partir des ontologies locales de ses différentes branches métiers capturées dans les applications du système d’information.

L’organisation centrée sur les applications comme source de la problématique d’intégration janvier 4, 2006

Posted by vincent poncet in Organisation.
2 comments

 

La logique actuelle dans la majorité des DSIs est qu’à chaque besoin ou typologie de besoin corresponde une application. Ces applications nécessitants des informations déjà présentes dans le système d’information, les personnes en charge de la réalisation de ces applications devront développer des connections entre ces nouvelles applications et celles déjà présentes dans le SI.

L’intégration d'application : sa complexité technique et organisationnelle

Toute application peut potentiellement être consommatrice des données générées par toutes les autres applications du SI. La multiplicité des liens point à point que l’on retrouve dans tous les SI ont amené les analystes à décrire le système d’information comme un plat de spaghettis. Cette multiplicité des interdépendances entre applications donne lieu à d’énormes coûts tout au long des différentes phases du cycle de vie d’une application.

Lors de l’étude, vu que bien peu d’entreprise disposent d’une cartographie exhaustive de leur SI, les personnes en charge de la réalisation d’une application devront aller enquêter auprès de leurs collègues pour savoir où se trouve l’information convoitée et quelle application – en espérant qu’il n’y en ait qu’une – en est génératrice. Dans la plupart des cas, cette enquête arrivera à la conclusion que chaque information prise individuellement se trouve dans telle ou telle application en fonction de telle ou telle condition. Ainsi, par exemple, pour avoir la totalité des clients de l’entreprise, on devra aller les chercher dans différentes applications en fonction, par exemple, de la ligne de produits qu’ils ont achetés. De plus, cette étude montrera que la représentation d’une même donnée ne sera pas identique d’une application à l’autre et donc que des règles de transformation spécifiques devront être réalisées durant le développement. De même, toutes les informations relatives à un client sont disséminées parmi toutes les applications du SI.

Lors de la conception, une fois les applications sources identifiées, la problématique à résoudre sera celle de la stratégie de connectivité. A cette étape, les concepteurs devront définir, avec les responsables de l’application tierce, comment se connecter, à quel niveau (par les données, par les APIs, par revamping d’écrans), par quelle technologie, selon quelle régularité (par batch, au fil de l’eau). Ce travail devra être fait pour toutes les applications auxquelles se connecter, et il y a de grandes chances pour que chaque connexion doive être réalisée selon une stratégie de connectivité spécifique.

Lors de l’exploitation de l’application, se posera le problème de la supervision de toutes ces chaînes de connectivité. En effet, la rupture de l’un des liens reliant une application à une autre peut rendre non fonctionnelles ces deux applications. L'impact pourra être encore plus important si l’on considère que chaque application fait partie d'un systèmes d'applications interdépendantes.

Lors de l’évolution de cette application, il devra être pris en compte l’impact des modifications demandées sur la multitude des liens relative à cette application.

Enfin, cette multiplicité des connections n’a pas qu’un impact technologique, car pour chacune de ces connections, il devra y avoir un accord entre les responsables des applications concernées. Chaque application ayant été conçue par rapport à un besoin métier circonscrit, la gestion de cette application en a pris la même direction. Il n’est effectivement pas rare de voir qu’en termes de sphère d’influence de pouvoir au sein de l’entreprise, un responsable d’application est très proche du responsable métier correspondant aux besoins de l’application. Ainsi le responsable d’une application n’a pas d’intérêt à voir « ses » données utilisées par d’autres applications ; de même, il n’a pas d’intérêt à voir « ses » ressources humaines travailler sur la connectivité nécessaire pour les besoins d’une autre application.

Nous voyons donc que tout au long du cycle de vie d’une application, de part ses implications organisationnelles, technologiques et politiques, la connectivité inter-applicative alourdit considérablement le processus de réalisation de cette application et alourdit surtout son évolution. Ces interdépendances non-alignées avec l’organisation de la DSI augmentent la rigidité du SI et freinent son adaptabilité au changement permanent du business face à une économie, elle aussi, en évolution perpétuelle.

L’urbanisation durable du SI passe par un alignement des concepts premiers du SI avec l’organisation de la DSI

En définissant implicitement ou explicitement les applications comme élément de base du SI, l’organisation actuelle des DSI ne mettent pas en avant les besoins de leur clients, mais une implémentation possible de ces besoins. En effet, les besoins des branches métiers s’exprimant en terme de processus métiers et d’objets métiers, alors que la DSI ne parle qu'en terme d'applications et de flux inter-applicatifs. Il est donc aisé de comprendre la difficulté de communication quand une branche métier exprime une demande informatique en terme de processus et que la DSI répond en terme d’applications. Cette différence de paradigme entre les branches métiers et la DSI est la source du non-alignement entre le SI et le métier. Si la DSI veut pouvoir réussir l’alignement du SI au métier de l’entreprise, elle doit donc abandonner son organisation par responsabilité d’applications, voire abandonner le concept même d’application pour s’organiser selon les concepts premiers du métier que sont le processus et l'objets métier.

 

Bienvenu sur le blog de «Urbanisation Durable du Système d’Information» janvier 4, 2006

Posted by vincent poncet in Architecture, Organisation.
3 comments

Ce blog vise à définir l’Urbanisation Durable du Système d’Information, comme relevant d’un ensemble de principes à la fois architecturaux et organisationnels dont l’objet d’aligner la DSI comme une partie intégrée au business de l’entreprise.