Archives de Catégorie: Urbanisation SI

Il est temps de s’occuper de l’existant…

Les entreprises ont ajouté des vagues de nouvelles technologies, démarrant souvent des nouveaux projets avant même d’avoir achevé les précédents, le tout avec des résultats décevants mais la frénésie était telle qu’on remettait à plus tard bilans et examens. Cette période a atteint son point culminant à la fin de l’année dernière avec la notion de « temps Internet » qui justifiait de développer « vite fait-mal fait » des projets sans objectif, sans stratégie et sans résultat mesurable. Maintenant que cette effervescence est retombée, le bilan est lourd.

Les deux dernières années ont été terribles pour le monde de l’informatique habitué à des taux de croissances confortables : les clients ont réduit leurs dépenses destinées aux nouveaux systèmes de 15 à 20% en moyenne alors qu’ils avaient investi massivement lors de la dernière décennie (avec des augmentations annuelles des dépenses d’investissement de l’ordre de 5 à 10%).

Ce contexte morose n’est pas vraiment surprenant : non seulement l’éclatement de la bulle Internet a « coupé les jambes » des projets de sites Web et d’Internetisation mais les déceptions ont également été nombreuses dans des domaines en vogue comme le CRM ou les ERP.

Tout cela combiné a provoqué une crise de confiance qui s’est traduite par un coup d’arrêt radical dans les dépenses. Comme si tous les directeurs informatique s’étaient passés le mot en même temps : j’arrête d’acheter !

Tous les responsables informatique, interlocuteurs des acteurs du marché répètent maintenant le même cri du coeur : ne me vendez pas de nouveaux systèmes, aidez-moi plutôt à faire marcher ceux que vous m’avez déjà vendus… C’est un retournement de marché qui est radical et sans doute durable. Car, même en baisse, les dépenses informatiques sont tout de même là, pas pour des nouveaux projets mais seulement pour entretenir l’existant et il y en a !

Depuis la fin de la bulle Internet, les opérations d’EAI sont devenues une priorité évidente pour la plupart des entreprises afin de retrouver un minimum de cohérence. C’est ainsi que nous sommes entrés pour au moins deux ans dans une période caractérisée par la volonté de consolider, d’intégrer et d’optimiser l’existant.

Même les éditeurs d’applications s’y sont mis comme SAP qui, dernièrement, a choisi les Web Services afin d’offrir un accès à ces processus sans avoir à choisir entre J2EE et dotNet… En conséquence, les Web Services ont été mis en avant comme l’alternative légère et idéale pour les opérations d’EAI…

Le fait que les Web Services se soient retrouvés mis en vedette dans le cadre de l’EAI n’est pas surprenant : les Web Services basés sur le protocole SOAP se révèlent être une technique peu intrusive et donc relativement facile à mettre en place, surtout si l’on compare aux autres solutions de middleware qui ont précédé les Web services comme DCOM ou CORBA (après tout, il ne s’agit que d’une RPC légère reposant sur XML) …

On assiste en ce moment à l’apparition d’une nouvelle offre de solutions mixant les avantages des Web Services, des connecteurs (comme JCA), des middlewares messages (comme JMS) et combinant le tout dans une infrastructure d’intégration et de gestion appelée ESB pour Enterprise Services Bus. 

D’une mentalité de Nomades à une mentalité de bâtisseurs…..

Certaines entreprises disposent de systèmes d’information formés d’un empilement « au fil de l’eau » des applications. Elles se sont construites au fur et à mesure, les interfaces, non normalisées, se sont développées spécifiquement et propagent au lieu de les absorber, les contraintes d’évolution, rigidifient et fragilisent le SI. Il n’y a pas d’infrastructure cohérente. Ce type de SI est présent surtout dans les banques.

La problématique qui se pose alors est la suivante : « comment continuer à faire évoluer le système » ?

Par contre d’autres entreprises ont un SI présentant des applications développées sans souci de communication. Ce type de SI est un modèle que l’on pouvait voir dans les grands systèmes hospitaliers par exemple (un malade peut être connu du service administratif mais pas du service qui va le soigner). Faire évoluer le système est là aussi compliqué : des données sont répliquées, il faut de plus faire communiquer les systèmes entre eux.

On pouvait aussi rencontrer certains SI ou les applications communiquent. Ceci dit, le SI n’est ni homogène (il n’y a pas d’infrastructure fédératrice, les différents systèmes composants sont restés tels quels, développés avec des outils différents par exemple), ni structuré (la réflexion n’est pas menée d’après les composants du système d’information dans une étude d’architecture globale).

Pour résumer, les DSI sont dans la situation suivante : il n’est plus possible de faire évoluer le système sans le reconstruire et refondre le système dans le contexte que nous venons d’évoquer devient impossible pour des raisons de :

  • complexité : « la complexité fait qu’on a du mal à en contrôler l’avancement, et à réunir les équipes compétentes nécessaires, ce qui oblige à faire largement appel à la sous-traitance et rend plus problématique encore la maîtrise globale. »
  • délais
  • coûts

