Archives du mot-clé Orientation service

Gérer la complexité des SI

Une complexité croissante

La complexité est au cœur des systèmes d’information (SI) d’aujourd’hui. On ne peut que constater que les grandes organisations ont à gérer des SI de plus en plus vastes et hétérogènes à tout point de vue : des centaines d’applications, des milliers de serveurs, des centaines de milliers d’échanges et de transactions, des utilisateurs de plus en plus nombreux et répartis sur la planète, qu’ils soient collaborateurs, partenaires, clients ou fournisseurs. La pression des évolutions imposées aux entreprises, l’intégration toujours plus forte des processus intra et inter entreprises et la poussée de la dématérialisation dans tous les domaines de l’économie ne font qu’accélérer ce phénomène et confèrent un rôle de plus en plus critique au SI. L’accroissement inexorable du périmètre du SI s’accompagne mécaniquement d’une concentration des risques et des enjeux portés.

Les effets néfastes de cette complexité sont multiples et la cause profonde de beaucoup des difficultés dans la gestion du SI sur de nombreux plans comme la gouvernance de l’urbanisme du SI, la maîtrise de l’intégration des grands projets d’évolution, la maîtrise des coûts informatiques et de leur refacturation aux clients métier, la gestion des performances et de la disponibilité, la gestion des risques techniques, la sécurité, etc. La complexité rend en effet très délicat le traitement de ces problématiques transverses.

Tous les SI importants font aujourd’hui face à des difficultés croissantes pour maîtriser les coûts et les risques tout en apportant satisfaction aux besoins métier dans des délais raisonnables. Il n’est pas rare de constater que de petites structures agiles réagissent de manière plus adaptée, plus rapide et finalement plus efficace que de grandes structures dotées de plus de moyens. La complexité s’avère souvent un obstacle aux fameuses économies d’échelle promises par tous les projets de mutualisation, centralisation, ou externalisation des moyens informatiques.

Caractérisation de la complexité des SI

Avant tout, il faut mieux définir ce qui caractérise la complexité d’un système en général et la complexité d’un SI en particulier. Bien qu’il n’en existe pas de définition objective et formelle qui fasse consensus, notamment dans le domaine des SI, plusieurs éléments clés caractérisent un système complexe :

  • en premier lieu, la taille du système rapportée à ce qui finalement est la métrique la plus naturelle : le temps pris par un humain à le décrire, le spécifier ou le construire. Un « petit » système ne peut pas être complexe. Pour un SI, cette taille se mesure en nombre d’applications, de tables de données, de flux, etc.
  • l’impossibilité (ou à tout le moins la très grande difficulté) à subdiviser ce système en sous systèmes plus petits sans introduire un nombre de liens entre ces parties qui ne croisse plus vite que leur nombre (de manière quadratique typiquement). Pour un SI c’est la difficulté rencontrée à isoler des sous ensembles pertinents du SI pour le découper en éléments plus simples : processus, domaines, applications, infrastructures, etc.
  • le couplage « in-démêlable » de toute partie du système avec les autres et l’action indirecte et mal maîtrisée qu’elle peut avoir sur d’autres parties avec lesquelles elle est connectée même indirectement. Dans un SI, ce couplage est porté par les interfaces entre applications, par les moyens mutualisés d’infrastructure, par les données partagées de manière transverse, etc. En dépit des promesses de la SOA (Service Oriented Architecture), la gestion des évolutions relève souvent du casse tête avec des coûts et des délais qui ne sont plus en proportion avec la valeur des changements apportés.
  • l’hétérogénéité forte, voire l’incohérence des parties entre elles qui rend impossible l’application de règles ou d’opérations communes à toutes les parties. Au niveau d’un SI cette hétérogénéité se constate sur tous les plans : organisation et processus métier, données partagées, architectures applicatives, langages de développement,
    infrastructures, etc… Cette hétérogénéité se paye à toute action globale sur le SI : les économies d’échelle de mutualisation/industrialisation se transforment alors en surcoûts par rapport à une action strictement locale et spécifique sur chaque élément.
  • l’impossibilité de prévoir le comportement ou de tester le système dans son ensemble par rapport à l’ensemble de ces cas potentiels de fonctionnement et encore moins de dysfonctionnement. Cette impossibilité est la conséquence directe des éléments précédents qui vient de l’explosion combinatoire de ses états possibles. Au niveau SI, cette incapacité se traduit par la multiplication des incidents et problèmes (au sens ITIL) et la grande difficulté d’intégration de grands projets.

Les « fausses bonnes idées » pour résoudre la complexité des SI

