Archives pour la catégorie enioka

Benchmark de l’Open Source dans les grandes sociétés

enioka a réalisé un benchmark de l’usage de l’Open Source dans les grandes entreprises Françaises. Les équipes informatiques de 8 grandes sociétés représentatives (dont la moitié font partie du CAC 40) ont été contactées dans différents secteurs d’activité :

  • Télécom,
  • Agribusiness,
  • Médias,
  • Institution Financière publique,
  • Transports,
  • Banques (x2),
  • Grande Distribution.

Voici les thèmes abordés dans ce benchmark :

  • Quel est votre usage de l’Open Source ?
  • Quels sont les modèles de support ?
  • Comment gérer la contribution ?
  • Quelles sont les motivations pour utiliser de l’Open Source ?

Ce benchmark s’appuie sur des sociétés représentatives et donne donc une illustration de la perception de l’Open Source en France par ces grandes entreprises. L’échantillon utilisé ne permet toutefois pas de généraliser ces informations. Les informations données ici sont le reflet et les opinions de ces sociétés, rien de plus.

Le terme Open Source est utilisé en lieu et place de Logiciel Libre car c’est ainsi que ces sociétés le désigne. En pratique, le coté Libre est en fait un critère plus important que l’on pourrait l’imaginer au premier abord pour ces sociétés.

Usage : un effort général vers l’Open Source

100% des participants disent qu’ils ont une approche Open Source first, c’est à dire que pour un nouveau projet, un composant Open Source est toujours privilégié en priorité, et qu’il faut argumenter pour utiliser un composant propriétaire à sa place.

L’étude a aussi montré deux catégories de systèmes d’information :

  • la partie IT de gestion pour les fonctions support (finance, RH, …) utilisant principalement des progiciels propriétaires ;
  • la partie informatique métier, plus souvent développée en interne, principalement construite sur un socle Open Source.

Les trois quarts des sociétés envisagent des composants Open Source pour réduire l’empreinte du propriétaire dans leur système d’information dans l’année à venir

La moitié des sociétés ont une stratégie qui encourage l’Open Source depuis plusieurs années (3 à 8 ans)

Analyse des modèles de support : un modèle de support ne peut couvrir tous les cas

La plupart du support est fait en interne. Chaque société possède des experts techniques en interne formés aux technologies Open Source choisies. Comme l’Open Source tend à faciliter le support en propre sur les composants logiciels, les experts en interne se révèlent souvent être le meilleur modèle de support disponible.

Les services professionnels de support sont chers, rarement utilisés, mais valent le prix dans les cas extrêmes d’urgence. Les sociétés qui font appels à des services professionnels de support sont d’accord pour dire qu’elles utilisent très peu leur abonnement à ce service. Elles ont néanmoins indiqué que cela les avait sauvé plus d’une fois. Il s’agit plus d’une assurance qu’autre chose, permettant aussi une transition plus aisée depuis un modèle propriétaire.

Le modèle de support communautaire et des distributeurs est envisagé dans le cas de composants simples ou maîtrisés. Les services de support professionnels ou de l’éditeur sont préférés pour les composants critiques.

Contribution et gestion des licences : des processus inexistants ou trop lourds pour être appliqués

Toutes les sociétés distribuent des logiciels à leurs clients avec des composants open source (applications web et mobiles principalement). Mais uniquement deux sur huit ont un processus de revue des licences formalisé.

100% des participants estiment que s’il n’existe aucun processus formalisé, ou si celui-ci est trop lourd, alors les équipes contribuent régulièrement en leur propre nom, sans aucun contrôle ni validation.

La contribution publique est encore une pratique peu représentée, bien que tous les participants soient d’accord sur les bénéfices techniques et opérationnels apportés quand ils ont contribué.

Différents niveaux de validation sont nécessaires pour garder le contrôle sur les contributions. Les profils Open Source ont la contribution dans leur ADN, et s’ils ne sont pas autorisés à contribuer ou si c’est trop compliqué, ils vont trouvés d’autres moyens (la contribution fantôme), mais les bénéfices en sont réduits et cela pourrait même induire des risques.

Motivations : l’Open Source permet aux sociétés de reprendre le contrôle de leur exploitation et du déploiement

100% des participants reconnaissent que le principal inducteur pour l’Open Source est l’agressivité de la politique de licence des logiciels propriétaires.

À égalité avec le coût, c’est l’absence ou la limitation du verrouillage qui motive les grandes entreprises à réaliser des choix stratégiques d’adoption des logiciels libres.

