Dan Garlasu, dgarlasu@yahoo.

com

1
Processus Metier – concepts, modèles et systèmes
Engl: Business Process Management - BPM
◦ Abstract
De fait, les capabilitées les plus importantes pour une entreprise ne sont plus la
fourniture de produits et services, mais celles qui permettent de modifier
dynamiquement les produits et services fournis (R&D, marketing, transformation
des processus métier...).
L’environnement numérique est marqué par la prolifération des capteurs; l’Internet
des Objets est devenu réalité. La capacité d’analyser des volumes massifs de
données permet un retour en temps réel, et les instruments analytiques (BI -
Business Intelligence) appliquée à l’analyse de l’opinion collective est largement
utilisée. Cela permet d’expérimenter et d’améliorer des produits et services
numériques de manière quasi-instantanée. Dans ce scénario, ce sont d’abord les
partenariats et les processus métiers qui priment.

2
 Un processus métier est un ensemble de procédures et d'activités
plus ou moins liées qui réalisent collectivement un objectif métier, en
général au sein d'une structure organisationnelle définissant des
rôles et des relations fonctionnelles. Un processus métier peut être
entièrement inclus dans une organisation simple ou peut s'étendre
sur plusieurs organisations. Un processus métier peut combiner des
activités automatiques et des activités manuelles (WfMC = Workflow
Management Services).
Client Banque

Agence de voyage

Expediteur
 L’idée :
◦ Sortir la logique en dehors des procédés des programmes d’application …
◦ … comme l’approche Bases de Données a sorti les données des
programmes d’application
 Autres révolutions :
◦ Système d’Exploitation,
◦ Bases de donnée,
◦ Interface Utilisateur
Logique et donnees dans les
programmes

Independence entre donnees et

programmes

Independence entre procedees et

programmes
 Dimension logique
◦ Quoi
 Dimension organisationnelle
◦ Qui: compétences
 Dimension informationnelle
◦ Comment: infrastructure technologique
 La même activité peut être :
◦ sous la responsabilité de participants différents,
◦ mise en oeuvre par des solutions techniques différentes
 dans des organisations différentes, ou
 dans la même organisation à des moments différents
11
 Les procédés les plus automatiques et plus structurés
(production automatisée …) sont bien établis
 Aujourd’hui, l’enjeu est sur les procédés moyennement créatifs
(interactifs) et structurés (circulation de documents)
 Les perspectives concernent les procédés les plus créatifs et
moins structurés qui sont les moins bien supportés (procédés de
co-conception …)
 Conception
◦ Conception initiale, puis re-conception en fonction des diagnostiques
à l’exécution ou des évolutions de l’application
 Configuration
◦ Déploiement d’un modèle dans un contexte organisationnel et
informationnel
 Exécution
◦ Mise en oeuvre incluant l’historisation à des fins d’analyse et de
diagnostique
 Diagnostique/Revue
