Centre d’enseignement de Reims

Rue des Crayères

BP 1034, 51687 REIMS Cedex 2
tel 03 26 36 80 10

Examen
Année universitaire 2011 -2012

Unité d’enseignement

Code de l’UE NFE107

Intitulé Urbanisation et architecture des systèmes d’information

Enseignant (s) M CROQUIN, M GRAVILLE, M MAURY

Examen

Date 08/09/2012

Session 2ème session

Durée 2 heures Horaires 13h15-15h15

Consignes particulières

Aucun document autorisé.

En cas de problème durant l’épreuve, joindre le centre d’enseignement à distance du Cnam

Champagne-Ardenne au 03 26 36 80 07.

1/8
 PARTIE 1 – QUESTIONS DE COURS – 7 POINTS

Question 1 (3 pts) – Citez et explicitez 3 éléments différentiateurs majeurs entre

un Architecte et un Urbaniste.

Question 2 (2+2 pts) – Qu’est ce qu’ITIL ? Pouvez-vous citer deux aspects (au
sens très général) d’un système d’information qu’ITIL « couvre » ?

2/8
 PARTIE 2 – REFLEXION – 6 POINTS
« L'urbanisme, c'est découpler les applications »
Grégory Weinbach le 27 mai 2003

http://www.journaldunet.com/solutions/itws/030530_it_weinbach.shtml

JDNet Solutions. Où s'arrête l'intégration et où commence l'urbanisme ?

Grégory Weinbach. : Le but d'une démarche d'urbanisme n'est pas d'unifier: on sait très bien faire
dialoguer ensemble des applications, avec un MOM [NDLR: Message Oriented Middleware] type
MQSeries, mais si on se focalise sur l'intégration technique, on peut investir beaucoup d'argent dans
quelque chose qui ne répond pas aux besoins de l'entreprise. L'objectif ultime est de permettre au SI
d'évoluer facilement, de faire migrer une application progicielle vers du spécifique ou l'inverse,
d'intégrer un nouveau service, etc.
Pour cela, l'essentiel est de pouvoir remplacer une application par une autre sans toucher au reste: il
s'agit de découpler les applications, s'assurer par exemple qu'un message est indépendant
techniquement de sa source et de sa destination, ce qu'une approche EAI n'effectue que vu de
l'extérieur.

Quelles sont les composantes de l'urbanisme des SI ?

Il s'agit d'un projet à étapes. D'abord, il est nécessaire d'identifier ce qui constitue la chaîne de valeur
ajoutée de l'entreprise: les processus métier. Comment interagissent les systèmes, quels sont les flux
qui sont échangés, etc. Ceci permet de bâtir un référentiel métier qui modélise une cible proche de
l'existant, destinée à évoluer, dynamique, itérative. Prendre en compte cette dimension fonctionnelle,
c'est garantir la souplesse de son SI afin de mettre en oeuvre un lien objectif entre les décisions
stratégiques et leurs projections sur l'infrastructure technique.
Il est important de noter que l'urbanisation est un projet d'entreprise qui s'inscrit dans la durée, et qui
est impliquant: la décision émane généralement de la direction générale, nécessite des budgets
importants, la création d'une structure fonctionnelle de liaison...

La notion de processus est mise en avant par les acteurs du monde des progiciels comme
SAP, PeopleSoft ou Siebel, Cela répond-il à la problématique d'urbanisation ?
L’approche progicielle n'est pas urbanisée pour la raison suivante: ce que nous définissons comme des
blocs d'urbanisme découplés sont au contraire fortement couplés dans un progiciel, où il est difficile de
faire évoluer un module sans faire évoluer le reste. On ne maîtrise pas ses processus, on ne peut pas,
par exemple, externaliser ce qui correspond à un bloc d'urbanisme. Par contre, la démarche progicielle
est pertinente si on veut déléguer la gestion de ses processus, et à l'inverse, il n'est pas interdit dans
une démarche d'urbanisme d'utiliser des éléments progiciels comme choix d'implémentation
technique.