Quelques domaines métiers verrouillés par des mainframes sont les derniers bastions résistant à l’Open Source. Exception faite de ces systèmes, en particulier au coeur des grands systèmes bancaires, l’Open Source est le bienvenu dans tous les domaines.

Les meilleurs profils Open Source sont dur à trouver… et dur à garder. Les experts dans l’Open Source partiront s’ils n’ont pas assez de liberté (pas de droit de contribution, pas de droit d’exploitation), ou si le modèle opérationnel est trop rigide.

Le développement et l’exploitation avec des équipes internes sont un des leviers principaux dans l’adoption de l’Open Source.

  • Les grands éditeurs ont tendance à ignorer les composants Open Source ;
  • Les équipes de développement internes sont partisanes des composants Open Source ;
  • Les fournisseurs de services d’exploitation (infogérance) de niveau 1 sont globalement défavorables à l’Open Source ;
  • Les équipes d’exploitation internes préfèrent les plateformes Open Source.

L’Open Source est maintenant globalement accepté comme un acteur à part entière dans les environnements de production dans la plupart des secteurs d’activité.

La nature ouverte de l’Open Source entraîne un regain d’intérêt des équipes exploitation sur leurs plateformes. Les logiciels Open Source leur permettent d’être assez agile pour répondre aux challenges apportés par l’innovation, tout en répondant aux enjeux de Time-to-Market.

Retour d’expérience

Voici les principaux retours d’expérience que ces grandes entreprises partagent après leur adoption de l’Open Source.

Les communautés Open Source doivent être auditées. Les communautés sont un des piliers fondamentaux des logiciels Open Source, et doivent donc à ce titre être auditées comme le serait n’importe quel fournisseur de solution logicielle propriétaire.

Les experts dans le monde propriétaire deviennent de bons experts de l’Open Source. La transition n’est pas toujours facile, mais généralement les experts du monde propriétaire évoluent rapidement vers une position d’expert du monde Open Source sur  le même domaine.

Les licences doivent être auditées. Bien que les licences Open Source ne soient pas en général un problème, un projet peut parfois être amené à utiliser une licence plus restrictive, qui impacterait l’utilisabilité du logiciel dans un environnement professionnel.

Les personnes contribuant en leur nom propre sont courtisés par les autres sociétés. Des contributions Open Source rendent visibles les meilleurs profils, ils seront alors très naturellement approchés par de nombreuses autres sociétés.

L’implication dans les communautés Open Source est un bon investissement :

  • capitalisation sur les compétences techniques ;
  • développement personnel des employés ;
  • incidence positive sur le recrutement.

Pour un urbanisme concret

L’urbanisme est un gros mot. Après avoir volé le mot architecte au génie civil, pourquoi s’arrêter en si bon chemin ? Au delà d’une définition pas toujours évidente d’un terme très français (les anglo-saxons parlent d’Enterprise Architecture), c’est d’abord beaucoup de théorie… mais un cruel manque de pratique.

L’échec (relatif) de l’urbanisme des SI peut être expliqué par plusieurs facteurs :

  • Les urbanistes sont souvent très éloignés des réalités du SI et des projets. La littérature est plutôt bien fournie… mais délicate à appliquer. La plupart du temps, c’est l’architecture transcendantale qui prévaut, au détriment de l’expérience et la pratique ;
  • Les urbanistes ont en général une faible culture technique qui les poussent à faire du top-down au mépris des réalités techniques. On cherche ainsi un découpage du SI avant tout guidé par un découpage fonctionnel, lui-même calqué sur une organisation ou la représentation à date de la chaîne de valeur de l’entreprise ;
  • La recherche de la cible idéale (et idéalisée) passant par des transformations big-bang (qui se soldent souvent par des big-crash) au lieu de privilégier des transitions douces et flexibles ;
  • Les vraies questions d’urbanismes (nous essaierons d’en poser quelques unes ci-dessous) sont souvent rapidement abandonnées au profit des projets phares des urbanistes : mettre en place un MDM ou un ESB ou les deux à la fois. L‘outil magique comme réponse à un problème…
  • L’intérêt court terme d’un projet (budget, planning et réponse à un périmètre circonscrit) n’est pas toujours compatible  avec la feuille de route d’évolution du SI imaginée par les urbanistes.

L’attitude la plus fréquente face à cela est d’ignorer les urbanistes ou tout du moins ce qu’ils disent et écrivent. C’est ce que font la plupart des directeurs de projets afin de préserver leur projet. On les comprends !

