Tous les articles par Jean-Christophe Ferry

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.

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

Dans un précédent article, il a été exposé les coûts et les bénéfices à vouloir mutualiser une démarche BI au sein de la DSI. Il s’agit maintenant d’aborder la facette organisationnelle de la question, en particulier dans le rôle de la DSI vis à -vis des entités métiers et l’organisation interne de la DSI.

Quelle doit être la proximité de la DSI auprès des entités métier ?

Sur l’axe des domaines fonctionnels : dans cette dimension du décisionnel, la DSI doit avoir une représentation métier forte. S’il y a une valeur à avoir une connaissance transversale des données de l’entreprise, celle ci est surtout une toile de fond. Mais il est de plus en plus essentiel qu’une cellule décisionnelle dans une DSI puisse parler des données de chaque domaine fonctionnel et parfaitement maîtriser le fond des indicateurs ou des chiffres et analyses qu’on peut tirer des données opérationnelles dans le domaine concerné. A minima une DSI se doit d’avoir une représentation décisionnelle par
domaines fonctionnels, un point de contact qui connaisse le domaine et les enjeux fonctionnels. Cela peut être mis en oeuvre de différentes manières. Mais il est important que ces représentants travaillent en étroite relation avec leurs homologues du SI classique pour chaque domaine. Une équipe décisionnelle doit s’investir dans la connaissance des données et du SI du domaine correspondant et se rapprocher des
sachants du SI.

Chaque métier a aujourd’hui des spécificités très fortes en matière décisionnelle, non seulement sur les données, mais même sur les outils. Certaines thématiques comme le marketing des réseaux sociaux, le lean dans la production, la prévision des ventes, etc. ont aujourd’hui des solutions à caractère décisionnel qui se spécialisent de plus en plus. Et s’intègrent en retour de plus en plus vers le SI opérationnel (gestion de production, gestion des achats, site eCommerce, etc.)

Sur l’axe des entités (branches et/ou business units) : la spécificité des entités doit être comprise et cartographiée.

Il y a des domaines où il y a une volonté de mutualisation groupe et/ou des bénéfices de mutualisation évidents. Pour ces thématiques là la relation avec les entités doit aller dans le sens d’une collaboration des experts. Des cercles de compétence sont une méthode d’organisation très intéressante qui peut donner l’opportunité du partage des
initiatives et des pratiques.

Il y a des entités qui ont des besoins spécifiques du fait de leur business model, de leurs produits ou de leurs services. Il faut dans ce cas une relation directe avec les métiers concernés.

Quelle est la répartition des rôles au sein de la DSI ?

Notamment, quel  répartition des rôles entre les équipes études et les équipes de production/exploitation du SI ?

Le fonctionnement classique d’un SI est de séparer assez fortement la partie études de la partie exploitation. Et ce, pour plusieurs raisons :

  • la structure de coûts : un bon ingénieur d’études décisionnel coûte 3 à 5 fois plus cher qu’un exploitant technique.
  • l’organisation service en astreintes pour tenir les objectifs de niveau de service : les équipes d’exploitation sont organisées pour couvrir les plages étendues pour faire face aux incidents hors plages standards des équipes étude.
  • la séparation des rôles : il est dangereux qu’une même personne développe et opère un SI. Dangereux en termes de risques informatiques, dangereux en termes de qualité, en termes de pérennité des compétences. Il n’est pas rare qu’un brillant spécialiste big data ou BI change de job. S’il n’avait pas été contraint par une cellule de production à formaliser la connaissance sur sa solution, au moins en mode run, c’est le fonctionnement de l’entreprise qui peut être mis en péril.

Cependant cette séparation est mise à mal par plusieurs éléments, et cela s’accentue :

  • la complexité fonctionnelle du processus d’alimentation et de fonctionnement d’une solution décisionnelle est structurellement grande. Beaucoup d’échanges.  Beaucoup d’incidents. En effet, une solution big data est mécaniquement en aval de tout le SI. En tant que telle, elle subit tous les aleas du SI. Tout incident en amont a souvent des conséquences en aval. Avec une variété des cas telle qu’elle peut
    rarement être procédurée et laissée donc à la main de non sachants. Donc même dans une BI classique, il y a toujours une structure d’exploitation applicative qui suit le fonctionnement des solutions décisionnelles. Cela ne peut pas être complètement évité. Mais il faut en revanche toujours veiller à transférer le maximum vers une exploitation technique et à formaliser des consignes permettant le meilleur niveau de service.
  • les nouvelles solutions sont de plus en plus complexes. Les outils big data, nosql,  in memory db , les algorithmes de traitement sont des solutions très avancés et non conventionnels. L’expertise manque dans les DSI au niveau des équipes  exploitation.

Une bonne manière de répondre à ces enjeux est de regarder les sujets en face : si une solution devient critique pour l’entreprise, il est nécessaire de mettre en place une organisation pour la gérer. Le principe d’une séparation entre projet et run est indispensable. Mais l’organisation du run peut/doit avoir de la souplesse. Des équipes hybrides entre production et études a du sens au moins sur certains thèmes. Il faut juste regarder le véritable coût complet d’une solution et ne pas masquer un coût récurrent dans un coût projet ou vice versa.

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

Après avoir identifié les questions autour l’organisation du BI et décrit la chaine de valeur du BI classique, l’objectif de ce second article est de répondre à la première de ces questions :

Dans un groupe multi entités, que mettre en commun versus quelle autonomie locale aux entités (branche ou business units) ?

La mutualisation sert des objectifs : réduire des coûts et (éventuellement) tirer des bénéfices plus larges par effets de levier. Quels sont-ils ?

 

