Archives pour la catégorie Architecture et modélisation des SI

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

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.

Urbanisme des référentiels – partie II

Suite à un premier billet qui posait la problématique des données de référence dans le SI et ce que pouvait être une démarche référentielle, il est ici question d’étudier les difficultés  et les écueils d’une telle démarche.

Ce que n’est pas une démarche référentielle

Ce n’est pas un simple outil MDM

Une approche référentielle n’est pas nécessairement associée à la mise en œuvre d’un  produit du marché.  Les outils de type MDM (Master Data Management), qu’ils soient  génériques ou spécialisés par domaines métiers, sont des facilitateurs, mais bien  rarement des solutions « clé en main » au-delà d’une simple maquette. L’enjeu essentiel  d’une démarche référentiel n’est donc pas l’outil mis en œuvre mais la transformation  progressive du SI pour urbaniser ses données de référence.

Néanmoins, certains domaines (relation client, gestion des identités) sont plus matures et plus standardisés que d’autres, laissant la place à des solutions verticales de gestion des données référentielles plus abouties que les outils génériques multi domaines.

Ce n’est pas un progiciel métier

Les progiciels métiers de type ERP (gestion commerciale, comptabilité, RH etc.)  consomment des données référentielles et sont souvent créateurs de données référentielles. Mais ce rôle de créateur de donnée référentiel n’en fait pas pour autant toujours un candidat idéal pour assumer le rôle de référentiel d’entreprise.

Ils sont rarement de bons référentiels d’entreprise du fait de leur rigidité et la restriction de leur vision du référentiel à leur métier. Par ailleurs, faire porter le rôle de référentiel central à un ERP complexifie l’évolution de celui-ci alors même qu’un des rôles d’un référentiel est d’amortir pour partie les évolutions des ERP.

Toutefois, dans le cas de SI de petite ou moyenne taille fortement structuré autour d’un seul progiciel, ou d’une suite intégrée de progiciel, l’option de gérer le référentiel dans le progiciel est souvent l’option la meilleure (simplicité, cohérence).

Ce n’est pas un projet d’intégration

La mise en œuvre d’un référentiel s’accompagne de la mise en œuvre de nombreux flux. Une des difficultés de mise en œuvre d’un référentiel, tout comme la mise en œuvre d’un ERP, est la gestion de ces nombreux flux et des interfaces associées. Ce besoin d’intégration pousse parfois à confondre démarche référentielle et mise en œuvre d’outils d’intégration spécifiques.

Une approche référentielle n’a pas pour objectif de définir les moyens techniques d’intégration des différentes applications.  Tout au plus elle définit des patterns d’intégration des applications au référentiel, indépendamment des technologies :

  • Diffusion de type publish & subscribe en mode événementiel ou de type batch par annule/remplace (full) ou modifications (delta)
  • Intégration par services synchrones vs messages vs fichiers

Il convient donc de s’intégrer aux pratiques existantes d’intégration du SI et si nécessaire de les faire évoluer

Les difficultés d’une démarche référentielle

Un travail de fond nécessaire…

Une approche référentielle demande une réflexion plus importante sur modéliser la forme des données de référentiel, et notamment sur leur généralité,  les règles de mise à jour et de cohérence, ainsi que les principes de diffusion dans le SI

Une approche référentielle n’a pas de sens si elle n’est pas accompagnée d’une étude d’urbanisme des briques du SI et des données de référentiel.  Le risque est sinon de construire un élément jetable,  au mieux satellite d’une petite portion du SI,  qui ne fera qu’ajouter de la complexité.

La mise en œuvre d’un référentiel simplifie et unifie l’intégration des référentiels dans le SI, mais ceci n’est pas pour autant une solution « magique » : les capacités et limites des progiciels à intégrer restent ce qu’elles sont…

Un arrimage nécessaire aux projets métiers

Bien que transverse, il est rarement possible d’initier un référentiel en dehors du cadre d’un projet métier. En règle générale, les deux principaux écueils sont :

  • L’absence d’un sponsor métier du fait de la forte transversalité
  • Le choix du périmètre initial (données et facettes des données) est difficile sans cas d’usage concret.

