Business Process Management

Business Process Management
De la modélisation à l’exécution Positionnement par rapport aux Architectures Orientées Services PARTIE 2 Extrait du BPM Whitepaper de Tanguy Crusson société Intalio

Plan INTRODUCTION AU BPM L’IMPORTANCE DE LA STANDARDISATION
PROCESSUS MÉTIER : DE LA MODÉLISATION À L’EXÉCUTION ARCHITECTURES ORIENTÉES SERVICES CONCLUSION

BUSINESS PROCESS MANAGEMENT
INTRODUCTION AU BPM L’IMPORTANCE DE LA STANDARDISATION PROCESSUS MÉTIER : DE LA MODÉLISATION À L’EXÉCUTION ARCHITECTURES ORIENTÉES SERVICES CONCLUSION

Rappel des objectifs des outils BPM
L’objectif des outils de BPM est de permettre aux utilisateurs métiers de collaborer avec les équipes techniques pour rendre les processus de l’entreprise exécutables et contrôlables. Cela implique en particulier les besoins suivants : Permettre la capitalisation sur les processus métiers de l’entreprise déjà modélisés : capacités d’import / export avec les outils de modélisation traditionnels. Offrir la possibilité de modéliser les processus en plusieurs niveaux. Les utilisateurs métiers doivent pouvoir modéliser leurs processus de manière complète les utilisateurs techniques lier les activités modélisées dans les processus aux applications / services du SI pour les rendre exécutables. L’outil doit permettre la gestion de versions, l’analyse d’impact d’une modification d’un processus, etc.

Rappel des objectifs des outils BPM (suite)
Fournir les capacités de génération / déploiement / exécution de BPEL en natif : aucun code ne doit être réalisé à la main, ce qui aurait pour impact de limiter les possibilités de modification des processus par les utilisateurs métiers. Offrir la possibilité de construire des interfaces utilisateurs complexes pour accéder aux processus, et cela pour deux besoins. Premièrement, pour permettre la gestion de tâches de type workflow pour les utilisateurs prenant part aux processus. Deuxièmement, il doit être possible de construire des dashboards destinés aux décideurs ou utilisateurs techniques permettant de suivre le déroulement des processus et anticiper ou corriger les sources d’erreurs.

Etapes de modélisation
La modélisation d’un processus métier se fait en plusieurs étapes: Les utilisateurs métiers définissent un «processus abstrait», qui définit le comportement du processus sans informations techniques Les utilisateurs techniques lient les activités du processus abstrait aux applications / services du SI de l’entreprise, pour le rendre exécutable On va étudier l’exemple d’un processus simple de Procurement permettant de gérer les demandes d’achat des employés d’une entreprise

Définition du processus abstrait
Les processus abstraits sont une représentation haut niveau des processus métiers. La définition des processus abstraits est indépendante des aspects techniques: on ne précise pas quelles actions sont effectivement réalisées par les activités comment une demande de devis est reçue quelle application est utilisée pour vérifier la disponibilité des produits etc.

Définition du processus abstrait: Processus de haut niveau
Le processus de Procurement étudié comporte cinq étapes: Réception d’une demande de devis de la part d’un utilisateur ayant les droits adéquats ; Transmission de cette demande de devis au fournisseur, et attente de sa réponse. Dans cette étape, si la réponse n’arrive pas après deux jours, le fournisseur est relancé par ; Transmission du devis à l’utilisateur, et attente de sa validation ; Transmission du devis au manager de l’utilisateur et attente de sa validation ; Si l’utilisateur et le manager ont validé le devis, un bon de commande est envoyé au fournisseur et l’utilisateur est notifié.

Définition du processus abstrait: Processus de haut niveau (suite)
Ce processus de haut niveau peut être représenté de la façon suivante: L’activité «Receive RFQ from User» démarre le processus «Send RFQ to supplier and receive Quote» gère l’envoi de la demande de devis au fournisseur et la reception de la réponse «User validation» gère l’acceptation du devis par l’utilisateur ayant effectué la demande de devis «Manager approval» gère l’acceptation du devis par le manager de l’utilisateur «Send Purchase Order to supplier» gère la transformation du devis en bon de commande et sa transmission au fournisseur

