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.

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.

Urbanisme des référentiels – partie III

Après avoir posé ce que pouvait être une démarche référentielle et souligné les écueils d’une telle démarche, il s’agit maintenant d’identifier quelques principes d’urbanismes applicables aux données de référence.

Ces principes sont à utiliser comme des indications et non comme des lois ou des dogmes. Il est tout à fait possible que par moment, violer ou s’écarter de ces principes soit une bonne option. Néanmoins, il convient de bien vérifier les motivations de ces écarts, la plupart étant de fausses bonnes idées.
Il ne s’agit que des principes de base de gestion des données de références, il convient de les enrichir et les adapter avec :
• le retour d’expérience suite à la mise en œuvre des premiers référentiels dans le SI,
• des illustrations et des exemples concrets appliqués dans les projets pour communiquer plus efficacement auprès des autres projets,
• une adaptation au contexte de chaque système d’information.

Unicité du référant

L’objectif de l’unicité du référant est de favoriser la cohérence des données référentielles au sein du SI.

ref_unicite

Ce principe propose que pour chaque type de donnée référentielle il y ait unicité du référant. Par exemple, un seul référentiel produit, un seul référentiel fournisseur. Plusieurs points importants sont à préciser :
• Le référant n’est pas nécessairement le créateur de la donnée référentielle.
• Il n’y a pas de contrainte d’unicité des sources de données référentielles sur des périmètres disjoints. Par exemple le référentiel des personnes peut provenir de deux systèmes de Paye qui concernent chacun des populations différentes de l’entreprise.
• Dans le cas d’applications très intégrées entres-elles, l’une d’elles peut jouer le rôle de point de diffusion pour les autres – elles sont vus comme globalement une seule application dans le circuit de diffusion des données référentielles.

Centralisation des mises à jour

Bien que leur cycle de vie soit souvent plus lent que les données opérationnelles, les données référentielles ne sont pas immuables. Elles font l’objet de mises à jour et ce n’est pas toujours le référant ou même le créateur de la donnée qui est à l’initiative de cette mise à jour. Il s’agit souvent de contribution sur des facettes particulières des données référentielles.

Le référant doit toutefois être le point de centralisation et diffusion de ces mises à jour pour favoriser la cohérence des données référentielles et éviter à chaque consommateur d’être à l’écoute des contributions de chacun.

ref_centralisation

Les modifications d’une donnée sous contrôle d’un référentiel sont diffusées par le référentiel uniquement si cette modification est susceptible d’être utilisée par d’autres applications.

Une exception particulière à cette règle concerne les ensembles d’applications très intégrées entre elles (plusieurs applications d’une suite progicielle exemple) ou l’une joue un rôle de mandataire pour les autres.

Unicité de l’identifiant

L’unicité de l’identifiant a pour objectif de faciliter les possibilités de rapprochement des données référentielles et les correspondances entre les applications.
Une donnée référentielle possède un unique identifiant fourni par le référant. Cet identifiant est la clé qui permet à tout composant du SI (producteur ou consommateur) de pouvoir identifier et distinguer les données référentielles. Ceci n’empêche pas une donnée référentielle d’avoir une codification propre dans chaque composant du SI qui l’utilise. C’est souvent le cas dans un progiciel qui gère ses propres codifications internes mais aussi dans toute application qui a le bon gout de gérer dans son modèle de données les liens avec des clé technique et non les clé fonctionnelles.
Le référentiel est également en charge des gérer les identifiants alternatifs et la correspondance avec l’identifiant standard. Cela permet de gérer les identifiants « historiques » des applications ; le référentiel étant rarement la première brique construite dans le SI ! Ceci est par ailleurs une nécessité pour les applications (en général progiciel) qui ne permettent pas d’utiliser un identifiant externe. L’idée est que le référentiel fournisse à chacun la table de correspondance afin que ces identifiants spécifiques ne contaminent pas tout le SI et soient éliminés dans les couches d’interfaces au plus tôt.

Indépendance du référant

L’indépendance du référant est sans doute le principe le plus délicat à mettre en œuvre. L’objectif est d’amortir le plus possible les impacts sur le SI de l’évolution des applications qui créent les données référentielles. Le référant faisant écran des évolutions et transitions entre les créateurs/contributeurs des données référentielles et les consommateurs.

Pour assurer cette indépendance, la structure de la donnée dans le référant doit être la plus indépendante possible des producteurs et des consommateurs :
• Indépendance de la structure technique : format, type, nommage
• Indépendance de la structure fonctionnelle : règles de gestion spécifiques et modèle conceptuel des données

