La plupart des systèmes d’information et des applications implémentées il y a dix ans (ou parfois moins) sont de conception monolithique, c’est-à-dire qu’ils sont composés d’une ou de quelques très grosses applications, qui partagent généralement une ou quelques bases de données dont la taille peut atteindre des centaines de giga octets voir même des téraoctets.
Les inconvénients des architectures monolithiques sont nombreuses :
- Modifications ou nouvelles fonctionnalités plus difficiles à implémenter
- Temps de déploiement de nouvelles versions fortement rallongé
- Complexification des opérations de maintenance, temps d’indisponibilité rallongées
- Couplage fort entre les différentes composantes du SI : effets de bord, tests difficiles à réaliser
- Portabilité et difficulté (voire impossibilité) à être déployées dans le cloud
- Etc.
En bref, il est impossible d’avoir un système d’information agile avec une architecture monolithique.
Comment prendre le chemin de l’agilité et enfin abandonner une architecture monolithique ?
La question est primordiale quelque soit votre parc applicatif : progiciels du marché, développements internes, développements sous traités, ou une combinaison de ces applications.
Si vous utilisez des progiciels du marché :
- Lors de l’évaluation de nouveaux progiciels, assurez-vous qu’ils proposent des API en libre accès (qui ne nécessite pas l’intervention d’un intégrateur agréé) et bien documentés. Cela vous permettra d’interfacer le progiciel avec vos autres applications, et/ou de développer de nouvelles fonctionnalités ou modules qui pourront communiquer avec le progiciel.
- Lors de l’étude du renouvellement d’un ERP, ne privilégiez pas à tout prix un logiciel unique, envisagez l’utilisation de plusieurs logiciels (car plus adaptés à vos besoins que l’ERP) qui communiqueront entre eux et avec un éventuel ERP.
- Evitez les développements spécifiques utilisant la technologie de l’ERP et directement embarqués dans l’ERP : cela vous lie fortement à l’intégrateur et à l’éditeur, cela complexifie les mises à jour, et il est difficile de reprendre la main sur ces développements par une équipe interne. On parle bien entendu ici de développements de nouvelles fonctionnalités ou de nouveaux modules. Les petits développements (par exemple, le rajout d’un champ) peuvent se faire directement dans l’ERP.
Si vous développez des logiciels (interne et/ou sous-traités), plusieurs technologies permettent de prendre le chemin de l’agilité et de la fragmentation du système d’information.
Tout comme les sites web doivent impérativement être conçus « mobile first » (priorité sur la version mobile et en adaptant progressivement le web design pour les écrans plus large), il est aujourd’hui essentiel d’avoir une approche « cloud first » dans la conception et l’architecture de tout nouveau développement. Une approche « cloud first » doit garantir que l’application développée pourra fonctionner sur un cloud « serverless » (Azure App Service, AWS Elastic Beanstalk, etc.) et donc qu’elle aura les caractéristiques suivantes :
- Utilisation d’API pour la communication avec le reste du SI
- Indépendance aux sous couches matérielles et logicielles
- Portabilité (facilité de déploiement dans un autre environnement)
- Facilité de modification et rapidité de déploiement
- Utilisation de langage et frameworks modernes
- Utilisation de protocoles de communication standards
- Autonomie (base de données propre à l’application également déployée dans le cloud)
- Sécurisation
- Etc.
L’approche « cloud first » doit être utilisée même si vous avez l’intention de déployer l’application sur vos propres serveurs.
Vos développements logiciels doivent également généraliser le développement et l’utilisation d’API (« Application Programming Interface »), qui permettent à vos différents logiciels de communiquer ensemble : échange de données, partage de fonctionnalités et d’algorithmes, etc.
Les API sont des composants réutilisables et qui garantissent l’intégrité des données dont elles sont responsables. Les API permettent également d’ouvrir le système d’information à des tiers, favorisation ainsi l’innovation, la création de nouvelles sources de revenus, l’élargissement du périmètre de l’entreprise, l’augmentation de la valeur de l’entreprise (facilité d’intégration en cas de rachat ou fusion), etc.
Si vous avez encore des doutes : les API ont largement contribué au succès insolent d’Amazon suite à la directive « tout API » de Jeff Bezos en 2002.
Enfin, si vous développez des logiciels, utilisez une architecture « microservices » : il s’agit d’une technique de développement logiciel qui structure l’application comme une collection de services avec un couplage faible. Les microservices sont donc des composants logiciels individuels, qui peuvent être facilement modifiés et déployés, et qui utilisent généralement des API pour communiquer entre eux. Les microservices apportent flexibilité, agilité et efficacité, et peuvent être de nouvelles sources de revenus pour l’entreprise. A noter que certains Frameworks facilitent la mise en œuvre de microservices (ABP Framework par exemple).
Pour conclure, le chemin vers un système d’information agile doit s’inscrire dans une stratégie d’architecture clairement définie et planifiée dans le temps. Les équipes informatiques internes (DSI, développeurs, architectes, administrateurs, etc.) doivent s’approprier cette stratégie et bien en comprendre les enjeux. Cette appropriation sera finalement le meilleur levier pour favoriser la transition vers un système d’information agile et l'abandon d'une architecture monolithique!