Groupe ISI 2013 Urbanisation Nicolas FIGAY

Présentation au sujet: "Groupe ISI 2013 Urbanisation Nicolas FIGAY"— Transcription de la présentation:

1 Groupe ISI 2013 Urbanisation Nicolas FIGAY nicolas.figay@gmail.com
Interventions Mars 2013 Nicolas FIGAY

2 Objectifs et plan de l’intervention
Pour des ingénieurs spécialisés en système d'information d'entreprise Comprendre ce qu’est l’urbanisation du système d’information d’entreprise Comprendre les apports et les limitations des approches actuelles Comprendre le potentiel d’y associer la cartographie sémantique et l’ingénierie des modèles Plan Problèmes et besoins des entreprises Constat non alignement DSI et entreprise Un nouvel outil: l’urbanisation du SI Les objectifs La métaphore de la cité Réalisation de cartographies Les principes Le processus d’urbanisation du SI Les diverses cartes Ce que ca apporte Exemple de cartes Meta modèles et concepts Limites Système complexe à considérer Entreprise étendue type 3 Modélisation Cartographie sémantique L’importance des standards Expérimentation: projet SUSIE Conclusion Bibliographie

3 Problèmes et besoin de l’entreprise
Utilisation de plus en plus systématiques des ordinateurs pour tout type d’activité et pour la communication SI au cœur des activités Importance stratégique d’un système flexible, adaptable, reconfigurable à un cout acceptable Besoin de rationalisation pour éviter le modèle spaghetti du Gartner Group Pérennité des investissements en terme de progiciels Interopérabilité requise pour la collaboration numérique Évolution constante des métiers de l’informatique et des techniques Difficultés: identifier les changements nécessaires à la mise en œuvre de la stratégie d’entreprise sauvegarde de la cohérence et amélioration de l’efficacité du SI Mise en place plus rapide et avec une meilleure qualité en réduisant les risques

4 Constat non alignement DSI-Entreprise
Il y a un constat sur le non alignement fréquent entre les départements informatiques s’occupant du Système d’Information et les besoins stratégiques de l’entreprise Peut être dû à: La complexité La différence de points de vue Une absence de prise de conscience de la dimension stratégique du SI et des technologies de l’information et de la communication Des méthodes et des pratiques qui sont devenues inadaptées Des problèmes culturels… Déphasage entre technologie, système d’information et maturité des dirigeants d’entreprise

5 Un nouvel outil: l’urbanisation du SI
Concept apparu progressivement lors des dix dernières années Lié à l’impossibilité de remplacer en une seule fois un SI par un autre de texture plus moderne Praticable à partir de l’apparition de la notion d’objet et de l’échange inter-objets de manière performante (middleware, EAI, ESB, transactionnel) pour passage à l’échelle Principe: traçabilité entre objectifs fondamentaux de l’entreprise et processus correspondants => Vue à moyen et long terme permettant de piloter au travers de plans de route (roadmap) ou de schéma directeurs.

6 Les objectifs Aligner les métiers, les processus fonctionnels, l’architecture applicative et technique sur les objectifs de l’entreprise Fournir les instruments clés et les guides de la représentation et de la cartographie du système d’information , pour un renouveau de la « cité » Permettre la définition et la représentation des référentiels et gisements de données liés à ce projet de refonte des SI Définir la nomenclature des actions à mettre en œuvre en soulignant les risques et les compétences requises pour aboutir aux résultats escomptés. Utilisable pour le dialogue entre experts: urbanistes, architectes, consultants, maitre d’ouvrage, etc.

7 La métaphore de la cité Métaphore de la cité et le vocabulaire associé, les règles et les principes de l’urbanisme des villes sont réutilisés pour le SI de la similitude de la problématique de départ: « Moderniser sans faire table rase du passé, dans des limites de coût maitrisés, tout en maintenant la vie dans la cité pendant les travaux » Plan d’urbanisme des sols (POS) Document d’urbanisme, en général à l’échelle d’une commune, fixant les règles générales d’utilisation du sol qui s’imposent à nous Pour une entreprise ou une organisation Défini services et responsabilités attachés à chaque sous ensemble, mais aussi l’organisation globale du SI en définissant Objet, mission des applicatifs et des composants Regroupement en ensembles cohérents Périmètres réservés à due futurs applicatifs à construire, notamment transversaux Compatible et aligné avec la stratégie d’entreprise, reflétant éventuellement les scénarios probables d’évolution des besoins métiers Comporte Un rapport de présentation synthétisant les orientations structurantes et la justification des options retenues Un ensemble de cartographies (documents graphiques) montrant avec précision les subdivisions du SI, avec les règles d’urbanisation associées Les règles d’urbanisme et la définition des services de chaque zone, quartier et ilot Annexes

8 La métaphore de la cité Similarité entre la cité et le SI
Règles à suivre par les architectes pour contrôler l’évolution de la cité Plan d’urbanisation régulièrement mis à jour Défini par un pole d’urbanisme La cité grandie harmonieusement, avec des infrastructures adaptée Sur ces principes, sont produits: Des cartes Des règles d’urbanisme Des infrastructures pour l’intégration des applications Des plans à long terme (as is situation, to be situation) Information system  city Application house Communication Infrastructures  Enterprise Service Buses Administration services repositories Urbanism rules  integration constraints City planning  “schéma directeur”