Les urbanistes restent trop souvent dans leur tour d’ivoire et, au mieux, cartographient le SI (à l’échelle 1:1 de préférence !), mais n’ont pas de réelle influence sur l’organisation du SI.

À défaut d’enlever les taches, au moins, les urbanistes n’abiment pas le linge

L’alternative est de promouvoir un urbanisme plus simple, plus concret et plus appliqué. Loin des salons et plus près des projets et des architectes applicatifs et techniques. Esquissons les contours ce que pourrait être cet urbanisme concret.

À quoi sert l’urbanisme ?

Dans ce contexte, on peut se demander à quoi sert l’urbanisme… Les besoins sont pourtant véritables, et répondent à des problématiques très concrètes. On peut distinguer quatre objectifs majeurs :

  1. Donner une visibilité globale du SI à tous les acteurs pour améliorer leur efficacité collective en explicitant les principaux processus, fonctions (hiérarchisées et regroupées), les applications, les données et les flux du SI.
  2. Permettre au SI d’obtenir des qualités globales et transverses sur différents plans :
    • Alignement aux besoins métier de « bout en bout »
    • Cohérence transversale des données et des processus
    • Efficacité dans la durée
    • Agilité aux évolutions
  3. Faire contribuer les projets à la dynamique d’ensemble en orientant les choix projets vers des décisions cohérentes.
  4. Aider à arbitrer les choix ou décisions en identifiant toutes les options, avec une meilleure visibilité sur leurs conséquences, court/moyen/long terme.

Il faut faire des choix…

L’urbanisme n’a pas de réponse absolue à des questions absolues. La plupart du temps les choix d’urbanisme sont à faire entre plusieurs options réellement possibles.

L’urbanisme vise à remettre les choix unitaires des projets en perspective de la globalité du SI. Les choix principaux d’urbanisme jouent typiquement sur :

  • Le niveau de partage des processus et des données entre organisations
  • La décomposition du SI en applications
  • L’allocation des fonctions aux applications
  • Le niveau de partage des applications entre organisations
  • Les processus de gestion et de diffusion des référentiels
  • La duplication (ou non) d’informations entre applications
  • Les flux d’échange et/ou de synchronisation de données entre applications

Les choix d’urbanisme ne sont ni des choix fonctionnels, ni des choix d’organisation, même s’il peut il y avoir un lien.

… guidés par certains principes…

Les choix d’urbanisme doivent pouvoir s’appuyer sur des règles d’urbanisme (ou plus généralement SI) partagées, compréhensibles et largement reconnues. L’objectif de ces principes est d’expliciter les règles souvent implicites qui gouvernent le fonctionnement du SI.

Le SI peut ne pas avoir d’urbaniste, il y a toujours un urbanisme. Plus ou moins spontané, plus ou moins anarchique, mais le résultat est là : les projets construisent et transforment des briques applicatives et techniques qui façonnent le SI. Le rôle de l’urbaniste est de mettre en lumière ces règles et principes, les rendre visible, faire prendre conscience aux parties prenantes des clés d’arbitrage.

Certaines de ces règles sont d’ordre générales et applicables à tous les domaines, notamment :

  • Règles de découplage et de modularité du SI
  • Règles de gestion des référentiels
  • Règles d’intégration des applications

D’autres règles résultent de choix d’urbanisme spécifiques sur des périmètres fonctionnels qui peuvent être plus variables dans le temps, par exemple :

  • Règles définissant les objets structurants du SI (données, domaines, etc.)
  • Règles identifiant les applications maîtresses des principaux objets du SI
  • Règles spécifiques entérinant des arbitrages passés

Ces règles ne sont pas absolues et peuvent, pour des raisons tactiques ou stratégiques, être enfreintes. Il s’agit de guides plutôt que de limites. Enfreindre ces règles indique simplement qu’il faut être en mesure de justifier et motiver son choix.

Enfin, et surtout, ces règles doivent s’enrichir et évoluer avec le SI et son environnement.

… et bâtis sur des modèles

Pour raisonner efficacement sur le SI et être en mesure de l’appréhender de manière globale, il faut s’appuyer sur un modèle simplifié du SI. Ce modèle traite de plusieurs plans dont les principaux sont :

  • Plan métier : quels sont les processus métier ? quelle est la chaîne de valeur de l’entreprise ?
  • Plan fonctionnel : quels sont les fonctions rendues par le SI pour supporter ces processus ? Comment organise-t-on ces fonctions en domaines ? Quels sont les objets métiers manipulés ? Selon quelles facettes ?
  • Plan applicatif : comment sont implémentés les fonctions du SI ? Quelles sont les applications du SI ? Comment sont-elles déclinées sur un périmètre ? Quelles données échangent-elles ?

