Manifeste pour du développement de haute-couture

Le développement est une chose trop grave pour être confié à des développeurs. Ce manifeste pour du développement de haute-couture est un appel pour que les entreprises mesurent la nécessité d’un développement maîtrisé et de qualité. enioka Haute-Couture est une maison de développement logiciel qui s’est donné comme mission d’accompagner ses clients dans cette démarche.

La transformation numérique des entreprises révolutionne la façon de travailler dans tous les secteurs, même de ceux à priori éloignés de l’informatique. La plupart des processus métier sont désormais outillés informatiquement, voire ne pourraient exister sans. Cela a une conséquence : la valeur ajoutée d’une entreprise, ce qui la différencie de ses concurrents, est de plus en plus souvent liée à un élément informatique. Tel distributeur aura une chaîne d’approvisionnement plus efficace grâce à des algorithmes de réapprovisionnement innovants, telle banque sera plus rapide sur les ordres à faible latence grâce à des processeurs dédiés, tel constructeur aéronautique pourra éviter de coûteux prototypes grâce à des modélisations plus avancées…

Est-il alors souhaitable de confier les logiciels de l’entreprise, cette pièce critique de la valeur de l’entreprise, à un tiers ? C’est pourtant le mouvement qui a eu lieu depuis les années 90, où les développements ont été massivement externalisés et délocalisés. Et les entreprises ont perdu beaucoup de connaissances sur leurs propres logiciels, y compris les plus critiques d’entre eux.

Notre vision est qu’une entreprise qui innove doit maîtriser ses développements. Pour cela, il lui faut acquérir, ou ré-acquérir, un certain nombre de compétences : techniques évidemment, organisationnelles, méthodologiques, de recrutement…

Cette reprise en main des développements peut se faire progressivement, en commençant par mettre en place organisation, architecture, outillage et équipe de développement pour leur donner les clefs pour créer les solutions nécessaires et répondre aux demandes des clients et utilisateurs.

Le développement logiciel est devenu un enjeu trop important pour qu’une entreprise soit dépendante de ses fournisseurs. Cette indépendance se manifeste à la fois par la propriété intellectuelle sur le code produit, par la capacité à faire évoluer le code source qui doit donc être livré documenté, avec tous les outils nécessaires à le faire vivre (chaîne de compilation, outillage de déploiement, suite de tests, outils de suivi projet) et un transfert des compétences nécessaires assuré. Ces éléments doivent être envisagés dès le lancement d’un projet sous-traité pour s’assurer de la bonne transmission du logiciel.

Si cette mise en place initiale est faite par une équipe tierce, il est alors essentiel qu’elle soit réalisée sur mesure pour les objectifs et contraintes de l’usage par l’équipe finale. Il faut alors, plus encore que d’habitude, insister sur la qualité du développement et de l’outillage instaurés, qui en faciliteront l’utilisation, la reprise et l’extension. La trajectoire permettant de s’assurer que toutes les parties impliquées (utilisateurs, chefs de projet, exploitants, développeurs, architectes, testeurs…) maîtrisent leurs (nouveaux) outils de travail est également essentielle.

Passé ces premières étapes, nos équipes partagent une vision de ce que doit être un projet informatique bien mené. Nous sommes convaincus que les projets informatiques modernes doivent être réalisés en contact direct avec les utilisateurs, sur des cycles de release rapides. Nous apportons en conséquence un savoir-faire pragmatique sur les méthodes agiles : sans les considérer comme sacrées, nous les utilisons comme des boîtes à outils pour en retenir des éléments en fonction du contexte client. Nous voyons l’organisation, les processus, comme une trajectoire menant vers une cible revue régulièrement plutôt que comme une destination fixée trop longtemps à l’avance. On doit se fixer des objectifs à court terme, puis continuer à améliorer de façon continue, et faire en sorte que cela continue de s’améliorer bien après le départ de nos équipes.

Il faut commencer petit pour amorcer un cycle vertueux : une démarche d’internalisation doit commencer petit, et doit faire ses preuves, que ce soit par un petit projet sélectionné ou par un prototype. Nous sommes capables de prendre complètement cette amorce en charge, en la réalisant complètement ou en encadrant les équipes en place.

Ce qu’il faut au bon endroit. Nous sommes également certains qu‘il n’y a pas de technologie miracle, quel que soit le domaine. Ce mythe a fait trop de dégâts par le passé. Les langages, les frameworks, les middlewares… ne sont que des briques dont il faut systématiquement évaluer l’adéquation au contexte.

Nous sommes aussi persuadés que des améliorations sensibles de la qualité des développements sont à la portée de toute organisation qui s’en donne les moyens. En partie grâce au contact métier permanent mentionné plus haut, qui permet d’opérer au plus près du besoin réel. Ensuite, en s’appuyant sur une organisation efficace et adaptée ainsi qu’à un bon outillage des cycles de développement pour assurer la qualité du produit (tests automatiques, processus de revue de code…). Enfin et surtout grâce à des développeurs compétents et responsabilisés sur leurs rôles dans les projets et dans l’entreprise.