Il y a quelques mirages récurrents et souvent dangereux sur les moyens de résoudre ces problèmes liés à la complexité des SI. Si ces idées apportent des éléments de réponse, elles sont souvent très dangereuses à considérer comme des solutions « magiques » en tant que telles, car elles sont toutes myopes aux phénomènes systémiques de la complexité et finalement en nient le caractère profondément structurel :

  • Le « top down » comme moyen de pilotage ou de gouvernance unique : à l’image des démarches en V classiques rassurantes qui partent d’un besoin et aboutissent à une solution technique, il y a le rêve de pouvoir appréhender de manière hiérarchisée et descendante un SI dans son ensemble. Ce serait possible si justement le SI n’était pas complexe et se prêtait à une description hiérarchisée, si ce n’est unique, au moins complète et représentative de l’ensemble de la complexité. Il est possible heureusement de gouverner un SI, mais rarement par un seul point de vue, fût il aussi prégnant que celui des coûts, des besoins métier ou des risques.
  • La centralisation, notamment autour d’un outil : un autre moyen de contrôle souvent préconisé est la mise en place d’un outil fédérateur et central qui permettrait de gérer et de piloter l’ensemble. Qu’on parle d’outil de CMDB (inspiration ITIL), d’outil de cartographie ou de solution d’intégration centralisée (EAI, ESB…) par exemple, le biais reste le même : l’idée d’un point fédérateur unique qui réussirait à capturer la complexité et à la gérer. L’expérience est plutôt que pour ce type d’outil, plus son périmètre est large, plus il est délicat à mettre en place et surtout quasi impossible à maintenir. Le fait est que cet élément central, qui
    cherche à capturer un objet d’une très grande complexité, se trouve lui même empêtré dans cette complexité, et à un degré de contraintes supérieur encore, parce que centralisé et donc très fragile. L’effort de sa maintenance s’avère finalement très souvent inférieur aux bénéfices réels qu’il apporte.
  • L’uniformisation comme solution ultime à tous les problèmes de complexité. L’industrie a répondu à la problématique de la gestion des processus complexes par une très forte normalisation et le travail en « séries » très homogènes. Si beaucoup de bénéfices sont à attendre d’approches de normalisation, le SI se trouve confronté à la réalité opérationnelle et humaine d’un SI structuré en strates hétérogènes historiques et technologiques qu’aucune volonté ne peut faire converger complètement à un instant donné. L’exception à la norme résiste au changement par le poids du patrimoine et s’introduit dans les nouveaux projets par le biais des nouvelles technologies, de nouveaux types de besoins ou de solutions progicialisées au socle incompatible avec les choix communs. Les opérations de fusion/acquisition entre sociétés rendent encore plus aléatoires les possibilités d’uniformisation. Enfin, traiter uniformément tous les éléments du SI strictement avec les mêmes normes amène à des solutions, lourdes, coûteuses et pas toujours adaptées aux attentes.
  • La transformation globale du patrimoine vers une cible idéale et enfin
    urbanisée. Toutes les initiatives qui constituent un choc sur le patrimoine et qui ne laissent pas la place à une trajectoire de convergence flexible et potentiellement partielle, sont vouées à l’échec. Pour deux raisons majeures : d’une part, un système complexe réagit de manière très violente et inattendue à une transformation trop rapide ou trop globale, et ce principalement parce que les impacts des changements importants ne peuvent pas réellement être maîtrisés dans un système complexe. D’autre part, la dimension temps est un facteur qui est un frein très direct aux transformations rapides : tout changement profond sur un SI complexe, que ce soit au niveau métier ou technique, prend un temps incompressible lié à son déploiement. Même des transformations relativement innocentes et apparemment simples comme le changement d’infrastructures de stockage ou de stratégie d’hébergement physique sont à mener en étapes progressives et en tout cas par étapes maîtrisées. Et la longueur de la trajectoire rend particulièrement incertaine cette fameuse cible globale initialement pensée comme idéale : la cible bouge finalement plus vite que la trajectoire…

Une décentralisation nécessaire

Ces approches font toutes plus ou moins l’hypothèse que la complexité est le fruit d’une histoire passée qu’il convient de redresser ou de corriger et recherchent une solution pour reprendre un contrôle central de l’ensemble. Le fait est que la complexité résiste à toute approche globale si celle ci n’est pas structurellement décentralisée. Autrement dit, les seules méthodes qui fonctionnent sont celles qui développent des caractéristiques locales au niveau des composantes élémentaires du SI et qui confèrent de manière systémique des caractéristiques intéressantes et vertueuses » à l’ensemble. Les éléments centraux, pour être nécessaires et utiles doivent rester extrêmement simples et robustes aux changements de toute nature.

Mais pour l’essentiel, un système complexe doit être décomposé en sous ensembles les plus découplés possibles entre eux. C’est la force clé attendue d’une approche décentralisée : la résolution des problèmes doit pouvoir être locale à chaque partie du système, et ainsi porter sur des sous ensembles moins complexes. La décentralisation doit minimiser les interactions, les interdépendances et les couplages entre les parties, pour permettre cette action locale, autonome, et adaptée au besoin. La difficulté réside finalement dans la qualité de ce découpage, qui n’est hélas pas naturel et surtout pas homogène selon les différentes facettes du SI. En fait, il n’existe pas un découpage unique. Il existe plutôt plusieurs découpages qui se superposent à la réalité du SI sur ses différents plans, des plans métiers et fonctionnels, aux plans des infrastructures et de l’exploitation.