◦ Etude critique des cas terminés en vue de d’amélioration
On appèlle « workflow » l’automatisation complète ou partielle des processus durant
lesquels des informations sont passées et des tâches sont affectées par un
participant à un autre, en accord avec des procédures [WFMC - WorkFlow
Management Coalition, http://www.wfmc.org/]
• Assure que le bon travail est fait au bon moment par la bonne personne et dans le
bon ordre

On appèlle flux de travail (workflow) les aspects opérationnels d’un processus:

• la séquence des tâches et qui les réalisent,
• le flot de données qui supporte ces tâches, et
• les mécanismes qui permettent de mesurer, suivre et contrôler ces tâches –

[Mohan1999] Workflow Management in the Internet Age

 Un système qui définit, crée et gère l'exécution de flux de travail
par l'utilisation de logiciel capable:
◦ d'interpréter les définitions de processus,
◦ d'interagir avec les participants et, lorsque cela est requis,
◦ d'invoquer les outils et les applications (WfMC)
 Définition (modèle) de processus
◦ Représentation d'un processus métier dans une forme qui supporte des
manipulations automatiques comme la modélisation ou l'exécution par
un système de gestion de flux de travail (workflow). Une telle définition
consiste en:
 un réseau d'activités,
 des critères pour indiquer le démarrage et la terminaison du processus,
 des information sur les activités comme les participants, les applications et
les données permettant la mise en œuvre des processus
 BPM représente une stratégie de gestion et d'amélioration de la performance de
l'entreprise en optimisant en permanence les processus d'affaires dans un cycle en
boucle fermée de la modélisation, l'exécution et la mesure.
 Tout ce que les compagnies font pour atteindre leurs objectifs d'affaires implique un
processus, structuré ou non structuré.
 La technologie BPM aide les organisations à créer, document et modifier rapidement
des processus d'affaires et des changements de processus d'entraînement, une
manière d'affaires non technique, avec la technologie de mise en œuvre, l'exécution
et le suivi des processus de bout-en-bout.
 Les systèmes BPM couvrent souvent de nombreux départements et systèmes
informatiques dans une organisation.
 En fusionnant les technologies et fonctions dans un environnement intégré de façon
transparente, BPM donne technologues et spécialistes des affaires un langage
commun pour la réalisation de leurs objectifs communs et distincts.

42
 SOA est devenue une méthode populaire pour lier des applications
disparates à travers de nombreuses lignes et différentes fonctions
commerciales, ainsi centraliser et d'améliorer l'efficacité des processus.
 Il facilite la création de services faiblement couplés et interopérables qui
sont facilement partagées au sein et entre les entreprises, qui utilisent
cette architecture pour sa réutilisation et l'agilité.
 Lorsqu'ils sont correctement construits et interfacés, les applications SOA
peuvent durer pendant des décennies sous la forme d'applications
d'entreprise virtualisés.
 SOA interagit avec toutes les parties de l'architecture informatique afin
d'intégrer des applications d'entreprise, en les déplaçant sur un bus de
service commun et un moteur de flots d’activités communes.

Pour réaliser l'intégration, deux possibilités s'offrent à vous :

1. L'approche descendante (top-down) - la gestion des processus métier.
Évidemment, c'est l'approche de l'utilisateur professionnel, spécifique au métier.
2. L'approche ascendante (bottom-up): Architecture orientée services (SOA)- c'est
l'approche informatique.
Dans les diapositives suivantes, nous nous concentrerons sur l'architecture orientée
services.

43
 Approche SOA
‣ L'architecture orientée services ou SOA (Service-Oriented
Architecture) est un style de topologie de logiciels (architecture):
 modulaire,
 distribuable
 faiblement couplé (loosely coupled).
‣ SOA offre la possibilité à un logiciel standard pour automatiser de
nombreuses autres tâches et les processus que ne l'est
actuellement le cas, d'une manière qui est flexible en permettant
des changements à un coût beaucoup plus bas qu'avant.
‣ SOA change l’équation société - fournisseur: au lieu de définir, et
débattre sur combien de produire à quel prix, de collaborer sur la
meilleure façon d'offrir une valeur pour le client final, qui est le cœur
de leur activité.

Les entreprises d'aujourd'hui sont obligées de répondre plus rapidement aux défis de la
concurrence et des clients et attendent de l'informatique qu'elle soit un différenciateur
offrant flexibilité et rapidité lorsqu'elles s'attaquent à des forces commerciales
complexes. Forcés de fournir plus, plus rapidement, les responsables informatiques
recherchent des fondations technologiques qui offrent à la fois agilité et réduction des
coûts, et l'architecture orientée services est présentée comme la solution miracle par
les analystes du secteur et la presse informatique. De nos jours, il est difficile d'assister
à une conférence informatique ou de lire un magazine sans entendre parler de la
promesse d'agilité et de réutilisation SOA via des interfaces de services Web standard
dans une architecture faiblement couplée.

44
 Quiz

L'architecture orientée services (SOA) est un style

d'architecture logicielle qui offre:
a. modularité,
b. couplage étroit
c. distributivité

Response: a, c.
 Consommateurs et fournisseurs de
services multiple
‣ Un consommateur de services peut utiliser les services d'un
certain nombre de fournisseurs de services
‣ Un prestataire de services peut fournir des services à un certain
nombre de consommateurs de services
‣ Un consommateur de service et tous les fournisseurs de services
qu'il utilise forment ensemble une application composite unique

Service Service Service

Consumer Consumer Consumer

Service Service Service Service

Provider Provider Provider Provider

Le premier concept à comprendre est la manière dont SOA décompose et distribue la

pile d'applications traditionnelle en plusieurs consommateurs de services et
fournisseurs de services qui peuvent communiquer entre eux comme ils le souhaitent,
comme le montre la figure. Un consommateur de services peut parler à de nombreux
fournisseurs pour obtenir des informations ou accéder à la logique nécessaire pour
effectuer le travail à accomplir. La combinaison d'un consommateur de services et de
tous les fournisseurs de services qu'il utilise est appelée une application composite.

