Examen. Année universitaire Urbanisation et architecture des systèmes d information. Consignes particulières

Transcription

1 Centre d enseignement de Reims Rue des Crayères BP 1034, REIMS Cedex 2 tel Examen Année universitaire Unité d enseignement Code de l UE NFE107 Intitulé Enseignant (s) Urbanisation et architecture des systèmes d information 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 / 8

2 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

3 PARTIE 2 REFLEXION 6 POINTS «L'urbanisme, c'est découpler les applications» Grégory Weinbach le 27 mai 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

4 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

5 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

6 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 ( 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

7 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

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 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