9

10 Le processus d’urbanisation du SI

11 La réalisation des cartographies
La cartographie Scientifique dans ses fondements et ses méthodes, repose sur un méta modèle Artistique dans sa conception, avec modes de représentations (signes, symboles, couleurs, etc) dont la combinaison concourt à l’efficacité, l’esthétique étant à la fois une fin en soi mais aussi un moyen de faciliter la transmission du message Technique par les procédés employés

12 Les principes Urbaniser permet de
Fédérer des briques d’un SI existant autour d’une architecture d’ensemble et de principes permettant d’acquérir flexibilité et réactivité nécessaire Gérer la prise en compte rapide et efficiente par le SI des demandes d’évolutions Faire porter les évolutions de développement sur les nouvelles fonctionnalités à forte valeur ajoutée et de réutiliser en majeure partie le système existant Passer d’un système existant à un système cible par pallier successifs correspondants à des étapes stables (roadmap) Maitriser des risques par paliers successifs et maitrisables D’obtenir un meilleur bilan financier en global dans le cas d’une évolution progressive Cadre de référence distinguant 4 visions du SI Métier (métiers et activités supportés par le SI), fonctionnelle (fonctions du SI pour supporter les métiers), applicative ( ensemble des éléments applicatifs du SI) et technique (ensemble de matériels, logiciels de bases et technologies utilisés) La vision applicative est au cœur de l’opération d’urbanisation: applications existantes vers applications futures Décomposition en zones, quartiers et ilots (blocs) Réorganisation d’un SI avec définition effective et modulaire des blocs Basé sur les approches objet Cohérence forte/couplage logique faible Minimisation de l’impact des changements Refonte possible progressive et totale

13 Les diverses cartes

14 Ce que ça apporte Nouvelle manière d’adresser la gouvernance des SI, en impliquant les divers experts et parti prenantes, sans être trop technique – tout le monde peut se référer à la métaphore de la cité Carte – visualisation de systèmes complexes Horizon plus large que la vision à un an

15 Exemple de cartes

16 Méta modèle et concepts Construit à partir de « Le projet d’urbanisation du SI - démarche pratique avec cas concret»,

17 Méta modèle et concepts
Acteur: selon définition UML, personne qui utilise le système ou agent externe Activité: unité de décomposition fonctionnelle du processus BDD: unité de stockage dans un SGBD, ensemble de tables Bloc: trois niveaux de découpages de l’architecture fonctionnelle et applicative: zone, quartier et ilots. Décrit par services assurées et principes de bases Bloc applicatif: module logiciel exécutable avec identité, proposant des services et ayant une prise bien définie – peut être une zone, un quartier ou un ilot applicatif (granularité); décrit par les fonctions assurées et les principes de base Classe concept: notion essentielle d’un concept métier Donnée: description des données utilisées dans le SI actuel et dans le système cible. Décrit par code, nom, format, type, etc. Evénement: signal reconnu par un acteur indiquant qu’un fait a eu lieu attaché à des données – pas de durée, daté, chainé, lié à plusieurs blocs, donnant lieu à des flux Flux: échange de données entre blocs Ilot: entité remplaçable du SI susceptible d’être développée ou achetée séparément. Finalité fonctionnelle, comprend traitements et accès à des données pour cette finalité. Correspond à une application, une grande fonction applicative, un progiciel ou un module de progiciel Message: mode de propagation entre blocs d’un flux de données associé à un événement de gestion

18 Méta modèle et concepts
Nœud physique: machine physique type avec environnement logiciel associé au point de vue système (OS,Pilotes, compilateurs, etc) Objectif: élément de définition de la stratégie d’entreprise Opération: étape d’une procédure correspondant à l’intervention d’un acteur de l’organisation dans le cadre des activités de l’entreprise. Une fois démarrée, va à son terme sans autres événements Procédure: processus organisé, i.e. avec dimension organisation (qui fait quoi)/processus. Décomposé en opération Processus: réseau d’activités ayant pour finalité le traitement d’un événement de gestion initiateur. A pour objectif la production de flux de résultats définis dans des conditions de délais et de qualité fixées pour répondre aux besoins tiers internes ou externes. Indépendant de l’organisation Quartier: regroupement d’îlots homogènes quand à la nature de l’information traitée (sous système). Ex: gestion des paiements, gestion des tarifs… SI: système d’information. Aspect d’une organisation qui fournit, utilise et distribue l’information. Il s’agit d’un aspect d’un système humain, contenant éventuellement des systèmes informatiques Site: lieu géographique considéré du point de vue d’une ou plusieurs activité. Ex: agence de Marseille Table: table de base de données ou fichier. Type de site: regroupement d’acteurs selon une structure de référence et ayant pour occurrence des sites géographiques. Zone: premier niveau découpage du SI – données par des règles de bonne pratique: zone échange, opération référentiel

