Guides Essentiels
Voir tous les articles de ce guide
Conseil
Cet article fait partie de notre guide: Le BPM : une clé pour la modernisation et la transformation numérique des entreprises

BPM et containers : un tandem, symbole de la convergence en entreprise

Le BPM a fort à gagner à supporter les containers, et ce, pour le bien des entreprises. Dans cet article, Tom Nolle explique comment ce duo s’inscrit dans la modernisation des architectures applicatives.

Tom Nolle
par
Publié le: 12 déc. 2017

Avec des applications de plus en plus « découpées » sous la forme de services et composants, et la nécessité chez les développeurs d’imaginer des workflows pour les relier entre eux, le BPM (Business Process Management - gestion des processus métier) joue un rôle clé dans l’architecture applicative. Si l’on ajoute à cette équation le fait que les containers gagnent aussi en importance dans les entreprises, il devient impératif de comprendre les relations qui existent entre ces deux mondes.

Le BPM permet de définir les périmètres de chaque composant de façon efficace - ainsi que les workflows associés - pour gérer des applications en containers. Les outils du BPM peuvent quant à eux bénéficier des containers pour l’intégration. Mais pour cela, il s’agit d’abord d’élargir la portée du BPM en prenant en compte l’ensemble des applications et de coupler les politiques associées aux containers, à celles du métier.

Le BPM consiste à définir et modéliser les processus métier, généralement pour optimiser l’usage de l’IT. Un diagramme BPD (Business Process Diagram) est ainsi créé. Il peut être utilisé pour définir les workflows qui ensuite peuvent conduire à une meilleure gouvernance en général et à une intégration optimisée des systèmes, par exemple. Dans ce cas, il existe deux façons de supporter le BPM : pour structurer le déploiement des containers et ces derniers pour héberger les outils du BPM.

Il serait faux de dire que les containers sont impossibles à mettre en place sans le BPM. D’ailleurs, la plupart des entreprises déploie des containers sans BPM. Toutefois, cela permet de caler la structure de l’application, les workflows et les cycles de vie sur les processus métier que l’application doit justement supporter. En résulte alors des déploiements plus efficaces – et des usages optimisés de containers.

Le diagramme : un point de départ

A diagramme BPD est un bon point de départ pour démarrer une stratégie autour des containers. Si les applications et les composants y sont cartographiés, il est alors facile de repérer les dépendances de chaque élément et de relier l’IT aux métiers.  Cela montre comment chaque composant est connecté aux processus métier, et donc comment ils doivent être regroupés pour être containeurisés. D’une façon générale, les applications et les composants associés au même processus doivent être rassemblés dans des pods ou clusters, puis orchestrés dans un tout cohérent.

Ce qui d’ailleurs n’a pas échappé aux utilisateurs de Kubernetes. Selon eux, les diagrammes BPD permettent de mieux structurer la façon dont Kubernetes déploie les applications – les relations entre composants sont optimisées ; l’intégration inter-applicative facilitée.

De plus en plus d’entreprises utilisent le BPM, comme un moyen pour intégrer les workflows de chaque composant et rendre ainsi les applications métier plus granulaires, mais sans avoir recours à de la programmation. Cela étend ainsi les relations qui existent entre le BPM et les containers en plaçant les workflows au cœur de l’application, elle-même hébergée dans des containers. Dans ce cas, le BPM réside dans un pod et peut gérer les workflows entre composants.

Evidemment, il est fort probable que les utilisateurs trouvent cela plus simple à réaliser avec des outils pré-intégrés. Red Hat propose par exemple OpenShift et Jboss BPM et a publié des bonnes pratiques pour connecter les deux et obtenir une intégration optimale. Dell, HPE, IBM, Microsoft et Oracle ont aussi des telles offres BPM + containers, mais l’intégration repose davantage sur des pratiques spécifiques, et peu d’exemples sont proposés. Cela devrait changer avec le temps, lorsque cette proximité BPM / Containers deviendra plus claire – ce qui est fort probable au regard de la montée en puissance des containers dans les entreprises.

Définir et tracer les workflows

L’un des exemples les plus parlants du tandem BPM / Containers est certainement celui de Box Relay, une offre de gestion de workflows  de Box et d’IBM à destination des particuliers ou petites entités. Avec cet outil, vous pouvez créer des workflows et on peut suivre des tâches en cours. Cela est une façon de démocratiser un peu plus le BPM – et en tâche de fond, de faciliter l’intégration de la connaissance des processus métier aux déploiements de containers.

L’intégration de cette connaissance s’effectue en fait à la main. Box Relay ne propose pas de connexion à des outils comme Kubernetes. Ce qui manque également : comment un BPM d’entreprise peut y être intégré.

Cela soulève la plus grosse question en matière de relations entre le BPM et les containers. Si tous les deux sont des outils d’entreprise, le BPM est plus centré sur le métier. Les processus métier et leur support sont ce qui justifie l’IT. Les containers sont un moyen d’héberger les applications et logiquement devraient être utilisés dans un contexte BPM. Des outils comme Box Relay ont la capacité d’étendre la portée d’un système BPM et d’en faire profiter un spectre plus large de métiers dans l’entreprise.

La convergence du BPM et des containers correspond à une logique dans l’entreprise, où beaucoup d’activités tendent aussi à converger. L’association du développement agile, du Shadow IT et de la transformation numérique visent en effet à rendre l’IT plus réactif aux besoins métier. Ces facteurs sont de plus en plus importants. 

Pour approfondir sur BPM et RPA