Sur l’axe des coûts, quels sont ces coûts et quelles économies y a-t-il à partager ?

Coûts d’infrastructure

En théorie, il y a des gains évident à partager les infrastructures. Mais là les gains ne sont avérés que si la structure d’accueil est compétitive et sait travailler de manière élastique avec les meilleures pratiques. Il reste difficile d’égaler le cloud.

On soulignera tout de même que le brassage de grands volumes de données reste un problème de stockage de données et de performances de ce stockage (dans des ordres de grandeurs qui sont éloignés de ceux des usages classiques du SI). Et donc dans ce domaine, il faut une vraie expertise pour piloter ce stockage. C’est un point de faiblesse des grands du cloud qui se sont surtout développés sur l’axe du très distribué. Et ce modèle ne donne pas toujours de bons résultats, notamment sur un modèle classique de BI à base de « cubes » et de tables de faits.

Coûts de licence

Les gains de coûts à ce niveaux sont essentiellement des enjeux d’achat. Mais a contrario la massification des achats peut avoir des risques de banalisation des coûts et s’avérer à moyen terme un piège. Les vendeurs de licence, notamment pour lutter contre le SaaS ont tendance à abaisser les coûts d’acquisition initiaux pour les masquer par des coûts de fonctionnement totalement distribués (maintenance, audits au bout de 2 ou 3 ans, fonctionnement à l’usage, etc)… Mais sur ce terrain, il y a peu de spécificités, si ce n’est que le modèle de vente adresse structurellement des décideurs et surfent sur l’idée d’une très forte valeur ajoutée métier liée aux outils qui justifient certains excès.

Coûts d’acquisition de données externes

Les coûts d’acquisition de données externes (données de marché, données d’achat, données client ou de zones de chalandise, données géographiques, etc) : là il y a clairement des enjeux de gains et de mutualisation. L’acquisition et la collecte des données externes est un problème, non seulement de coûts purs d’achat, mais également de prise en compte dans le contexte de l’entreprise et de maîtrise de la qualité. Cette fonction mérite d’être mutualisée. La mutualisation permet en outre de donner un accès plus large aux différentes entités qui individuellement n’auraient même pas la connaissance de ces sources de données.

Coûts d’exploitation technique

L’exploitation technique gagne souvent à être mutualisée. Mais c’est surtout vrai s’il y a une cohérence des socles techniques (ie des technologies employées et des manières de les mettre en oeuvre) et une réelle industrialisation de l’exploitation. Un peu comme pour les infrastructures, la mutualisation n’a de sens que si elle s’accompagne d’une réelle maturité, normalisation et automatisation. Sinon on risque d’avoir une structure de coûts peu différente, mais en revanche une lourdeur et une réactivité faibles du fait de la mutualisation.

Coûts d’exploitation applicative

L’exploitation applicative (administration du paramétrage, des référentiels techniques, des outils et applications) est liée au socle technique et à ses normes de mise en oeuvre. Sur des éléments très communs, ou autour de socles ERPs constitués (ex BI autour de SAP), il y a de la valeur à mutualiser autour de bonnes pratiques. Mais les gains sont moindres sur des technologies applicatives encore en plein développement et expérimentation. Là une exploitation partiellement « locale » aux projets concernés par des équipes plus étude fait du sens, même si cela n’est pas une cible pérenne.

Coûts d’administration fonctionnelle

Il s’agit là d’adresser toutes les activités métier de structuration des droits d’accès, des dimensions, des hiérarchies, des indicateurs, voire de la réalisation de certains tableaux de bord ou de restitutions. Celle ci est directement liée à l’organisation métier. Il est souhaitable d’avoir un modèle de proximité fort sur ce volet. Qui peut/doit s’appuyer sur une cellule centrale si la solution est mutualisée.

Coûts de projet

C’est probablement le domaine dans lequel il y a le plus de promesses de gains de mutualisation. Un projet commun semble toujours plus efficace. Et pourtant … Il y a beaucoup d’éléments qui de fait restent spécifiques à l’entité métier, ne serait ce que
l’ensemble des données de base (pour l’essentiel). S’il n’y a pas une volonté commune (plutôt issue des points de gains attendus ci dessous) de mettre en commun certaines données, les bénéfices sont faibles voire sont contre productifs. Quelle valeur y a t il à partager des données ?
S’il y a des bénéfices évidents techniques, cela peut avoir un sens. Par exemple, si plusieurs entités ont des systèmes d’information communs, il y a clairement des économies d’échelle à mutualiser l’extraction des données. Mais si les SI sont hétérogènes, il est très probable que les coûts de convergence seront supérieurs aux gains, avec l’effet néfaste de rendre plus rigide le SI et la solution de BI. En tout cas sur cet
axe, il est dangereux de vouloir partager la solution décisionnelle quand les SI sources sont distincts et hétérogènes et encore plus si l’objectif fonctionnel commun n’est pas fortement sponsorisé au niveau global groupe.

Sur l’axes des bénéfices, quels sont les bénéfices additionnels liés à la mutualisation ?

Cohérence des méthodes et capitalisation des savoir faire

Cela exige qu’une équipe mutualisée fasse justement l’effort de mettre en place ces méthodes et ces savoir faire et de les diffuser. On observe trop souvent des équipes centrales qui ne sont finalement qu’une juxtaposition de compétences personnelles avec des éléments communs peu marqués. Et finalement des gains en comparaison du recours à une équipe d’experts externes assez faibles. Les gains ne peuvent être effectifs que par des formations communes, des méthodologies communes, des outils communs.

Cohérence des données en termes de sémantique