Définition du processus abstrait: Détails fonctionnels
La phase suivante consiste à détailler les sous processus représentés dans la phase précédente. Par exemple, le sous-processus «Send RFQ to supplier and receive Quote» peut être formalisé de la façon suivante : La demande de devis, reçue de la part de l’utilisateur dans l’étape précédente, est transmise au fournisseur. Le processus attend la réception d’un devis de la part du fournisseur. Si les éléments demandés par l’utilisateur ne sont pas disponibles, l’utilisateur est notifié et le processus se termine. Sinon, le processus suit son cours.

Définition du processus abstrait: Détails fonctionnels (suite)
A ce niveau on définit des règles métiers conditionnant le déroulement du processus. Ici, le choix est simple : les produits demandés par l’utilisateur sont ils disponibles ? Mais il est possible d’utiliser des règles métiers plus complexes, basées sur un historique de commandes ou un profil utilisateur par exemple. Ces règles métiers peuvent être modélisées dans l’outil de BPM, ou externalisées pour être traitées par le moteur de règles de l’entreprise. On définit de même les quatre autres étapes du processus. Une fois cette tâche réalisée, les utilisateurs techniques entrent en jeu pour lier les activités définies dans le processus avec les applications / services du SI.

Rendre le processus exécutable
Le processus abstrait est la base utilisée par les équipes techniques pour créer un processus exécutable. Pour rendre un processus exécutable, l’équipe technique renseigne un certain nombre d’informations techniques : le format les messages échangés, les protocoles de transport utilisés, les applications impliquées dans le processus par le biais de leurs connecteurs, les transformations de données effectuées, l’intégration des utilisateurs comme participants au processus, etc. Un processus exécutable, une fois modélisé, peut être déployé sur un moteur BPMS qui gère alors le contrôle de son exécution.

Rendre le processus exécutable
En particulier, dans notre exemple de processus de Procurement: L’envoi du devis au fournisseur se fait par un appel de Web Service : le fournisseur propose un Web Service .Net. Le devis est transmis par le fournisseur au processus par appel de Web Service, de manière asynchrone. Si le devis n’est pas reçu au bout de deux jours, un mail est envoyé au fournisseur. L’activité « Cancel RFQ » notifie l’utilisateur que les produits demandés ne sont pas disponibles. Cela peut se faire de plusieurs façons : envoi de mail, assignement d’une tâche de type workflow, etc. Dans notre exemple, nous assignons une tâche à l’utilisateur lui notifiant un message.

Rendre le processus exécutable (suite)
Ces éléments techniques peuvent être manipulés de manière graphique en utilisant un outil de BPM complet. Voici par exemple la représentation correspondante

Rendre le processus exécutable: Manipulation des données
Le format retenu pour représenter / manipuler les données dans les outils de BPM est le XML. Il est alors possible de capitaliser sur la spécification XML-Schema pour définir le format des messages échangés entre les participants d’un processus. Par exemple, le devis du fournisseur est transmise au processus via un message SOAP, donc un message XML, contenant des informations sur : le contact client (nom, prénom, téléphone, ), des informations sur les produits demandés (référence de produit, nom du produit, quantité demandée, prix proposé), etc. :

Rendre le processus exécutable: Manipulation des données (suite)
Toutes les données entrantes / sortantes sont stockées dans l’état du processus. En général, les outils BPM fournissent un utilitaire « Mapper », permettant d’effectuer les transformations de données nécessaires. Ainsi, les données du devis reçu de la part du fournisseur peuvent êtres réutilisées par la suite, par exemple pour transmettre le devis au client.

Rendre le processus exécutable: Participation des applications aux processus
Un des objectifs techniques majeurs du BPM est de permettre aux entreprises de capitaliser sur les investissements qui ont été réalisés au niveau du SI. Certains outils (IntalioDesigner) permettent d’introspecter les applications / services du SI pour les intégrer aux processus en tant que participants. En particulier, dans notre exemple, le fournisseur propose un Web Service .Net permettant de transmettre un devis, ou de transmettre un bon de commande. On ajoute ce Web Service en tant que participant au processus (en l’appelant « Supplier »), et utilise son opération receiveRFQ en tant qu’activité (nommée « Receive RFQ ») pour transmettre le devis reçu de la part de l’utilisateur au fournisseur, après une transformation simple réalisée avec le Mapper :