C’est pour proposer du développement en accord à ces principes qu’enioka Haute Couture a été créé. Ceci nous permet de proposer à des sociétés, de toute taille et de tout secteur d’activité, de commencer immédiatement à travailler comme si elles avaient internalisé leurs développements tout en progressant vers l’autonomie complète. Tout cela est porté par une équipe désireuse de partager sa vision et son expérience du développement, avec comme objectif d’aider nos clients à (re) devenir maître de leurs développements.

Topologie CPU & VMware vSphere

Quelle est la performance des processeurs dans un contexte virtualisé ? L’architecture des processeurs ne peut être complètement oubliée quand il s’agit de virtualiser des infrastructures importantes. NUMA ? Virtual CPU ? Virtual Socket ? Wide VM ? Cet article fait le point sur ces concepts clés de la virtualisation, leur impact sur la performance des VM et comment cela se matérialise avec VMware vSphere.

Introduction

Contexte

Au cours d’une mission chez un de mes clients, j’ai accompagné un certain nombre de projets sur la partie architecture infrastructure. L’un de ces projets reposait sur la technologie Active Pivot. Ce logiciel permet, à partir d’un jeu de données, de créer des cubes en mémoire et de l’offrir aux utilisateurs sous la vue d’un tableau croisé dynamique.

La question de la configuration et l’optimisation des processeurs sur ce type de technologie dans un environnement dédié et virtualisé (VMware) s’est posé. L’enjeu était de valider les performances des traitements sur un gros volume de données en mémoire (128/256 Go par VM) et comprendre l’impact de la virtualisation.

Problématique

La première fois que l’on voit l’interface de vSphere, certains paramètres peuvent sembler étranges sur la partie CPU. En particulier :

  • Le paramètre « core per socket »
  • Le paramètre « vSocket »

Plus globalement, il faut comprendre que, chercher à optimiser le traitement CPU d’une machine virtuelle revient à s’interroger sur l’optimisation CPU de la totalité de la stack de virtualisation: l’hôte -> l’hyperviseur-> le matériel virtuel. Ces deux paramètres ont des impacts sur deux des composants de cette stack, nous allons expliquer pourquoi dans cet article.

Périmètre de l’article

Le sujet est large. C’est pourquoi cet article se limite volontairement à l’impact de la topologie des processeurs sur la virtualisation avec VMware et ESXi. Par exemple, le CPU scheduling n’est pas traité et pourra faire l’objet d’un autre article.

Rappel des composants VMware vSphere

Dans un datacenter, on va trouver des serveurs physiques sur lesquels sont installés des hyperviseurs natifs (type 1) nommés ESXi. Ces serveurs (des hosts) par le biais des ESXi portent des VMs (des guests). Le tout est  opéré par une suite logicielle nommée vCenter. L’administrateur à l’aide de l’IHM web ou du client lourd vSphere administre l’ensemble de cette ferme. Un lexique technique est proposé en fin d’article.

Dans la suite de cet article, nous ne parlerons que de VMware vSphere.

Structure d’un processeur et NUMA

En vrai

Une socket est l’emplacement physique sur lequel se branche le composant qui contient le ou les processeur(s).

Sur cette image on voit que les barrettes de RAM sont plus rapprochées de certaines sockets que d’autres. Cette affinité entre les processeurs et la mémoire est au cœur de la problématique NUMA (cf. chapitre suivant).

Ici on peut imaginer deux nœuds NUMA qui comprennent une socket chacun et la RAM immédiatement positionnée au dessus et en dessous de la dite socket.

Les nœuds NUMA

Mais qu’est-ce donc qu’un noeud NUMA ? Et pourquoi est-ce important de le comprendre ?

Une socket peut contenir plusieurs processeurs, des cœurs physiques. Ces cœurs font partie d’un ensemble que l’on nomme CPU package. Un CPU package contient donc X cœurs et un cœur ne peut faire parti que d’une seul CPU package.

Un nœud NUMA est l’association entre un CPU package et la mémoire accessible localement par l’ensemble des cœurs du CPU package. Quand on parle d’un nœud NUMA, on parle autant de processeurs que de mémoire.

Dans cette exemple, nous avons un serveur de 512 Go de RAM et de 16 cores répartis sur deux sockets.

  • Serveur physique de 512Go de RAM et de 16 cores
    • Socket 0:
      • Un package CPU
        • 8 cœurs
      • A accès à 256Go de mémoire en local et 256 Go en distant
    • Socket 1:
      • Un package CPU
        • 8 cœurs
      • A accès à 256Go de mémoire et 256 Go en distant

Il existe différents types de sockets et de processeurs. On peut trouver des sockets avec plusieurs CPU packages et donc plusieurs nœuds NUMA. On parle dans ce cas d’architecture Cluster-On-Die.