C’est important de partager un vocabulaire commun. Certains indicateurs clés destinés à la comparaison des entités entre elles ou à la mise en commun d’information doivent pouvoir s’appuyer sur des notions communes bien définies.

Fourniture d’éléments de comparaison et de pilotage groupe

Le premier bénéfice d’une équipe mutualisée est bien de porter les éléments mutualisés. Par exemple, dans un groupe avec une structure fortement distribuée comme PPR, les indicateurs de pilotage de chaque activité sont extrêmement normés. Et la solution qui les exploite en central est commune. C’est aux équipes centrales de piloter des indicateurs communs. Et en cela l’organisation BI ne peut que refléter celle métier. J’ai un client qui a mis en place des outils d’analyse des achats groupe, mais sans « vraie » équipe achats groupe. Celle ci ne commence à prendre son intérêt que maintenant que cette structure se met en place et prend de l’épaisseur. Une telle mutualisation peut d’ailleurs tout à fait rester segmentée par domaines fonctionnels en se concentrant ceux où la mutualisation et le benchmarking des entités à une réalité métier de gains. Par exemple les achats, le pilotage financier, le marketing et la relation client à 360….

Levier des données entre business

Les entités entre elles peuvent potentiellement tirer levier de la connaissance d’indicateurs de leurs entités soeurs. Pour se comparer, avoir des éléments d’information connexes, etc..Mais ce partage n’est possible qu’avec le partage de certaines notions et données…

La maîtrise de certains risques

La maîtrise de certains risques (notamment de confidentialité des données) : plus les structures sont distribuées et éparses, moins elles sont sensibilisées aux risques. La mutualisation du pilotage des risques est intéressante. Elle ne s’accompagne pas nécessairement d’une mutualisation technique des solutions et des moyens … Une telle
centralisation en tout cas crée un risque structurellement plus important qui mérite une attention encore plus grande. Par exemple une mutualisation technique des moyens exige une mutualisation de la politique de sécurité.

La valorisation des données à l’extérieur

Cela est un peu nouveau… mais la donnée peut de plus en plus se monétiser à l’extérieur de l’entreprise. Cela peut donner lieu à du troc (information contre information), ou faire partie de la valeur offerte à ses partenaires. Par exemple de la donnée à valeur ajoutée à fournir aux distributeurs sur les profils de clients cibles ou sur les éléments clés de défilement d’un produit… ou vers des partenaires pour du cross selling (ne serait ce qu’en intra groupe).

Les risques à trop mutualiser…

Il y a des risques en revanche à trop mutualiser, ou à mutualiser trop vite sans alignement métier et/ou du reste des SI :

  • Une perte d’agilité et de « time to market »
  • Une promesse de gains de mutualisation pas atteints
  • Une lourdeur et une structure de coût récurrents élevés

Conclusion

En résumé, c’est peut être une tautologie, mais il convient de bien analyser ce qui gagne à être mutualisé versus ce qui apporte peu de gains à l’être.

… et à prendre les options les plus efficaces. Il est dangereux en tout cas d’excessivement centraliser et mutualiser, si on ne prend pas les actions qui permettent de réellement tirer les bénéfices attendus quels qu’ils soient. Une des caractéristiques de la BI moderne c’est qu’elle ne vise plus tant à satisfaire les envies de beaux tableaux de bord de grands managers, mais à donner aux entreprises des possibilités de prises de décisions et d’optimisation du fonctionnement qui peuvent conditionner sa survie. Il vaut mieux une solution sous optimale en termes de coûts informatiques qui donnent des réponses maintenant aux vrais problèmes posés qu’une solution théorique qui répondra demain à des questions qui n’existeront plus…

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

Les activités de Business Intelligence et de Big Data, de part de leur aspect parfois très transverse, posent beaucoup de questions sur l’organisation à mettre en oeuvre pour en assurer la réussite et l’efficience.

Plus spécifiquement, les questions qui se posent sont :

En introduction, l’activité de BI étendu intégrant les nouvelles méthodes et outils d’analyse de données du big data, a beaucoup évolué sur les 20 dernières années.

D’abord une simple consolidation de données en Infocentre, puis les grands programmes dataware house qui espéraient extraire de manière exhaustive toute l’information pour la ranger dans de grands entrepôts de données très structurés, puis les initiatives plus réactives commençant à valoriser cette information de plus en plus en temps réel
sur des niches et avec une décentralisation des sujets par grands pans fonctionnels (marketing, ventes, production, achats, contrôle de gestion).

Plus récemment de nouveaux types de données changent et enrichissent la donne : données issues des objets connectés, de la mobilité, des réseaux sociaux, de l’open data… Les sources de données se multiplient en termes de natures/structures et d’acteurs. Au delà les technologies d’analyse de données se « vulagrisent ». Non pas qu’il y ait vraiment de révolutions, mais plutôt que des technologies d’exploitation des données deviennent de plus en plus praticables à grande échelle : machine learning, modèles de prévision, analyse de graphes, …

Du coup, les questions précédentes prennent un relief particulier… Il n’y a pas un seul modèle de BI, (et donc d’organisation à mettre en place) mais plusieurs et qui seront variables selon les maillons de la chaine de valeur du BI.

La chaine de la valeur classique d’une BI étendue

Acquisition

Aller chercher la donnée dans les systèmes opérationnels doit rester la responsabilité de la DSI. Ponctuellement un quick win peut être obtenu avec des solutions agiles comme QlikView ou Tableau qui s’alimentent directement dans des bases d’applications métier. Cela ne peut pas être une solution pérenne. Et doit être géré par des équipes DSI classiques.