46
 Avec SOA, les applications composites
élargissent la portée de l'automatisation
‣ Les applications composites peuvent réutiliser les services fournis par les
applications d'entreprise et les autres fournisseurs de services et d'élargir le
champ d'application de l'automatisation
‣ Les fournisseurs peuvent étendre la portée de leurs produits et les utilisateurs
peuvent les étendre encore plus
‣ L'automatisation et la flexibilité vont ouvrir la porte à la transformation des
relations d'affaires à tous les niveaux
Aplication Aplication
Composite Composite

Composite SCM
ERP Aplication
Application Composite
HCM
CRM
Aplication
Aplication
Composite
Composite

Si nous regardons la figure, nous pouvons imaginer que tous les logiciels standard
peuvent être étendus par configuration pour répondre aux exigences d'une entreprise
ou d'une grande organisation. La question est de savoir comment la SOA permet aux
logiciels standard d'étendre la portée ou d'automatiser davantage de processus et de
tâches.

47
 Quiz

SOA (Service-oriented architecture) offre la possibilité de

permettre à un logiciel standard de (choisir toutes les bonnes
réponses):
a. Automatisez beaucoup plus de tâches et de processus
qu'actuellement
b. Offrir de la flexibilité
c. Permettre aux changements de se produire à un coût
bien inférieur à celui d'avant

Response: a, b, c.
 Quiz

SOA (architecture orientée services) concerne (choisissez

toutes les bonnes réponses):
a. Un consommateur de services qui peut utiliser les
services de n'importe quel nombre de fournisseurs de
services
b. Un fournisseur de services qui peut fournir des services à
n'importe quel nombre de consommateurs de services
c. Une application composite unique composée d'un
consommateur de services et de tous les fournisseurs de
services auxquels il fait appel

Response: a, b, c.
 À propos de services
 Service – interface pour une fonctionnalité spécifique bien définie offerte par un fournisseur
de services qui exposent fonctionnalités réutilisables à l'intérieur d'une application
d'entreprise ou un autre fournisseur de service de sorte qu'il peut être utilisé:
 pour créer des applications composites, ou
 par d'autres consommateurs de services,
 Interface de service – la couche visible d'un service, accessible à tous

 Services Web – fonctionner de la manière décrite ci-dessus mais,

 leur interface de service est décrite en utilisant WSDL (Web Services Description Language)
 Les données qui se déplace dans et à l'extérieur sont envoyé dans les messages XML (généralement via le
protocole SOAP)
 Garder la trace des services web est rendu possible par UDDI (Universal Description, Discovery and
Integration), qui est le protocole standard pour la création d'un répertoire de recherche des services

 Mashup – application composite créée en combinant deux ou plusieurs services Web

 Business Objects – morceaux réutilisables de fonctionnalités à l'intérieur d'une application
qui peut être utilisé pour soutenir les services

Comme son nom l'indique, les composants fondamentaux de la SOA sont les services.
Les services sont composés de deux couches:
1. l'interface de service et
2. la mise en place des services

SOAP (Simple Object Access Protocol) est une spécification de protocole de

messagerie pour l'échange d'informations structurées dans la mise en œuvre de
services Web dans des réseaux informatiques. Il utilise l'ensemble d'informations XML
pour son format de message et s'appuie sur les protocoles de la couche application, le
plus souvent le protocole de transfert hypertexte (HTTP), bien que certains systèmes
hérités communiquent via le protocole SMTP (Simple Mail Transfer Protocol), pour la
négociation et la transmission des messages.

50
 Comparaison
Architecture Architecture orientée
traditionnelle services (SOA)
Orientation fonctionnelle  Orientation vers le Processus
Conçu pour durer  Conçu pour le changement

Développement à long cycles  Développement itératif

étroitement couplé  Faiblement couplé

Spécifique aux applications  Hétérogène

Orienté vers l’Objet  Orienté vers le Message

L'architecture orientée services est essentiellement une architecture d'application

conçue pour permettre un couplage lâche entre les applications logicielles en
interaction. Ceci permet:
• Une architecture applicative plus modulaire
• Des applications à intégrer de manière lâche (loosely coupled).
La plus grande valeur que les clients obtiennent avec le passage à une architecture
orientée services est une plus grande flexibilité dans le développement, l'intégration et
la gestion des applications d'entreprise.