19 Limites (1) Il y a pas une manière unique de réaliser des cartographies urbanistes Différentes “couleurs” Orientation analyse métier (c.f. Longépé – Urbanisation du système d’information - DUNOD) Orienté informatique Ne s’appuie pas toujours sur des formalismes standardisés en terme de langage textuel et graphique Ne s’appuie pas sur des modèles – or il est important pour des systèmes complexes de pouvoir appuyer l’activité sur l’usage de l’ordinateur (« Computer aided activities »), afin de travailler sur des représentations cohérentes et valides, incluant des modèles de comportement (une carte est en générale statique) et des vues multiples. Recouvrement des concepts de modélisation d’une carte avec un certain nombre de concept UML. De plus, si certains diagrammes UML pourrait être utilisés et spécialisés pour réaliser un certain nombre des ces cartes(ex: diagrammes de déploiement et de composants), les mises en correspondances ne sont pas toujour

20 Limites (2) Les problèmes d’interopérabilité sont partiellement adressées par l’approche urbanisme. Celle-ci doit être adressées en prenant en compte simultanément divers « systèmes »: les organisations, le DI et les applications distribuées La décomposition en zones, quartiers et ilots fourni un partitionnement et non pas une catégorisation, ce qui serait plus appropriée, du fait de la virtualisation, du découplage fonctionnel, logique et physique et des organisations matricielles. De fait, les décompositions ne se recouvrent pas nécessairement entre les diverses cartes L’urbanisation se limite au SI de l’entreprise. Hors la collaboration numérique avec l’extérieur de l’entreprise est de plus en plus important. Il faudrait pouvoir passer de la cité (urbanisme) au territoire (aménagement du territoire), selon des approches similaires, mais beaucoup plus fédératives qu’intégrées

21 Système complexe à considérer
Ecosystème d’entreprises Entreprises Systèmes d’informations Applications Composants logiciels Composant physiques, hardware Où sont les frontières? Sont elles alignées quand on change de point de vue ? (la réponse bien sûr est non) Différentes représentations et cartes peuvent compléter celles de l’urbanisme, avec les cartes de communautés eBusiness (écosystèmes de l’entreprise étendue), les architectures eBusiness, les architectures orientées services (services plugged on service bus), les réseaux physique constituant internet, etc. Quelques exemples de la manière de les cartographier suivent.

22 Entreprise étendue type 3 (collaborative) Echelle du territoire
Référentiel modèles d’information, services et processus de collaboration pour l’écosystème considéré

23 Entreprise étendue type 3 (collaborative) Echelle de l’entreprise avec le connecteur externe

24 Entreprise étendue type 3 (collaborative) Vue technique et applicative – la logique
Chaque composant fonctionnel se base sur des standards en terme de spécification et d’offre du marché: Portail avec WSRP-JSR168, moteur de workflow avec XPDL, composition de service avec BPEL, bus de service ESB avec RMI/IIOP, les standards du W3C, JBI, JCA, etc. Il s’agit de standards horizontaux. Il y a également les standards métiers verticaux (AP214) lié à une sémantique métier pour l’échange d’information, les services métiers et les processus métiers

25 Entreprise étendue type 3 (collaborative) Vue technique: le réseau physique (hardware)

26 Modélisation Utiliser les standards de modélisation pour modéliser les cartes, non pas les dessiner UML et les standards associés semblent offrir bien des opportunités Des diagrammes permettant de représenter des décompositions de type SI, zone, quartier et ilots: composants et déploiements UML comme langage extensible, permettant de créer un langage approprié pour des représentation graphiques (profiles UML) et manipulable par les ordinateurs (Profiles + XMI, meta object facitilities et MDA) Prendre en compte les langages de modélisation d’entreprise constituant des standards: Business Process Modeling Modélisation d’entreprise (COMET, Archimate, etc) …

27 Diagramme de composants et de déploiement en UML Appropriés pour réaliser des cartes?

28 Langage de description et de modélisation de cartographie Exemple rapide pour constituer un profile UML Les étapes pour une approche simplifiée sont les suivantes Création d’un profile Identification des métaclasses UML appropriées: classes, nœuds, composant, package, etc. Créations de stéréotypes pour les constructions de modélisation des cartes (selon le métamodèle – amélioré, proposé par C. Longépé) Création d’un modèle de type cartographie du SI, avec un certain nombre de diagrammes: objectifs (dérivé d’un diagramme de classe), processus (dérivé d’un diagramme de classe), et cartes fonctionnelles, applicatives et techniques (dérivées de diagrammes de composants ou de déploiement) Pour une approche industrielle, il faudrait: Compléter avec des formalismes graphiques (formes et icones) Compléter avec des règles et des contraintes permettant de valider le modèle et de ne proposer que les constructions permises Eventuellement passer à une formalisation d’un langage à part entière à partir du MOF, non pas à partir d’UML 2 - mais demande plus de développement, et il pourrait être intéressant de reprendre un sous ensemble des constructions UML comme construction de base de la cartographie. Autres limitations: UML est orienté diagrammes, d’où certaines contraintes sur ce qui peut être représenté graphiquement sur une seule carte Tous les outils ne permettent pas de modéliser graphiquement de manière ergonomique et rapide. Certaines limitations d’outils sont très contraignantes de fait Toutes les techniques de la cartographie sémantique ne sont pas toujours prises en compte par UML, et peuvent apporter des plus, notamment pour des représentations interactives et intuitives permettant de travailler sur des cartes représentants une réalité complexe.