Rendre le processus exécutable: Participation des applications aux processus (suite)

Il est possible d’introspecter et d’utiliser comme participants / activités aux processus des classes Java – par exemple une API propriétaire permettant d’accéder à un progiciel – des EJB – Certains outils introspectent des EJB présents sur un serveur et leurs méthodes des bases de données: introspection de procédures stockées ou de requêtes SQL, des connecteurs permettant d’accéder aux ERPs, des MOMs, etc. Ainsi les utilisateurs techniques capitalisent sur les applications / services du SI, et les utilisent de manière visuelle en tant que participants aux processus métiers.

Dans notre exemple l’outil Intalio Designer fournit une vue unique XML de tous ces services : on manipule de la même façon un connecteur Java, une base de données ou un Web Service, en utilisant le Mapper. Notons que les communications doivent pouvoir être indifféremment synchrones ou asynchrones, quelle que soit la technologie utilisée pour la communication. C’est le cas des activités « Receive RFQ » et « Send Quote » du fournisseur dans notre exemple. Il est possible de définir des informations de corrélations permettant d’associer un message reçu à un message envoyé précédemment – par exemple tel devis reçu correspond à telle demande de devis, et doit donc être transmise à telle instance de processus.

Rendre le processus exécutable: Participation des utilisateurs aux processus
Les outils de BPM doivent permettre un rapprochement entre l’approche d’intégration, mettant en jeu des applications, et l’approche Workflow, mettant en jeu des utilisateurs. Il existe deux types d’utilisateur : L’utilisateur actif prend part à l’exécution du processus en fonction de son profil. Cela peut prendre les formes suivantes : le processus assigne une tâche à un utilisateur (qu’il peut accepter, rejeter ou déléguer), l’utilisateur transmet des données à un processus, etc. L’utilisateur est alors vu comme un participant au processus, au même titre qu’une application. L’utilisateur passif contrôle l’exécution des processus. Il y a deux types de supervisions : le BAM – Business Activity Monitoring – permettant aux utilisateurs métiers d’avoir une vue du bon déroulement fonctionnel des processus, évaluée en fonction d’indicateurs métiers (temps de traitement d’une commande, coûts liés à une activité, etc.) et la supervision technique, permettant de contrôler les processus d’un point de vue infrastructure

Rendre le processus exécutable: Gestion des erreurs
Les outils de BPM doivent permettre de gérer les erreurs – ou exceptions. La plupart des outils permettent en effet de modéliser facilement le comportement « normal » du processus, mais que faire lorsqu’une erreur intervient ? Une exception peut être technique (timeout, un service ne répond pas, etc.), ou métier (lever une erreur lorsque le coût total d’un bon de commande est trop élevé par exemple). Dans tous les cas, il doit être possible de définir des actions à effectuer en cas d’erreur. L’erreur peut être: déléguée à un autre processus, ou traitée dans le processus même. Dans notre processus de Procurement, si le devis n’est pas reçu de la part du fournisseur sous deux jours après l’envoi de la demande de devis, on le notifie alors par

Rendre le processus exécutable: Gestion des erreurs (suite)

Rendre le processus exécutable: La gestion des transactions
La gestion des transactions est aussi un élément essentiel: l’utilisation de transactions permet de garantir la cohérence des données du processus. Une transaction peut être considérée comme un regroupement de traitements formant une unité: soit l’ensemble des activités réussissent et le résultat est publié, soit une de ces activités échoue et toutes les autres doivent être annulées.

Rendre le processus exécutable: La gestion des transactions (suite)
Une transaction possède les propriétés suivantes, communément appelées ACID : Atomicité : une transaction doit soit être complètement validée ou complètement annulée. Cohérence : aucune transaction ne peut sortir de la base de données dans un état incohérent. Isolation : une transaction ne peut voir aucune autre transaction en cours d'exécution. Durabilité : après que le client a été informé du succès de la transaction , les résultats de celle-ci ne disparaîtront pas