Cette indépendance est toujours relative et les formats sont souvent teintés des applications créatrices de données référentielles. Les formats pivots purs et parfaitement indépendants n’existent que dans les livres et les organismes de normalisation ou dans de rares cas simples de données largement échangées. Il s’agit donc de trouver le compromis entre les gains à s’aligner en partie sur le format et les concepts de l’application créatrice et la capacité à gérer le remplacement de cette application sans impact trop lourd sur les consommateurs.

Dans le cas ou le référentiel est porté par une application métier de type progiciel, il faut bien prendre en compte les limites suivantes :
• Les consommateurs de ces données référentielles seront contraints par la modélisation et l’évolution propres au métier de cette application. Les capacités d’adaptation (au-delà de simples attributs personnalisés) du progiciel sont donc à étudier de près avant de prendre une telle décision.
• Ce référentiel ne peut être qu’un sous-ensemble des données gérées par cette application. Si ces données sont étendues et que le progiciel n’en gère qu’une partie, les deux options ne sont pas idéales : charger dans le progiciel des informations qu’il ne gère pas, au risque de l’alourdir, pour maintenir son rôle de référentiel, ou bien créer un second référentiel pour ce nouveau périmètre de données.

Ce raccourci, qui consiste à s’appuyer sur un progiciel métier comme référentiel, est souvent une bonne option pour les SI de petite taille ou bien complètement structuré autour d’un progiciel intégré qui couvre la majorité des métiers de l’entreprise. Cela est toujours plus simple à mettre en œuvre et le couplage aux formats des données référentiels n’a que peu de conséquences pour les SI déjà entièrement modelé autour d’un progiciel.

Mise sous contrôle d’une donnée référentielle

La mise sous contrôle d’une donnée référentielle a un cout et toutes les données référentielles ne nécessitent pas autant d’attention.

ref_controle

En première approche, il est souhaitable de mettre une donnée référentielle sous le contrôle d’un référentiel quand au moins une de ces conditions est remplie :
• Quand elle est produite par plus d’une application
• Quand elle est consommée par plus d’une application
• Quand les fonctions à valeurs ajoutées du référentiel (historisation, gestion à date etc.) sont souhaitées

Conclusion

Ces principes ne sont qu’une ébauche qu’il convient d’adapter à chaque contexte (taille du SI, présence ou non d’un ERP jouant un rôle de centre de gravité…) et à chaque donnée référentielle (niveau de diffusion, multiplicité et stabilité des sources etc,). Le référant, point de vérité de la donnée référentielle, se doit de posséder plusieurs qualités et fonctionnalités pour justifier son existence. Celles-ci seront développées dans le prochain  article de cette série.

« Make or Buy » sur les plateformes d’intégration : un modèle de choix

Ce billet a pour objectif de proposer un modèle de choix pour répondre aux problématiques de « Make or Buy » rencontrées lors des phases de conception d’une plateforme d’intégration, en entreprise, à savoir choisir une solution outillée du marché – qu’elle soit dans le « cloud » , open source ou non – ou bien choisir de bâtir une solution spécifique, et sur-mesure.

Cette notion de plateforme d’intégration est à rapprocher de la notion d’iPaaS[1] très en vogue actuellement, mais pour un usage interne à l’entreprise. Nous parlerons davantage de retours d’expériences que des aspects académiques, néanmoins nous donnerons une définition de plateforme d’intégration qui correspond au métier d’architecte d’enioka.

I) Plateforme d’intégration : kesako ?

Qu’est-ce qu’une plateforme d’intégration ?

Une plateforme d’intégration est un middleware, c’est à dire un logiciel d’infrastructure fournissant des fonctions d’intégration aux applications du SI, et dont la valeur ajoutée pour le SI est d’abstraire et de réduire la complexité liée aux chaînes de liaison techniques des échanges inter-applicatifs, en proposant des solutions « clés en main » pour les principaux cas d’intégration.

Le schéma ci-après illustre la position du middleware d’intégration dans l’architecture :

Quels sont les principales caractéristiques d’une plateforme d’intégration ?

Parmi les critères fondamentaux caractérisant un service middleware on retrouve toujours:

  • l’interopérabilité inter-applicative, notamment sur la connectivité proposée aux applications, avec notamment des connecteurs pour l’intégration (annuaires, bases de données, outils MFT[2]/MOM[3]…) et une API[4] de développement pour l’intégration des applications,
  • l’abstraction de l’hétérogénéité des infrastructures techniques sous-jacentes,
  • le passage à l’échelle par administration et paramétrage plus que par développement logiciel.