29 Un profile UML pour modéliser les cartes comme des diagrammes UML

30 Un exemple de l’usage du profile

31 Cartographie sémantique
Représentation formelle et graphique de la connaissance, utilisant divers outils de visualisation tels des graphes (avec divers layouts), les boites imbriquées, les treemaps, etc.. On peut faire le lien avec la géométrie euclidienne et la géométrie analytique, qui sont complémentaires, l’une visuelle et inductive, l’autre analytique et textuelle Quelques exemples suivent qui sont exposés durant le cours: Jambalaya, touchgraph, yed et kartoo.

32 Cartographie sémantique
Quelques sites à explorer Le site de Christophe Tricot sur la cartographie sémantique: Les technologies de visualisation Le CHISEL group, avec Shrimp, Jambalaya et Creole: Yed: Touchgraph: Freemind: Treebolic: MagicDraw ( ) Visual Paradigm ( ) : création automatique de diagramme avec arrangement automatique Usage possible Fouille graphique et visuelle Dessin et mise en forme automatiques à partir d’un modèle Modélisation graphique – on dessine le modèle Notion de hiérarchie comme combinaison de relations hiérarchiques orientées Multi-vues et multi-représentations « efficaces » Hypergraphes Combinaison visualisation avancée avec divers langages de modélisation: ontologies, système, etc. Emergeant: cartographie urbaniste sémantique agrégeant les langages de chaque domaine d’expertise (analyse métier, architectes métiers/SI/eBusiness/logiciel, etc)

33 Modélisation et cartographie sémantique avec Protégé et Jambalaya
Les technologies implémentant le MDA restent le plus souvent “syntaxique” Elles sont plus contraignantes et moins flexibles que celles basées sur OWL Pour expérimenter les langages de modélisation et de représentation graphique dans un cadre sémantique et logique, on peut, en phase amont, expérimenter les modèles que l’on veut mettre en œuvre sur ces environnement Pour les cartes urbanistes: Formalisation des concepts de modélisation d’entreprise à utiliser Formalisation des concepts de cartes urbanistes à produire, en s’appuyant sur la combinaison de graphes (représentant des graphes sémantiques constitués par les concepts, leurs propriétés et certains individus) et de boites imbriqués (basé sur les hiérarchies, somme de relations hiérarchiques, par exemple la composition qui peut s’appliquer pour les zones, quartier et ilots) Il faut découpler le modèle de la représentation graphique Le transparent suivant fourni un exemple

34 Cartographie urbaniste avec Protégé 3.4.4 Beta Le modèle

35 Cartographie urbaniste avec Protégé 3. 4
Cartographie urbaniste avec Protégé Beta La vue associée à la cartographie urbaniste Une vue rapide est crée, de type Grid by type, avec: La sélection des relations de « composition » qui va définir la hiérarchie utilisée pour construire les boîtes imbriquées islandContaining (pour les applications, les processus, les logiciels); Q_contient_I (pour les ilots contenus dans les quartier)… La sélection des types d’arc à afficher ou à masquer islandContaining Affichage des relations entre applications et progiciels, applications et composant logiciels, etc Affichage entre processus et applications les supportant … Les concepts ont été créés à partir de rien, mais on pourrait s’appuyer sur des concepts utilisés par divers langages de modélisation d’entreprise, si possible standardisés, et en fonction de leur adéquation par rapport à la réalisation d’une cartographie urbaniste On peut enrichir avec la formalisation de plusieurs langages, et la capture des équivalences sémantiques On peut également enrichir avec des primitives de langages permettant de réaliser des cartes ou de la visualisation avancée

36 Cartographie urbaniste avec Protégé 3.4.4 Beta La carte
note: Jambalaya sur Protégé est boguée

37 Quelques langages de modélisation standardisés
Réutilisable pour définir son cadre d’urbanisation

38 Object Management Group Le marché du composant – UML, OMA, MDA

39 OMG, W3C, Wfmc Le marché du Business Process Modeling et les langages associés

40 Archimate and archi

41 What is ArchiMate ArchiMate is an Enterprise Architecture modeling language open and independent to support the description, analysis and visualization of architecture within and across business domains in an unambiguous way. ArchiMate is an Open Group’ technical standard based IEEE 1471 standard supported by various tool vendors and consulting firms. Registered trademark of The Open Group ArchiMate 2.0 certification program Can be obtained at ArchiMate distinguishes itself UML and BPMN by its enterprise architecture modeling scope