Néanmoins, une approche référentielle trop ambitieuse requiert un travail significatif peu compatible avec les plannings des projets métiers.  Les risques de « court circuit » du référentiel en cours de projet sont dans ce cas élevés. Il est souvent long et difficile de relancer un projet référentiel suite à ce type d’échec.

De fait, un arrimage aux projets métier est nécessaire mais la trajectoire de mise en œuvre est toujours délicate et doit gérer le compromis entre la masse critique nécessaire et les risques/coûts de mise en œuvre. De fait,  un référentiel prend de la valeur à mesure qu’il accumule et croise des données référentielles en nombre suffisant et qu’il alimente une majorité des applications du SI, mais une première version doit se contenter d’un périmètre restreint de données et d’applications connectées pour limiter les risques coût et planning.

Dans quels cas une démarche référentielle est-elle pertinente ?

Pour les SI et les entreprises qui préparent des grands projets de transformation. Dans ces situations, le SI a besoin d’absorber les évolutions et non seulement les subir. Les projets de transformation sont aussi l’occasion d’extraire certains référentiels des applications métiers et mettre en œuvre progressivement des référentiels d’entreprise.

Lorsqu’une application centrale du SI perd petit à petit son rôle de centre de gravité au profit d’une ou plusieurs nouvelles applications, la mise en œuvre progressive d’un référentiel permet de faciliter la transformation de ce patrimoine en amortissant les impacts de ses évolutions et en évitant  de faire porter à ce patrimoine tous les concepts et contraintes des nouveaux progiciels ou applications qui visent à le remplacer.

L’arrivée de nouveaux progiciels bouleverse souvent l’équilibre du SI et posent des nouveaux concepts sans la distance nécessaire. Certaines notions structurantes sont amenées par des progiciels et il convient de déterminer s’il s’agit d’un patois local au nouveau progiciel ou bien d’un terme partagé dans le SI et l’entreprise. Ceci conduit à l’émergence forte d’un besoin d’une plate-forme neutre qui matérialise le vocabulaire de l’entreprise.

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.

Concevoir des interfaces inter-applicatives : les formats pivots

Suite au précédent billet sur les interfaces, nous allons ici approfondir les intérêts ainsi que les risques que peuvent présenter la mise en place de formats pivots.

La thèse initiale

La promesse faite par les partisans des formats pivots est que leur utilisation permet de réduire les coûts d’intégration : il est plus intéressant que chacune des applications ayant besoin de s’intégrer fasse la moitié du chemin.

Ainsi, une approche directe (sans format intermédiaire) consiste à ce qu’une application conserve son format et ses contraintes et que les applications avec qui elle doit communiquer s’y adaptent. À l’opposé, la mise en place d’un format pivot consiste à définir un format intermédiaire permettant de tenir compte des différents cas d’usages, puis de développer des traitements d’intégration pour que chacune des applications puissent interagir avec ce format.

Qu’est-ce qu’un format

Lors de la mise en place d’un format pivot ou dans la spécification d’une interface entre deux applications, un format représente le contrat sur les données échangées. Nous parlons ici de contrat car la définition de formats pivots prend toute sa dimension dans une approche service des interfaces entre applications, ce qui fera l’objet d’un prochain billet sur le blog.

Que sa description soit formelle ou implicite, le format porte donc :

  • Le type des données échangées : les entités métier qui transitent dans l’interface
  • Le format technique utilisé dans l’interface, ce qui matérialise le format structurel (arborescence, tabulaire, relationnelle), le format du conteneur technique (XML, CSV, tables) et la manière d’encoder chacun des attributs (encoding des chaînes de caractères, format des dates…)
  • Les codifications ou référentiels associés à chacun des attributs
  • La définition des critères d’unicité des entités : les contraintes d’unicité des entités et les multiplicités des relations des données transitant dans l’interface peuvent être différentes de celles des applications impliquées (par exemple la relation entre un client et un dossier client qui peut faire que les entités sont confondues dans certains systèmes (relations 1-1) et pas dans d’autres)
  • La définition de l’ensemble des objets transitant dans l’interface : le sous-ensemble des entités qui sont concernées par l’interface (par exemple, une application de gestion des ressources humaines qui travaille sur l’ensemble du personnel et une application de gestion des contrats avec les entreprises d’intérim qui ne travaille que sur le personnel intérimaire).

