ET PROCESSUS D'ENTREPRISE

Transcription

1 MIAGE M2 GO2 Paris 1 Panthéon Sorbonne MODULE STRATÉGIE D'ORGANISATION ET PROCESSUS D'ENTREPRISE 3 PROCESSUS - 2 ÈME PARTIE (ARCHITECTURES ET BPM) 1 Rafael Gutierrez Octobre 2015 SOMMAIRE Bibliographie A propos d architectures SI - Définition Le développement traditionnel Stratégies d intégration Le Workflow Les architectures orientées services le BPM Les challenges 2

2 BIBLIOGRAPHIE 3 ARCHITECTURE SI 4

3 LES PROJETS BPM 5 6

4 A PROPOS D ARCHITECTURES SI L ARCHITECTURE DES SYSTÈMES D INFORMATION L orientation vers les processus fait partie d un mouvement plus vaste qui conduit la conception des systèmes d information depuis le début Ce qui conduit à considérer l évolution des architectures des systèmes d information d entreprise 8

5 LES 2 PRINCIPES Deux principes sont à l œuvre dans toute conception d architecture La Séparation des Préoccupations «Separation of Concerns (SoC) Edsger Dijkstra (1974) Le Masquage d Information «Information Hiding» David Parnas 1974) Cela conduit à identifier des ensembles de fonctionnalités liées et les regrouper dans un sous système avec des responsabilités et des interfaces clairement identifiées Gains Autorise l ingénierie Facilite la réutilisation Favorise la réponse au changement Dans un système ainsi conçu un changement local n impacte pas le système entier Des sources potentielles de changements pouvant être Nouvelles exigences imposées par le marché Changement de technologie Changement de législation 9 ARCHITECTURE LOGICIELLE Une architecture logicielle définit une structure qui organise les éléments logiciels et les ressources d un système logiciel Les éléments et les ressources sont représentés par des sous systèmes. Dans une architecture donnée, ces sous systèmes ont des responsabilités, et des relations avec les autres sous systèmes, spécifiques Les architectures logicielles ne détaillent pas la structure interne d un sous système mais elles détaillent leur comportement extérieur visible et donc leurs relations avec les autres sous systèmes Les aspects internes d un sous système pourront toujours être décrits dans l architecture logicielle du sous système! 10

6 LE DÉVELOPPEMENT TRADITIONNEL 11 DÉVELOPPEMENT TRADITIONNEL D APPLICATIONS Le développement des débuts Applications développées à partir de rien Réutilisation limitée aux sous programmes Gestion applicative de : L accès aux données La mémoire Portage difficile 12

7 LES PREMIÈRES ÉTAPES Premières améliorations Indépendance de la machine : le Système d exploitation Indépendance physique des données : la Base de Données Indépendance de l utilisateur : l Interface Utilisateur GUI Application Application Application OS DBMS OS data base DBMS OS data base APPLICATIONS D ENTREPRISE Application Ressources Humaines Application Gestion des Achats DBMS OS Database RH Database Achats DBMS OS Gestion de l entrepôt Le problème : la Redondance des données OS 14

8 INTÉGRATION 1 LES ERP INTÉGRATION 1 : LES ERP Entreprise Ressource Planning De MRP : Management Ressource Planning, méthode de gestion de production Progiciel de Gestion Intégré «PGI» Le plus connu : SAP mais aussi Oracle (PeopleSoft), en libre Compiere, myerp Caractéristique : base de données intégrée Les applications fournissent les fonctionnalités en partageant la même base Un serveur d application émet des requêtes vers un serveur de base de données 16

9 ARCHITECTURE CLIENT SERVEUR 2-TIER Modules applicatifs Client 1 Client 2 Client 3 Intégration du stockage des données Accès à distance via un logiciel client Serveur d application ERP DBMS OS Database ERP : NOUVEAUX BESOINS On outille le système de la valeur De part et d autre de la chaine de valeur, outillée par l ERP Nouveaux types de logiciels SCM : supply chain management CRM : customer relationship management Nouveaux acteurs Nouveaux produits Avec leur Base de données incorporée Nouvelle situation Redondance des données avec l ERP existant Information non intégrée Impact sur la relation client => Notion de silos d information 18

