La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Groupe ISI 2013 Urbanisation Interventions Mars 2013 Nicolas FIGAY

Présentations similaires


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

1 Groupe ISI 2013 Urbanisation Interventions Mars 2013 Nicolas FIGAY

2 Objectifs et plan de lintervention Objectifs Pour des ingénieurs spécialisés en système d'information d'entreprise Comprendre ce quest lurbanisation du système dinformation dentreprise Comprendre les apports et les limitations des approches actuelles Comprendre le potentiel dy associer la cartographie sémantique et lingénierie des modèles Plan Problèmes et besoins des entreprises Constat non alignement DSI et entreprise Un nouvel outil: lurbanisation du SI Les objectifs La métaphore de la cité Réalisation de cartographies Les principes Le processus durbanisation 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 Limportance des standards Expérimentation: projet SUSIE Conclusion Bibliographie

3 Problèmes et besoin de lentreprise Utilisation de plus en plus systématiques des ordinateurs pour tout type dactivité et pour la communication SI au cœur des activités Importance stratégique dun 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 linformatique et des techniques Difficultés: identifier les changements nécessaires à la mise en œuvre de la stratégie dentreprise sauvegarde de la cohérence et amélioration de lefficacité 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 soccupant du Système dInformation et les besoins stratégiques de lentreprise 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 linformation 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 dinformation et maturité des dirigeants dentreprise

5 Un nouvel outil: lurbanisation du SI Concept apparu progressivement lors des dix dernières années Lié à limpossibilité de remplacer en une seule fois un SI par un autre de texture plus moderne Praticable à partir de lapparition de la notion dobjet 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 lentreprise 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, larchitecture applicative et technique sur les objectifs de lentreprise Fournir les instruments clés et les guides de la représentation et de la cartographie du système dinformation, 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 douvrage, etc.

7 La métaphore de la cité Métaphore de la cité et le vocabulaire associé, les règles et les principes de lurbanisme 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 durbanisme des sols (POS) Document durbanisme, en général à léchelle dune commune, fixant les règles générales dutilisation du sol qui simposent à nous Pour une entreprise ou une organisation Défini services et responsabilités attachés à chaque sous ensemble, mais aussi lorganisation 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 dentreprise, 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 durbanisation associées Les règles durbanisme 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 durbanisation régulièrement mis à jour Défini par un pole durbanisme La cité grandie harmonieusement, avec des infrastructures adaptée Sur ces principes, sont produits: Des cartes Des règles durbanisme Des infrastructures pour linté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 durbanisation 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 à lefficacité, lesthé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 dun SI existant autour dune architecture densemble et de principes permettant dacqué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 dun système existant à un système cible par pallier successifs correspondants à des étapes stables (roadmap) Maitriser des risques par paliers successifs et maitrisables Dobtenir un meilleur bilan financier en global dans le cas dune é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 lopération durbanisation: applications existantes vers applications futures Décomposition en zones, quartiers et ilots (blocs) Réorganisation dun SI avec définition effective et modulaire des blocs Basé sur les approches objet Cohérence forte/couplage logique faible Minimisation de limpact des changements Refonte possible progressive et totale

13 Les diverses cartes