La définition de ces formats est une base de la mise en place d’une démarche d’urbanisme des interfaces d’une DSI. Elle permet en effet de distinguer les éléments communs qui doivent être partagés entre les applications de ceux qui peuvent être spécifiques à une application ou une interface. Pour chacune des caractéristiques du format (type de données, formats technique (structurel, conteneur et encodage des attributs), référentiels et codifications), il faut donc se poser la question de l’intérêt d’une homogénéisation ou d’une spécialisation.

Les intérêts des formats pivots

Le premier gain qui peut être attendu lors de la mise en place d’un format pivot est la diminution du coût de mise en place des interfaces.

La description de formats pivot, et des services associés, place les applications dans une relation client-fournisseur. Cette contractualisation permet de définir de manière nette les frontières de responsabilité entre applications et leurs dépendances. Ce n’est pas un hasard si les formats pivots dont l’usage est le plus généralisé (SWIFT et les formats EDI par exemple) se retrouvent dans les interfaces inter-SI : elles se sont placées sur des interfaces qui étaient déjà des relations clients-fournisseur contractualisées.

La généralisation de formats pivots peut également être l’occasion pour une DSI de spécifier une méthodologie de définition de ses formats, une grammaire commune à toutes les applications pour définir les données qui transitent dans les interfaces. Cette grammaire peut s’exprimer en termes d’entités, de relations et d’attributs, dans un vocabulaire de modélisation objet ou dans tout langage de description de données. Cette démarche peut mener jusqu’à une industrialisation des développements des traitements d’intégration (export et import des données des interfaces par les applications) dans les projets.

Spécifier des formats pivots nécessite d’identifier les différentes entités qui circulent entre les applications. Cette spécification est donc également l’occasion de formaliser le dictionnaire de l’entreprise et de définir un langage commun aux utilisateurs des différents métiers et à la DSI. Ceci facilite la communication dans l’entreprise, entre autre lors des projets informatiques.

Enfin, la mise en place de formats pivots autour d’une application facilite son rôle de fournisseur. Durant un projet, cela permet de limiter la quantité de spécificités des clients à prendre en compte à ce qui a été identifié comme suffisamment commun et donc mis dans le pivot et le service rendu par le fournisseur.

De manière générale, dans une interface, la mise en place d’un format pivot profite à l’application qui est du côté où il est seul (souvent le fournisseur). La limite de sa responsabilité est définie et il sera ainsi souvent plus facile de faire bouger un nouveau tiers pour qu’il se conforme à la règle qui est déjà définie et partagée. Il faut aussi garder à l’esprit que le nombre de clients qui utilisent effectivement un format pivot est en général moins grand que ce qui est espéré lors de sa conception initiale pour deux principales raisons : la partie commune peut se révéler trop faible et la complexité de mise en œuvre trop élevée.

Les coûts de la généralisation

La généralisation nécessaire à la mise en place de formats pivots a un coût, qui doit être rentabilisé par la réduction du coût marginal d’une intégration supplémentaire utilisant ce nouveau pivot. Ceci est généralement démenti lors de la mise en place des interfaces jusqu’au format pivot : elles sont souvent aussi coûteuses à mettre en œuvre que des interfaces directes. Mais la principale difficulté réside dans la généralisation nécessaire à la mise en œuvre d’un format pivot.

La mise en place d’un format pivot demande de prendre en compte les spécificités de toutes les interfaces qui vont l’utiliser, ce qui demande un travail de conception beaucoup plus complexe et risqué que de spécifier les formats unitairement. En effet, la construction d’un format pivot par juxtaposition des besoins des différentes applications ne va faire que concentrer la complexité de toutes les interfaces dans un seul format qui sera de plus rigidifié par le nombre de contraintes qu’il porte.