10 APPLICATIONS EN «SILOS» GUI GUI GUI CRM SCM ERP DBMS data base DBMS data base DBMS data base OS OS OS Si ces applications peuvent être physiquement connectées, par un réseau local par exemple, elles ne sont pas logiquement intégrées 19 CONSÉQUENCES En conséquence, la seule façon d intégrer l information c est via l utilisateur qui accède aux différents systèmes et réalise l intégration manuellement Cette intégration manuelle étant coûteuse et sujette à erreur, on a pensé à d autres solutions : Dans le cas des ERP ce problème avait déjà été traité par le redéveloppement d une solution intégrée Malheureusement la complexité des systèmes en cause rend cette solution irréalisable dans le nouveau contexte La seule solution reste donc d intégrer les systèmes Ce qui conduit à inventer un nouveau type de middleware : l EAI 20

11 INTÉGRATION 2 L EAI 21 INTÉGRATION 2 : ENTREPRISE APPLICATION INTEGRATION Les entreprises font face au problème de l intégration de logiciels complexes dans un paysage informatique hétérogène (appelé autrefois ironiquement le «SICOB») Chaque application a été développée de façon indépendante et possède ses propres données Le problème de l hétérogénéité des données apparaît 22

12 HÉTÉROGÉNÉITÉ DES DONNÉES Le problème apparaît quand un item logique (une adresse client par exemple) est stocké plusieurs fois dans des silos différents Quoiqu il s agisse, le plus souvent, de bases de données relationnelles, les structures des données peuvent être différentes et donc pas immédiatement comparables Au niveau syntaxique Type des attributs : «CustomerName» peut être un string de longueur différente dans les différentes bases Nom des attributs : «ClientAdresse» peut s appeler «Caddr» ailleurs Le niveau suivant concerne la sémantique Le champ «Price» désigne un prix TTC ou HT? Les techniques d intégration des données sont utilisées pour surmonter ces difficultés syntaxiques et sémantiques L intégration des données est un élément clé de l intégration des applications : plusieurs approches ont été proposées 23 INTÉGRATION POINT À POINT L EAI se base sur la technologie du middleware qui n est pas nouvelle (intergiciel en vrai français!) L objectif est de tirer partie de ces technologies pour réaliser l intégration des données De plus, les processus doivent aussi être intégrés Un système réalise certaines étapes puis Transfère le contrôle à un autre système L autre système prend le résultat et continue le travail Dans l approche qui nous occupe, l intégration des processus, qui fait partie de l intégration des applications, est d une importance primordiale 24

13 EXEMPLE D INTÉGRATION POINT À POINT Data Warehouse CRM SCM ERP RH Inventaire Le problème : N x N! N= 6 => 15 interfaces 25 BESOIN D UNE AUTRE SOLUTION Dans un système d information d entreprise les changements sont fréquents et l architecture du système doit les supporter d une façon efficiente et effective L intégration point à point ne répond pas à cette exigence Tout changement dans le paysage applicatif entraine l adaptation des interfaces concernés L adaptation est souvent réalisée par la reprogrammation des interfaces, qui requiert des ressources considérables Un exemple plus sophistiqué est le middleware orienté-message où les applications communiquent en envoyant et recevant des messages 26

14 MIDDLEWARE ORIENTÉ MESSAGE Ici le middleware devient un composant central qui assure la connexion entre les applications L intégration point à point est bien présente Chaque émetteur encode le message pour le receveur, mais aussi la réponse La livraison du message est garantie Mais le problème perdure Tout changement dans le paysage applicatif doit être implémenté par un changement de la structure de communication des applications 27 MIDDLEWARE ORIENTÉ MESSAGE Client Integration SCM ERP CRM Data Warehouse Application Queues de Message Middleware orienté message