Consolidation & mise en qualité

Cette fonction est probablement celle qui va/doit le plus changer. La vision d’une dataware house urbanisé qui passe par des étapes très structurées ne répond plus aux enjeux de rapidité. Il vaut mieux vivre avec les anomalies que de chercher à les corriger toutes. Il y a un vrai enjeu pour la DSI a essayer de mettre à disposition l’information de manière très efficace et réactive. Sans faire trop d’hypothèses sur les usages qui en seront faits. C’est un élément qui fait du sens à partager, surtout pour les éléments les plus volumineux et critiques. La source du big data interne en quelque sorte.

Structuration

La structuration en tables de faits et/ou cubes. Cela existe et existera toujours. Mais cette dimension structurée et institutionnelle n’est que la partie émergée de l’iceberg. Qui n’est plus nécessairement là où est la plus grande valeur. On structure les problèmes que l’on connaît et que l’on maîtrise. L’objectif aujourd’hui devient de découvrir de nouveaux gisements… Pour la partie structurée en charge de produire des indicateurs de pilotage opérationnels aux différents de l’organisation, une démarche classique DSI est utile pour assurer la qualité des données et leur mise en cohérence. Mais éventuellement à scinder entre ce qui est commun groupe et ce qui est propre à des branches voire BUs.

Pilotage des indicateurs

Cela reste un élément clé de communication. Avec un besoin de qualité sur la sémantique des indicateurs publics. Rien de plus destructeur que des chiffres divergents et incohérents …

Analyse des données

C’est un domaine en pleine explosion, avec des outils, méthodes en grande effervescence. Il faut privilégier de l’agilité. Et permettre les explorations tactiques et agiles sur le stock de données brut consolidé. C’est un des endroits où cela bouge le plus et où les technologies sont les plus complexes et liées aux typologies de problèmes.

Calcul de données opérationnelles  et réinjection dans les systèmes opérationnels

Ces options se développent de plus en plus. Le BI et le Big Data participent du SI. Il ne s’agit plus simplement d’indicateurs passifs, mais de solutions de plus en plus intégrées aux processus opérationnels. Pour piloter les réappros, la production, les stocks, les prix, les ventes, … Ces boucles donnent à ces technologies une criticité tout à fait nouvelle. Qui doit être sécurisée quand elle en vient à piloter l’opérationnel et le mettre en péril. Celles ci sont impérativement à mettre sous le contrôle d’une DSI.

Le prochain article de cette série reprendra les questions posées en introduction et proposera des éléments de réponse.

Approche générale des problèmes de performance

Chaque type de problème de performance mérite une démarche adaptée, mais il se dégage néanmoins une approche générale des problèmes de performances qu’il est d’autant plus nécessaire de suivre que le problème est complexe. Voici quelques principes généraux à appliquer pour prévenir, diagnostiquer et résoudre des problèmes de performance.

Des objectifs de niveau de service

Au départ d’une démarche de performances, il doit impérativement il y a avoir des objectifs à atteindre définis en termes mesurables non subjectifs. Par exemple un temps de réponse de transactions clés, un temps d’exécution d’un traitement, une durée pour un plan batch, un délai pour traiter des messages, etc. Cet exercice de formalisation est  nécessaire pour échapper au « tout tout de suite » qui est l’expression naturelle du besoin utilisateur sans contraintes. La définition d’objectifs de niveau de service est avant tout  une analyse du besoin et de la valeur attendue du SI. C’est aussi un premier niveau de  négociation d’un compromis acceptable entre besoin et coûts.

Une implication de toutes les compétences et de tous les acteurs

Pour traiter les trois axes des performances (charge, niveau de service, ressources) il faut faire collaborer efficacement des représentants métier/organisation, des acteurs du  développement de la solution, des experts des technologies et des exploitants qui opèrent la solution au quotidien et en pilote le fonctionnement. Cette collaboration doit s’appuyer sur des processus (ITIL notamment), sur des outils (métrologie, tableaux de bord, outils
d’extrapolation/prévision) et sur des hommes. La collaboration décloisonnée entre organisations est essentielle pour le succès. Les solutions ne sont pas toujours exclusivement dans les technologies ou même le développement. L’analyse des  problèmes peut amener les clients à reconsidérer l’organisation du travail pour un compromis globalement plus efficace.

Un respect des « bonnes pratiques » d’architecture

Ceci permet très en amont de garantir des marges de manœuvre dans la solution pour traiter les problèmes de performances éventuels. Ces bonnes pratiques ne sont hélas pas toujours les plus en vogue, car elles ont tendance à promouvoir des solutions qui ont fait leurs preuves au détriment de solutions prétendument innovantes.

Certains principes d’architecture sont les garants les plus sûrs de certains écueils classiques sur lesquels des générations d’informaticiens se sont déjà cassés les dents. Privilégier la « scalabilité »
des infrastructures, limiter les fonctions centrales uniques surtout dotées d’un stock de données, modulariser les fonctions et les données des systèmes complexes en les découplant au maximum (notamment en termes de ressources), ne pas chercher à réinventer ce que fait très bien une base de données (notamment en termes de cache ou de tri), etc.

Une démarche scientifique

Modèle, mesure et prévisions ! Au cœur de travaux sur la performances d’un SI, il doit il y avoir une démarche scientifique de construction de modèles qui expliquent ce qui est observé et qui doivent permettre de prévoir ce qui se passera plus tard. La confrontation  entre la prévision et la réalité est le moyen le plus efficace d’identifier et de comprendre les anomalies. Par exemple, paralléliser un traitement en deux processus, doit permettre de réduire le temps de traitement par près de deux. Si ce n’est pas le cas, c’est qu’il y a des ressources en contention ou que le traitement n’est pas parallélisé efficacement.

