Développer des logiciels de manière composable, à l’aide de portions de code, semble en effet bien plus flexible et facile que de créer des applications sous forme de blocs verticaux monolithiques intégrés. Concrètement, cela signifie qu’il sera aussi plus facile d’exploiter des technologies comme l’automatisation robotisée des processus (RPA), l’intelligence artificielle ou la kyrielle de fonctionnalités d’hyper-automatisation disponibles aujourd’hui pour schématiser les workflows et optimiser les processus métier.
Ainsi, dans le monde de l’informatique d'entreprise, l'utilisation d'une infrastructure composable constituée de composants indépendants (qui peuvent être remplacés en cas de besoin) est déjà largement appliquée. Mais en matière de BPM (automatisation des processus métier), peu d’acteurs appliquent cette approche à forte valeur ajoutée, alors que les DSI sont de plus en plus confrontés à de nombreuses pressions de la part de leurs équipes en quête de réactivité et de rapidité pour accélérer leur "go-to-market". Pourquoi ?
Les plateformes actuelles d'automatisation des processus métier déploient des applications qui dépendent toutes de ressources partagées. L'équipe DevOps doit ainsi prendre en compte l'interopérabilité et l'intégration entre un groupe d'applications utilisant des ressources partagées pour les nouveaux développements, les nouveaux déploiements et la maintenance. Cela peut s’avérer complexe, prendre du temps et nécessiter des tests approfondis avant que les mises à jour soient déployées.
De même, chaque fois que la plateforme d'applications de processus est mise à niveau (nouvelle version) pour bénéficier de nouvelles fonctionnalités, ou lorsqu'une maintenance d’une seule et même application est nécessaire, toutes les applications sont affectées par la nécessité de mettre ponctuellement le système hors ligne, entraînant un coût élevé en fonction du temps d’arrêt.
Par ailleurs, la mise à l'échelle d'applications de processus métier groupées peut représenter des coûts inutiles car elle est appliquée à l'ensemble des applications, alors que toutes les applications n’en ont pas forcément besoin.
C’est pourquoi une approche consistant à construire des applications d'entreprise à partir d'éléments interopérables permet de résoudre certaines de ces problématiques.
En matière de développement de logiciels, la notion de composabilité est appliquée par le biais de la conteneurisation, une approche qui, comme nous l’avons déjà souligné, est largement utilisée par les équipes DevOps (utilisation croissante de plateformes telles que Docker et Kubernetes).
Or, les technologies BPM s'inscrivent parfaitement dans cette approche d’architectures composables, alors que les applications internes sont déjà conçues sur la base d'éléments composables : processus, sous-processus, connecteurs, services, morceaux de code réutilisables, règles métier et widgets d'interface utilisateur, pour n'en citer que
quelques-uns.
L'approche des "Self-Contained Apps" (applications autonomes) combine ainsi les avantages des approches et des technologies de conteneurisation à la puissance des technologies BPM. Le socle BPM offre une grande extensibilité pour s'intégrer à l'informatique d'entreprise, avec une bonne auditabilité, traçabilité et conformité, alors que, dans le même temps, le déploiement d'applications individuelles à l'aide de conteneurs offre une livraison plus rapide, une portabilité et une gestion plus facile.
Grâce aux "Self-Contained Apps", les équipes DevOps peuvent déployer plus facilement des applications complexes, les livrer en continu et favoriser l'innovation, tout en accélérant leur "go-to-market". Chaque "Self-Contained App" peut être déployée individuellement, indépendamment et rapidement, afin de fournir toujours plus de valeur, en fonction du volume et du rythme des activités.
En conclusion
Si les machines virtuelles fonctionnent bien sur les architectures monolithiques classiques, les conteneurs sont compatibles, quant à eux, avec les technologies émergentes telles que le cloud computing, l’approche CI/CD (intégration continue) et le DevOps. En bref :Le développement et le déploiement indépendants des "Self-Contained Apps" se traduisent en général par une mise en production plus rapide des applications.
La mise à l'échelle d'une application indépendante est plus simple et peut être appliquée à chaque application individuellement.
Les coûts de maintenance des applications sont réduits, grâce à des mises à jour plus récurrentes et moins importantes.
La productivité des équipes de développement est meilleure et la mise en œuvre de nouveaux projets facilitée.
L'équipe commerciale bénéficie d’un meilleur contrôle de la maintenance planifiée (calendrier des temps d'arrêt) car chaque application autonome n'est plus dépendante d'un calendrier de plateforme partagée.
Par Nicolas Chabanoles, Chief Technical Officer chez Bonitasoft