Au fur et à mesure que l'architecture applicative évolue vers les services, elle a besoin
d'une infrastructure elle-même plus flexible. Cependant, la plupart des entreprises
utilisent aujourd'hui de nombreux composants logiciels fragmentaires pour créer des
applications d'entreprise, ce qui rend difficile l'obtention de cette flexibilité:
• Ils peuvent avoir un serveur Java d'un fournisseur, mais…
• Ils ont un brocanteur (broker) d'intégration pour connecter ce serveur Java à un
système hérité d'un autre fournisseur, et encore…
• Ils ont un serveur de portail d'un troisième fournisseur!
Garder toutes ces pièces synchronisées peut être extrêmement compliqué et coûteux,
c'est pourquoi nous assistons à une transition vers une infrastructure logicielle intégrée
pour les applications.

51
 Modèles de valeur SOA
 Dans un univers de SOA, le développement d'une application à
partir de zéro est un événement rare.
 Le plus souvent, les gens vont configurer une application composite
(ou service) qui existe déjà ou bien ils vont commander un modèle
qui correspond presque déjà aux exigences de la solution.
 Ces modèles sont désignés comme des modèles de valeur
(patterns) et les suivants modèles de valeur SOA ont été identifiés:
1. Intégration basé sur SOA
2. Le développement d'applications composites modernes
3. Modernisation des applications héritées et Mainframe

À travers les trois principaux modèles de valeur SOA, les clients ont réalisé un impact commercial
d'un ordre de grandeur - la plupart des résultats obtenus se situant entre 100 et 500% d'amélioration.
Les avantages les plus significatifs de SOA ont été réalisés lorsque des modifications étaient
nécessaires à une application ou à une intégration. La raison en est que SOA a relevé des défis
fondamentaux avec des approches traditionnelles.
Des études de cas réels illustrent ce potentiel de valeur SOA et fournissent des tactiques de réussite
basées sur les « leçons apprises ». Un client a changé le jeu de l'intégration en réduisant le temps de
réponse aux demandes de changement d'intégration de deux mois à cinq jours, fournies sans budget
supplémentaire par du personnel informatique interne non expert. Un autre client a réduit le délai de
mise sur le marché d'un projet informatique majeur de deux ans à six mois tout en améliorant la
satisfaction des utilisateurs professionnels vis-à-vis de l'application grâce à une validation et un
raffinement itératifs. En fait, les adopteurs les plus éclairés de la SOA tirent parti des meilleures
pratiques BPM (Business Process Management) telles que la cartographie descendante des
processus, le développement itératif/agile et les architectures de services en couches pour lutter
contre « l'écart d'alignement métier/IT » et en tirer une valeur maximale de SOA. SOA a aidé un autre
client à lutter contre l'un des problèmes brûlants des grandes organisations informatiques : comment
réduire les coûts énormes (souvent 70 à 80 % du budget informatique) et les besoins en ressources
(30 personnes pour diagnostiquer un problème dans un code COBOL étroitement couplé). de
maintenir les anciens systèmes mainframe. Après avoir refactorisé une application COBOL avec les
principes et la technologie SOA, les cycles de correction de bogues ont été réduits de trois à quatre
mois avec 30 personnes à trois à quatre semaines avec cinq à huit personnes.

52
 Intégration basé sur SOA

xxx

Modèle de valeur SOA #1: Intégration basée sur SOA

Lorsque nous parlons d'intégration d'applications d'entreprise (EAI – Enterprise
Application Integration) avec les organisations informatiques, nous avons souvent
entendu beaucoup d'insatisfaction vis-à-vis des technologies traditionnelles,
propriétaires, de brocanteur (broker) d'intégration ainsi que des intégrations point à
point. De nombreuses entreprises ont eu du mal à maintenir leurs intégrations et ont
largement sous-estimé le temps, l'argent et l'aide de conseil qui seraient nécessaires.
Ils avaient besoin d'une meilleure façon d'intégrer les applications, une façon qui
permettrait à leurs ressources informatiques internes, non expertes, de maintenir et de
faire évoluer les intégrations existantes rapidement et à moindre coût. Nos résultats
montrent qu'avec l'intégration basée sur des normes, vous disposez désormais des
outils nécessaires pour créer des intégrations faciles à gérer. Les projets d'intégration
mis en œuvre en tant qu'orchestrations SOA à l'aide de BPEL (Business Process
Exécution Language) ont surpris les responsables informatiques avec des cycles de
changement très rapides. De plus, les ressources informatiques, qui n'avaient aucune
expérience préalable en développement J2EE, étaient à l'aise pour maintenir les
processus BPEL après s'être familiarisés avec la vitesse en moins de deux semaines.