Un pivot est également supposé être utilisé plus longtemps qu’un format pour une interface point à point, ce qui demande de concevoir dès le premier jour son évolutivité. La construction d’un format pivot pose la question de sa responsabilité et de sa propriété. Il faut en effet à la fois un sponsor qui finance cet effort initial dont les gains à court terme ne sont pas évidents et un responsable qui portera l’effort au-delà de la première mise en place. Ces deux rôles sont complémentaires car ils ont des intérêts différents : l’un voudra que le coût initial soit le plus raisonnable tandis que l’autre cherchera à ce que le pivot soit le plus général possible pour pouvoir le diffuser largement dans le SI.

La tentation d’un urbaniste lors de la définition d’un pivot peut être d’essayer d’englober la totalité des notions qui ressemblent à l’objet visé sous prétexte qu’elles portent le même nom ou partagent une structure commune (par exemple facture client et facture fournisseur ou client et prospect). Plus le format prendra en compte de spécificités, plus il sera compliqué de s’accorder sur son contenu et plus il sera complexe à mettre en œuvre. Il est alors important de se concentrer sur les éléments qui sont réellement communs, ce qui peut rendre le format sans intérêt (par exemple lorsque seuls les identifiants et les libellés sont partagés) ou décevant intellectuellement.

Le rythme de mise en œuvre des évolutions à coordonner entre les différentes applications (client(s) et fournisseur(s)) représente une difficulté supplémentaire, à la fois à la conception (réussir à collecter les besoins de tout le monde pour réaliser une version initiale) et dans le maintien de l’interface et des différents environnements dans lesquels elle peut être exécutée. Ce problème de coordination peut résulter dans une situation ou une application principale impose son format au nom de ses contraintes de planning.

La mise en place de formats pivots permet de maîtriser (ou au moins d’identifier) les points de dépendance avec un tiers (fournisseur) ou une application (par exemple un progiciel). Cependant, la mise en place d’un pivot dans le seul but de se rendre indépendant peut conduire à la superposition de couches d’isolation n’apportant aucune valeur (par exemple en imposant un format technique sous prétexte qu’il est technologiquement neutre). D’autre part, à l’échelle d’un SI, vouloir isoler absolument les applications d’un ERP central qui est mis en place pour rester 5 à 10 ans apporte beaucoup de contraintes et bien peu de gains.  Il n’est pas absurde de conserver des parties du format du fournisseur, mais cela doit relever d’un choix et non être subit. Il peut également être tentant de se réfugier derrière un produit (ETL, EAI, ou ESB) ou une technologie (XML) promettant l’isolation. Or, la valeur et la durabilité du format pivot résident dans le modèle et les codifications, pas dans son format technique.

Faut-il mettre en place des formats pivots ?

S’il peut être bénéfique de mettre en place des formats pivots dans les interfaces de service de son SI, à quelles fins ?

Nous pouvons identifier deux cas d’usage où les formats pivots peuvent apporter de réels gains :

  • La diffusion de données de référentiels
  • Le transport de données opérationnelles fortement partagées qui traversent le SI (stock, ventes…)

Dans ces deux cas, il s’agit de données qui sont déjà largement partagées dans le SI. Il est donc ici possible d’espérer tirer les avantages de la mise en place d’un format pivot :

  • Le partage de la définition des données, ce qui en facilite l’interprétation et la cohérence
  • La réduction des coûts d’intégration des applications (développements et données mieux maîtrisés)
  • Dans certains cas, la réduction du nombre de développements d’intégration