Il faut savoir que la valeur ajoutée d’une refonte totale de système est marginale. On estime à seulement 20% la part du système totalement repensé, le reste (80%) étant refait à l’identique. Par contre le risque pris lors d’une telle transformation et le coût portent sur les 100% du projet. Rappelons que les directions informatiques sont alors liées à leurs constructeurs et veulent sortir de ces monopoles, reprendre les rênes de leurs solutions informatiques.

Aujourd’hui, les enjeux pour les DSI sont alors les suivants :

  • Comment continuer de faire évoluer le système dans la maîtrise des coûts et de délais ?
  • Comment le faire en concentrant l’effort sur les parties à plus forte valeur ajoutée ?
  • Comment, dans le même temps se libérer du joug des gros constructeurs ?

Ne faudrait-il pas que les informaticiens « passent d’une mentalité de Nomades à une mentalité de bâtisseurs ? »

BPM/Urbanisation du SI : faut-il modéliser l’existant ?

Vous connaissez peut-être le principe de Peter. En résumé, c’est un principe qui dit que chaque personne tend à s’élever jusqu’au poste où elle est incompétente. L’une des variations de ce principe s’appelle l’incompétence par l’informatique et dit que :

  • quelqu’un d’incompétent ne deviendra pas compétent si on lui colle un ordinateur,
  • quelqu’un de compétent peut devenir incompétent avec un ordinateur.

Au delà du clin d’œil et pour revenir au sujet, l’ordinateur ou l’outil de modélisation ne fera qu’amplifier vos choix, fussent-ils bons ou mauvais. C’est pourquoi, le périmètre d’un projet processus ou d’urbanisation du SI est aussi important que la méthode qui sera utilisée pour décrire ces éléments dans le référentiel : il cadre le projet.

L’un des premières et inévitables questions concernera l’existant, le patrimoine (legacy) : faut-il le modéliser ? Faut-il capturer son fonctionnement, son essence ?

Il n’y a pas de réponse universelle car la question est trop générale.

Les mauvaises raisons pour modéliser l’existant

  • Créer une documentation (temps passé*taux d’utilisation de la documentation = quelque chose proche de 0)
  • Comprendre l’existant (question trop vague, particulièrement côté IT)
  • Démontrer la capacité de l’outil (c’est l’éditeur qui sera content)
  • Démontrer l’intelligence de l’équipe de modélisation (c’est le consultant qui sera content)

N’essayez pas de faire bouillir l’océan !

Les bonnes raisons pour modéliser l’existant

  • Trouver une réponse à une question précise (confirmer/infirmer une hypothèse de la roadmap)
  • Préparer un changement sur un périmètre défini
  • Trouver un problème dans un domaine précis (diagnostique)

Savoir pourquoi on le fait

Le fait de disposer d’un patrimoine ne signifie absolument pas qu’il doit être modélisé. Il n’y a donc aucun impératif naturel à modéliser l’existant dans le seul but d’immortaliser son existence !

Comme pour n’importe quel projet de modélisation, sans objectif vous êtes condamné à modéliser trop en détail ou trop peu tout ceci pendant trop de temps. Si vous ne savez pas pourquoi vous le faites, vous ne saurez pas quand vous arrêter.

Un tel projet peu être catastrophique : dépense d’énergie et de ressources importantes, perte d’intérêt voir défiance envers le fait même de modéliser.

Il faut donc savoir pourquoi on le fait. Il y a de bonnes chances qu’un tel projet soit lancé pour apporter des réponses nécessaires à quelqu’un dans l’entreprise. Trouvez-le !

Être méthodique

Partir sur de bonnes bases est essentiel. Si un projet démarre sur de mauvaises suppositions, tous les modèles vont être influencés par ces suppositions.

Définissez ce que vous cherchez

Partant de la question de départ, il y a généralement 2 possibilités :

  1. la réponse n’est pas identifiée
  2. il y a une début de réponse mais elle est si incertaine ou imprécise que l’information n’est pas utile

Se laisser du temps

La modélisation en général est un travail itératif : la bonne réponse n’arrive que très rarement dès la première fois. La modélisation de l’existant l’est tout autant et le fait de s’attaquer à quelque chose d’existant ne facilite par le travail de modélisation pour une raison simple : la réalité est souvent beaucoup plus complexe que ce que l’on aurait décrit dans un modèle cible (donc n’ayant pas encore de réalité). La réalité n’apparaît jamais en une seule fois dès le premier modèle.

La modélisation de l’existant crée une charge supplémentaire qu’il ne faut pas négliger : celle de la mise à jour.  Chaque modèle devra être surveillé par un responsable afin d’être certain que le modèle décrit toujours la réalité. Un modèle dépassé perd beaucoup de sa valeur (voir toute sa valeur).

En clair, si vous voulez définir un To Be (votre cible), il est préférable d’avoir un As Is (existant) pour mesurer la différence et surtout pourvoir l’expliquer aux équipes qui exécutent le processus : « Qu’est-ce qui va changer ? ».

Cela permet aussi d’affiner ses réponses concernant la faisabilité de l’objectif et la probabilité de l’atteindre.

Modéliser l’existant est donc parfois nécessaire. N’ignorez pas la charge implicite que cela amène sur les épaules des responsables de processus.

Tagué