Une démarche pragmatique et hiérarchisée

Modèle ne signifie pas « usine à gaz », cela doit rester un outil pragmatique au service de
la résolution des problèmes et rester au niveau de précision suffisant pour obtenir les résultats attendus. La démarche doit également toujours privilégier les actions simples aux gains très probables, aux actions complexes aux conséquences délicates à
anticiper. De même, la relation étroite avec les clients du service (ou leurs représentants) doit permettre de hiérarchiser les problèmes et de traiter les priorités ; les problèmes
les plus visibles ne sont pas nécessairement les plus prioritaires et les plus dangereux pour l’ensemble de la solution.

Une remise en cause des évidences

Il s’avère quelque fois que les solutions mises en œuvre sont inadaptées pour traiter les besoins exprimés. Il faut savoir remettre en cause les besoins ou les solutions pour échapper à de telles impasses. Par exemple, certains usages peuvent solliciter une
solution applicative d’une manière suffisamment particulière pour justifier des développements spécifiques (par exemple : des factures avec un nombre de lignes très élevé par rapport à la moyenne, des volumes de données très asymétriques selon les
entités clientes, etc). La solution peut également être inadaptée parce qu’elle propose une architecture qui structurellement ne peut pas assurer le service demandé. Il est par exemple vain d’attendre d’une architecture asynchrone de garantir un temps de traitement très court et très constant ou à l’inverse d’attendre d’un service synchrone unitaire de traiter efficacement un grand volume d’événements.

Une valorisation objective des gains et des coûts

Pour les opérations lourdes, il est important de peser les coûts, les bénéfices attendus et  les risques encourus avant de les lancer. Il faut s’assurer en outre de la faisabilité et de la portée des gains au plus tôt. Cet exercice peut aider à prioriser les travaux et à favoriser les actions les plus efficaces. Le risque est important, notamment en présence d’experts chevronnés et soucieux de bien faire, de traiter d’abord ce qui valorise l’expertise au  détriment de ce qui est essentiel.

Un suivi dans le temps

Les problèmes de performance complexes ne se font ni ne se défont en un jour. La maîtrise des performances est un travail qui s’inscrit dans la durée et doit être porté par des processus pérennes des équipes de la DSI. Les problèmes sont souvent décelables par une analyse continue et un suivi dans le temps, avant de devenir des risques véritables pour les utilisateurs. Ce suivi dans le temps, commence en amont du projet, dès la conception, en phase de recette notamment avec des tests de performance, en phase de déploiement en anticipant chaque étape du déploiement, et en fonctionnement récurrent pour surveiller et détecter toute dérive inexpliquée (pour aligner les ressources ou mener les travaux d’amélioration et d’optimisation).

Une communication efficace

Pour mobiliser toutes les compétences et tous les acteurs, pour ne pas démobiliser les clients et leur (re)donner confiance dans la solution, il est indispensable de communiquer efficacement. Cette communication doit à la fois être la plus objective (en s’appuyant sur des mesures incontestables) et la plus transparente possible (en identifiant les problèmes et en rendant public le processus de leur résolution). Elle doit également donner de la visibilité sur le plan d’amélioration pour permettre à chacun de percevoir la démarche et d’aider de son mieux en attendant la résolution cible. Par exemple, des utilisateurs peuvent mieux supporter des mesures transitoires même contraignantes si la cible est bien identifiée.

Modèle des performances d’un SI

Dans le cadre de cette problématique des performances du SI, comme dans d’autres où la complexité du SI pose en soit problème, enioka a la conviction qu’il est nécessaire de modéliser le SI pour mieux le comprendre, raisonner sur les questions ou problèmes rencontrés, et décider d’actions. Modéliser ne veut pas nécessairement établir un modèle
informatisé cathédrale du SI, mais d’abord d’avoir à travers un ou plusieurs modèles, des vues de synthèse d’un objet complexe permettant de l’analyser plus efficacement.

La performance est un domaine où la modélisation est une nécessité pour ne pas travailler au hasard, obtenir des résultats durables et bénéficier de bonnes pratiques.
Plusieurs points de vue de la modélisation sont à prendre en compte :

Modèle d’architecture

Pour étudier les performances d’un système, il faut avant toute chose en connaître l’architecture. On ne répare pas un appareil sans en avoir les plans. L’approche enioka sur ce point s’appuie sur deux grandes fondations : le modèle général des architectures et le modèle des services d’infrastructures (SOI : Service Oriented Infrastructure).

Le modèle général des architectures, structurés autour de quatre points de vue :

  • Modèle fonctionnel des services offerts par la solution, l’objectif de ce point de vue est de cerner de manière synthétique les services (avec les exigences associées)
    que rend l’architecture à ses différents utilisateurs/clients/administrateurs.
  • Modèle logique du fonctionnement : l’objectif de ce point de vue est de détailler le fonctionnement de la solution, et de comprendre comment chaque composant est
    sollicité pour rendre chaque service. C’est ce modèle qui permet d’assurer le lien entre l’usage des services et l’usage des ressources.
  • Modèle physique des ressources affectées aux fonctions : l’objectif de ce point de vue est de décrire précisément les ressources allouées et les éléments clés de
    leur configuration (en termes quantitatifs). C’est ce modèle qui porte les « capacités » des ressources de la solution en termes de puissance et de rapidité de traitement notamment.
  • Modèle des opérations destiné à décrire comment est opéré la solution. Dans certains sujets de performances, la clé réside en partie dans les capacités de
    pilotage données aux opérations et/ou à la délégation de certains travaux à l’ « usine » des opérations en lieu et place des utilisateurs finaux.