53
 Le développement d'applications composites modernes

Modèle de valeur SOA #2: le développement d'applications composites modernes

Les applications écrites sur mesure sont importantes pour de nombreuses entreprises, car elles
aident à mettre en œuvre une différenciation concurrentielle. Cependant, de nombreuses
applications écrites sur mesure deviennent des applications héritées le jour de leur création, et
l'évolution du code d'application monolithique et étroitement couplé qui a été écrit avec l'intégration
après coup n'est souvent rien de moins qu'un cauchemar. Les approches de développement
traditionnelles ont créé un « écart d'alignement métier/IT ». SOA offre une meilleure façon de
concevoir des ressources applicatives intégrables et réutilisables, orchestrées à partir de services
existants plutôt que reconstruites à partir de zéro, ce qui comblera cet écart.
On a constaté que les clients qui appliquent les meilleures pratiques de gestion des processus
métier (BPM) maximisent la valeur de SOA. La technologie SOA associée à une approche de
développement itérative fournit des résultats commerciaux de haute qualité en un temps de
développement record. Malheureusement, nous avons fait l'expérience d'un certain nombre de
projets SOA « ascendants », qui sont rarement considérés comme réussis, car ils ne favorisent
pas l'adoption à l'échelle de l'entreprise. Comme les services ne sont pas proposés au bon niveau
de granularité pour les analystes métier, cela limite le potentiel de réutilisation. La cartographie des
processus «descendante» s'est avérée un remède efficace.

54
 Modernisation des applications
héritées et Mainframe

XXX

Modèle de valeur SOA #3: Modernisation des applications mainframe et héritées

Le troisième modèle de valeur est mentionné moins fréquemment dans le contexte de la SOA.
Ce modèle cible les applications mainframe – applications monolithiques les plus étroitement
couplées que nous connaissons, et qui constituent la cause d'un dilemme informatique
fondamental. Il n'est pas rare que les entreprises consacrent 70 à 80 % de leur budget
informatique à la maintenance de leurs applications mainframe.
Les cycles de changement sont étendus et les améliorations sont risquées, car l'impact du
changement est difficile à prévoir. Pourtant, il semble impossible pour la plupart des
entreprises de se libérer de ce poids qui draine ses ressources informatiques et ses dollars.
Le remplacement d'un mainframe coûte des dizaines de millions de dollars et prend plus de
cinq ans, souvent plus longtemps que la plupart des mandats de CIO. Jusqu'à la SOA, de
nombreuses entreprises étaient tout simplement bloquées. Nous expliquerons une stratégie
d'activation de service pour migrer hors du mainframe un service à la fois. Cette approche
permet de réduire les cycles de maintenance de plusieurs mois à plusieurs semaines et de
réduire de 70 % le nombre d'employés informatiques impliqués dans la recherche et la
correction des bogues. De plus, cette technique de modernisation des applications peut être
étendue aux applications serveur client héritées, et des outils SOA avancés tels que BAM
(Business Activity Monitoring) et un moteur de règles peuvent moderniser et optimiser
considérablement une application existante grâce à des stratégies en boucle fermée pour
obtenir un impact commercial significatif.

55
 Programme de facilitation de service

Lignes directrices d’approche

• Concevoir un seul service à la fois
• Concevoir des systèmes de services
• Concevoir un service qui permet la
facilitation de vos applications d'entreprise

Voici trois approches pour garantir le succès de votre migration vers l'architecture SOA.

56
 Accélérateurs de valeur d’affaires de SOA
“SOA Sweet Spots”
Changement constant de l'industrie
 Consolidation de l'industrie
 Personnalisations de base commune
 Applications multi-canaux
 Reseau Service B2B

xxx

Changement constant de l'industrie