15 EXEMPLE DE FONCTIONNEMENT L émetteur d un message spécifie les récepteurs Le SCM définit dans son interface qu un certain message doit être reçu par l ERP et le CRM Des files de messages sont utilisées pour stocker de façon permanente les messages et assurer ainsi la livraison Un client utilise une application qui intègre plusieurs applications : c est l «Integration Application» qui envoie le message à l application cible En le plaçant dans la file de l ERP Lequel invoque la fonctionnalité demandée et Renvoie un message résultat à l application d intégration En le plaçant dans sa file A la réception du message l application d intégration prépare un message et l envoie au CRM L émetteur doit encoder le message, réalisant donc une connexion point à point entre les applications 29 ANALYSE CRITIQUE DU FONCTIONNEMENT Cet exemple montre que la coopération entre les systèmes (ERP, SCM, CRM) est réalisée par l application d intégration Comme au premier jour des systèmes d information, le processus qui décrit comment cette coopération se passe est implémenté dans une application : l application d intégration Le processus est codé «en dur» dans l application et il n existe pas de modèle du processus explicite qui pourrait être facilement communiqué Ou changé si nécessaire Tout changement du processus aura un effet sur la structure de la communication, implémentée pour chaque application 30

16 INTÉGRATION 3 HUB & SPOKE HUB AND SPOKE (MOYEU ET RAYON) Le paradigme Hub & Spoke Un Hub (moyeu) central Centralized entreprise application integration middleware Des Spokes (rayons) attachés au Hub Les applications à intégrer L interaction se fait par le Hub Important : L émetteur n encode plus le message Le Hub est configuré de telle façon que la structure du message et son contenu peuvent être utilisés pour détecter automatiquement le ou les récepteurs! On échappe au N x N 32

17 HUB AND SPOKE Un adaptateur par application CRM ERP SCM Middleware EAI centralisé Data Warehouse Inventaire HR 33 HUB AND SPOKE : UNE SOLUTION! Selon la complexité des systèmes, et la disponibilité des adaptateurs génériques fournis par les vendeurs, le développement des adaptateurs peut coûter très cher Mais, une fois le Hub configuré et les adaptateurs en place les applications sont intégrées! 34

18 TECHNIQUE : LE MESSAGE BROKER Ou Courtier de Messages Les Message Broker sont des logiciels qui autorisent un utilisateur à définir des règles de communication entre les applications Ainsi la tâche de l implémentation et du changement des structures de communication est maintenue à l écart des applications En définissant, d une façon déclarative, comment la communication s établit entre applications l implémentation est remplacée par la déclaration la réponse au changement améliorée 35 MESSAGE BROKER Le Hub utilise des règles pour gérer les dépendances entre les applications Le Hub peut alors décider comment relayer un message selon son émetteur et son contenu Le Message Broker effectue aussi la transformation des messages afin de régler les problèmes d hétérogénéité des données (data mapping) 36

19 MESSAGE BROKER Client SCM ERP CRM Data Warehouse SCM Adaptateur ERP Adaptateur Application utilisateur CRM Adaptateur Data Warehouse Adaptateur Evaluation des règles Message broker 37 PUBLIER/S ABONNER C est le mécanisme pour lier les applications au Message Broker Une application peut s abonner à certains messages ou types de messages Une application peut aussi publier des messages De nombreux types d interactions entre les applications sont possibles De la simple invocation À des interactions complexes multi applications Une fonction particulière de l ERP pourra ainsi être déclenchée quand une information particulière concernant un client sera extraite du CRM, par exemple 38

20 LES DÉFAUTS Le Message Broker contient une grande partie de la logique applicative Cette logique applicative est cachée dans les règles utilisées pour la communication des messages La configuration et la gestion de ces règles deviennent difficiles et pesantes Des dépendances entre règles peuvent apparaître, rendant les changements plus difficiles à gérer Pourquoi? 39 LA RAISON? La raison est le manque de fondation de l EAI Malgré les règles, les technologies EAI s appuient sur la programmation et la configuration à bas niveau des adaptateurs et des message brokers Ceci vaut autant pour l intégration des données pour celle des processus L intégration des données est basée sur des outils de «data mapping», qui conceptuellement exigent un modèle global, qui, souvent, n existe pas! 40