Ce modèle d’architecture s’appuie sur le modèle des services d’infrastructure, le modèle « SOI » (Service Oriented Infrastructure) qui définit les différentes couches de service que l’on retrouve de manière standard dans toutes les solutions. Ce modèle sert d’accélérateur dans l’analyse et la conception des architectures SI (et dans des DSI
industrielles, de rationalisation), et dans le contexte précis à normaliser les éléments clés de contrat de service et de moyens de pilotage associés de ces services. Ce modèle s’appuie notamment sur plusieurs couches de services :

  • couches des infrastructures physiques et des ressources : services de stockage, services de calcul, etc.
  • couches middleware : services base de données, serveur d’application, services d’intégration, etc.
  • couches applicatives génériques : services de portail, de reporting, éditique, services d’annuaire, etc.

Modèle d’activité métier

L’objectif est de caractériser l’usage de la solution et finalement de définir des unités d’œuvre qui permettront de tailler la solution. Le modèle le plus primitif se limite le plus souvent à estimer le nombre d’utilisateurs nommés, voire connectés à l’application. Mais au delà de ce modèle trivial, il convient de modéliser, avec une finesse plus ou moins grande selon les objectifs poursuivis :

  • les données en termes de stocks versus flux. Autrement dit les données accumulées au cours du temps (en fonction de la rétention des données) et les taux d’accroissement par jour ou par mois de ces principaux stocks (nombre de clients ou fournisseurs créés, nombre de factures émises, etc).
  • les utilisateurs, non seulement en termes de  nombre mais en les caractérisant par profils principaux (comme acheteurs, chefs d’affaire, comptables) et en évaluant leur niveau d’activité (habituellement on définit des profils normatifs de type utilisateurs lourds/moyen/léger) qui permet d’estimer leur niveau de sollicitation combiné.
  • l’activité de ces profils d’utilisateurs doit en outre être caractérisée par un profil de charge qui permet de mesurer leur usage des différents services de la solution : usage des différentes transactions, des restitutions ou des traitements qui peuvent être déclenchés par les utilisateurs. Cet usage est caractérisé par un nombre d’exécutions par unité de temps.
  • les principaux traitements à effectuer dans le cadre du plan batch, en identifiant les facteurs principaux dimensionnants de ces traitements (nombre de factures  traitées, nombre de ventes, etc).

Modèle de temps de réponse

Un temps de traitement est la composition de différents temps élémentaires. Cette décomposition découle directement du modèle d’architecture. Dans les architectures n tiers modernes, ce « temps » est en fait décomposé en multiples tronçons qui ne sont pas toujours simples à démêler : temps du navigateur, temps réseau WAN, temps  infrastructures de sécurité, temps frontal web, temps serveur d’application et  d’intégration, temps bases de données, temps stockage, etc. Le temps de réponse vu de l’utilisateur est par ailleurs rarement la simple somme des temps de chacun de ces tiers. La vision claire de cette décomposition et des éléments les prépondérants dans le temps global est indispensable pour guider les travaux d’analyse et d’optimisation.

Modèle d’usage des ressources

Le lien entre l’activité métier et l’usage des ressources (et indirectement du temps de  réponse) est un lien complexe. Il peut heureusement sous réserve d’hypothèses à valider  (notamment de plages d’usage) souvent être considéré comme lié « linéairement » à certaines unités d’œuvre qui caractérisent l’activité métier. Néanmoins les différentes contributions de chaque type d’activité à l’usage des ressources restent souvent délicates à discerner entre elles. Par exemple un utilisateur métier moyen actif consomme par période de référence (par exemple 10 minutes) un certain volume de mémoire sur chaque tiers, un certain nombre de secondes CPU sur chaque tiers, un certain nombre d’IO  logiques et physiques et une certaine quantité de bande passante sur le réseau.
Modèle des coûts SI

En filigrane de cette réflexion, il y a toujours de manière implicite la notion de coûts. Coût des ressources (et notamment de leur augmentation, avec les effets de seuil éventuels  associés), coût des développements à réaliser pour corriger/améliorer la solution, coût des équipes en charge de détecter et caractériser les problèmes de performance, coût induit sur les utilisateurs du fait de performances insuffisantes.

Ces différents modèles seront abordés dans des articles plus spécifiques à chacun d’entre eux et à leur usage dans le contexte de problématiques de performances.

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.

Introduction à la performance des systèmes d’information

Cet article a pour objectif de poser quelques définitions de base qui seront reprises dans une suite d’articles à venir sur la gestion des performances des Systèmes d’Information, qui traiteront différents points de vue : pilotage du niveau de service, optimisation du temps de réponse des applications, plan de capacité, déploiement de grands systèmes applicatifs, optimisation des ressources, etc.

La gestion des performances d’un SI est un problème délicat pour deux raisons :
parce que les SI sont de plus en plus complexes d’une part et parce que d’autre part la performance d’un SI ou d’une application est une notion relativement complexe en soit. La performance, à l’image d’autres notions transversales du SI comme l’urbanisme ou la
sécurité, est en effet une notion vaste qui exige différents points de vue pour être correctement traitée.

Beaucoup de SI rencontrent de fait des problèmes de performance qui se traduisent
par des symptômes assez différents comme des écroulements sous des pics de charge (par exemple dans des périodes de solde ou de clôture comptable), des changements d’échelle douloureux voire impossible quand l’activité d’une application ou d’un système s’accroît fortement, des coûts techniques qui dérivent de manière non
proportionnelle avec l’activité, des niveaux de service qui se dégradent et pénalisent les utilisateurs métier, des instabilités techniques récurrentes, etc.