Ces modèles doivent avoir des représentations et une structure permettant de communiquer sur l’organisation du SI à tous les acteurs impliqués dans sa transformations, du développeur au management, aux métiers en passant par les équipes de production.

 

Projets et urbanisme

L’urbanisme devrait être le plus possible porté par les projets. Ces derniers restent les meilleurs vecteurs de transformation du SI et donc de l’évolution de l’urbanisme du SI.

Souvent, les grands projets portent intrinsèquement des transformations structurantes du SI.  L’urbaniste doit savoir surfer sur ces grandes évolutions du SI.

Il peut parfois être nécessaire d’investir dans le cadre d’un projet métier au-delà de ses besoins propres et court terme pour constituer un bien commun plus large.

Une approche d’urbanisme doit favoriser ces investissements sans plomber les projets.

Il s’agit alors d’entrer dans un cercle vertueux à chaque projet : l’approche d’urbanisme sera d’autant plus efficace si la transformation s’opère étape par étape, du moment que ces états intermédiaires sont suffisamment stables. Il ne s’agit donc pas d’imposer des arbitrages par une réponse absolue, mais de remettre en perspective les choix des projets dans la globalité du SI : il convient alors de convaincre et de séduire les projets du bien fondé de cette démarche. C’est finalement une approche d’amélioration continue, avec ses bons côté (les améliorations des uns profitent aux autres projets et vice versa), mais qui possède son pendant vicieux bien connu : chaque projet porte alors le fardeau des prédécesseurs.

Quelques exceptions toutefois : il peut être nécessaire, à moyen/long terme, de faire des investissements transversaux que les projets métier ne peuvent pas toujours (planning…) ou ne doivent pas (indépendance…) porter. Par exemple des services d’intégration transverses, des référentiels, des services décisionnels…  Idéalement, ces investissements doivent pouvoir être valorisés par des projets métier bien identifiés qui en seront les clients et bénéficiaires à chaque étape. Il ne s’agit donc pas d’être en dehors des projets mais transverse aux projets.

Comment faire ?

L’urbanisme est avant tout un processus de réflexion transversal. Ce processus a besoin d’éléments partagés qui supportent de manière opérationnelle les choix :

  • Un référentiel qui décrit l’existant du SI (modèle)
  • Une cible et une trajectoire d’évolution qui définissent les orientations d’évolution du SI à 2/3 ans
  • Un guide d’urbanisme qui explicite les principes d’urbanisme partagés et les choix faits qui expliquent la trajectoire
  • Une organisation opérationnelle qui permette aux projets de construire leur trajectoire en cohérence avec celle du SI et aux responsables de domaines (métier et applicatif) de piloter les évolutions SI et amender la cible et la trajectoire

Il est essentiel que les urbanistes acquièrent non seulement une bonne compréhension du métier mais aussi de la technique (développement, système, exploitation…). Sans cette clé technique de compréhension du SI, le dialogue avec les équipes de développement et de production restera en grande partie stérile et les plus belle idées d’urbanismes conduiront à des catastrophes.

Le bon sens est trop souvent négligé par des urbanistes, on les caricature souvent comme des monarques un peu éloignés des réalités du SI. Au delà de toutes les méthodes, démarches, modèles d’urbanismes etc., il faut savoir viser la simplicité et faire preuve de pragmatisme. Les SI actuels sont déjà des monstres de complexité. Un urbaniste et architecte talentueux ne se distingue pas en construisant un énième composant tapageur dans le SI composé de toutes les dernières technologies ou principes à la mode mais en construisant quelque chose de simple, sobre et fonctionnel. La parcimonie n’est pas souvent à la mode chez les urbanistes, c’est pourtant un principe essentiel.

Pluralitas non est ponenda sine necessitate (G. d’Ockham)

En définitive, on voit que l’urbanisme tient plus à l’urbaniste qu’aux théories, concepts et autres éléments de littérature pourtant nombreux (Zachman, Togaf…) qui n’ont pas vraiment changé le monde, au contraire. C’est un constat amère d’un coté (tant d’énergie et de complexité pour en rester aux balbutiements) mais également porteur d’espoir : tout reste à construire, à reconstruire et à transformer.

Mesdames et messieurs les urbanistes, mettons nous au travail !