Étant donné que la SOA se nourrit du changement, il n'est pas surprenant que vous recherchiez des
environnements dans lesquels des changements fréquents et souvent imprévus peuvent être anticipés. Les
exemples incluent l'industrie des télécommunications, où la concurrence oblige à des cycles d'introduction de
nouveaux produits de plus en plus courts, et l'industrie de la santé, où la nouvelle législation exige la conformité aux
révisions des processus.
Consolidation de l'industrie
On a vu de nombreux projets SOA réussis unifier plusieurs systèmes back-end hérités d'acquisitions. Par
conséquent, nous pensons qu'une entreprise qui acquiert activement d'autres entités est un bon candidat pour la
SOA, et le nombre d'acquisitions est une mesure clé à prendre en compte.
Personnalisations de base commune
Il s'agit d'un scénario typique dans le domaine de l'externalisation des processus métier (BPO – Business Process
Outsourcing). L'idée est de maximiser la réutilisation des services de base dans plusieurs projets clients.
Applications multi-canaux
Avec l'essor d'Internet, de nombreuses entreprises proposent leurs services via plusieurs canaux tels que les
agents de l'entreprise, les services en ligne et les liens vers des partenaires. Par conséquent, la plate-forme de
services SOA est adaptée pour alimenter plusieurs canaux.
Reseau Service B2B
La grande vision de la SOA est un monde en réseau dans lequel les entreprises fournissent des offres de services
virtuelles qui intègrent de nombreuses offres de services de partenaires électroniques (business to business).

57
 Architecture stratifié SOA/BPEL

Interface utilisateur

processus /
intégration /
logique applicative

Une architecture en couches typique comprend deux couches distinctes de processus BPEL
(Business Process Exécution Language).
1. La première couche est une couche de niveau inférieur d'orchestrations de « micro-flux » qui
transforment les interfaces d'application (services d'implémentation) en services métier
significatifs que les analystes métier comprennent et adoptent donc plus facilement.
2. Des processus métier de haut niveau sont construits au-dessus de ces services métier.
Cette architecture en couches, naturellement activée par BPEL, permet de réagir rapidement aux
demandes de changement. Étant donné que la couche de micro-flux n'est pas affectée par la
plupart des changements d'exigences, de nombreuses modifications sont limitées à la couche de
services métier. Ce niveau de réutilisation réduit le nombre de cycles consacrés aux modifications.
Il est important de prendere avantage de l'Enterprise Service Bus (ESB). L'ESB est clairement une
partie importante d'une infrastructure SOA, car il fournit une couche de messagerie basée sur des
normes avec des capacités de virtualisation des services. Les responsables informatiques
responsables du centre de données apprécieront les avantages d'un ESB lors de l'exécution.
Cependant, ne vous laissez pas berner en pensant que l'achat d'un ESB et la simple exposition
des interfaces de bas en haut en tant que services Web est un raccourci vers la SOA. Vous devez
également considérer BPEL pour l'orchestration des services comme un élément clé de votre
stratégie SOA et essayer d'identifier les bons services métier grâce à une conception de processus
descendante.

58
 SOA & BPM
Applications
SOA Suite resp. CRM HCM Financials SCM Legacy BPM Suite est
conçue pour la
• BPEL / SCA conception des
• Service Bus Processus Métier et
• ODI gestion des équipes
• GoldenGate de soutien pour
• MFT analyse métier
• AIA

integration
Au niveau
JAVA, XML, DB

Il y a le syndrome de «l'écart d'alignement métier/IT» résultant des approches de

développement traditionnelles (comme le développent en cascade/waterfall). Tout d'abord,
les analystes commerciaux explorent et documentent les exigences par eux-mêmes
pendant des mois. Une fois ces exigences gelées, le service informatique développe
l'application. Plusieurs mois plus tard, la demande est terminée et tout le monde est surpris
que les exigences initiales aient changé, aient été mal interprétées ou simplement mal
analysées. Mais après 12 à 18 mois, l'application a été conçue avec peu de flexibilité pour
le changement. Par conséquent, cela devient un handicap, et non un atout, dès le premier
jour. Bientôt, une nouvelle application sera construite à partir de zéro pour remplacer son
prédécesseur dans un autre projet informatique "big bang"...
Le mariage des techniques de développement SOA et BPM crée une opportunité de mettre
fin à ce gâchis.

59
 SOA & BPM

SOA Suite Applications

BPM Suite
CRM HCM Financials SCM Legacy
Webservices

BPEL Employee
Credit? Supplier?
Analysts
?
Business
Developer 'Drawing'
IT Business Processes
Integration BPMN
'Programming' BPM Suite
Atomic / Small Share / Team
SOA Abstract
Tax Catalog Stock
Suite Calc. upd. upd.

Webservices
JAVA
Developer
BPMN - Business Process Modeling Notation

Ceci est un exemple de la manière dont SOA et BPM peuvent travailler ensemble afin
de créer un nouveau produit de crédit pour une institution financière.

60
 SOA Suite & BPM Suite