Notre conviction est que certains problèmes de performance sont des problèmes complexes et qu’à ce titre, ils exigent une démarche particulière, et une vision relativement globale et structurée de la problématique. Le développement de la complexité des systèmes d’information ne fait qu’accroître ces cas où de nouvelles approches, ou au moins des approches utilisées dans d’autres domaines que celui de
l’informatique de gestion, deviennent nécessaires.

Quelques exemples de problèmes de performance
complexes

Tous les problèmes de performance ne sont pas complexes, fort heureusement. Quand il s’agit seulement de corriger une anomalie dans un programme, d’optimiser un
traitement ou une requête dans une base de données, d’accroître la puissance d’un serveur, les processus naturels et standards du développement et de l’exploitation des SI sont suffisants pour résoudre les problèmes qui peuvent apparaître et qui sont de fait
plus des incidents que de vrais problèmes au sens ITIL du terme.

Mais il y a certains cas où le problème ne se trouve pas facilement isolé sur un
point d’expertise où la bonne compétence dans la DSI apportera naturellement et facilement une solution. Il y a des cas, où même en « payant » et en ajoutant des
ressources le problème n’est pas résolu pour autant et des cas où, si le problème reste mal posé, il n’a pas de solution.

Voici quelques exemples où une approche plus globale est nécessaire :

  • Améliorer la performance d’une fonction critique complexe : certaines
    fonctionnalités sont difficiles à mettre en œuvre et la tenue des exigences de performances peut être structurellement délicate, par la complexité des traitements, la multiplicité des applications à faire collaborer ou les contraintes de temps pour traiter les volumes. Quelques exemples :

    • Assurer une vision « temps réel » des stocks pour une entreprise
      de distribution multi-canal avec des stocks distribués (fournisseurs, entrepôts, magasins, partenaires logistiques).
    • Assurer les pics de transactions de sites internets pendant des périodes de
      promotion ou des ventes flash, en garantissant la disponibilité
      des stocks.
    • Assurer un calcul d’optimisation logistique ou d’approvisionnement dans un temps limité pour tenir les délais et contraintes des partenaires
      logistiques.
  • Dimensionner une infrastructure pour une cible de déploiement : dans le cadre
    du déploiement d’une solution à l’échelle d’un grand groupe ou d’une montée en charge associée à une évolution forte d’une activité métier, il est souvent nécessaire d’anticiper la capacité de la solution à prendre en charge la montée en charge
    et d’avoir un « coup d’avance ». L’enjeu est de garantir le niveau de service et la capacité à aligner les infrastructures requises, sans « sur-investir » ni mettre en péril
    l’activité métier.
  • Améliorer les performances d’une solution applicative globalement médiocre :
    certaines applications issues de développements lourds et longs sont mises en service sous une forte pression de délais, au détriment d’un temps de qualification et d’optimisation suffisant. En conséquence, les problèmes de performances surgissent au fil du déploiement, avec l’augmentation de l’activité et l’accroissement
    du volume de données d’historique. Traités trop tardivement ces problèmes peuvent bloquer le déploiement, voire créer des incidents opérationnels graves en nuisant à des processus métier critiques pour l’entreprise.
  • Identifier et traiter une contention de ressources qui impacte toutes ou plusieurs
    fonctions : certains problèmes de performances n’ont pas de cause manifeste aisée à cerner. Les contentions peuvent être liées à l’architecture de la solution et à des contentions indirectes ou subtiles entre différentes ressources.
  • Réguler et absorber un pic d’activité : le dimensionnement d’une
    infrastructure pour supporter l’intégralité d’un pic de charge est souvent trop coûteux, surtout s’il n’y a pas d’enjeux incontournables métier à tenir un délai de traitement strict. La mise en place de mécanisme de délestage est pour autant souvent subtile à mettre en place, et en particulier doit favoriser les
    processus ou clients/usagers les plus critiques du service (favoriser les transactions d’achat par rapport aux transactions d’information par exemple). Cette régulation demande une coordination très forte entre vision fonctionnelle (des besoins et
    priorités) et vision technique (des contraintes de ressources).
  • Maîtriser la durée d’un plan batch : garantir qu’un plan batch de nuit ne
    dépassera pas la fenêtre allouée est sans doute l’exemple le plus complexe des problèmes de performances. Beaucoup de facteurs influencent cette performance : la complexité et la structure des traitements, leur capacité ou non à être parallélisés (eux mêmes ou entre eux), les dépendances fonctionnelles qui en
    contraignent l’ordonnancement, les contraintes induites par d’autres applications ou partenaires externes, les grands volumes à traiter, la fluctuation de l’activité au cours du temps, etc.

Quels sont les principaux facteurs de complexité ?