Quelle organisation autour de la Business Intelligence et du Big data dans les grandes entreprises ? (5/5)

Quels sont les enjeux de sécurité autour du BI ?

La donnée devient un élément de plus en plus critique pour la performance des entreprises. La donnée a de la valeur pour trois raisons :

  • parce qu’elle a une valeur intrinsèque monétisable qui mérite de la protéger (fichier client, ratios types,…)
  • parce que la diffusion de certaines données confidentielles est un facteur de risque élevé pour l’entreprise (ratios financiers, structure de coûts, marché, …) notamment vis à vis de la concurrence.
  • parce que la maîtrise et l’autonomie de l’accès aux données est un enjeu :  externaliser certaines données au risque d’en perdre l’autonomie de gestion et d’exploitation est un risque important qui peut entraver l’autonomie business.

Ces enjeux de sécurité méritent une gouvernance globale pour laquelle la DSI est probablement (avec son RSSI) la plus à même de mettre en perspective les risques et de prendre les mesures de protection adaptées. Cela peut se traduire par des actions internes sur la sécurisation des stocks de données mais aussi vis à vis de l’extérieur en veillant aux cadres contractuels et aux risques associés à l’externalisation de certaines données (et fonctions d’analyse associées).

Conclusion

Cet article était la conclusion d’une série de cinq articles sur l’organisation autour du BI dans les grandes entreprise (partie 1, partie 2, partie 3, partie 4).

En résumé, ce n’est qu’une cartographie des usages métiers, des enjeux associés, de leur portée (très locale jusqu’au très large) et des gains à attendre d’une mutualisation qu’on peut mettre en place une gouvernance alignée. Dans cette période de forte effervescence sur les sujets big data, cette gouvernance doit trouver un juste équilibre dans le temps qui créée un éco système favorable à l’émergence de solutions rapidement. Et se prépare à pérenniser, durcir et industrialiser ce qui mérite de l’être, et cela progressivement…

Quelle organisation autour de la Business Intelligence et du Big data dans les grandes entreprises ? (4/5)

Dans quelle mesure le BI est-il bousculé par les nouvelles technologies ? Au delà des apports technologiques, il y a un impact certain sur l’organisation.

Quel est l’impact du Big data sur les organisations ?

Le big data apporte finalement la promesse de l’analyse rapide de très grands volumes de données…

Le vrai big data (a contrario des déguisements de projet en big data pour surfer sur la mode) exige des architectures très nouvelles et des manières de les exploiter très différentes.

La logique n’est plus tant de construire des cathédrales décisionnelles qui vont durer 5 ou 10 ans que de monter des projets pour répondre à une question particulière, en acceptant que la solution ne durera peut être que 6 mois.

Il y a donc une vraie logique à accepter des expérimentations étroitement liées au métier et à des enjeux de certains domaines fonctionnels clés pour l’entreprise.  Expérimentations à mener au plus près des métiers dans des équipes fortement intégrées avec experts métiers, analystes de données spécialisés sur les méthodes et outils à employer dans le domains, équipes études et développement agiles avec une forte connexité métier, équipes techniques d’exploitation temporaire mais qui conservent un lien avec des équipes de production cibles (surtout si elles sont internes). L’objectif est d’incuber les solutions au sens large et de se préparer à internaliser une partie des compétences et des solutions si cela constitue de la valeur et un enjeu stratégique durable.

Quelles options prendre vis à vis du Cloud (IaaS,  PaaS, SaaS) ?

Le cloud fait partie d’une logique d’optimisation des infrastructures. Qui peut s’avérer indispensable dans une logique de réponse élastique aux besoins. Cela a du sens. Mais ne doit pas faire oublier la dimension stockage des grands volumes de données. Il ne s’agit (souvent) pas de cloud classique. Il doit être adossé à une solution de stockage performante (en volumétrie bien sur, mais aussi en capacité de traitement de flux et de montée en charge).

Le cloud spécialisé type cloud SAP HANA par exemple, est à prendre avec précautions. Cela peut être un kick starter efficace… Mais qui pose question sur la maîtrise du niveau de service, sur la sécurité et à terme sur la structure de coûts tout court… Il n’y a pas de solution magique. S’il faut vraiment des ressources informatiques, celles ci ne
seront pas gratuites…