42 About Enterprise architecture
Enterprise architecture is about Making good choices in the light of the strategic goals and positions of the enterprise(s) Making coherent choices across you enterprise Making good choices in themselves (e.g. in sense of total cost of ownership, etc.) System architecture (ISO/IEC/IEEE 42010) “ Fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution Architect or Designer No so different, two forms of design with different level of detail they are concerned two But here stand the difficulty: what is the relevant level of details to deal with To deal with coherent detailed and non detailed views of the same model Evolution of the enterprise information system Current state (or AS IT IS) architecture (Business, Applicative, Technical layers) The future state (or TO BE) architecture (Business, Applicative, Technical layers Change architecture (Project – implementation & migration )

43 Open Group La modélisation d’entreprise avec Archimate
Technique de modélisation (langage) permettant de décrire l’architecture des entreprises Ensemble de concepts clairs et liens avec l’architecture pour d’autres domaines (organization, processus métiers, application, application, information, architecture techniques), visant à réduire les ambiguités entre ces domaines pour une collaboration efficace Au dessus d’UML, avec une claire séparation de la représentation graphique et des modèles Candidat pour un modèle conceptuel plus riche que celui proposé par Longépé Autres candidats: Component and Model based development methodology (COMET): Process Oriented Enterprise Modeling (POEM): TOGAF avec la démarche ADM Les constructions sont similaires mais pas toujours alignées Le processus d’urbanisation n’est pas nécessairement considéré Des liens avec la modélisation sont établis, parfois seulement visuelle, parfois à partir de modèles, pas à partir d’ontologies Pas encore de vrai standard, largement utilisé par une communauté existante

44 Open Group La modélisation d’entreprise avec Archimate

45 ArchiMate principles and concepts
A language , not a methodology One single model with different views on the model Clear separation between views on the model and the model Predefined viewpoints (23) associated to stakeholders and concerns Few modeling concepts (about 50) compared to UML (about 250) or BPMN (about 100) 3 aspects : Information, Behavior, Structure 3 types of object: Active, Behavioral, Passive 3 layers in V1 Business& Information, Application & Data, Technology(Infrastructure) Augmented in V2 : Motivation, Implementation & Migration Can be used as well for drawing than visual modeling Visio Stencils as well as UML Profile but also modeling tools with ArchiMate as a DSL

46 Illustration of ArchiMate Architectural Framework
3 aspects Information Behavior Structure 3 layers Business Application Technology Augmented in v2 Motivation Implementation & Migration based on Henk Jonkers 2004

47 The Archimate layered views
The Business layer about business processes, services, functions and events of business units. Other concepts are business objects, actors, roles, interactions, collaborations, locations, representations, values, meanings, contracts and products. This layer "offers products and services to external customers, which are realized in the organization by business processes performed by business actors and roles". The Application layer about software applications that "support the components in the business with application services". Other concepts are application collaborations, services, interfaces, functions and interactions, plus data objects. The Technology layer deals "with the hardware and communication/application infrastructures to support the Application Layer. This layer offers infrastructural services needed to run applications, realized by computer and communication hardware and system software". Concepts are artifacts, communication paths, networks, infrastructure interface, infrastructure functions, nodes, system software and devices. The motivation layer was added in version 2, in order to capture motivation for an architecture. Concepts are stakeholders, drivers, assessments, goals, principles, requirements and constraints The Implementation & migration layer was added in version 2, in order to capture how to go from an as is architecture to a to be architecture Concepts are work packages, deliverables, plateaux and gaps Each layer "aims to provide a natural way to look at service-oriented models. Each layer is self contained despite being a component of the integrated model, and caters to one or more architecture domains".

48 The Archimate views, viewpoints and concerns
23 viewpoints are defined in the specifications (similar to UoF/Templates) Actor cooperation, application behavior, Application cooperation, Application structure, application usage, business function, business process, Business process cooperation, Business Product, Goal contribution, Goal realization, Implementation & Deployment, Implementation & migration, Information structure, Infrastructure, Infrastructure usage, Layered, Migration, Motivation, Organization, Principles, Project, Requirement realization, Service realization, Stakeholders and Total Associated to some stakeholders and concerns Can be use in order to create Views (diagrams) on the overall global model, with filtering/categorization capabilities based on viewpoints (The way to see the models)

49 The Archimate views, viewpoints and concerns

50 Interest within the scope of strategic standardization
Could be a way to perform capture of process frameworks (ISO 15288, ILS processes, PLM processes, etc.) Perform capture of solutions related to these processes Capture the standards blips and capture their scope and motivation Capture vision and principles defined by strategic standardization for using of standards to support PLM and interoperability Interrelate all the standards

51 ArchiMate Basic with Archi
Prerequisite: installation of Archi 2.4 at It can be as well for Windows WP, Vista or Windows 8, 32 bit or 64 bit (distribution also available for Linux or Mac OS X 32 or 64 bit) It can be an executable installer, or a Windows zip Go on the directory where the program is installed or unziped The executable will be Archi32.exe or Archi64.exe The extension of Archi model is “.archimate” Note: let’s install the software before to attend to the training in order to save time.

52 Archimate Basic with Archi 3 type of objects – active, behavioral, passive
General Active: object that acts Behavior: the verb Passive: objects that can’t act, but are acted upon by that behavior Additional – what is used to support the act – “with” or “is used for” Business Who? – active – the business role with as visible part the interface Behavior – verb – could be (business) function/process, with as visible part the (business) service Upon what: passive – the business object With what – the (application) component (active), performing operation (function or process) on passive data object Application Active: (application) component, with as visible part the interfac Behavior – verb – the (application) function/process with as visible part the (application) service Upon what – passive – the data object Technical Who- active- the software system, deployed on devices with appropriated deployed artifacts Behavior – verb- (infrastructure) function, with as visible part the (application) interface Upon what – passive object - artifact

53 3 layers – links between business, application and technical layers
The palette groups visual object per layer The default color is different per layer In the model, 3 different folders per layer, where the model element are automatically put when created on the views Relationships are put on “Relations” folder of the model frame Views are on the “Views” folder

54 One single model with different views
Let’s create a second view Drag and drop one object on this view Change the name of the object Go and see on the second view: the name is updated on all views!

55 Illustration of usage ISO 15288 process framework

56 Usage of ArchiMate and Archi for analyzing consistent usage of a set of standards together
Capturing ISA95

57 What is ISA 95 (ISO 62624) Enterprise-Control System Integration
Separate business processes from manufacturing processes Allow changes in production processes without requiring unnecessary changes scheduling and logistic processes Provide a clear demarcation of responsibilities and functions Provide a clear description of exchange information Improved integration of manufacturing through communication by defining A common terminology A consistent set of models Emphasize good practices for integration of control systems with other enterprise systems Reduce cost and difficulty of integration of business logistics systems with manufacturing systems Expected benefits Better planning and scheduling through better information Support for “capable to promise” strategy Support for agile manufacturing and flow manufacturing strategies Reduce errors in optimized supply chain operations

58 ISA 95 Derived from MESA Model

59 Adopted approach for ISA 95
Definition of the functions in the domains What is in business/planning and what is in manufacturing operations? The functions of interest are detailed The information flows of interest between the function of interest are defined Information model is defined, with: 3+ 1 resource models (Personal, Material, Equipment, Segment) 4 interactive models (capability information, product definition, production schedule, production performance) Can be used as basis for formalized information exchange protocol The information are categorized, and relationships with activity model is made

60 Similarity with ISO 10303 Application protocol domains
Application Activity Model, based on IDEF0, for contextualization of information flow Conformance classes and Unit of Functionalities Application Reference Model and Application Implementation Model

61 ISA 95 proposes a set of functions organized according Purdue Model hierarchy
From OAGIS, ISA-95 and Related Manufacturing Integration Standards - A Survey

62 The structure of ISA 95 content and mapping with ArchiMate
Multi levels architecture of reference (MESA - Purdue) Identification of functions Flow of information between functions Set of object models Logical model, not implementation model (implementation is ensure by B2MML) ISA 95 ArchiMate Business and Motivation layers Function Business Function, applicative function Object model Object model, data Flow of data between function Flows coupled with data Domain Business Function, macro

63 Usage of ArchiMate and Archi for analyzing consistent usage of a set of standards together
Capturing ISO 15288

64 What is ISO 15288 A process framework, produced jointly by INCOSE and ISO Related to System engineering, and widely used in Aerospace and Defense industry Considering The system of interest: e.g. the Aircraft The enabling systems used for designing, producing, supporting and recycling the system of interest: e.g. design capabilities or production capabilities of the enterprises involved in an industrial program Each of these systems has its own lifecycle. The lifecycles are to be synchronized by Program Management The lifecycle models are to be manage by the enterprise to support programs The standard is not focusing information system using ICT => only business processes, business objects (the systems) and business actors/roles

65 The structure of ISO15288 content and mapping with ArchiMate
Document and text based (no formal model) Structure is provided for: Process Purpose : goal of performing the process Outcomes: observable results Activities Tasks But also non structured set of actors, roles, documents, business objects, systems (of interest , supporting, etc.) ISO 15288 ArchiMate Business and Motivation layers Purpose Goal Process Outcome Activity Task From text Actors, Roles, Business Objects, Products From structure and text Composition of processes, relation between objects

66 E.g. Plants All systems have a life cycle
Example 1: Modeling the main ISO15288 systems , roles, and relationships E.g. an Aircraft E.g. Marketing departments E.g. Design offices All systems have a life cycle Design – Produce – Operate - Retire E.g. Plants The roles are ensure by different companies. E.g. Aircraft Integrator will design, develop, produce partially and Airline company will use, while the support or the retirement can be made by other companies

67 Example 2: Modeling ISO 15288 Processes (without activities and tasks)
Life Cycle Models Management - STRATEGIC Industrial program concerned by all the systems – the product and systems supporting

68 Example 6: ISO15288 detailed process modeling – Supply process (Extended Enterprise)
E.g. Airbus E.g. 10 Aircrafts with some characteristics E.g. KLM E.g. 10 Aircrafts

69 Example 7: : ISO15288 detailed process modeling – Acquisition process (Extended Enterprise)
E.g. Airbus E.g. Motorists E.g. Engine for A380

70 Lessons learnt ISO based only on the Business Layer – ICT and applications agnostic (so no data interchange) But interoperability to be considered at this business layer Exchange of Business objects between processes Business objects (contracts, exchange between suppliers and acquirers all along the supply chain Interoperability on Business Layer ArchiMate allows to capture a visual way the standard with a set of views Archi allows to model it, and not to draw it Easier to manage and to experiment Complexity: to be managed without providing simplistic views and drawing only

71 Lessons learnt ISA 95 isn’t an implementation model => ICT layer agnostic Like ISO STEP and unlike ISO15288, strong focus on functional aspect, and on information flows between functions. The active object the function will be attributed will defined the information flows. Distribution can be very various according the functional coverage supported by a software solution and the functional coverage attributed to an application realized by this software solution. The business object flow between business process and activities will remain the same whatever the distribution of function will be The business boundaries and technical boundaries are not aligned due to virtualization which hide how functions are distributed between physical and actual systems

72 From Business Layer to application and data layer
Decoupling Business, logic and realization by ICT layer

73 From Business Layer to application and service layer Illustration of principle of PLM Services V2 for architect Principles of the PLM services, dispatched at the different layers, being business, application or technology

74 Other modeling languages

75 COMET

76 Le lien avec le cycle de vie des systèmes applicatifs et des systèmes d’information
L’établissement de la communication peut se faire: À l’exécution, à postériori Etre anticipé lors de la conception Etre anticipé lors de la spécification des besoins De plus, les besoins de communication obligent à prendre en compte l’existant et éventuellement à réaliser du Roundtrip engineering (représentation des applications en production dans les environnements de conception, avec rétro-engineering du code vers les langages de modélisation. Les outils de transformation et les mappings de langage et de modèles (spécification, modélisation, exécution) deviennent primordiaux, avec des environnements de meta-modélisation. Illustration avec Papyrus basé sur le plug-in UML2 d’Eclipse, résultat du projet OpenDevFactory dans le programme Usine Logicielle…

77 L’importance des standards
Définition données dans Wikipédia pour la différence entre standard et norme ( « Standard signifie aussi « norme » en anglais. Les anglophones ne possédant qu'un seul mot pour désigner deux concepts différents, les traductions des textes anglais sont souvent sources de confusion. En langue française, il n'y a pas équivalence entre un standard et une norme. Une norme résulte d'un processus de normalisation effectué dans le cadre d'un organisme public. Un standard peut être défini par n'importe quel organisme privé (produit standard), puis devenir une norme.[réf. nécessaire] Le mot standard est fréquemment utilisé dans le sens de norme en informatique (anglicisme). On parle souvent de standard ouvert lorsque le standard répond à certains critères d'accessibilité et de gouvernance. Un produit standard n'implique pas que ses interfaces soient connues. Quand elles le sont entièrement, on peut parler d'interopérabilité. Une façon intéressante de comprendre la différence entre une "norme" et un "standard" serait de dire : pour créer une norme, il suffit d'en décrire les principes, en se préoccupant seulement du fait que ces utilisateurs la respectent, sans se préoccuper du fait que le nombre de ses utilisateurs soit grand. une "norme" devient un "standard" lorsque "tout le monde" l'utilise. »

78 L’importance des standards
Les standards sont important pour l’urbanisation modèles de référence obtenus de manière consensuel et favorisant le dévelopement industriel constitue un référentiel pour l’entreprise et hors enterprise indispensable pour réduire les risques de dépendances par rapport à des fournisseurs indispensable pour obtenir la meilleure interoperabilité possible entre applications métiers L’urbanisation est importante pour les standards un standard utilisé au coup par coup n’a aucun interet, et coute plus cher qu’une solution spécifique la plupart du temps l’application d’un standard se concoit à un niveau stratégique, et le retour sur investissement est important avec le facteur d’échelle, envisageable uniquement avec l’urbanisation et pas avec les projets de développement d’application considérés unitairement

79 La typologie des standards
On distingue donc Normes (de jure standard) Standards de facto (tout le monde l’utilise) Standards de lego (contraintes légales ou contractuelles) Un produit commercial utilisé majoritairement est considéré comme un standard (tout le monde l’utilise) mais n’est en rien une norme Il existe aujourd’hui des produits open source implémentant des normes et largement utilisés. Cette combinaison est extrêmement intéressante pour établir l’interopérabilité. Même si l’usage des solutions libres reste limité dans les entreprises (défiance quand au support, au modèle économique ou au aspect juridique), un impact positif existe sur les fournisseurs de produits commerciaux qui sont obligés de suivre quand à l’implémentation des normes, s’ils ne veulent pas se singulariser en ne suivant pas les standards. En outre, ils peuvent en tirer parti en ayant la possibilité d’intégrer des composants externes à leurs solutions. Il faut bien distinguer les normes métiers et les normes du domaine de l’informatique et de la communication. Exemple: les standards définis dans le projet SEINE de collaboration PLM, avec les standards informatiques d’intégration (ex: BPEL, XPDL, XSLT, etc) et les standards métiers (AP214)

80 Impact des composants d’entreprises comme commodités sur le Web
Composants applicatifs de haut niveau Fonctions horizontales d’entreprise basés sur des normes et de standard du marché Moteur de Workflow Serveur d’application (basé sur les EJB ou le CORBA Component Model): JBoss, Jonas, Websphere, etc. Portail d’entreprise (basé sur WSRP, JSR168, JSR286): liferay, exo-portal, etc. Bus d’entreprise et inter-entreprise (basé sur JBI, la pile de standard du W3C pour les services, etc): Petals, Mule, etc. Pour ceux connaissant Websphere et les EJB, bien prendre en compte qu’il s’agit de solutions d’entreprises Tout comme d’autres composants décrits, ils sont adapté à utiliser dans des stratégies d’entreprise pour le passage à l’échelle, nécessitant de supporter la collaboration de très nombreuses personnes et l’accès à la connaissance et aux ressources de l’entreprise.

81 Les portails d’entreprise les standards et les outils du marché

82 Les portails d’entreprise les principes

83 Expérimentation Le projet SUSIE
Système d’Urbanisation de Système d’Information d’Entreprise Fonctionnellement: une application WEB pour réaliser et partager des cartographies urbanistes Techniquement: évaluation des technologies permettant de créer des applications d’entreprises interopérables et flexibles Serveurs d’applications et standards associés Génération à partir de l’ingénierie par les modèles sur des architectures orientées services Visualisation WEB avancée: treemap en SVG Apport relatif à l’urbanisation Retour pour identification des technologies et des standards appropriés à recommander dans une stratégie urbaniste visant à obtenir des SI flexibles, agile et évolutif à un prix raisonnable dans des délais très courts. Piste de réflexion: en quoi les outils qui vous sont enseignés pour le cursus s’inscrivent ils dans une stratégie urbaniste? Quelles recommandations, meilleurs pratiques et standards fournir sous forme de règles d’urbanismes ou intégrer dans un référentiel, en lien avec l’évolution de la maturité des entreprises (qualité totale, Capabiltiy Maturity Model, etc.). La présentation de la roadmap du projet avec les objectifs et les résultats sont fournis en annexe

84 Extraction SUSIE

85 Conclusion L’approche urbanisme existe depuis longtemps, mais est inégalement appliquée dans les entreprises – et pas toujours comprise Elle vise à répondre à un besoin fort des entreprises Elle peut devenir plus largement utilisée en associant les technologies émergeantes en terme d’ingénierie par les modèles, de cartographie sémantique, etc. Du fait de l’extension vers l’extérieur de l’entreprise et du fait de l’achat systématique de produits logiciels, les standards et les normes deviennent extrêmement importants Il faut penser à tout le cycle de vie des applications, en prenant en particulier en compte les couts d’exploitation et d’évolution Il faut penser également en terme d’approche industrielle, en prenant en compte les approches utilisés pour l’ingénierie système, à base de composants à acheter, assembler et compléter (Application server, enterprise portal, workflow engines, ESB, etc)

86 Bibliographie Ouvrages Sites WEB
« L’EAI par la pratique », Francois Rivard, Thomas Plantain, EYROLLES « Urbanisation et BPM  - le point de vue d’un DSI », Yves Caseau, DUNOD « Processus métiers et SI- Evaluation, modélisation et mise en œuvre », C. Morley, J.Hugues, B. Leblanc, O. Hugues, DUNOD « Le projet d’urbanisation du SI - démarche pratique avec cas concret», C. Longépé, DUNOD Sites WEB CIGREF: Club URBA EA: Lectures complémentaires pour ouvrir d’autres perspectives « TOGAF et l’Urbanisation du SI », Muriel Boizard, Oresys, présentation au club urbanisme « La communication collaborative unifiée », état de la réflexion dans les grandes entreprises , CIGREF Mémoire de thèse « Interoperability of enterprise applications within networked organizations », Nicolas Figay, 2009, Université Lyon 1

87 Recherche Web “Processus urbanisation du SI” sur google
BPMS Conseil, Formation et Veille de Management des processus MET02: “L’urbanisation du SI: concepts et bonnes pratiques” BPA02: “Pratique de l’urbanisation du SI: Produire un cahier des charges fonctionnel” ORSYS Formation Modélisation des processus et urbanisation Consultant BPM Comment articuler l’urbanisation du SI et l’approche Processus? Cursus Centrale Supélec Mastère spécialisé “Architecture des systèmes d’information” Introduction besoin des entreprises au SI Méthodes et langages de modélisation Transverse Option architecture technique Option architecture logicielle (intégration solutions logicielles, tests, intégration et mis en exploitation, développement et intégration, , preuve formelle de logiciels) Option architecte entreprise (frameworks TOGAF, Zachman… ; cartographie des SI; planification stratégique du SI/Gouvernance) Formation CNAM NFE107 – Urbanisation et architecture des Systèmes d’information Trop orienté processus 420 Heures !