Au contraire, certains objets peuvent se révéler être de mauvais candidats pour l’utilisation d’un format pivot. On peut prendre pour exemple l’entité « client ». C’est une notion dont la définition peut varier très largement entre les différentes utilisations qui en sont faites (de la prospection commerciale à la facturation). Non seulement les attributs nécessaires aux différentes étapes du cycle de vie de l’objet ont peu en commun, mais l’identité même de l’objet peut être différente : il faut parfois faire la distinction entre les filiales et les agences d’une même entreprise (au moment de la livraison par exemple) alors qu’elles peuvent être considérées comme une seule entité pour la facturation ou l’évaluation de la solidité financière. C’est un objet dont une représentation unique servant tous les usages du SI est une illusion, ce qui n’empêche pas d’avoir un pivot plus spécifique pour certains usages clairement définis.

Il faut garder à l’esprit lors de la conception d’un format que sa complétude est moins importante que sa souplesse (capacité à y décrire des données de natures différentes et complexes), sa facilité de mise en œuvre (en tenant compte de l’outillage disponible sur le marché et l’intégration aux méthodes et outils de la DSI) et son évolutivité (capacité à évoluer sans rompre la compatibilité avec les utilisateurs déjà en place).

Au-delà des caractéristiques générales que nous pouvons proposer, la conception de formats pivots demande une grande maturité de la fonction urbanisme dans une DSI au point d’avoir une vision de l’évolution du métier de l’entreprise et du SI qui le sert, pour comprendre quels sont les points d’adhérence justifiés et les éléments qui peuvent être mis en commun entre les applications. Surestimer cette maturité est une erreur fréquente des architectes et des urbanistes.

Conclusion

Nous avons vu ici que la mise en place d’un format pivot représente rarement une réduction des coûts de développement. Elle peut cependant permettre un transfert de coût de l’application fournisseur aux applications clientes et un lissage des dépenses dans le temps.

Sur le plan méthodologique, la mise en place de formats pivots et la définition des niveaux de partage (définition des entités, formats techniques, référentiels), permet de matérialiser la démarche d’urbanisme et de faciliter l’industrialisation de l’intégration des applications.

Ce partage et les normalisations associées imposent des rigidités et des difficultés supplémentaires. Celles-ci doivent donc être équilibrées par les gains apportés par la mutualisation.

Nous avons ici évoqué le contrat passé entre les applications sur les données. Or, cette démarche de contractualisation est bien plus vaste et doit prendre en compte les traitements faits sur les données, les cinématiques de plusieurs interfaces, les volumes de données, les capacités d’annulation ou de réémission d’une interface, l’outillage mis à disposition pour le développement et la disponibilité. En résumé, tout ce qui constitue un service, qui sera détaillé dans un prochain billet.

Urbanisme des référentiels – partie I

Ce billet a pour objectif de présenter la vision d’enioka sur l’urbanisme des référentiels. Il vise à expliquer le rôle et l’intérêt d’un référentiel et comment celui-ci peut s’intégrer dans les projets d’évolution du SI. Il s’agit du premier billet d’une série sur les référentiels. Il aborde plus spécifiquement la définition de ce qu’est une démarche de gestion des référentiels (ou MDM : Master Data Management). De prochains billets traiteront des sujets suivants :

  • Ce que n’est pas une démarche référentielle et les difficultés d’une telle démarche
  • Les principes d’urbanisme des référentiels
  • Les fonctionnalités attendues d’un référentiel

La problématique des données de référence

Les données de référence du SI (clients, produits, fournisseurs, organisation…) sont très souvent créées par les applications de gestion de leur domaine respectif (gestion de la relation client, gestion commerciale,
comptabilité, ressources humaines…). Ces données sont également utiles à toute autre application du SI qui manipule des données opérationnelles s’y référant (une commande ou stock référence un produit par exemple).

Les données référentielles sont ainsi souvent échangées conjointement avec les données
opérationnelles. Le cycle de vie de ces données de référence n’est pourtant pas toujours aussi simple : enrichissement par des applications tierces, contradictions entre plusieurs domaines du SI sur la forme et la nature d’une donnée référentielle, besoins de réconciliations entre plusieurs créateurs de données référentielles, workflows de validation, besoin de contrôle de cohérence… Ceci est d’autant plus flagrant dans les SI distribués dont la colonne vertébrale n’est pas très fortement structurée par une application de gestion interne ou un ERP « tout en un ».