Comment s'organise la modélisation et l'évolution du projet d'urbanisation ?

Prenons l'exemple de notre client Bouygues Telecom, pour lequel nous avons mis en place une
démarche d'urbanisme fin 99 début 2000 avec la construction d'un référentiel métier ciblant le SI
commercial, mais ayant un impact sur l'ensemble du réseau de l'entreprise. Nous avons procédé par
des entretiens avec les acteurs de la maîtrise d'ouvrage, puis par validation et prototypage de
spécifications formelles: par le biais d'enchaînement d'écrans, de scénarios concrets de manipulation
de données réelles, nous avons pu obtenir un retour sur des simulations de processus. Par ailleurs, il
fallait favoriser l'appropriation du formalisme de notre référentiel par les acteurs, ce qui est un aspect
fondamental: sans un transfert de compétence et une bonne communication, on court le risque que les
travaux restent lettres mortes faute d'une maîtrise d'un vocabulaire pivot.

Quels sont les choix techniques d'Objet Direct pour la modélisation des processus ?
Nous aimons travailler avec l'UML, qui est un outil standard bien adapté à la modélisation de bout en
bout, mais n'est pas obligatoire. Les entreprises ont souvent des outils de BPM avec leur formalisme
propriétaire ou non, qui permettent de faire beaucoup de choses. Cela dit, le BPM ne permet pas de
décrire le contenu fonctionnel des flux, au contraire d'UML.

3/8
Question 1 (4 pts): Quelles sont les raisons pour lesquelles nous sommes censés,
dans le cadre d’une démarche d’urbanisation, définir des blocs découplés ?
Qu’attendons-nous des services qui composent ces blocs ? En bref, quelles sont les
règles de conception des services permettant d’éviter de construire des « plats de
spaghetti » ?

Question 2 (2 pts): Les ERP répondent-ils à cette attente ? Dans quelle mesure ?

4/8
 PARTIE 3 – REFLEXION – 7 POINTS
Votre entreprise souhaite, dans le cadre d’une démarche d’urbanisation cohérente, initier une
analyse de ses différents processus métier. Toujours au fait des plaquettes commerciales de ses
différents partenaires, votre direction s’exprime ainsi :
- Il parait qu’on peut économiser des coûts en optimisant nos processus, en séminaire, nous
avons entendu plein de choses sur le sujet en séminaire il y a peu (traduction : en 2004…) :
BPM, UML, XPDL…
« Vous pouvez nous résumer en 2 mots le sujet ? »

Vous hésitez bien sûr à répondre immédiatement non, mais vous commencez cependant une
petite étude du sujet en parcourant diverses sources sur Internet, fort de votre sensibilisation nouvelle
en urbanisation.

Texte 1 : BPM sur CommentCaMarche.Net

Introduction au BPM
On appelle « BPM » (Business Process Management, traduisez littéralement « gestion des
processus métiers ») l'approche consistant à modéliser informatiquement les processus métiers de
l'entreprise, aussi bien dans leur aspect applicatif qu'humain.
L'objectif de cette démarche est d'aboutir à une meilleure vue globale de l'ensemble des
processus métiers de l'entreprise et de leurs interactions afin d'être en mesure de les optimiser et,
dans la mesure du possible, de les automatiser au maximum à l'aide d'applications métier.

Une démarche « bottom-up »

La démarche du BPM propose une approche ascendante, dite « bottom-up » (du bas vers le
haut), consistant à analyser le fonctionnement réel de l'entreprise afin de le modéliser informatique.
Cette démarche constitue une rupture par rapport aux schémas généraux, dits « top-down »
(traduisez « du haut vers le bas »), dans lesquels le fonctionnement de l'entreprise doit s'insérer dans
un modèle proposé par l'équipe dirigeante.

Cycle de vie d'un processus métier