Il existe deux types de transaction : Les transactions courtes : un coordinateur demande à tous les participants de la transaction leur état, si cet état est positif (l’activité a réussi), alors il leur envoie l’ordre de commiter leurs résultats. L’exemple classique utilisé pour expliquer ce type de transactions est un virement bancaire : le débit sur le compte origine ne doit se faire que si le crédit sur le compte destinataire réussit. Ces deux activités doivent être simultanées, il ne peut y avoir de période transitoire où un compte est débité sans que l’autre soit crédité. Les transactions courtes sont adaptées dans le cas d’utilisation de connecteurs transactionnels (bases de données, EJB, etc.). Dans l’exemple suivant, si une activité échoue (ajouter bon de commande, ajouter facture), l’autre est rollbackée.

Les transactions longues : le coordinateur envoie l’ordre à tous les participants de réaliser l’activité et de commiter les résultats. Si un participant échoue, alors le coordinateur demande à tous les participants d’effectuer des activités de compensation pour annuler leurs traitements. Ce mode transactionnel est plus adapté aux processus métiers de longue durée, ou qui font intervenir des applications accessibles via des connecteurs non transactionnels, comme des Web Services.

Rendre le processus exécutable: Déploiement et exécution
Enfin, il doit être possible de déployer directement le processus modélisé sur un moteur de processus, sans avoir à réaliser de code : l’outil doit prendre en charge la génération du document BPEL.

Méthodologie de modélisation Processus réutilisables
Un processus réutilisable est un processus qu’il est possible d’inclure dans d’autres processus métiers. Prenons l’exemple d’un processus de validation de bon de commande : le service commercial reçoit un bon de commande, valide la disponibilité des produits, puis la solvabilité du client, et enfin fait valider la commande par le responsable commercial. Alors, l’acceptation ou le refus sont renvoyés :

Méthodologie de modélisation Processus réutilisables (suite)
Ce processus est générique, et peut par exemple être utilisé dans un processus de gestion de bons de commande

Méthodologie de modélisation Processus réutilisables (suite)
Les processus réutilisables peuvent être des processus techniques (ajout d’informations utilisateurs dans les applications du SI, réplication de bases de données, etc.), ou des processus de niveau fonctionnel tels que celui présenté ici. Les outils de BPM doivent permettre de composer les processus existants, tout en permettant à ces processus d’évoluer de manière indépendante. Certains outils offrent des fonctionnalités permettant d’analyser les dépendances entre processus et donc les impacts d’une modification d’un processus sur ses processus clients. Les processus réutilisables sont disponibles dans un référentiel commun, permettant entre autre une gestion de versions. Plusieurs versions d’un même processus réutilisable peuvent être utilisées simultanément. Le niveau de réutilisabilité est donc bien plus important que celui que l’on connaît dans le développement applicatif, même avec les Web Services !

Méthodologie de modélisation Interface / implémentation de processus
La notion d’interface et d’implémentation n’est pas nouvelle et est utilisée en informatique depuis des années: une interface décrit un comportement, Une implémentation les détails de mise en place. L’objectif est de cacher aux utilisateurs d’un service le fonctionnement interne de ce service, ce qui est un gage d’évolutivité. Reprenons l’exemple précédent de processus de validation de bon de commande : il est composé de cinq étapes. Cependant, du point de vue de ses clients, deux étapes uniquement sont à connaître : Le processus client lui communique un bon de commande. Le processus transmet la réponse (acceptation ou refus) à son client.

Méthodologie de modélisation Interface / implémentation de processus (suite)
Son interface peut donc se représenter de la façon suivante:

Le processus client peut alors utiliser cette interface. Le processus de gestion de bon de commandes devient :

Le serveur BPMS se charge de transmettre le bon de commande à la version adéquate du processus d’implémentation, de manière transparente pour le processus client. Ainsi, le processus de validation des bons de commande peut évoluer indépendamment de ses processus clients, à partir du moment où son interface reste inchangée. Pour éviter un enfer bien connu sur les déploiements de nouvelles versions, plusieurs versions d’un processus peuvent cohabiter, et le changement peut être progressif.