21 UNE SOLUTION? Au niveau de l entreprise les fonctionnalités offertes par les applications intégrées s organisent en séquence formés d étapes qui suivent un processus Le processus est caché dans les règles du Message Broker et n est donc pas visible explicitement La prochaine étape, le «workflow management», identifiera les spécifications des processus comme des «citoyens de première classe» pour la résolution du problème de l intégration des processus de l entreprise 41 LE WORKFLOW

22 GESTION DU WORKFLOW Le développement des architectures logicielles des systèmes d information d entreprise et l organisation basée sur les processus conduisent à la question de la gestion du workflow La gestion dudit workflow étant : La représentation explicite des structures des processus dans des modèles et Le pilotage de ces processus selon ces modèles 1990 : Workflow Management Coalition (WfMC) 43 DÉFINITIONS (WFMC) Workflow Automatisation d un processus métier, en tout ou en partie, durant lequel les documents, l information ou les tâches sont échangés entre les participants selon un ensemble de règles de procédure Gestion du workflow Un système de gestion du workflow est un système logiciel qui définit, crée, et gère l exécution de workflows à l aide de logiciels tournant sur un ou plusieurs moteurs de workflow qui est capable d interpréter la définition du processus, interagir avec les participants, et le cas échéant invoquer l usage d autres outils ou applications informatiques 44

23 WORKFLOW ET APPLICATIONS Traditionnellement : les applications ne réalisent pas seulement les fonctions mais aussi l ordre dans lequel les fonctions sont activées L application incorpore la logique du processus Mais alors, toute modification du processus oblige à toucher au code Modification => Test => Maintenance =>! Recours au workflow 45 LE RECOURS AU WORKFLOW Les fonctions de l application sont les étapes du workflow, et il existe un composant de workflow qui utilise un modèle pour activer les fonctions Ainsi la modification du processus logique, spécifié dans le modèle de workflow permet d influer sur le comportement de l application sans toucher au code Le composant de workflow donne de la flexibilité à la variabilité du processus 46

24 SINGLE OU MULTI APPLICATIONS GUI Système de Gestion du Workflow Composant Workflow Application ERP Stock SCM DBMS OS data base DBMS OS OS DBMS OS 47 SYSTÈMES DE WORKFLOW Dans un tel système les activités du workflow sont réalisées par des logiciels L utilisateur n interagit pas avec l application, l interface graphique est réduit au minimum L utilisateur n a plus le choix des tâches Les contraintes d exécution sont spécifiées dans le modèle Le système s assure que l ordre des appels au logiciel sous-jacent est en ligne avec le modèle de processus Définition Un système de workflow consiste en un ensemble d activités implémentées dans un logiciel, sans implication des utilisateurs 48

25 UN MODÈLE DÉFINIT SI ET QUAND UNE APPLICATION EST INVOQUÉE CRM ERP SCM Data Warehouse Inventaire HR 49 CAS DE L OPÉRATEUR HUMAIN «Human Interaction Workflows» On appelle ainsi, les workflows où les Humains sont activement impliqués et interagissent avec les systèmes d information Historiquement : focalisation sur le poste de travail Insuffisant Nécessité de prendre en compte les relations entre les activités réalisées par des personnes différentes Ensuite : aider la collaboration Partage de données (bases de données, repository) Amélioration du transfert Utilisation massive de formulaires Aujourd hui : contrôler la mise en œuvre du processus Liste de tâches : corbeille 50

26 LES ARCHITECTURES ORIENTÉES SERVICES ORIENTÉ-SERVICE? Les services sont des tâches informatiques, faiblement couplées, communiquant via Internet On réserve le terme orientées services aux architectures qui se focalisent sur la façon dont les services sont décrits et organisés pour permettre, automatiquement et dynamiquement, leur découverte et leur usage Deux intérêts Un aspect B2B, lié à Internet Un haut degré de flexibilité : «Late run time finding and binding» 52

