groupe isi 2013 urbanisation interventions mars 2013 nicolas figay [email protected]
TRANSCRIPT
Objectifs et plan de l’intervention
Objectifs 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
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
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
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.
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.
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
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 cityApplication house
Communication Infrastructures Enterprise Service BusesAdministration services repositories
Urbanism rules integration constraintsCity planning “schéma directeur”
Le processus d’urbanisation du SI
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
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
Les diverses cartes
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
Exemple de cartes
Méta modèle et concepts Construit à partir de « Le projet d’urbanisation du SI - démarche pratique avec cas concret»,
Méta modèle et concepts
Acteur: selon définition UML, personne qui utilise le système ou agent externeActivité: unité de décomposition fonctionnelle du processusBDD: unité de stockage dans un SGBD, ensemble de tablesBloc: trois niveaux de découpages de l’architecture fonctionnelle et applicative: zone, quartier et
ilots. Décrit par services assurées et principes de basesBloc 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étierDonné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 fluxFlux: échange de données entre blocsIlot: 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
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’entrepriseOpé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énementsProcédure: processus organisé, i.e. avec dimension organisation (qui fait quoi)/processus. Décomposé
en opérationProcessus: 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 MarseilleTable: 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
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
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
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.
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é
Entreprise étendue type 3 (collaborative)Echelle de l’entreprise avec le connecteur externe
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
Entreprise étendue type 3 (collaborative)Vue technique: le réseau physique (hardware)
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) …
Diagramme de composants et de déploiement en UML
Appropriés pour réaliser des cartes?
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.
Un profile UML pour modéliser les cartes comme des diagrammes UML
Un exemple de l’usage du profile
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.
Cartographie sémantique Quelques sites à explorer
Le site de Christophe Tricot sur la cartographie sémantique: http://www.knowledge-mapping.net/
Les technologies de visualisation Le CHISEL group, avec Shrimp, Jambalaya et Creole: http://www.thechiselgroup.com Yed: http://www.yworks.com/en/products_yed_about.html Touchgraph: http://www.touchgraph.com/TGGoogleBrowser.html Freemind: http://freemind.sourceforge.net/wiki/index.php/Main_Page Treebolic: http://treebolic.sourceforge.net/en/index.html
MagicDraw (http://www.magicdraw.com/ ) Visual Paradigm (http://www.visual-
paradigm.com/ ) : 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)
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
Cartographie urbaniste avec Protégé 3.4.4 BetaLe modèle
Cartographie urbaniste avec Protégé 3.4.4 BetaLa 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
Cartographie urbaniste avec Protégé 3.4.4 BetaLa carte
Quelques langages de modélisation standardisés
Réutilisable pour définir son cadre d’urbanisation
Object Management GroupLe marché du composant – UML, OMA, MDA
OMG, W3C, WfmcLe marché du Business Process Modeling et les langages associés
ARCHIMATE AND ARCHI
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 http://www.opengroup/org/subjectareas/enterprise/archimate
• ArchiMate distinguishes itself UML and BPMN by its enterprise architecture modeling scope
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 )
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):
http://www.modelbased.net/comet/ Process Oriented Enterprise Modeling (POEM): http://bpmnpop.sourceforge.net/ 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
Open Group La modélisation d’entreprise avec Archimate
ArchiMate principles and concepts
1. A language , not a methodology2. One single model with different views on the model3. Clear separation between views on the model and the model4. Predefined viewpoints (23) associated to stakeholders and concerns5. Few modeling concepts (about 50) compared to UML (about 250) or BPMN
(about 100)6. 3 aspects : Information, Behavior, Structure7. 3 types of object: Active, Behavioral, Passive8. 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 modeling10. Visio Stencils as well as UML Profile but also modeling tools with ArchiMate
as a DSL
Illustration ofArchiMate Architectural Framework
3 aspects• Information• Behavior• Structure
3 layers• Business• Application• Technology
Augmented in v2• Motivation• Implementation & Migration
based on Henk Jonkers 2004
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".
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)
The Archimate views, viewpoints and concerns
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
ArchiMate Basic with Archi
Prerequisite: installation of Archi 2.4 at http://archi.cetis.ac.uk 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.
Archimate Basic with Archi3 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
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
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!
Illustration of usageISO 15288 process framework
CAPTURING ISA95
Usage of ArchiMate and Archi for analyzing consistent usage of a set of standards together
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 processes2. Provide a clear demarcation of responsibilities and functions3. Provide a clear description of exchange information4. 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
ISA 95 Derived from MESA Model
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 definedThe 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
Similarity with ISO 10303
Application protocol domains
Application Activity Model, based on IDEF0, for contextualization of
information flow
Conformance classes and Unit of
FunctionalitiesApplication Reference Model and Application Implementation Model
ISA 95 proposes a set of functionsorganized according Purdue Model hierarchy
From OAGIS, ISA-95 and Related Manufacturing Integration Standards - A Survey
The structure of ISA 95 contentand 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
CAPTURING ISO 15288
Usage of ArchiMate and Archi for analyzing consistent usage of a set of standards together
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
The structure of ISO15288 contentand 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 Process
Outcome Goal
Activity Process
Task Process
From text Actors, Roles, Business Objects, Products
From structure and text Composition of processes, relation between objects
E.g. an Aircraft
E.g. Plants
E.g. Design offices
E.g. Marketing departments
All systems have a life cycleDesign – 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
Life Cycle Models Management - STRATEGIC
Industrial program concerned by all the systems – the product and systems
supporting
Example 2: Modeling ISO 15288 Processes (without activities and tasks)
E.g. 10 AircraftsE.g. 10 Aircrafts with some characteristics
E.g. Airbus
E.g. KLM
Example 6: ISO15288 detailed process modeling – Supply process (Extended Enterprise)
E.g. Airbus
E.g. MotoristsE.g. Engine for A380
Example 7: : ISO15288 detailed process modeling – Acquisition process (Extended Enterprise)
Lessons learnt
• ISO 15288 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
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
From Business Layer to application and data layer
Decoupling Business, logic and realization by ICT layer
From Business Layer to application and service layerIllustration of principle of PLM Services V2 for architect
Principles of the PLM services, dispatched at the different layers, being business, application or technology
OTHER MODELING LANGUAGES
COMET
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…
L’importance des standards
Définition données dans Wikipédia pour la différence entre standard et norme (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. »
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
La typologie des standards
On distingue doncNormes (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)
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.
Les portails d’entrepriseles standards et les outils du marché
Les portails d’entrepriseles principes
ExpérimentationLe 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
Extraction SUSIE
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)
Bibliographie
Ouvrages « 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: http://cigref.typepad.fr/cigref_publications/urbanisme_et_architecture_/index.html
Club URBA EA: http://www.urba-ea.org/
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
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 !