14 Ce que ça apporte Nouvelle manière dadresser 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 durbanisation 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 larchitecture 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 dun 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 quun 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 dun 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 dentreprise Opération: étape dune procédure correspondant à lintervention dun acteur de lorganisation dans le cadre des activités de lentreprise. 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 dactivités ayant pour finalité le traitement dun é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 lorganisation Quartier: regroupement dîlots homogènes quand à la nature de linformation traitée (sous système). Ex: gestion des paiements, gestion des tarifs… SI: système dinformation. Aspect dune organisation qui fournit, utilise et distribue linformation. Il sagit dun aspect dun système humain, contenant éventuellement des systèmes informatiques Site: lieu géographique considéré du point de vue dune ou plusieurs activité. Ex: agence de Marseille Table: table de base de données ou fichier. Type de site: regroupement dacteurs 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 dinformation - DUNOD) Orienté informatique Ne sappuie pas toujours sur des formalismes standardisés en terme de langage textuel et graphique Ne sappuie pas sur des modèles – or il est important pour des systèmes complexes de pouvoir appuyer lactivité sur lusage de lordinateur (« 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 dune 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 dinteropérabilité sont partiellement adressées par lapproche 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 Lurbanisation se limite au SI de lentreprise. Hors la collaboration numérique avec lextérieur de lentreprise 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 quintégrées

21 Système complexe à considérer Ecosystème dentreprises Entreprises Systèmes dinformations 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 lurbanisme, avec les cartes de communautés eBusiness (écosystèmes de lentreprise é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 dinformation, services et processus de collaboration pour lécosystème considéré

23 Entreprise étendue type 3 (collaborative) Echelle de lentreprise 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 doffre 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 sagit de standards horizontaux. Il y a également les standards métiers verticaux (AP214) lié à une sémantique métier pour léchange dinformation, 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 dentreprise constituant des standards: Business Process Modeling Modélisation dentreprise (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 dun 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 dun modèle de type cartographie du SI, avec un certain nombre de diagrammes: objectifs (dérivé dun diagramme de classe), processus (dérivé dun 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 dun langage à part entière à partir du MOF, non pas à partir dUML 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, doù 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 doutils 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 lusage 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, lune visuelle et inductive, lautre 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 ( paradigm.com/ ) : création automatique de diagramme avec arrangement automatique paradigm.com/ Usage possible Fouille graphique et visuelle Dessin et mise en forme automatiques à partir dun 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 dexpertise (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 lon veut mettre en œuvre sur ces environnement Pour les cartes urbanistes: Formalisation des concepts de modélisation dentreprise à utiliser Formalisation des concepts de cartes urbanistes à produire, en sappuyant 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 sappliquer 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é Beta Le modèle

35 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 darc à 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 sappuyer sur des concepts utilisés par divers langages de modélisation dentreprise, si possible standardisés, et en fonction de leur adéquation par rapport à la réalisation dune 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é Beta La carte

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

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 dentreprise avec Archimate Technique de modélisation (langage) permettant de décrire larchitecture des entreprises Ensemble de concepts clairs et liens avec larchitecture pour dautres 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 dUML, 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 durbanisation nest pas nécessairement considéré Des liens avec la modélisation sont établis, parfois seulement visuelle, parfois à partir de modèles, pas à partir dontologies Pas encore de vrai standard, largement utilisé par une communauté existante

44 Open Group La modélisation dentreprise avec Archimate

45 ArchiMate principles and concepts 1.A language, not a methodology 2.One single model with different views on the model 3.Clear separation between views on the model and the model 4.Predefined viewpoints (23) associated to stakeholders and concerns 5.Few modeling concepts (about 50) compared to UML (about 250) or BPMN (about 100) 6.3 aspects : Information, Behavior, Structure 7.3 types of object: Active, Behavioral, Passive 8.3 layers in V1 1. Business& Information, Application & Data, Technology(Infrastructure) 2. Augmented in V2 : Motivation, Implementation & Migration 9. Can be used as well for drawing than visual modeling 10. 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: lets 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 cant 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 Lets 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 process framework

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

57 What is ISA 95 (ISO 62624) Enterprise-Control System Integration 1. Separate business processes from manufacturing processes Allow changes in production processes without requiring unnecessary changes scheduling and logistic processes 2. Provide a clear demarcation of responsibilities and functions 3. Provide a clear description of exchange information 4. Improved integration of manufacturing through communication by defining A common terminology A consistent set of models 5. Emphasize good practices for integration of control systems with other enterprise systems 6. 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 What is in business/planning and what is in manufacturing operations? Definition of the functions in the domains The functions of interest are detailed The information flows of interest between the function of interest are defined The information are categorized, and relationships with activity model is made 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

60 Similarity with ISO 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 95ArchiMate Business and Motivation layers FunctionBusiness Function, applicative function Object modelObject model, data Flow of data between functionFlows coupled with data DomainBusiness Function, macro

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

64 What is ISO 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 15288ArchiMate Business and Motivation layers PurposeGoal Process OutcomeGoal ActivityProcess TaskProcess From textActors, Roles, Business Objects, Products From structure and textComposition of processes, relation between objects

66 E.g. an Aircraft E.g. Plants E.g. Design offices E.g. Marketing departments All systems have a life cycle Design – Produce – Operate - Retire 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 Example 1: Modeling the main ISO15288 systems, roles, and relationships

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

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

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

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 isnt 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 dinformation Létablissement de la communication peut se faire: À lexé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 lexistant 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 dEclipse, résultat du projet OpenDevFactory dans le programme Usine Logicielle…

77 Limportance des standards Définition données dans Wikipédia pour la différence entre standard et norme (http://fr.wikipedia.org/wiki/Standard#Informatique)http://fr.wikipedia.org/wiki/Standard#Informatique « 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 Limportance des standards Les standards sont important pour lurbanisation modèles de référence obtenus de manière consensuel et favorisant le dévelopement industriel constitue un référentiel pour lentreprise 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 Lurbanisation est importante pour les standards un standard utilisé au coup par coup na aucun interet, et coute plus cher quune solution spécifique la plupart du temps lapplication dun standard se concoit à un niveau stratégique, et le retour sur investissement est important avec le facteur déchelle, envisageable uniquement avec lurbanisation et pas avec les projets de développement dapplication considérés unitairement

79 La typologie des standards On distingue donc Normes (de jure standard) Standards de facto (tout le monde lutilise) Standards de lego (contraintes légales ou contractuelles) Un produit commercial utilisé majoritairement est considéré comme un standard (tout le monde lutilise) mais nest en rien une norme Il existe aujourdhui des produits open source implémentant des normes et largement utilisés. Cette combinaison est extrêmement intéressante pour établir linteropérabilité. Même si lusage 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 à limplémentation des normes, sils ne veulent pas se singulariser en ne suivant pas les standards. En outre, ils peuvent en tirer parti en ayant la possibilité dintégrer des composants externes à leurs solutions. Il faut bien distinguer les normes métiers et les normes du domaine de linformatique et de la communication. Exemple: les standards définis dans le projet SEINE de collaboration PLM, avec les standards informatiques dintégration (ex: BPEL, XPDL, XSLT, etc) et les standards métiers (AP214)

80 Impact des composants dentreprises comme commodités sur le Web Composants applicatifs de haut niveau Fonctions horizontales dentreprise basés sur des normes et de standard du marché Moteur de Workflow Serveur dapplication (basé sur les EJB ou le CORBA Component Model): JBoss, Jonas, Websphere, etc. Portail dentreprise (basé sur WSRP, JSR168, JSR286): liferay, exo-portal, etc. Bus dentreprise 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 quil sagit de solutions dentreprises Tout comme dautres composants décrits, ils sont adapté à utiliser dans des stratégies dentreprise pour le passage à léchelle, nécessitant de supporter la collaboration de très nombreuses personnes et laccès à la connaissance et aux ressources de lentreprise.

81 Les portails dentreprise les standards et les outils du marché

82 Les portails dentreprise les principes

83 Expérimentation Le projet SUSIE Système dUrbanisation de Système dInformation dEntreprise Fonctionnellement: une application WEB pour réaliser et partager des cartographies urbanistes Techniquement: évaluation des technologies permettant de créer des applications dentreprises interopérables et flexibles Serveurs dapplications et standards associés Génération à partir de lingénierie par les modèles sur des architectures orientées services Visualisation WEB avancée: treemap en SVG Apport relatif à lurbanisation 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 sinscrivent ils dans une stratégie urbaniste? Quelles recommandations, meilleurs pratiques et standards fournir sous forme de règles durbanismes 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 Lapproche 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 dingénierie par les modèles, de cartographie sémantique, etc. Du fait de lextension vers lextérieur de lentreprise et du fait de lachat 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 dexploitation et dévolution Il faut penser également en terme dapproche industrielle, en prenant en compte les approches utilisés pour lingénierie système, à base de composants à acheter, assembler et compléter (Application server, enterprise portal, workflow engines, ESB, etc)

86 Bibliographie Ouvrages « LEAI par la pratique », Francois Rivard, Thomas Plantain, EYROLLES « Urbanisation et BPM - le point de vue dun 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 durbanisation du SI - démarche pratique avec cas concret», C. Longépé, DUNOD Sites WEB CIGREF: Club URBA EA: Lectures complémentaires pour ouvrir dautres perspectives « TOGAF et lUrbanisation 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: Lurbanisation du SI: concepts et bonnes pratiques BPA02: Pratique de lurbanisation du SI: Produire un cahier des charges fonctionnel ORSYS Formation Modélisation des processus et urbanisation Consultant BPM Comment articuler lurbanisation du SI et lapproche Processus? Cursus Centrale Supélec Mastère spécialisé Architecture des systèmes dinformation 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 dinformation Trop orienté processus 420 Heures !


Télécharger ppt "Groupe ISI 2013 Urbanisation Interventions Mars 2013 Nicolas FIGAY"

Présentations similaires


Annonces Google