Le cycle de vie d'une démarche BPM peut globalement être décomposé de la manière suivante :
- Etude de l'entreprise en analysant ses objectifs et son organisation afin d'être en mesure de
décomposer l'ensemble de son activité en processus métier.
- Modélisation des processus métiers, c'est-à-dire représenter informatiquement un modèle le
plus proche possible de la réalité,
- Implémentation de la solution : mise en oeuvre d'une solution de BPM, reliée au système
d'information de l'entreprise (applications et bases de données)
- Exécution : il s'agit de la phase opérationnelle où la solution de BPM est mise en oeuvre.
- Pilotage, consistant à analyser l'état des processus à travers des tableaux de bords présentant
les performances des processus
- Optimisation, c'est-à-dire proposer des solutions permettant d'améliorer les performances des
processus métiers

Eléments constitutifs
Une solution de BPM comprend généralement les éléments suivants :
- Un outil de modélisation de processus, permettant de modéliser à l'aide d'une interface
graphique les processus métiers de l'entreprise.
- Des outils d'aide à l'implémentation, c'est-à-dire des interfaces (API) et des connecteurs
permettant d'intégrer la solution de BPM au système d'information.
- Un moteur d'exécution (moteur de workflow) chargé d'instancier les processus et de stocker le
contexte et leur état dans une base de données relationnelle.
- Des outils de pilotage et de reporting basé sur des indicateurs précis et pertinent afin de
disposer de tableaux de bord permettant de prendre rapidement les bonnes décisions. On parle

5/8
 ainsi de BAM (Business Activity Monitoring) pour désigner la notion de contrôle du déroulement
des processus de l'entreprise.

Standardisation du BPM
Un des objectifs du BPM est la réusabilité, c'est-à-dire la capacité à ne pas réinventer la roue à
chaque changement. Or, la plupart des outils sont propriétaires, c'est-à-dire qu'ils possèdent leur
propre modèle de données et un mode de fonctionnement opaque, ce qui les rend difficilement
interopérable.

Ainsi, la standardisation de la représentation des processus est un enjeu majeur pour faciliter
l'intégration entre les outils de BPM. La standardisation a lieu à différents niveaux :
- Au niveau de la modélisation des processus
- Au niveau de l'exécution des processus
- Au niveau de la communication avec le SI