27 LES RÔLES DANS L ORIENTÉ SERVICES Service Requestor 4 : Bind/ Invoke Service Provider 3 : Reply 2 : Request 1 : Publish Service Registry 53 Les éléments existent pour construire un nouveau type de SI où Un «petit» changement de stratégie ne provoquera qu un «petit» changement du SI Sans toucher au code? LES ARCHITECTURES BPM

28 LES ARCHITECTURES ORIENTÉES WORKFLOW BUILD TIME ET RUN TIME Build Time Run Time Modélisation du Workflow Repository des Modèles Moteur de Workflow Changer le modèle n affecte pas les instances en cours d exécution A l Exécution : création d une instance 56

29 ARCHITECTURE Concepteur Participant Modélisation du Workflow Interface Graphique Repository des Modèles Moteur de Workflow Applications invoquées 57 GESTION FLEXIBLE DU WORKFLOW Traditionnellement la gestion du workflow s occupe de contrôler l exécution de processus métier selon un modèle prédéfini qui formalise Les activités Leur structuration en processus Leur réalisation technique Le workflow traditionnel est basé sur une la séparation de la conception et de l exécution A l exécution il n y a plus de lien entre l instance et le modèle Dans des environnements hautement dynamiques, la structure du processus n est plus statique ce qui conduit à de nouvelles exigences, on parle alors d adaptation dynamique Au fil du temps, une instance pourra être pilotée par différents modèles 58

30 WEB SERVICES WEB SERVICES Les web services sont la réalisation actuelle de l Orienté-Service Toutes les caractéristiques ne sont pas disponibles Chaque nouvelle version des outils améliore la situation 60

31 RECOMMANDATIONS DU W3C SOAP Service Requestor 4 : Bind/ Invoke Service Provider WSDL 3 : Reply 2 : Request Service Registry 1 : Publish WSDL UDDI 61 EN PASSANT REST Representational State Transfer Architecture Pas un protocole Roy Fielding 62

32 COMPOSITION DES SERVICES COMPOSITION DES SERVICES Les Web services décrits jusqu ici fournissent la possibilité de définir et d invoquer des services, réalisant ainsi un couplage «lâche» de services La composition de service est un concept important pour le développement d applications basées sur des services existants Les compositions de services décrivent comment un ensemble de services sont reliés les uns aux autres Elles décrivent la structure d un processus Chaque service réalisant une activité 64

33 OUTILLAGE 2 «Suites BPMS» 66

34 67 CONCLUSION La composition des services est une réalisation concrète des concepts évoqués Une implémentation d un système de workflow dans un environnement orienté service basé sur des Web services Des outils existent! Le «SI aligné» devient possible!

35 LES CHALLENGES LES «KNOWLEDGE WORKERS» Un soin spécial doit être porté aux futurs utilisateurs pour éviter tout risque de refus Un domaine particulier, celui des «Knowledge Workers», a toujours posé des problèmes Celui où les gens décident de leurs activités! Leur devise Processes don t work, people do! On sort du sujet Mais, on rentre dans l avenir! Avec deux livres

36 LES PROBLÈMES D INTÉGRATION Les applications qui doivent être intégrées Ne possèdent pas toujours une interface bien documentée Ont souvent les fonctionnalités incluses dans l interface utilisateur Peuvent être en relation directe au niveau de leur code Les granularités des activités et du code peuvent être différentes Les architectures orientées services et l encapsulation des applications «legacy» tentent de résoudre ces problèmes LES PROCESSUS SANS WORKFLOW Tous les environnements n exigent pas un système de gestion du workflow Base de données (procédure stockée) Système de publication ERP Ces systèmes sont dits à workflow embarqué (Embedded workflow management systems) On peut citer aussi Les systèmes de réservation automatique, d achat en ligne Réalisés par les techniques habituelles du développement Web Toutefois le paradigme «processus métier» peut aider pour des scénarios qui n exigent pas un workflow dédié