Il est probablement impossible de dresser la liste des facteurs qui peuvent influer sur la complexité des performances d’un SI ou d’une application, mais les suivants sont certainement les principaux :

  • La complexité des solutions et technologies : le premier facteur est clairement celui de la complexité des solutions et technologies. La fragmentation des tiers, l’interdépendance des applications, la complexité des technologies sous-jacentes, la rapidité de leur évolution et de leur obsolescence, la multiplication des progiciels, l’introduction de services en mode SaaS, la virtualisation des ressources… Tous ces éléments rendent la compréhension des problèmes de performance plus délicate. Cette complexité est un fait qui ne changera pas et risque au contraire de continuer à s’accélérer.
  • La multiplication et la dispersion des expertises : cette complexité s’accompagne d’une fragmentation des expertises, tant sur les solutions fonctionnelles, applicatives que techniques. Dans des DSI où ces mêmes experts sont souvent déjà fortement sollicités, il est difficile de les faire travailler efficacement ensemble.
  • Le manque de points de mesures : on pense trop rarement dans ces solutions complexes à les doter de moyens de mesures efficaces (au delà des fondamentaux du socle d’infrastructure de base) permettant d’en comprendre finement le comportement et les dysfonctionnements éventuels.
  • L’absence de repères : cette complexité et ces multiples expertises font perdre les repères sur ce qui est « normal » versus ce qui ne l’est pas. Dans un contexte où le plus souvent, les technologies « masquent » une partie de la complexité, il n’est plus très facile pour un administrateur SAN d’identifier le comportement anormal en IO d’une application, pour un administrateur de base de données d’identifier des requêtes en anomalie ou une mauvaise conception des données, pour un développeur de comprendre les conséquences d’un de ses choix d’architecture logicielle, etc.
  • Les effets d’échelle : le comportement des technologies n’est pas similaire à toutes les échelles, une base de données qui traite un volume de données de quelque Go de données utiles, ne se comporte pas comme une base qui en traite des To. Une application Java pour 50 utilisateurs internes ne se comporte pas comme un site
    internet soumis à des pics d’activité de milliers d’utilisateurs par nature incontrôlables. Pour autant, les technologies, les experts et les développeurs sont souvent les mêmes.
  • La progressivité de la dégradation : les problèmes de performance sont rarement détectés « au bon moment » et apparaissent souvent de manière progressive ou à l’occasion de périodes exceptionnelles où la solution est sollicitée de manière anormale. Cet enlisement progressif dans les sables mouvants de la dégradation des performances endort les acteurs et lorsque le problème se révèle vraiment, il peut être trop tard pour agir…
  • La difficulté d’anticipation et d’extrapolation : il est structurellement difficile de prévoir le comportement d’un système complexe. C’est d’ailleurs un des facteurs de caractérisation d’un système complexe : son comportement ne peut plus se prévoir
    simplement par celui de ses parties.
  • La négociation des solutions : les problèmes de performance réellement complexes s’accordent rarement d’une solution technico/technique « locale » et nécessitent plutôt un compromis entre contraintes technologiques, complexité
    et délai de développement et besoin métier. Cette « négociation » est rarement perçue comme telle par tous les acteurs mais donne souvent au contraire lieu à des affrontements stériles entre études et production, ou DSI et utilisateurs.

Trois points de vue indissociables…

La notion de performance n’a pas de sens dans l’absolu. Il n’est pas pertinent de parler d’une application ou d’un SI performant ou non performant sans mettre en relation trois axes majeurs qui caractérisent vraiment et pleinement la performance. Ces trois axes principaux sont :

  • le travail à effectuer, où en termes informatiques le volume et la complexité des traitements à effectuer sur les informations. Autrement dit : quelle complexité intrinsèque de traitement, indépendamment de l’implémentation qui peut en être faite. Ce travail à effectuer est à mesurer sur plusieurs plans :
    • le volume des données effectivement à traiter, en discernant ce qui doit lu, mis à jour, créé ou supprimé par le traitement,la complexité algorithmique du traitement en termes d’accès aux données, de calculs et de mise à jour de données.
    • le modèle de charge du travail qui définit le profil de la charge : est-il
      étalé ou au contraire astreint à des pics ou périodes particulières ?
  • le temps imparti pour effectuer ce travail : cette dimension temps de
    traitement est déterminante pour caractériser la performance. Ce temps de travail peut selon les cas se mesurer en millisecondes (pour la proposition de mots clés dans un moteur de recherche au fil des saisies), en secondes (pour les temps d’attente d’un utilisateur dans le cadre d’une transaction interactive), en minutes (pour l’attente d’un traitement de restitution) ou en heures (pour des traitements lourds de type batch). La relation au temps est
    éminemment subjective et doit être autant que possible mise en perspective des enjeux opérationnels et du coût associé au temps pour le métier. La mesure du temps pour une solution d’enchère en ligne n’est pas la même que pour un traitement de facturation mensuel.
  • les ressources utilisées pour effectuer ce travail : il s’agit là d’identifier toutes les ressources employées. Les plus évidentes sont les capacités de traitement (secondes CPU) du ou des serveurs assurant le traitement ou le volume des données
    stockées sur disque. Mais il y a d’autres ressources employées qui sont à prendre en compte : comme la mémoire, le nombre et le volume des entrées / sorties (lié en partie à la mémoire), le nombre et le volume d’échanges réseau, etc.

La difficulté de ces trois points de vue est qu’il ne sont pas maîtrisés par les mêmes
acteurs de l’entreprise, ni en termes de causes réelles, ni en termes de conséquences. Et à l’évidence, ils s’opposent. On comprend bien qu’il est plus difficile de traiter vite un travail
plus difficile ou plus volumineux, ou que traiter plus vite est susceptible de consommer plus de ressources. Tant que ces points de vue peuvent être conciliés, il n’y a pas de soucis particuliers : par exemple si les utilisateurs acceptent le « surcoût » de davantage de ressources ou l’impact de temps de traitements allongés. En revanche, si ce n’est pas le cas, il faut arbitrer ces trois points de vue et trouver les meilleurs compromis.

Conclusion

Ce premier article pose les bases de la problématique de la performance des SI. Dans un prochain article, seront abordés le coût de la gestion des performances, les modèles permettant de d’appréhender la performance et la démarche générale proposée par enioka pour gérer la performance des 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.