Quels sont les enjeux de maîtrise de la complexité du SI ?

Un service middleware d’intégration répond à plusieurs enjeux de maîtrise de la complexité des SI :

  • réduire les coûts et délais liés à l’intégration d’applications et formaliser des abaques,
  • proposer une architecture d’intégration homogène,
  • industrialiser la supervision et l’exploitation techniques de l’intégration,
  • fonder des modèles d’architecture et de service d’intégration « clés en main ».

 

 

II) Identification des critères pour un choix « Make or Buy »

Nous nous proposons de sélectionner les critères déterminants pour décider de l’implémentation d’une plateforme d’intégration par un produit du marché ou par un développement spécifique.

La maturité technique du SI client

La maturité technique du SI client est un critère majeur de décision.

Si la maturité est faible, faire le choix d’un développement spécifique serait risqué, l’accent est donc généralement mis sur le choix d’un produit du marché, et une intégration faible de celui-ci au SI pour limiter les impacts. Et si les besoins en évolution des fonctions d’intégration sont méconnus, il est préférable de mettre en œuvre un développement spécifique léger en forme de prototype permettant aux équipes IT d’identifier les premiers éléments de complexité, et de faire évoluer la solution d’intégration avec les besoins des applications au fur et à mesure de la croissance du SI.

A l’opposé, pour un SI dont la maturité est forte, le choix portera davantage sur un outil du marché avec une forte industrialisation de son intégration au SI, ou bien sur un développement spécifique avancé pour une intégration «sur mesure».

La vitesse d’évolution du SI est également un paramètre à prendre en considération au regard du cycle de vie d’un produit du marché (nouvelles versions, support fin de vie).  Par exemple, dans le cas d’un SI à évolution rapide – cas courant – un développement spécifique peut jouer un rôle de « joint de dilatation » entre les interfaces et les produits qui implémentent le service middleware et limiter les impacts de montée de version sur les applications du SI.

Le modèle technique de répartition

Le modèle technique de répartition est également l’une des clés de décision pour le choix. Une faible répartition correspond à un modèle client-serveur classique, avec une centralisation des fonctions d’intégration sur le serveur, et l’appel de ces fonctions par les clients. Une forte répartition correspond davantage à un modèle peer-to-peer qui permet à chaque client de disposer localement des fonctions d’intégration sans faire appel à un tiers sur le réseau.

Le modèle de répartition peut engendrer selon les produits du marché des coûts conséquents de licence (produits payants) et des coûts d’administration importants en cas de croissance rapide du SI.

La plupart des produits du marché proposent un modèle à faible répartition.

La complexité des chaînes d’intégration

Plus les chaînes d’intégration sont complexes (nombre d’étapes, nombre d’applications, topologie de la chaîne d’intégration, règles de gestion, hétérogénéité technologique, interactivité homme-machine, …) plus les contraintes sont fortes sur le service middleware. Rares sont les produits du marché capables de maîtriser de facto cette forte complexité tout en respectant les exigences de la Production. Il est souvent utile dans ce cas de fournir un développement spécifique qui implante du liant entre Intégration et Production.

Le choix d’un outil du marché – seul – ne permettra pas la flexibilité requise de bout en bout, et souvent l’intégration du « dernier kilomètre » est le maillon faible qui masque toute la valeur du middleware d’intégration. Par exemple, ce sujet est particulièrement visible lorsqu’il s’agit d’interfacer la chaîne d’intégration avec les outils de la Production (ordonnancement, supervision, …) et les différents outils métier, de bout en bout et de manière homogène!

Les compétences

Les compétences internes (ou externes) sont celles qui à moyen et long terme sont garantes, au quotidien, du maintien en condition opérationnelle du socle, et de l’accompagnement des projets jusqu’en production.

Dans ce contexte, le choix d’un développement spécifique est à proscrire si les équipes ne sont pas suffisamment formées pour le développement de services middleware complexes.

Par son positionnement dans l’architecture et dans les processus IT, un socle d’intégration est par nature à mi-chemin entre le monde des Etudes, et le monde de la Production. Afin de sécuriser l’avenir d’un développement spécifique, il est presque indispensable de recruter des compétences qui puissent comprendre ces deux mondes. Par exemple, une DSI qui ne dispose pas de ces compétences fera davantage le choix de l’achat d’un produit du marché.