Autonome ou Coexistence
Fonctionne sur WebLogic (et d'autres)
La suite BPM est livré avec SOA Suite
Les deux fournissent: - Human Workflow
- Règles d'affaires
- Business Activity Monitoring (BAM)

Oracle 6

Tout comme le BPM et la SOA convergent, les frontières entre les disciplines de
l'intégration et de la création d'applications composites s'estompent également. Il existe
une similitude significative entre le modèle de valeur 1, qui se concentre sur
l'intégration basée sur des normes, et le modèle de valeur 2, qui décrit comment créer
des applications composites modernes. Ce n'est pas surprenant étant donné la vision
de la SOA de construire des applications intégrables. Dans le monde SOA, les
architectes d'applications commenceront par créer des couches de services métier que
les futures applications pourront réutiliser. Les architectes d'intégration ne seront pas
limités à l'intégration de données entre les applications packagées ; ils créeront des
applications composites qui apporteront de la valeur en connectant les canaux Web.

61
 SOA dans le Nuage (Cloud)

Pour la dernière section de ce cours, nous examinerons comment la SOA a tiré parti de
la technologie cloud et quelle est la stratégie de la SOA dans le Cloud.
 Le monde change - pour nos
clients et pour nous!

Les plateformes existent depuis des années. L'informatique rend la construction et la

mise à l'échelle des plates-formes beaucoup plus simples et moins chères, permet une
participation presque sans friction qui renforce les effets de réseau et améliore la
capacité à capturer, analyser et échanger d'énormes quantités de données qui
augmentent la valeur de la plateforme pour tous. Vous n'avez pas besoin de chercher
loin pour voir des exemples d'entreprises de plate-forme, d'Uber à Alibaba à Netflix,
dont la croissance spectaculaire brusquement bouleversé leurs industries.
Une plate-forme fournit l'infrastructure et les règles d'un marché qui réunit producteurs
et consommateurs. Les acteurs de l'écosystème remplissent quatre rôles principaux
mais peuvent passer rapidement d'un rôle à un autre. Comprendre les relations à la
fois à l'intérieur et à l'extérieur de l'écosystème est au cœur de la stratégie de la plate-
forme. Ça te dit quelque chose? il s'agit beaucoup de SOA et de BPM !
 ... Et elle exige une fondation
forte d'intégration

Les trois piliers de la stratégie d'Oracle pour la SOA dans le Cloud :

1. Connecter tout en unifiant les connexions aux appareils, aux données, aux API et
aux applications ;
2. Simplifier l'intégration en éliminant la complexité entre le cloud et les applications
mobiles comme base d'une entreprise connectée ;
3. Offrez flexibilité et choix en permettant à votre intégration de passer au cloud ou
d'être étendue sur n'importe quelle plate-forme.
 La stratégie Oracle d'Intégration
dans le Nuage

C'est pourquoi Oracle fournit des services d'intégration en tant que plate-forme dans le
Cloud (PaaS). La même plate-forme est également disponible sur site. Il est également
possible de fournir une intégration hybride entre les applications cloud et sur site
 Plate-forme Cloud pour l'intégration
des différents utilisateurs

Oracle Integration est une plate-forme de connectivité et d'automatisation d'entreprise

permettant de moderniser rapidement les applications, les processus métier, les API et les
données. Les développeurs et les architectes cloud peuvent connecter les applications
SaaS et sur site six fois plus rapidement avec une expérience de développement visuelle,
des intégrations prédéfinies et des meilleures pratiques intégrées. Oracle Integration vous
donne un accès natif aux événements dans Oracle Cloud ERP, HCM et CX. Connectez des
silos analytiques spécifiques à l'application pour simplifier la demande d'achat à la
réception, le recrutement au paiement, le prospect à la facture et d'autres processus
critiques. Enfin, offrez à vos responsables informatiques et commerciaux une visibilité de
bout en bout.
Oracle SOA offre la possibilité de déplacer des intégrations existantes sur site et des
applications composites vers le cloud telles quelles avec Bring Your Own License (BYOL)
et la possibilité de créer des intégrations modernes avec Oracle Integration.
 Avantages
• Facilite le développement, la maintenance et
l'intégration des grandes applications
• Permet aux entreprises de reconfigurer les
applications sans avoir à réécrire beaucoup de
code ou de modifier les bases de données
• Favorise la réutilisation de composants
d'affaires et des données dans de multiples
applications et des canaux d'accès (comme la
téléphonie mobile, web, desktop et batch)
 Limites