BPMN
BPMN (Business Process Modelling Notation) est une initiative de la BPMI (Business Process
Management Initiative, un consortium d'entreprises) visant à définir une notation graphique commune
permettant de modéliser les processus métier.
La notation BPMN permet notamment de découpler l'information métier de l'information
technique (éléments techniques du système d'information) afin de maximiser sa portabilité d'une
entreprise à une autre.
BPMN peut être vu comme une notation UML appliquée à la gestion des processus métier.

BPEL
BPEL (Business Process Execution Language) est une initiative de la BPMI dont le but est de
proposer une représentation XML des activités liées à l'exécution d'un processus. Là où la notation
BPMN s'attache à décrire statiquement les processus, le langage BPEL décrit la dynamique d'ensemble.

Dernière modification le mardi 14 octobre 2008 à 17:40:39

Ce document intitulé « BPM - Business Process Management » issu de Comment Ça Marche
Informatique (www.commentcamarche.net) est mis à disposition sous les termes de la licence Creative
Commons. Vous pouvez copier, modifier des copies de cette page, dans les conditions fixées par la
licence, tant que cette note apparaît clairement.

Question 1 (1 pt) : La définition du Bottom-Up proposée par ce texte convient à

l’analyse organisationnelle de processus. Pouvez-vous donner une autre définition du
Bottom-Up, appliquée à l’urbanisation informatique ?

Question 2 (1 pt) : Réusabilité

Pouvez-vous donner un meilleur mot à utiliser en français ? Ainsi qu’en proposer une
courte définition pointant ses avantages ?

Question 3 (2 pts) : Solution idéale

Selon le texte 1, de quoi devrait se composer une solution de BPM ?
Dans quelles visions voyez-vous une place pour chacun de ces composants ?
Que pouvez-vous dire de chaque composant ?

6/8
 Texte 2 : BPM : Vers une standardisation des pratiques ?
Modélisation des processus métiers et standardisation

Source : Journal du net, (17/09/2004), tiré du site BPMS.info.

XPDL, BPML, BPEL

Ces langages de modélisation de processus sont des langages dédiés à l’exécution de
processus. Ils ne sont généralement pas utilisés directement dans les phases de conceptions.
Exprimés dans une syntaxe XML, ils disposent ainsi d’un format d’échange natif. Aucun d’entre
eux ne propose une notation graphique standardisée. Par définition, ils n’ont pas vocation à couvrir les
niveaux d’analyse des chaînes de valeur et de l’organisation.
Le premier standard d’exécution est apparu sous l’égide de la WFMC – Workflow Management
Coalition. Une nouvelle version XML du langage de la WMFC a été publiée en 2002 sous le nom de
XPDL.
Le groupe BPMI – Business Process Management Initiative – a lancé un langage concurrent en
2001 : BPML – Business Process Modeling Language. Cette initiative a relancé les travaux sur les
langages d’exécution de processus et a apporté de nombreuses contributions à son successeur, le
langage BPEL.
Le langage BPEL – Business Process Execution Language – a été lancé à l’initiative de Microsoft
et IBM en réponse à l’initiative de BPMI. Depuis, ce langage a reçu le support de la plupart des acteurs
du marché, y compris de BPMI. BPEL est devenu le standard de facto.
Il vient en complément de la spécification sur les services webs. Depuis 2003, c’est l’organisme
de standardisation OASIS qui a en charge l’évolution du langage BPEL.

UML vs BPMN
Proposé par l’OMG pour la conception orientée objet, UML 1.X (1.1, 1.2, 1.3, 1.4) dispose d’un
modèle d’activité qui présente certaines fonctionnalités pour la modélisation des processus. Il présente
l’avantage d’offrir à la fois un métamodèle, une notation et un format d’échange pour les modèles avec
XMI 1.x. Cependant, sa portée reste limitée à la conception objet et son métamodèle comporte
certaines erreurs sémantiques (activité = état) qui en réduisent d’autant le caractère opérationnel. Ces
faiblesses ont été reconnues par l’OMG qui a profondément revu ce modèle dans la version 2 d’UML.
La fin de l’année 2004 devrait voir l’aboutissement de la spécification UML 2.0 de l’OMG, fruit
d’un long processus de maturation. UML 2.0 est une spécification très vaste et nous ne dirons ici que
quelques mots sur le nouveau « modèle d’activité ». Les modèles d’activités d’UML 2.0 ont été
totalement revus par rapport aux versions 1.X. Les erreurs notables des spécifications 1.X ont été
corrigées et le nouveau modèle offre une base robuste pour l’analyse des processus. Cependant, par
son caractère technique, il s’adresse encore essentiellement à des concepteurs de processus
automatisés. Le modèle d’activité d’UML 2.0 ne peut pas fournir, tel quel, un support d’analyse et de
communication pour les processus "métier". L’OMG a conscience de ces limitations et à lancer une
initiative complémentaire – BPDM – pour traiter spécifiquement des processus métier (voir paragraphe
ci-dessous sur BPDM).

BPMN – Business Process Modeling Notation

A la suite du langage d’exécution BPML, BPMI a lancé une nouvelle initiative sur la notation
graphique des processus. C’est ainsi qu’a été publiée la spécification BPMN 1.0 en mai dernier. BPMN
présente une avancée indéniable dans la formulation graphique des processus.
Elle introduit, en particulier, la notion de message et de flux d’information qui manquait à la
plupart des représentations traditionnelles de processus (IDEF, SAP EPC). Certains articles se sont fait
dernièrement les promoteurs de cette nouvelle spécification. Nous apporterons ici un point de vue
interne au groupe de travail ayant participé directement à la spécification.
BPMN 1.0 a pour périmètre fonctionnel l’analyse des processus automatisés. Celles des chaînes
de valeur et de l’organisation ne sont pas dans son cahier des charges. […] Les règles de
correspondance avec le langage d’exécution BPEL viennent compléter le dispositif.
Une deuxième remarque important concernant BPMN est que la spécification adresse
uniquement la question de la notation. BPMN ne spécifie pas un métamodèle ni un format d’échange. Il
sera donc difficile de parler d’échange de modèles BPMN. […]

7/8
 Des réponses devront aussi être apportées pour la définition d’un métamodèle et d’un format
d’échange. Des relations ont été engagées avec l’OMG afin de faire converger les travaux des deux
organisations.

Les autres référentiels

Les normes ISO 9000/2000 : L’ISO a été une des premières organisations à s’intéresser aux
processus métiers avec les normes de la famille ISO 9000. L’ISO fournit de nombreuses définitions
très pertinentes pour les niveaux d’analyse concernant l’organisation ou les chaînes de valeur.
Malheureusement, l’ISO n’a jamais fourni ni une expression formelle des processus qualité ni une
notation graphique associée. Conséquemment, Les normes ISO 9000 n’ont pas conduit à un standard
de modélisation des processus. Elles restent une référence pour l’analyse des processus qualité.

BPDM – Business Process Definition Metamodel

L’OMG a son propre plan de développement pour couvrir la modélisation des métiers. Ce plan
s’inscrit dans l’architecture générale de modélisation promue par l’OMG sous le nom de MDA :
Model Driven Architecture. MDA est un cadre pour définir des métamodèles, les transformer,
définir les notations associées et échanger les modèles et leurs diagrammes dans un format d’échange
normalisé (XMI). Le cadre MDA fournit ainsi automatiquement les éléments essentiels à tout standard
de modélisation.
Pour la prise en compte de l’analyse des métiers l’OMG a lancé plusieurs initiatives conjointes :
la spécification des règles métiers – BSBR : business semantic for business rules – et la spécification
des processus métiers – BPDM. Cette dernière spécification s’appuie sur les modèles d’activité d’UML
2.0 mais en en simplifiant l’utilisation et en prenant en compte les différents niveaux d’analyse des
processus : implémentation, organisation, stratégie.
L’OMG et BPMI ont commencé à nouer des contacts pour coordonner leurs efforts. Le plan de
travail de BPDM à l’OMG inclut la prise en compte de la notation BPMN. Cependant, les deux
organisations ont gardé chacune leur marge de manœuvre.

L’inconnue Microsoft
Il reste une inconnue dans l’univers de la modélisation des processus, c’est l’attitude de
Microsoft. Il peut sembler étrange de citer la firme de Redmond sur ce sujet. Cependant, Microsoft a
pris très au sérieux la place de la modélisation dans la conception des logiciels. Un projet appelé
"Whitehorse" vise à intégrer la modélisation au cœur de la plateforme de développement de l’éditeur.
De la modélisation des composants à celle des services web jusqu’à celle des processus d’intégration,
on voit ici le chemin suivi depuis le code vers des spécifications de plus en plus orientées métier. En
fait, Microsoft cherche à s’opposer à l’initiative MDA de l’OMG qui est fortement soutenue par IBM et
les autres acteurs de la modélisation. Les éléments de convergence entre les deux approches ne sont
pas encore clairement définis.

En résumé
L’activité de standardisation des processus métiers est en pleine effervescence et de nombreux
progrès ont été accomplis. La partie exécution, sous l’égide de OASIS continue sa fusion avec les
services web ; la partie conception remonte des préoccupations d’exécution vers des problématiques
plus résolument métiers. Plusieurs organismes de standardisation participent à ce mouvement : BPMI,
OMG. Il faudra encore quelque temps pour que toutes les pièces du puzzle soient assemblées et
rodées et qu’un standard complet et unifié apparaisse clairement.

Question 4 (3 pts) : A votre avis ? Par rapport à votre expérience de modélisation

métier d’entreprise (réalisée pendant le dossier, ou au travers vos expériences
professionnelles et personnelles, vers quelle(s) méthode(s) de modélisation iraient
votre (vos) préférence(s) ? Pourquoi ?

8/8