A l’inverse, le choix d’un produit du marché peut nécessiter des compétences d’administration spécifiques, et donc des formations à prendre en compte lors de la contractualisation.

Les normes et standards des développements projets et de la Production

Les normes et standards des développements et d’infrastructure peuvent conditionner la décision. Il est nécessaire de contrôler que les normes en vigueur ne sont pas incompatibles avec la portabilité des développements sur le produit du marché et/ou sur son exploitation. En effet, il est fréquent dans un SI de voir tout un périmètre implémenté par un outil du marché qui ne respecte par les normes et standards définis en interne. Dans tous les cas, des exemples (ou templates) de développement respectant les normes et standards sont souvent les bienvenus pour montrer l’exemple aux équipes études.

La prise en charge de protocoles spécialisés

La prise en charge de protocoles spécialisés comme Odette FTP ou EDIFACT/EANCOM pour l’industrie, ou NOEMIE pour le secteur de la Santé, peut nécessiter le choix d’une solution du marché disposant du support intégré de ces protocoles. D’autant que l’implémentation de ces protocoles peut faire l’objet d’une certification par leur autorité de gestion ou tout simplement s’avérer coûteuse. A l’opposé, des protocoles standards et simples d’accès pour le développement logiciel comme FTP et HTTP/SOAP seront plus pertinent dans le cadre d’un développement « maison ».

Le modèle de coûts

Enfin, le critère coût restera déterminant pour le choix, avec un équilibre à trouver entre CAPEX et OPEX en fonction du budget. Il faut prendre en compte le cycle de vie « classique » d’un middleware d’intégration et projeter une vision d’architecture à 3-5 ans. Dans les deux cas, il y aura des postes de coûts en CAPEX et en OPEX.

Dans le choix « make », le CAPEX sera moindre la plupart du temps, parce que les coûts de licence des produits du marché sont encore importants pour ce type de service middleware, mais l’OPEX peut être en retour élevé (coût de maintenance logicielle). Néanmoins, dans le choix « buy », la problématique est la visibilité sur l’OPEX (coûts de maintenance et renouvellement de licences) dans une vision à 3-5 ans, ce qui n’est pas toujours simple en fonction du modèle de licence plus ou moins flou proposé par les éditeurs. Les solutions iPaaS dans le « cloud » peuvent à ce titre proposer une alternative avec un bon compromis, mais les offres restent encore un peu jeunes et ce choix pose de nouvelles questions en termes technique, fonctionnel, et financier.

 

III) Conclusion

En conclusion, bien que la notion de middleware ne soit pas nouvelle et que l’implantation de produits middleware dans les SI contemporains soit une pratique répandue de facto, le besoin d’adaptation et mise à niveau est toujours présent. Il n’y a pas de réponses à la complexité à travers un modèle unique de middleware. Les produits du marché ne satisfont pas toujours les contraintes et les exigences des entreprises et des organisations, qui doivent répondre à des problématiques techniques et humaines toujours plus ambitieuses. Et les solutions « cloud » qui se développent amènent de nouvelles solutions avec leurs contraintes spécifiques… Le choix est guidé en fonction d’échéances dans l’évolution du SI, de contraintes d’architecture, et de possibilité budgétaire de la DSI et de compétences.

[1] Integration Platform as a Service

[2] Monitored File Transfer

[3] Message Oriented Middleware

[4] Application Programming Interface

JQM : un serveur de batch asynchrones en Java

JQM (Job Queue Management) est un gestionnaire de batch sous licence Apache qui permet de traiter sur des noeuds de traitement répartis toutes les tâches potentiellement longues qui ne sont pas désirables dans un serveur d’application à travers un système de files de priorité. Ce logiciel s’adresse à toute application qui souhaite gérer l’exécution de ses tâches hors du serveur d’application.

Une tâche peut être déclenchée depuis un appel Web Service ou une API par une application web, un ordonnanceur ou un flux d’interface.

L’outil propose de nombreuses fonctionnalités comme l’arrêt d’une tâche, la récupération de fichiers générés, la priorisation d’une tâche et bien d’autres. JQM a été développé en Java SE 1.6, utilise Hibernate/JPA 2.0 comme ORM, et une base de donnée comme référentiel de configuration et file d’attente des traitements. JQM est compatible avec les bases HSQL, MySQL et Oracle, les serveurs d’application WebSphere et Glassfish (prochainement Tomcat) pour l’API cliente et gère les ressources JNDI pour les bases de données et les brokers de messages.