Le schéma ci-dessous illustre ce concept. On a une socket de 16 cœurs mais ces cores sont répartis en deux CPU packages de 8 cœurs. Chacun de ces CPU Packages ont un accès local à une partie de la RAM (256 Go pour être précis) ce qui fait deux nœuds NUMA pour un seul processeur.

Un autre exemple avec le processeur AMD Opteron 6174. Cette gamme de processeur dispose de 12 cœurs par socket mais répartis en deux CPU Packages de 6 cœurs. Si on dispose donc de 4 sockets, on va voir apparaître 8 nœuds NUMA de 6 cœurs.

Accès à la mémoire

Nous avons dit précédemment qu’un nœud NUMA est l’association entre un ensemble de cœurs regroupés dans un CPU Package et la mémoire (RAM). Pourquoi ?

Tout simplement parce qu’avec le concept NUMA (Non Unified Memory Access) il existe deux types d’accès à la mémoire :

  • Un accès dit local (un accès direct à la mémoire « proche », c’est à dire sans passer par les liaisons QPI (QuickPath Interconnect, bus de données entre les CPU) pour les technologies Intel

  • Un accès dit en remote, c’est-à-dire que l’on est obligé de passer à travers les liens QPI pour avoir accès à la mémoire

On trouve l’équivalent de la technologie QPI chez AMD sous le nom de HyperTransport.

Ce qu’il faut retenir c’est que l’accès, du fait que l’on soit obligé de passer par des bus supplémentaire, augmente le temps d’accès à la mémoire. Cette problématique d’accès à la mémoire est au cœur ( 🙂 ) des enjeux des constructeurs de CPU, et l’arrivée d’une nouvelle gamme de CPU est souvent accompagnée d’optimisations côté QPI ou HyperTransport.

La mémoire cache

L’accès à la mémoire est au centre des problématiques de performance, parce qu’un accès long à la mémoire bloque un processeur (qui attend, « iowait »). Plus le temps d’accès à la mémoire est long plus le processeur sera bloqué et terminera son calcul tardivement.

Pour palier à cette problématique les constructeurs ont implémenté différents niveaux de cache pour améliorer les temps d’accès. L’image ci dessous montre à quoi ressemble ces caches au sein d’un CPU.

Il existe deux grands types de cache:

  • Les caches non partagés (L1 et L2) c’est à dire ceux qui appartiennent à un cœur physique
  • Les caches partagés entre les cœurs d’une même socket physique. C’est le cas des caches type L3 et L4 qui font partis d’un ensemble que l’on nomme LLC (Last Level Cache)

Ce qu’il est intéressant de regarder, dans le tableau ci-dessus, sont les temps d’accès aux caches et à la mémoire. On remarque globalement une grande différence entre les temps d’accès aux différents niveaux de caches (Lx) et la RAM qu’elle soit locale ou non. Ces temps d’accès nous permettent de nous rendre compte de l’importance de rester le plus possible dans un contexte mémoire local et donc au sein d’un même nœud NUMA.

Résumé et Hyperthreading

Deux grands axes intimement liés quand on parle des nœuds NUMA :

  • L’accès mémoire qui se doit d’être le plus local et optimisé possible
  • les cœurs sur lesquels repose la VM doivent faire partis du même nœud NUMA pour optimiser l’allocation et l’accès mémoire par ces cœurs

Le schéma ci-dessous résume les différentes couches que nous avons vu dans les chapitres précédents:

L’hyperThreading (HT) est un terme commercial Intel. On trouve l’équivalent chez AMD avec l’architecture Bulldozer, qui implémente du CMT (Cluster Multi Threading), et plus récemment sur l’architecture Zen qui implémente du SMT (Simultaneous Multi Threading).

Il est à noter que dans le cas d’une utilisation de technologies type HyperThreading, les caches L1 et L2 sont partagés entre les deux cœurs logiques d’un même cœur physique.

L’enjeu du NUMA alignment

L’enjeu de cette partie est de décrire et expliquer l’importance des nœuds NUMA dans un contexte non virtualisé dans un premier temps et dans un contexte virtualisé dans un second temps.

Les nœuds NUMA sur du bare metal

Les nœuds NUMA n’ont pas une importance qu’au sein de contextes virtualisés.

Prenons l’exemple ici d’un serveur physique sur lequel est installé un système d’exploitation. L’OS quel qu’il soit voit la topologie NUMA des processeurs qui lui sont rattachés. Par des appels système, l’OS optimise lui même les allocations mémoires affectées aux applications installées. Cette optimisation se fait, tant que faire se peut, en fonction de la quantité de RAM demandée initialement par l’application et les espaces mémoires disponibles sur le serveur.

Au cours du temps, si l’application demande plus de RAM à l’OS ces même optimisations peuvent être assurées par l’OS ou par un administrateur système avec des outils type numad sous Linux.

Exemple :

Les nœuds NUMA pour une VM

Les nœuds NUMA, s’ils sont mal gérés, peuvent poser deux problèmes :

  1.  Le cas le plus classique : des cœurs sont alloués à une VM mais répartis sur deux nœuds NUMA distincts. Dans l’exemple ci-dessous, nous avons une VM de 8 vCPU répartis sur deux nœuds NUMA. Si on part du principe que la RAM allouée à la VM a été provisionnée sur la mémoire accessible en local par le nœud NUMA 0, les deux cœurs du nœud NUMA 1 y accèdent en remote
  2. Le second cas possible : la quantité de RAM demandée par la VM est plus importante que la quantité de RAM au sein d’un nœud NUMA. Dans ce cas, la RAM de la VM va être partagée au sein des deux nœuds NUMA et un accès en remote à cette mémoire va avoir lieu

Nous verrons dans les chapitres suivants comment se prémunir et superviser ces comportements.

Revenons à la problématique

On l’a vu en première partie de cet article, la définition d’une VM passe par la définition d’éléments de configuration qu’il est important de comprendre.

Une VM dans VMware vSphere

Une VM, c’est :

  • un OS
  • des resources de stockage
  • des interfaces réseaux
  • de la mémoire RAM
  • des resources de traitement (un nombre de vCPU)

Sur ce dernier point, celui qui nous intéresse le plus, on remarque que plusieurs éléments, configurables, définissent le nombre de vCPU :

  • vCPU = nombre de vSocket x cores per socket

Comme le montre l’image ci-dessus, le paramètre vSocket correspond à la socket « physique » vue par l’OS. Dans la VM de test Archlinux utilisée ici, dont le paramétrage sur l’hyperviseur VMware Fusion apparait à droite, on identifie clairement grâce à la commande « lscpu » :

  • 2 sockets
  • 2 processeurs (l’OS voit une socket de 1 cœur physique, chaque cœur possède un thread unique, il n’y a pas d’hyperthreading)
  • 1 nœud NUMA

Dans la suite de la présentation, ces paramétrages seront représentés sous la forme suivante :

vSocket et cores per socket

La notion de vSocket a été introduite dans vSphere 4.1 pour passer outre les restrictions des OS sur le nombre de CPU – dans les versions précédentes il n’y avait pas possibilité de paramétrer le nombre de cœurs par vSocket :

  • Le vSocket est vu par l’OS comme étant le CPU (la socket)
  • Le nombre de « cores per socket » est vu comme le nombre de cœurs par CPU
  • Ex : Un Microsoft Windows Server 2008 R2 Standard Edition ne supporte que 4 processeurs maximum

Les éléments de configuration « vSocket» et « cores per sockets » :

  • Affectent les performances lorsque le nombre de vCPU (totaux) paramétrés sur la VM est plus grand que le nombre de CPU dans le CPU package
  • N’affectent (normalement) pas les performances dans le cas contraire et peuvent permettre d’économiser en licence
Je dis « normalement » parce que VMware est on ne peut plus claire (cf. VMware Performance Best Practices on vSphere 6.0 White Paper) :
For non-wide virtual machines, the number of cores per virtual socket is not as critical as for wide virtual machines. On rare occasions, however, configuring cores per socket to a value other than 1 could influence guest CPU scheduling in either helpful or harmful ways. Careful testing is therefore recommended before changing this configuration.
Résumé : sur une VM dont les vCPU ne tournent pas dans un seul noeud NUMA (non wide), toucher au cores per socket n’a normalement pas de conséquences mais rien ne permet d’en être certain. Chaque cas nécessite d’être testé.
L’objectif n’est pas de tourner en dérision les propos de VMware, dans de nombreux cas (réel) la gestion des fermes VMware changent du tout au tout :
  • différentes gammes de serveurs au sein d’une même ferme
  • différentes gammes de CPU au sein d’une même ferme
  • parfois les administrateurs VMware privilégient la modification des cores per socket plutôt que le nombre de vSocket (ce qui va à l’encontre des best practices VMware)
  • souvent la configuration de la VM dépend plus de l’admin que des standards d’infrastructure

Pour conclure, dans une entreprise qui a un SI depuis plusieurs années, une ferme VMware est en général très hétérogène et ce sur plusieurs plans (software, hardware, etc.).

Dans ce genre de contexte, difficile de déterminer l’évolution des performances de la VM (que ce soit sur le CPU ou autre) au cours de son évolution dans le temps, en particulier si on ajoute un déplacement automatique de la VM sur les hosts qui composent la ferme VMware…

vSocket vs cores per socket

Pour vous montrer les conséquences de ces paramétrages depuis la machine invitée, voici quelques exemples:

L’OS voit 4 processeurs de 1 cœur physique (1 thread montre qu’il n’y a pas de HT parce que: x threads = x cœurs).

L’OS voit 2 sockets de 2 cœurs physiques.

L’OS voit 1 sockets de 4 cœurs physiques.

Les bonnes pratiques

Dans la littérature, il est recommandé de laisser le nombre de core per sockets à 1.

Pour de nombreuses raisons (en général du licencing), on peut être amené à mettre plus de 1 core per socket, dans ce cas :

  • Pour une « wide » VM, le nombre de cores par socket va déterminer la taille des vNUMA exposés à la VM (cf. chapitre suivant)
  • Pour une « non-wide » VM, modifier cette configuration peut, dans de rares cas, améliorer ou détériorer les performances de la machine par son influence sur le CPU scheduler (host)

Les « wides » VMs

Exposition du vNUMA

Depuis vSphere 5.0 il est possible de présenter au système invité la topologie NUMA via la technologie vNUMA. Le terme vNUMA est un terme spécifique à  VMware.

Ça a donc pour effet de permettre :

  • des optimisations NUMA depuis l’OS invité
  • des optimisations NUMA pour le/les application(s) du système invité

Par défaut, une VM est considérée comme « wide VM » si :

  • Le nombre de vCPU vu par la VM est strictement supérieur à 8 (chiffre par défaut dans la configuration VMware vSphere)
  • Le nombre de vCPU de la machine invitée dépasse le nombre de cœurs d’un nœud NUMA

La terminologie « wide VM » est un terme commercial utilisé par VMware.

Ce qu’il faut retenir: Quand une VM est une wide VM, la topologie NUMA est remontée à l’OS. On parle alors de vNUMA.

Faire remonter la topologie NUMA au guest

Plusieurs éléments de configuration permettent de paramétrer et gérer l’exposition de la topologie NUMA à l’OS de la VM. Ces configurations peuvent se faire par VM ou directement par host.

Comment vérifier la topologie NUMA remontée

De manière générale, sur un OS (ex avec Linux)

Nous l’avons vu, la topologie concerne autant les machines physiques que les VMs. Regardons ici comment afficher les informations liées à la topologie NUMA et comment les interpréter.

Nous l’avons vu, lscpu permet d’avoir des informations génériques sur tout ce qui est lié aux processeurs:

Sur notre machine de test, il y a deux sockets physiques, chacune contient:

  • 1 core physique (« cœurs par socket »)
  • de 1 thread (pas de HT, ligne « threads par cœur »)
  • 1 nœud NUMA (« nœuds NUMA »)
  • la taille des caches et leur nombre (cf. chapitre précédent)

On peut obtenir la correspondance et les relations entre ces différentes informations avec l’option « -p » ou « -e »:

Il faut lire cette sortie comme un tableau à double entrée. Le cœur physique 0 (« core » dans le tableau) appartient au nœud NUMA 0 (tout comme le core 1) et est sur la socket 0. Il a un unique cœur logique (« CPU » dans le tableau). Aucun des caches ne sont partagés (logique puisque sur des sockets distinctes, rappelez-vous).

L’exemple n’est ici pas très complexe, en voici un autre avec l’option « -p » qui a un peu plus la classe :

$ lscpu -p
# The following is the parsable format, which can be fed to other
# programs. Each different item in every column has an unique ID
# starting from zero.
# CPU,Core,Socket,Node,,L1d,L1i,L2,L3
0,0,0,0,,0,0,0,0
1,1,1,1,,1,1,1,1
2,2,0,0,,2,2,2,0
3,3,1,1,,3,3,3,1
4,4,0,0,,4,4,4,0
5,5,1,1,,5,5,5,1
6,6,0,0,,6,6,6,0
7,7,1,1,,7,7,7,1
8,8,0,0,,8,8,8,0
9,9,1,1,,9,9,9,1
10,10,0,0,,10,10,10,0
11,11,1,1,,11,11,11,1
12,0,0,0,,0,0,0,0
13,1,1,1,,1,1,1,1
14,2,0,0,,2,2,2,0
15,3,1,1,,3,3,3,1
16,4,0,0,,4,4,4,0
17,5,1,1,,5,5,5,1
18,6,0,0,,6,6,6,0
19,7,1,1,,7,7,7,1
20,8,0,0,,8,8,8,0
21,9,1,1,,9,9,9,1
22,10,0,0,,10,10,10,0
23,11,1,1,,11,11,11,1

On peut voir que les cœurs logiques (CPU) 0 et 12 partagent un certain nombre de choses :

  • ils sont sur la même socket (0)
  • ils sont sur le même cœur physique (0)
  • ils sont sur le même nœud NUMA (0)
  • ils partagent les même caches
    • L1i et L1d (évident, ils sont sur le même cœur physique)
    • L2 (idem)
    • L3 (parce que sur la même socket)

A propos des caches, on peut voir que le cœur logique (CPU) numéro 2 n’appartient pas au même cœur physique (core) que les 0 et 12 mais la même socket. Il n’a donc pas les mêmes cache L1x/L2 mais le même cache L3.

La commande « numactl –hardware » permet d’avoir plus de détails sur ce qui nous intéresse :

La distance ici exprime la latence d’accès à la mémoire. La  configuration de cet exemple étant simple, voici un autre exemple avec cette fois-ci 8 nœuds NUMA :

node   0   1   2   3   4   5   6   7
  0:  10  21  21  21  21  21  21  21
  1:  21  10  21  21  21  21  21  21
  2:  21  21  10  21  21  21  21  21
  3:  21  21  21  10  21  21  21  21
  4:  21  21  21  21  10  21  21  21
  5:  21  21  21  21  21  10  21  21
  6:  21  21  21  21  21  21  10  21
  7:  21  21  21  21  21  21  21  10

La valeur 10 représente un accès local à la mémoire (entre les nœuds 0 et 0 ou les nœuds 1 et 1, etc…). les autres des accès en remote.

Vu de la machine invitée (VM VMware) : coreinfo

Configuration des machines de l’infra pour ces exemples.

Host :

  • Socket: 2
  • CPU Package: 10
  • NUMA: 2

VM :

  • vSocket : 16
  • Cores per socket : 1

la commande « coreinfo » (équivalent de « lscpu » sous Linux):

On retrouve ici les même informations que dans le chapitre précédent mais sous une autre forme :

  • la quantité de cœurs physiques et le mapping par rapport aux cœurs logiques
  • la quantité de sockets et le mapping des cœurs physique par rapport aux sockets
  • des infos sur les nœuds NUMA et les cœurs physiques associés
  • des infos sur les caches

Vu du host

La commande « vmdumper » permet d’avoir les configurations d’une machine allumée sur un ESXi :

On y retrouve nos configurations VMware vSphere :

  • Mémoire/CPU de la VM
  • Cores per socket
  • vSocket
  • Nœuds NUMA
  • Nous parlerons des autres métriques dans le chapitre suivant

La commande « esxtop » permet de sortir des métriques plus liées à la vie de la VM au sein de l’ESX :

Les métriques intéressantes :

  • NRMEM : NUMA Remote Memory (doit être le plus bas possible)
  • NLMEM : NUMA Local Memory (doit être le plus élevé possible)
  • N%L:  pourcentage de la mémoire accédée en local par la VM
  • NMIG  : NUMA migration: Nombre de fois que la VM à migré d’un NUMA à un autre

La topologie processeur par VMware vSphere

Les couches

Chaque couche qui compose la stack de virtualisation (ici ESX et VM) s’approprie et enrichie la topologie CPU du host.

Reprenons notre modèle de nœud NUMA sur un host :

Ajoutons à ce modèle la couche ajoutée par l’ESX (hyperviseur de VMware).

On retrouve de nouveaux concepts :

  • NUMA Home Node : Surcouche de l’ESX qui interprète la topologie NUMA présente sur le host
  • pCPU : pour physical CPU, représente un cœur physique ou un cœur logique dans l’hyperviseur
  • NUMA Client : ensemble cœurs/mémoire remonté à la VM. Ça ne veut pas forcément dire que la VM voit la topologie NUMA

On ajoute la couche VM. On retrouve les vSocket et vCPU :

Décomposition du vNUMA

Plongeons donc au sein de ce NUMA Client qui nous intéresse tant. En le décomposant, on retrouve deux choses :

  • le Physical Proximity Domain (PPD)
    • il assure la corrélation entre un pool de vCPU et un pool de cœur physique au sein du même CPU package
    • C’est la garant de la relation suivante :
      • « j’assure que tel groupe de vCPU sera affilié à tel CPU Package » (qui peut changer au cours du temps en fonction des choix du CPU scheduler)
      • Ce n’est pas du pinning
    • il se construit automatiquement à partir du nombre de cœurs physiques présents au sein d’un CPU Package (sauf si le paramétrage « core per socket » n’est pas égal à 1, dans ce cas, c’est ce paramétrage qui détermine la taille du PPD)
    • il est utilisé pour le placement initial des vCPU et pour le load-balancing
  • le Virtual Proximity Domain (VPD)
    • il expose la topologie vNUMA à la VM
    • sa taille dépend du nombre de vCPU et du nombre de cœurs physiques sur la machine physique ou du paramétrage « core per socket » (pour les version ESX inférieures 6.5)
    • Peut reposer sur plusieurs PPDs

Reprenons notre modèle et ajoutons les VPDs et les PPDs. Vous trouverez ci-dessous, sous forme de schémas, tous les impacts possibles en fonction de la configuration pour laquelle on opte.

Dans cet exemple, on a créé une machine virtuelle. Ses configuration sont les suivantes :

  • cores per socket: 1
  • vSocket: 16
  • Total vCPU: 16 (16 x 1)

On a donc suivi les bonnes pratiques de base recommandées par VMware (cf. VMware Performance Best Practices on vSphere 6.0 White Paper) :

When creating a virtual machine you have the option to specify the number of virtual sockets and the number of cores per virtual socket. In general, we recommend leaving this at the default value of 1 core per socket (with the number of virtual sockets therefore equal to the number of vCPUs).
Ce qui nous donne la modélisation suivante :

Le VMdumper nous confirme cette modélisation :

On remarque cependant un commentaire intéressant : « Exposing multicore topology with cpuid.CoresPerSocket = 8 is suggested for best performance ».

Il serait donc intéressant, selon VMware, de modifier la configuration « cores per socket » pour avoir de meilleurs performances. Ce qui est normal :

  • Comme vu dans le chapitre précédent sur les Wides VMs, une VM est considérée comme étant une wide VM si la machine possède plus de 8 vCPU (paramètre par défaut)
  • ou si le nombre de vCPU de la machine invitée dépasse le nombre de cœurs d’un nœud NUMA

Ce log est cohérent avec les bonnes pratiques de VMware dans le cas de wide WMs (cf. VMware Performance Best Practices on vSphere 6.0 White Paper):

For wide virtual machines, be very careful about setting cores per virtual socket to a value other than the default (1 core per socket). It’s best to first try the default to determine what vNUMA size ESXi selects for your virtual machine in your environment. Once you know the vNUMA size, use it to choose a value for cores per socket.
For example, when running a 16-vCPU virtual machine on a host system with 10 cores per physical socket, ESXi will select a vNUMA size of 8. Once this vNUMA size is known, you would configure this virtual machine to have 8 cores per virtual socket.
Donc, si on crée une wide VM, cette fois-ci de 20 vCPU, et en suivant tous les conseils de VMware :
  • cores per socket: 10
  • vSocket: 2
  • Total vCPU: 20 (10 x 2)

On a la modélisation suivante :

  • Nos PPD sont répartis sur nos deux nœuds NUMA et se composent de l’intégralité des processeurs du host
  • On trouve autant de VPDs que de PPDs et ceux ci se composent d’autant de cores que ces derniers

Bref, tout est bien aligné… On voit qu’a travers cette configuration le travail du CPU Scheduler s’en retrouve simplifié. Vous aurez le temps de vous en rendre compte en jetant un œil aux modélisations suivantes 😉

Entrons maintenant dans la maison des horreurs de la configuration VMware.

Prenons l’exemple de l’élève qui à tout compris de travers et qui a toujours modifié le nombre de cores per socket plutôt que le nombre de vSocket.

Configuration de notre nouvelle VM:

  • cores per socket: 12
  • vSocket: 1
  • Total vCPU: 12 (12 x 1)

La modélisation associée :

  • un VPD de 12 cœurs et réparti sur deux PPDs
  • deux PPDs de 6 cœurs répartis sur les deux nœuds NUMA

On sent que ça va bien se passer…

On a donc une VM dont l’OS va voir un nœud NUMA au lieu de deux. La mémoire va vite se retrouver répartie entre les deux NHN (NUMA Home Node) et des accès en remote vont apparaitre. Le travaille du CPU scheduler au sein de l’ESXi va s’en trouver affecté et on peut s’attendre à beaucoup de context switch.

Prenons maintenant l’élève qui a compris à peu près la moitié de tous les concepts et qui, pour se rassurer, va donc tout mélanger.

Configuration de notre nouvelle VM :

  • cores per socket: 2
  • vSocket: 6
  • Total vCPU: 12 (2 x 6)

La modélisation associée :

  • six VPDs de 2 cœurs
  • six PPDs de 2 cœurs

Un carnage, la VM va voir une topologie de six nœuds NUMA au lieu des deux qui existent réellement. Au niveau de l’ESXi, le CPU scheduler va devoir scheduler 6 PPD au lieu de 2. L’OS quant à lui va être amené à faire beaucoup plus d’optimisations que nécessaire et qui, au final, n’en seront pas.

Tous ces exemples montrent bien l’impacte de l’option « cores per socket » sur la taille des VPDs/PPDs et toutes les horreurs associées si l’on ne fait pas attention.

L’article « Does corespersocket Affect Performance » publié sur le blog de VMware appuie ces théories.

Faut-il le répéter ? Le plus simple reste tout de même de faire en sorte de n’occuper qu’un seul nœud NUMA.  Pourquoi ? Tout simplement parce que le travail de l’OS de la VM et de l’ESXi vont s’en trouver simplifiés. Comment faire si la quantité de vCPU de la VM dépasse le nombre de cœurs d’un nœud NUMA ? (Je pars ici du principe que la quantité de RAM souhaitée sur la VM soit inférieur à la quantité de RAM du nœud NUMA.)

C’est là que l’option PerferHT entre en jeux. Pour rappel, cette option va faire en sorte que les cœurs logiques comptent lors de la contruction du NUMA Home Node.

Configuration de notre nouvelle VM :

  • cores per socket: 12
  • vSocket: 1
  • Total vCPU: 12 (12 x 1)

La modélisation associée :

  • un VPD de 12 cœurs
  • un PPD de 10 cœurs

Au final notre VM, même si elle a plus de vCPU que de cœurs physiques sur notre nœud NUMA, tient au sein d’un même NUMA Home Node. Attention cependant, il faut avoir en tête que ce sont des cœurs logiques (HyperThreading ici) qui vont être utilisés. En fonction de l’applicatif de la VM cela peut dégrader ou améliorer les performances.

Et si on validait cela avec un vrai benchmark ?

Pour valider ces différentes configurations et les théories associées, enioka prépare un benchmark qui prendra en compte :

  • les config CPU (dans un contexte de stress sur l’host ou non)
  • l’applicatif sur la VM (workload court et long)
  • d’autres technologies de virtualisation

Dès que ce benchmark sera réalisé, un compte rendu sera fait dans ce blog.

Les nouveautés (vSphere 6.5)

vSphere 6.5 permet de rattraper beaucoup de bêtises, en particulier, pour la topologie vNUMA :

  • L’option cores per socket est découplée de la taille du VPD
  • Le sizing du VPD se fait automatiquement par VMware

Conclusions

Quand on ne connait pas, on ne touche pas

Dans le doute, laissez le paramètre « cores per socket » à 1. Faites des tests dans le cas contraire.

Les bonnes questions à se poser

Le sujet est complexe, il y a beaucoup de paramètres à prendre en compte et deux bonnes questions à se poser :

  • Ai-je vraiment besoin de ce niveau de performance ?
  • Ai-je vraiment vraiment besoin d’autant de vCPU ?

Diagramme de choix

Si la réponse à ses deux questions est « oui », vous pouvez-vous aider de ce diagramme de choix pour déterminer la configuration CPU à faire sur votre VM.

Faites tout de même attention, ce diagramme n’a pas la prétention de vous donner à coup sûr la bonne configuration pour votre VM et surtout il ne remplace en rien des tests de performance et d’intégration. Il est peut probable que votre VM soit seule au monde, mais plutôt ajoutée au sein d’une ferme existante et potentiellement vieillissante (la version des ESXi a une grande importance). Sans compter que les hosts qui composent cette ferme peuvent porter des CPU de gammes différentes et donc avec des topologies NUMA différentes. Les impacts peuvent être très visibles si le DRS en mode automatique est activé.

Webo/Biblio/Humanographie

  • Les livres :
    • The CPU scheduler in VMware vSphere 5.1 : pour les impacts du NUMA alignment
    • VMware vSphere Performance : Designing CPU, Memory, Storage, and Networking for Performance-Intensive Workloads. Pour les éléments de configuration et plus tard pour le CPU scheduling
  • Et les hommes :
    • Gael Lalleman : pour nos discussions passionnées sur le sujet

Lexique

  • vCenter : API et IHM qui permet d’opérer les fermes vSphere VMware (permet de communiquer avec les ESX)
  • vSphere : Solution qui comprend vCenter + ESXi + Modules vCenter (ex: vSAN)
  • ESXi: vSphere ESXi est un hyperviseur bare-metal (type 1 – natif)
  • Host: Machine physique sur laquelle est installée ESXi et qui héberge les VMs crées
  • Guest: Une VM qui repose sur un host
  • NUMA: Non Unified Memory Access, architecture répartissant la mémoire physique par ensemble de cœurs processeurs
  • Hyperthreading: Technologie Intel (HyperTransport chez AMD) permettant de présenter deux cœurs logique à partir d’un cœur physique
  • Socket: Connexion physique d’un processeur à la carte mère (HW)
  • vCPU: Virtual CPU, le matériel présenté à la machine virtuelle
  • «Wide » VM : Une VM dont la topologie NUMA lui est remontée par la technologie vNUMA
  • PPD: Physical Proximity Domain, pool de cœurs physiques associés à un CPU package
  • VPD: Virtual Proximity Domain, (ensemble de) pool(s) de cœurs logiques/physiques associé(s) à un ou plusieurs PPD
  • pCPU: Physical CPU vu par l’ESX (peut-être associée à un processeur logique ou physique)
  • vSocket: Virtual Socket (vu par la VM comme une socket physique)
  • core/coeur physique: processeur physique intégré à une socket physique
  • core/coeur logique: processeur logique s’exécutant sur un processeur physique

Pour aller plus loin

Des articles complémentaires sont en cours de rédaction pour prolonger la réflexion  :

  • Benchmark sur les configurations CPU pour VMware/KVM/Hyper-V (permettra de valider/réfuter les théories avancées ci-dessus en fonction des contextes et des paramétrages) – à venir
  • VMware CPU Scheduling: fonctionnement et principes – à venir
  • Virtualisation des CPU – à venir

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.