Sans une démarche adaptée, la gestion de ces données de référence devient, pour un SI d’une certaine taille, une problématique complexe dont les conséquences les plus visibles sont :

  • La multiplication des interfaces et des formats représentant les mêmes données,
  • Un manque de traçabilité et de cohérence des données,
  • Des difficultés de réconciliation entre les données de transaction d’applications qui n’utilisent pas les mêmes référentiels ; ceci est particulièrement visible au niveau des systèmes décisionnels,
  • La propagation mal maîtrisée de notions spécifiques d’un progiciel.

Face à cette problématique, structurer les données de référence du SI, leur cycle de vie et leur gestion devient un enjeu fort pour l’urbanisme du SI afin d’en conserver la maîtrise. L’objectif d’une démarche référentielle est de répondre à cet enjeu.

Qu’est-ce qu’une démarche référentielle ?

Une démarche référentielle vise la mise en œuvre d’une gestion des données référentielles au sein du SI. Il ne s’agit ni de la simple mise en œuvre d’un outil ni d’incantations ou de recueil de bonnes pratiques. Il s’agit d’une
démarche globale, transverse et continue qui change la manière de gérer les données référentielles à tous les niveaux du SI, de l’urbanisme à la conception des applications. Une telle démarche a pour objectif de :

  • matérialiser des principes d’urbanismes,
  • concentrer des données et des règles de gestion,
  • mettre en œuvre des processus et des outils de gestion des données de référence.

Une matérialisation des principes d’urbanismes.

Une approche référentielle a pour objectif de matérialiser les principes d’urbanisme autour des référentiels d’entreprise qui sont partagés entre les applications, et de participer au découplage des applications entre elles. L’objectif est d’avoir une vision fédérée des référentiels sans que chaque
application ait à connaître quelle application gère quel élément de référentiel.

Une approche référentielle doit s’appuyer avant tout sur une cartographie des données de référentiel, et l’identification de la ou des application(s) maître(s) de chaque donnée de référentiel, selon :

  • Chaque facette du référentiel (i.e. groupe d’attributs/relations d’une donnée de référentiel – par exemple : facettes budgétaire, structuration de l’offre, achat, logistique, stock, etc.),
  • Chaque élément d’organisation de l’entreprise (certaines données peuvent être partitionnées en fonction de l’organisation de l’entreprise, et avoir des niveaux de partage variables – (exemple par filiale commerciale, par business unit),
  • Chaque étape du cycle de vie de la donnée de référentiel (ex. pour un produit : pré-référencement, référencement, commercialisé, retiré).

Une concentration des données et des règles de gestion

Une approche référentielle s’appuie sur une concentration des données et des règles de gestion des données référentielles. Ce point de concentration sert de fédérateur à toutes les applications et « orchestre » le partage de l’information entre elles au fil des évolutions des référentiels.

Enfin, un référentiel gère structurellement la cohérence de l’information de référentiel
au sein du SI et sa dimension temporelle. Cela s’appuie notamment sur les notions de statuts et de dates d’effet des modifications apportées aux référentiels.

La mise en œuvre de processus et d’outils de gestion des données de référence

Une démarche référentielle se concrétise par la mise en œuvre de processus et d’outils de gestion des données de référence. Une application de gestion des
données de référence, bien que centrale dans le SI, n’est pas nécessairement unique, mais au contraire peut être partitionnée par domaine ou par entité afin de refléter des particularités d’une données (par exemple la donnée client) ou bien d’apporter une souplesse tactique lors de l’urbanisation d’une partie du SI.

Par ailleurs une application de gestion des données de référence n’est pas pour autant nécessairement perçue par les utilisateurs métier du SI. Il est très souhaitable que la gestion de chaque élément de référentiel soit déléguée à l’application légitime pour le faire à chaque fois que cela est possible.

Conclusion

Cette définition d’une démarche référentielle pose les bases de notre démarche. Nous verrons dans un prochain article les risques et difficultés à adopter une telle démarche.