L’outil est compatible avec les projets Maven et tout particulièrement la gestion des dépendances et des projets parents.
Architecture

JQM est composé de trois grandes parties :

  • les moteurs de traitements (des JVM standalone) qui exécutent les tâches. Il est possible de déployer plusieurs moteurs (ou noeuds) de traitements pour des raisons de performance ou de haute disponibilité
  • une base de données qui joue le rôle de file de traitement et de référentiel de configuration
  • les clients (une application Web dans un serveur d’application, une ligne de commande, un ordonnanceur, un autre job JQM etc.) qui soumettent des jobs à JQM

Les noeuds de traitement sont reliés à des files de traitement en base de données et ont chacun un intervalle de polling et un nombre défini de jobs pouvant tourner simultanément.

Par exemple:

  • VIPqueue = 10 jobs simultanées + intervalle de polling de 1 seconde
  • SLOWqueue = 3 jobs en simultanés + intervalle de polling de 15 min
schema_jqm

Cycle de vie d’une tache

Le cycle de vie d’un job passe par quatre états différents.

Après avoir été ajoutée à la file d’attente, la tâche prend le status « SUBMITTED ». Une fois  que le job est « attrapé » par un noeud, son statut passe à l’état « ATTRIBUTED » suivi de  « RUNNING » une fois que l’exécution de celui-ci a commencé.

Le job à la fin de son execution a deux états possibles, « CRASHED » si le job n’a pas  fonctionné correctement ou « ENDED » si tout le processus s’est déroulé correctement.

cycle_of_life_JQM

 

Fonctionnalités 

Pour les développeurs
  • Pour les développeurs de traitement
Un job est défini comme tel une fois qu’il « extends » de la classe JobBase de l’API jqm-api. Au sein d’un job, il est possible de récupérer des ressources via JNDI (base de données, broker de message, répertoire de traitement…), d’envoyer une progression, un message de log ou de mettre en file un autre job.
  • Pour les clients des traitements

Il existe plusieurs moyens d’utiliser JQM.

– Par le biais de l’API jqm-clientapi qui permet d’avoir toutes les fonctionnalités existantes, à savoir la possibilité de mettre un job en file, de regarder son état, de l’annuler, de le changer de file et bien d’autres.
  • Par le biais d’un web service
  • Par une interface en ligne de commande
  • Par une IHM web (très frustre à l’heure actuelle)

Pour les administrateurs

Un administrateur à la possibilité de consulter les logs, de gérer les connexions JNDI, de paramétrer les associations entre les jobs et  les files.

Exemple de job

public class Caller extends JobBase
{
    @Override
    public void start()
    {
        Map<String, String> params = new HashMap<String, String>();
        p.put(“myParam1”, “Pouet”);
        p.put(“myParam2”, “Tut tut”);
        // enQueue is a JobBase method.
        // It is used to enqueue a Job, here “Called”.
        enQueue(“CalledJob”, “Bob”, null, null, null, null, null,
                 null, null, null, null, params);
        }
}
 

Exemple d’intégration de JQM dans un SI

Dans cet exemple, JQM est utilisé pour gérer une intégration au fil de l’eau de message dans un ERP qui ne possède qu’une interface d’entrée de type table / prodédure stockée.
JQM joue un rôle de « joint de dilatation » entre un système évènementiel qui gère des pics à 200 000 messages par heure et une interface de type procédure stockée qui traite des données en masse mais ne se prête pas à de nombreuses exécutions simultanées.
Chaque message est traité par un thread d’un conteneur MDB (Message Driven Bean) et déclenche un job JQM. La file de job JQM est paramétrée pour n’exécuter qu’un seul job à la fois et annuler les lancements surnuméraires. Le job lance la prodédure stockée de l’ERP qui traite toutes les données en attente dans la table d’interface.
En pic, plusieurs centaines de messages n’occasionneront qu’un ou deux lancement de la procédure stockée qui traitera en masse les données. Le système permet ainsi de rester très réactif en période creuse (au contraire des systèmes de type batch cyclique) tout en permettant la montée en charge lors des pics.

 

integration_jqm

Origine du projet

Le projet a été développé par la société enioka dans le cadre d’un projet pour l’un de ses clients pour l’intégration d’un ERP.
Suite à la réalisation de ce projet, il a été convenu que JQM deviendrait open source afin de combler le manque actuel de ce type d’outils libres dans un contexte java SE/EE 6.

Le code source et la documentation sont disponibles sur Github.