Cette technique peut aussi être utilisée pour affranchir un processus des applications ou services utilisés. Reprenons notre exemple précédent de processus de Procurement : tel qu’il est modélisé, un changement au niveau de l’interface du Web Service du fournisseur a un impact direct sur le processus dans son ensemble. Pour pallier à ce problème, et architecturer convenablement la solution, on l’abstrait des détails d’implémentation en utilisant la technique d’interface / implémentation. L’interface utilise des formats de données pivots, définis en interne à l’entreprise. L’implémentation effectue les transformations de données nécessaires et les appels aux Web Services.

Evolutivité des processus
Une modélisation des processus métiers en plusieurs niveaux permet de découpler la modélisation métier et fonctionnelle de la modélisation technique d’un processus. L’objectif est de permettre de limiter l’impact d’une modification. Rappelons les rôles et responsabilités des acteurs définissant les processus : L’utilisateur métier modélise les processus métier de haut niveau, capitalisant sur des services fonctionnels. Il utilise les interfaces des services fonctionnels. Les équipes fonctionnelles définissent les services fonctionnels, ayant une interface et une implémentation. L’architecte intervient sur les processus de niveau fonctionnel pour réaliser le lien entre les services fonctionnels et les services techniques. Il réalise l’interface des services techniques offerts par le SI. Les équipes techniques réalisent l’implémentation des services techniques, faisant appel aux applications du SI

Evolutivité des processus (suite)
Il y a alors deux approches pour faire évoluer les processus : l’approche top-down et l’approche bottom-up. Niveau métier Interface Niveau fonctionnel Top-down bottom-up Interface Niveau technique

Evolutivité des processus: Approche top-down
L’approche top-down est utilisée lorsque le processus est modifié par le niveau métier ou fonctionnel. L’impact d’une modification sur le niveau technique est normalement limité à l’interfaçage entre les services fonctionnels et les services techniques. L’équipe technique doit alors déployer la nouvelle version du processus et contrôler la bonne exécution. Ceci dit, dans certains cas la modification intervient sur tous les niveaux, par exemple: lors d’une modification des formats de données utilisés : si le bon de commande nécessite un attribut supplémentaire, des modifications sont à effectuer au niveau fonctionnel, puis sur l’interface des services techniques, et dans l’implémentation de ces services techniques. Pour cela, la best-practice est d’externaliser les règles métiers et les transformations de données dans des outils externes (moteurs de règles métiers).

Evolutivité des processus: Approche bottom-up
L’approche bottom-up est utilisée lorsqu’une modification intervient dans l’implémentation des services techniques. Dans la plupart des cas, une modification à ce niveau n’a aucun impact sur les niveaux métiers et fonctionnels. Cela est le cas par exemple lorsqu’on change de Web Service externe. L’implémentation modifie les transformations de données et l’appel du service, mais cela n’a aucun impact sur les autres niveaux. Ceci dit, cela est vrai uniquement dans le cas où l’interface des services techniques reste inchangée. Dans certains cas, l’impact peut se propager à l’interfaçage entre les services fonctionnels et techniques.

SOA : définition Les architectures orientées services (SOA – Service Oriented Architecture) sont présentées actuellement comme la solution miracle à tous les problèmes d’intégration du SI. Le système d’information basé sur cette architecture est urbanisé sous la forme de services réutilisables qu’il est possible de découvrir et composer dynamiquement, avec un couplage lâche. On est alors bien loin des solutions totalement intégrées, de type boîte noire, que sont ERP ou autres progiciels. Cette architecture veut répondre aux besoins de flexibilité et d’adaptabilité rapide exprimés par les décideurs. Seulement, de la théorie à la pratique, il n’y a pas qu’un pas. Les solutions proposées par les éditeurs pour implémenter une SOA ne répondent que très partiellement aux concepts vendus. Dans cette partie, nous décrirons les composantes d’une SOA, nous montrerons les limites de cette approche et les possibilités pragmatiques de mise en place.