Les solutions SaaS sous différentes formes sont des accélérateurs encore plus tentants. Ils permettent de s’affranchir de à la fois des infrastructures, mais aussi (en grande partie) des technologies voire des compétences… C’est également un accélérateur, et dans certaines niches une solution qui peut être pérenne. Mais la vigilance doit rester très importante sur les risques et les coûts. Et il est indispensable si de telles solutions au delà de premières expérimentations, deviennent des solutions stratégiques pour le fonctionnement de s’assurer auprès de la DSI que les compétences sont internalisées (même si la solution reste en SaaS).  Il faut impérativement que des sachants DSI soient en mesurer de challenger le fournisseur et veille à garantir des solutions de réversibilité dans la durée.

Le coût des performances

Après une première introduction à la problématique de la performance des SI, il est nécessaire de se préoccuper du coût des performances. La raison pour laquelle il n’y a pas de vérité absolue en matière de performance est que les trois points de vue essentiels à optimiser (le travail à effectuer, le temps imparti et les ressources utilisées) sont à équilibrer par rapport à des critères objectifs. L’un de ces critères essentiel est le coût. Ce n’est sans doute pas le seul critère (il y en a d’autres, comme la qualité de service, qui peuvent influer sur le comportement des utilisateurs ou des clients de manière indirecte), mais c’est en tout cas le plus objectif.

On distingue deux coûts à équilibrer : le coûts des ressources employées et le coût du temps consommé par le SI.

le coût des ressources employées.

Ce volet du coût est le plus simple à mesurer,  même si le plus souvent il ne l’est pas de manière satisfaisante :

  • ni complètement : le coût complet des ressources n’est pas si trivial à évaluer. Amortissement des investissements matériels, coûts de licence des logiciels, maintenance, opérations, coûts indirects de m2 ou de climatisation de  l’hébergement, etc.
  • ni analytiquement : quelle est la contribution de chaque fonction/usage au  coût des ressources ? La difficulté est à ce niveau double : avoir la capacité de tracer l’usage des ressources par les fonctions/utilisateurs et d’autre part discerner ce qui réellement dimensionne les ressources. Par exemple, un système peut être taillé pour supporter une activité transactionnelle de jour très lourde, et du coup, le coût de l’usage des (ou de certaines) ressources pour les traitements batch est sans influence sur le coût total.

le coût du temps consommé par le SI.

Il s’agit du temps pendant lequel les utilisateurs ou l’entreprise  ou les clients attendent ou travaillent à la place du SI. La valorisation de ce coût est très variable selon l’usage :

  • 10 secondes d’attente d’un utilisateur à chaque transaction représente peu si l’utilisateur utilise la fonction une fois par jour, beaucoup plus si l’utilisateur l’utilise
    des centaines de fois. Si très peu d’utilisateurs sont concernés, le compromis peut rester acceptable, surtout si la solution apporte par ailleurs des bénéfices.
  • En deçà d’un certain seuil (< 300 ms pour une fonction interactive par exemple) un gain de temps n’est plus pertinent, et ce surtout si ce gain correspond à une unité
    de travail de l’utilisateur naturellement associée à une rupture de charge (comme le passage à la facture suivante à traiter).
  • Le coût du temps est toujours délicat à valoriser. C’est une notion élastique qui est  souvent liée à l’organisation du travail ou du modèle d’activité de l’entreprise (selon le modèle d’activité, le temps de traitement SI est ou n’est pas un enjeu de compétitivité). Selon les activités il y a ou non des enjeux associés au temps de réponse ou au temps de traitement.
  • Il y a également quelquefois à considérer le coût d’un défaut de service : certains problèmes de performance (notamment lors de pics d’activité) peuvent créer une
    indisponibilité dont les conséquences financières peuvent être très graves.

Pour équilibrer ces coûts, un troisième coût est à prendre en compte : le coût d’optimisation ou d’alignement de la solution pour réduire l’usage des ressources et/ou réduire le temps de traitement. Ce coût est à considérer comme un investissement pour améliorer l’efficacité. L’optimisation suit souvent le principe de Pareto : 80% des
gains sont relativement faciles à obtenir mais les derniers 20% coûtent très chers à obtenir. Il faut donc toujours mesurer la valeur marginale des gains en comparaison des coûts engagés. Et les gains les plus forts ne sont pas toujours à attendre des investissements les plus lourds.

Cette approche de valorisation des coûts (et des bénéfices) du SI est d’ailleurs une approche d’analyse de la valeur qui va bien au-delà de la performance d’une application. Elle devrait s’appliquer comme dans l’industrie aux fonctions offertes par le SI aux utilisateurs comme moyen d’arbitrage des fonctions à implémenter dans le SI.

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.