Une instance d’ERP est toujours une architecture en trois tiers

  • Un serveur de base de données
  • Un serveur applicatif
  •  Un serveur de clients historiquement propriétaires, mais de plus en plus web (et de plus en plus responsive)

Le serveur SQL de base de données esthistoriquement utilisé à bas niveaux par laplupart des ERP pour être le plus compatible possible selon le SGBD (sauf certains progiciels qui font le choix d’être mono SGBD et d’enutiliser à fonds les possibilités, notamment avec ORACLE (PL-SQL, triggers...) ou POSTGRES (objets).

Ce serveur manipule des bases de grandes taille (des Go, souvent des To), et les approches « In Memory » se répandent. Elles gèrent les données en mémoire dans une base de données virtuelle accélérant  grandement les traitement (notamment les traitements de masse)


Architecture type d'une instance ERP

Figure 20. Architecture type d'une instance ERP

Le serveur d’application repose en général sur une architecture propriétaire de l’éditeur (peu d’ERP utilise Jboss ou équivalent). Pour réduire le coût de maintenance du code, les éditeurs ont en général structuré leur application en couches :

  • Une couche de gestion des données, qui vient assurer l’intégrité de données qui n’est pas toujours totalement assurée dans le SGB

  • Une couche métier assurant la mise en œuvre des règles de gestion selon le paramétrage

  • Une couche orientée services, souvent publiée en XSLD

  • Une couche de processus codée en dur dans l’application (la plupart des ERP n’utilisent pas les moteurs de workflow externes)

  • Une couche de présentation organisant les écrans et l’ergonomie de navigation

Dans les plus anciens ERP, le serveur d’application communique selon un protocole propriétaire avec des clients propriétaires, mais de plus en plus souvent, il communique de manière propriétaire avec un serveur HTTP.Le serveur d’application Odoo repose lui sur une architecture MVC (Model/Vue/Controleur). Certains ERP comme INFOR LN intègre un serveur de type réseau social dans le serveur de présentation. Des offres d’ERP dans le cloud se développent.

L’évolution récente vers le « in-memory »

Historiquement, un ERP est organisé autour d’une base de données de grande taille (To) et quelle que soit la puissance des SGBD, le traitement sur des centaines de tables dont certaines contiennent des millions de lignes représentent des temps d’accès non négligeables.

De même, historiquement, on navigue dans un ERP à travers des processus prédéfinis, à travers une logique métier qui fait qu’on cherche un objet particulier dans le module qui le gère (un fournisseur dans le module achat, un ordre de réparation dans le module services...

Dates clefs de l'évolution du SQL au In-Memory

Figure 21. Architecture: du SQL au In-Memory

De plus en plus, les capacités des serveurs en puissance de calcul et en taille de mémoire, permettent de gérer entièrement la base de donnée en mémoire, offrant alors des possibilités « temps réel » pour l’application de règles complexes à travers l’ensemble des modules. On passe alors d’une logique « par module » selon des « processus » de gestion prédéfinis, à une logique d’application en temps réel de toutes les règles de gestion possible, dans tous les modules concernés.

De même, on peut chercher de plus en plus « comme google », sans savoir où il faut chercher, mais en cherchant sur des mots clés, des chaines de caractères, des tags, qui vont mélanger tous les types d’objets.

La dimension métier porté par les processus et les structures de données peut disparaitre ainsi derrière la puissance de calcul, avec des effets positifs sur la rapidité de réponse à une question peu formalisée, mais des risques de perte de maitrise des processus et des dépendances entre les objets métiers.