SOA : définition Origine de la SOA
La SOA est l’aboutissement des retours d’expérience liés majoritairement à deux technologies : l’EAI et les Web Services. Un outil d’EAI possède trois fonctions principales: interfacer les applications (connecteurs propriétaires), transformer les messages (utilisation de formats pivots) et les router vers les destinataires adéquats en fonction de règles de décision techniques. On utilise les outils d’EAI pour faire dialoguer des applications qui n’ont pas été prévues à cet effet : l’application de facturation peut alors récupérer les bons de commande du progiciel de gestion des commandes pour générer automatiquement les factures à transmettre aux clients. Les éditeurs d’EAI souhaitaient ajouter une dimension métier à leurs progiciels en fournissant une quatrième fonction : La possibilité de créer des processus métiers de haut niveau reposant sur les capacités d’intégration de leurs produits. Dans les faits, les outils de BPM des éditeurs d’EAI sont inadaptés: l’approche est beaucoup trop technique, ils imposent une infrastructure propriétaire (bus de données, connecteurs) qui ne permet pas de capitaliser sur l’existant du SI. De plus, les projets d’EAI peinent généralement à justifier un ROI : on effectue majoritairement de l’intégration point à point, et la réutilisabilité est quasiment nulle.

SOA : définition Origine de la SOA (suite)
Les Web Services standardisent et banalisent les connecteurs applicatifs. Ils ont été proposés pour pallier aux coûts des intégrations propriétaires tels que ceux entraînés par la mise en place des outils d’EAI L’approche est simple : des solutions telles que IBM Websphere ou Microsoft .Net permettent de créer des services accessibles par des protocoles standards. Ces services encapsulent des appels aux applications du SI. On crée donc des services permettant d’accéder de manière transparente aux applications du SI. Le système d’information de l’entreprise est alors vu comme une collections de services qu’il est possible de composer pour créer des services avec un plus haut niveau de granularité. On s’approche alors des concepts proposés par la SOA.

SOA : définition Composantes de la SOA
La SOA peuvent se définir de la façon suivante : Le système d’information de l’entreprise est découpé en services. Le niveau de granularité n’est plus l’application mais le service. Les services délèguent les traitements aux applications, mais fournissent une interface indépendante de ces applications. Les services transverses utilisés par les applications sont mutualisés : ainsi, la notification, la sécurité ou le logging sont accessibles sous forme de services. Il n’est plus nécessaire, par exemple, de redévelopper la gestion du logging pour chaque application. Les échanges entre les services sont gérés grâce à des fonctionnalités de Service Management. Il est alors possible de diagnostiquer et de prévenir les problèmes de montée en charge, d’indisponibilité d’une application, etc. Le Service Management permet aussi de remonter des informations basées sur des indicateurs métiers, à destination des décideurs. Les services sont utilisés dans les processus métiers de l’entreprise. On dépasse largement la notion de connecteur applicatif : les processus n’accèdent pas à des applications via des connecteurs, ils accèdent aux services du SI.

SOA : définition Composantes de la SOA (suite)
Le couplage entre services est lâche. Les nouvelles applications sont développées par agrégation et composition de services existants. Les concepts sont vendeurs, on quitte le tout intégré pour rejoindre le tout adaptable Application Service Alerte Sécurité Services Management Process

Mise en place d’une SOA : le BPM à la rescousse: Approche Bottom-up
L’approche Bottom-up, consiste en les étapes suivantes : La première est de développer des services façade permettant d’exposer les fonctionnalités offertes par les applications en suivant un modèle unique. Les services développés doivent fournir un niveau d’abstraction par rapport aux applications : typiquement dans le cas d’un moteur de recherche, le service de recherche doit être indépendant du moteur, et utiliser des formats pivots. Ainsi un changement de logiciel n’a aucun impact sur les clients du service de recherche. Une fois tous les services développés, on ajoute une couche de Service Management. Les outils permettent de superviser les échanges et ’anticiper les problèmes techniques ou fonctionnels. La troisième et dernière étape, maintenant que les services sont stables et contrôlés, est de les utiliser dans les processus métiers de l’entreprise