L’approche enioka

Pour structurer son action et sa réflexion sur les systèmes complexes avec ses clients, enioka fonde son approche sur quatre éléments clés :

  • L’identification et la formalisation de plans ou points de vue du SI : pour percevoir un système complexe, il faut l’observer à travers des projections sur différents plans qui sont des points de vue du SI. Ces « plans de coupe » du SI permettent des analyses simplifiées focalisées sur des objectifs portés par différentes parties de l’organisation de la DSI, un peu à la manière d’une radiographie ou d’un scanner. Ces plans masquent certains aspects de la complexité pour se focaliser sur certains objectifs, comme le coûts, la sécurité, l’urbanisme, les infrastructures, l’exploitation, etc. Chacun de ces points de vue n’a pas besoin de traiter la complexité des autres points. Mais cette segmentation en points de vue se doit d’être cohérente et de ne pas introduire de biais dans les raisonnements.
  • La modélisation du SI : la difficulté rencontrée dans l’analyse et la maîtrise des systèmes complexes vient avant tout d’un manque de modèles formels du SI qui permettent de raisonner efficacement sur le SI par des vues simplifiées adaptées à certains types de questions sur le SI. Le pluriel à modèleS est volontaire, car il n’est pas à notre sens possible ni même intéressant de construire un modèle unique, central et uniforme du SI qui permettrait de répondre à toutes les questions sur la complexité du SI. Les modèles doivent être adaptés pour répondre à des questions concrètes ou comme support à une politique de gouvernance sur les différents plans et points de vue du SI… Ces modèles doivent être faiblement couplés entre eux mais fédérés autour de quelques notions pivot communes comme celles d’application, de flux, de service, etc. Ces modèles doivent en outre être déployés en fonction des objectifs et non de manière uniforme et systématique. Par exemple, on peut très bien avoir deux niveaux de modélisation de l’intégration des applications selon leur complexité et leur criticité : un niveau commun très simple pour le pilotage du patrimoine et un niveau fin réservé aux objets et processus critiques du SI.
  • L’approche service : une forme de modèle très générale et très puissante est la notion de service. Ce principe consiste à identifier des services généraux réutilisables et à en masquer l’implémentation aux clients par des interfaces formelles et abstraites. L’identification des services est une véritable démarche marketing d’analyse du « marché » des besoins et de promotion de solutions partagées (qui s’opposent souvent à l’axe « local » des projets métier).Cette démarche se décline sur les différents plans du SI, qu’il s’agisse de l’urbanisme, du développement ou des infrastructures ou de l’exploitation. De plus, cette vision de service est très utile comme support à la décomposition normalisée d’un SI complexe en éléments simples, et structurellement plus homogènes. Enfin, l’approche service permet à la fois d’unifier sans uniformiser : un même « service » peut être implémenté de différentes manières selon les cas d’usage. enioka s’attache notamment à développer un modèle des services du SI, structuré en différents plans de service, des infrastructures aux services applicatifs et métier.
  • La définition de trajectoires d’évolution : on raisonne trop sur la cible et pas assez
    sur le chemin qui y mène. Très souvent le chemin dicte des contraintes déterminantes sur la cible. Et comme on l’a vu, le chemin étant souvent long pour les projets de transformation significatifs, la cible « désirable » peut évoluer beaucoup au fil du parcours. Une bonne cible est avant tout une cible avec une trajectoire robuste aux événements inattendus, qui fait intelligemment levier sur les évolutions majeures et les grands projets incontournables pour porter les transformations systémiques. Enfin, la trajectoire elle même doit être modélisée
    et suivie pour être réactualisée.

L’ambition d’enioka à travers son activité et plus spécifiquement au travers de ce blog, est de contribuer de manière très concrète au développement de ces différents modèles du SI et d’en décliner l’usage à travers la réponse à des questions très opérationnelles sur les coûts, sur les analyses de risque, sur la maîtrise du niveau de service, sur la maîtrise du patrimoine applicatif et technique, etc. enioka développe en outre un outillage de modélisation permettant de supporter ces différents modèles et de collecter les informations déjà existantes dans le SI, qu’il s’agisse de référentiels du SI ou de sources de métriques adossées à ces référentiels. A travers ce blog, au fil des mois, nous tenterons de partager nos réflexions sur les différents aspects de la complexité autour de thèmes comme : l’industrialisation des processus, les normes et standards techniques, l’intégration des grands projets applicatifs, la gouvernance opérationnelle des flux, l’urbanisation des référentiels de l’entreprise, la maîtrise des coûts récurrents et notamment de licence, etc.