• Normes incomplètes
• Difficultés liées à la réutilisation des services
entre les équipes de développement disparates
• Beaucoup de services spécifiques à
l'application ne peuvent pas être réutilisés

Comme vous pouvez l'imaginer, l'architecture orientée services peut être un peu
difficile à casser, mais une fois que vous en aurez compris les rouages et les
avantages qu'elle peut apporter à votre entreprise, vous serez ravi de l'avoir
découverte.
Quelle que soit la direction dans laquelle vous décidez d'aller lorsque vous fournissez
des services à vos clients, il est important de garder à l'esprit que différentes choses
fonctionneront pour différentes personnes. Bien que vous ne puissiez pas fournir de
services personnalisés pour chaque client que vous avez pris en charge, vous pouvez
fournir une gamme de services qui répondront aux besoins les plus courants de vos
clients.
  Les microservices, également connus
sous le nom d'architecture de
microservices, sont un "style
architectural qui structure une
application comme une collection de
petits services autonomes, modélisés
autour d'un domaine métier". Bien
que les microservices et l'architecture
orientée services soient similaires à
certains égards, les principales
différences résident dans leurs
fonctionnalités.

Les services sont évidemment la principale composante des deux architectures. Il

existe quatre types de services de base :
1. Service fonctionnel : ceux-ci définissent les opérations commerciales de base;
2. Service entreprise : ceux-ci implémentent les fonctionnalités définies par les
services fonctionnels;
3. Service applicatif : ceux-ci sont limités à un contenu applicatif spécifique;
4. Service d'infrastructure : implémente des tâches non fonctionnelles telles que
l'authentification, l'audit, la sécurité et la journalisation.
Comme vous pouvez le voir, chacun de ces services s'appuie sur celui qui le précède,
créant un système qui est non seulement facile à utiliser, mais qui vous offre une
variété de façons de gérer votre entreprise. Comme pour toute fonctionnalité, il s'agit
de déterminer ce qui fonctionne le mieux pour vous et votre entreprise.
 Avec SOA (Service-oriented architecture), les applications
composites élargissent le périmètre de l'Automatisation par
(choisir toutes les bonnes réponses):
a. Réutiliser les services fournis par les applications
d'entreprise et d'autres fournisseurs de services et étendre
la portée de l'automatisation
b. Étendre la portée des produits du fournisseur tandis que
les utilisateurs peuvent les étendre d’avantage
c. Ouvrir la porte à la transformation des relations d'affaires à
tous les niveaux

Response: a, b, c.
 Quelles sont les différences entre l'architecture orientée services
SOA et les microservices (choisir toutes les bonnes réponses):
a. Les microservices sont un "style architectural qui structure
une application comme une collection de petits services
autonomes
b. Bien que les microservices et l'architecture orientée
services soient similaires à certains égards, les principales
différences résident dans leurs fonctionnalités
c. Il n’y a pas de différences, le terme microservice remplace
l’ancien terme SOA

Response: a, b.
 Workflow Management: Models, Methods and Systems. ISBN 0-262-
01189-1. MIT Press, 2002, W.M.P. van der Aalst and K.M. van Hee.
 Process Aware Information Systems, Wiley, 2005, Dumas Marlon, Van
Der Aalst Wil and Arthur H. M. ter Hofstede.
 Processus métiers et S.I., "Evaluation, modélisation et mise en oeuvre" ,
Edition Dunod, 2005, Chantal Morley, Jean Hugues, Bernard Leblanc,
Olivier Hugues.
 Les processus métiers : concepts, modèles et systèmes
http://www.loria.fr/~godart/BPM/PM_chapitre3.pdf
 What Is Service-Oriented Architecture?,
https://medium.com/@SoftwareDevelopmentCommunity/what-is-service-oriented-architecture-fa894d11a7ec

 https://www.oracle.com/integration/soa/
 « Production workflow : concepts and techniques », Frank
Leymann, Dieter Roller, Prentice Hall
 « Workflow Mangement : models, methods and systems »,
Wil van der Aalst, Kees van Hee, MIT Press
 « Process-Aware Information Systems », Marlon Dumas, Wil
van der Aalst, Arthur ter Hostede, Wiley
 « Business Process Management : concepts, langages,
architectures », Mathias Weske, Springer
 Mashup Corporations – The End of Business as Usual: Andy
Mulholland, Chris S. Thomas, Paul Kurcina with Dan Woods,
Evolved Technology Press, New York 2006