Cette approche a une justification : les outils des éditeurs qui préconisent la SOA sont stables uniquement pour la première étape. Les problèmes de la mise en place d’une SOA en suivant ces étape sont: Les décideurs ne voient l’utilité de la SOA qu’à partir de la troisième étape, c'est-à-dire quand il est possible de composer les services pour les utiliser dans les processus métiers. La réalisation des services est une tâche transverse. L’approche souvent employée est d’inclure la réalisation des services dans la mise en place d’une application dans le SI, ou dans un projet d’intégration entre deux applications. Or la réalisation d’un service transverse a un surcoût qui dépasse le cadre du projet, et qui est généralement sous estimée. Il est donc fréquent que des services soient développés au dessus d’une application dans le cadre d’une intégration, et soient ensuite inadaptés pour l’intégration avec d’autres applications. Le surcoût de la réalisation d’un service transverse ne se justifie que sur le long terme, quand le service a été utilisé dans un certain nombre de processus.

Pour ces raisons, peu de démarches SOA aboutissent. Les essais se font sur quelques projets, mais le chemin est trop long pour entrapercevoir les bénéfices de l’architecture. Cette approche de la SOA est uniquement technique, elle ne prend absolument pas en compte les contraintes des décideurs, et la nécessité de justifier les investissements IT sur leurs apports fonctionnels

Mise en place d’une SOA : le BPM à la rescousse : Approche Top-down
L’approche Top-down est beaucoup plus pragmatique. Elle permet la définition des services en fonction de leurs cas d’utilisation : Modélisation des processus métiers exécutables, comme détaillé dans la partie précédente. Ces processus métiers exécutables définissent des services techniques permettant d’accéder au SI, utilisant tout type de connecteurs, y compris les Web Services. Ces services techniques ne sont à priori pas transverses lors de la première modélisation : il y a possibilité qu’un même service technique soit mis en place différemment par plusieurs équipes. 2. Identification des services transverses : cela est facilité par les capacités d’analyse des dépendances entre processus que proposent les outils de BPM. Une fois les services transverses implémentés, ils sont référencés dans l’annuaire de l’entreprise. Intalio propose Intalio|n3 Repository, permettant de référencer tous les éléments composant un processus de manière distribuée, et de gérer les versions via un protocole standard : WebDAV. 3. Ajout de Service Management, ou plutôt de Business Activity Monitoring

Le principal problème de l’approche bottom-up est de considérer que les services sont des Web Services. On est beaucoup trop proche du modèle objet (opérations atomiques et sans états) pour garantir une réutilisabilité. Dans l’approche top-down, un service a un niveau d’abstraction supérieur : il s’agit plutôt de processus BPEL réutilisable, masquant les détails d’implémentation, mais capitalisant sur les connecteurs permettant d’accéder au SI.

Un service peut être technique ou fonctionnel. Ci-contre un exemple de service technique

Conclusion L’actualité informatique a souvent mis à mort des technologies au profit de technologies plus récentes. Voici quelques généralités que l’on peut trouver sur Internet, dans le discours de certains éditeurs ou dans la presse spécialisée : «Les Web Services sonnent le glas des connecteurs propriétaires» «Les progiciels intégrés n’ont aucun avenir» «Les technologies Web supplantent les mainframes»

Conclusion (suite) Or la capacité d’intégration d’une technologie avec l’existant devrait être le gage de sa maturité et de son adoption. Toutes les affirmations précédentes sont fausses : les Web Services ont des limitations, en particulier au niveau transactionnel, et dans certains cas il est préférable d’utiliser d’autres technologies, pour des raisons de performance, sécurité, etc. Les progiciels intégrés hébergent des processus qui sont implantés dans les entreprises et qu’il doit être possible d’intégrer et d’étendre. Beaucoup d’applications, en particulier dans le milieu bancaire, reposent sur les capacités transactionnelles des mainframes. Ces derniers doivent toujours pouvoir être utilisés dans les nouveaux processus de l’entreprise.

Conclusion (suite) Le BPM est peut être la première initiative visant à capitaliser sur l’existant, en offrant un niveau d’abstraction par rapport aux technologies sous-jacentes. L’objectif est définir des processus répondant aux besoins métiers et fonctionnels, et capitalisant sur les services offerts par le SI

Business Process Management

Présentations similaires

Présentation au sujet: "Business Process Management"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Business Process Management

Présentations similaires

Présentation au sujet: "Business Process Management"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back