[eXia.cesi][A5] Urbanisation Du SI
-
Upload
maximilien-buee -
Category
Documents
-
view
38 -
download
1
Transcript of [eXia.cesi][A5] Urbanisation Du SI
[eXia.Cesi][A5]Urbanisation du SI
25/01/2013 - Youen Chéné
Votre intervenant• Youen Chéné
• Reponsable d’équipe de developement chez Masternaut
• 5 ans de consulting SOA et Urbanisation
• Fondateur de Driveo : www.driveo.fr
• Animateur au Normandy JUG : www.normandyjug.org
• Blog : www.youenchene.fr
• Twitter : @youen_chene
• Email : [email protected]
Agenda
• 14h00-15h00 : Principes d’urbanisation
• 15h00-16h00 : Patron d’intégration
• 16h00-17h00 : Cloud Computing
Principes d’urbanisation
Urbanisation• L'urbanisation du système d'information de l'entreprise est une
discipline informatique consistant à faire évoluer le système d'information d'une entreprise dans son ensemble afin de garantir sa cohérence vis-à-vis des objectifs et du métier de cette entreprise, en prenant en compte ses contraintes externes et internes, tout en tirant parti des opportunités de l'état de l'art informatique.
• L'urbanisme définit des règles ainsi qu'un cadre cohérent, stable et modulaire, auquel les différentes parties prenantes se réfèrent pour toute décision d'investissement relative au management du système d'information.
• En version anglaise : Enterprise Architecture.
Système d’InformationApproche systémique et métaphore de la cité
Le début>> Le village <<
• La première application
La phase d’expansion>> L’exode rurale <<
Des problèmes de croissance organique
>> Les banlieues et les centres villes insalubres <<
L’intégration avec les SI extérieurs>> Routes, autoroutes et sens de conduite <<
La fusion avec d’autres SI>> Les communautés de communes et les agglomérations <<
Urbaniser le SI>> L’heure de Georges Eugène Haussmann <<
L’approche systémiqueLe système
• Un ensemble d'éléments interagissant entre eux selon certains principes ou règles.
• Un sous-système ou module est un système participant à un système de rang supérieur.
RèglesEntrée Sortie
L’approche systémiqueLa systémique
• La systémique permet d'aborder des sujets complexes.
• Complexité et Compliqué :
• Chaque partie du système est simple.
• L’interaction entre les modules rends le système complexe.
Le Système d’Information
• Les applications :
• Les applications graphique.
• Les traitements de fonds.
• Les silos de données (Bases, GED).
• Les données/objets.
• Les flux de données interne.
• Les flux de données avec l’extérieur.
Les enjeux de l’urbanisme
• Définir les règles d’évolution du système d’information : le schéma directeur.
• En garantissant la cohérence et le bon fonctionnement des rôles remplies par le SI.
• En permettant une évolution constante du système d’information.
• En maitrisant la dette technique.
Le schéma directeur
• Définition de la cible à 3 ans ou 5 ans.
• des fonctions et processus recouverts.
• des choix applicatifs.
• des référentiels de données,
• des flux de données.
• Définition des étapes d’évolution du SI.
Dette technique
• Surcoûts lié à la maintenance corrective ou évolutive de parties de logiciels mal conçues et/ou mal documentées.
• Ces surcoûts sont un intérêt que paye l’entreprise suite à des manque de qualité ou à des choix court-termes.
Les acteurs de l’urbanisme
• Les urbanistes.
• Les architectes de données.
• Les architectes d’intégration.
• Les architectes d’application.
Rôle des urbanistes
• Définir le schéma directeur :
• En garantissant le recouvrement des fonctions demandé par les métiers à tout moment.
• En choisissant les applications qui recouvrent ces besoins.
• En déterminant les dates de fin de vie de certaines applications.
• En déterminant les flux de données inter-applicatifs qui recouvrent les processus d’entreprise.
Rôle des architectes de données
• Exécuter la vision des urbanistes sur les données.
• Ecrire la définition des objets d’entreprises.
• Accompagner les équipes de développements.
Rôle des architectes d’intégration
• Exécuter la vision des urbanistes sur les flux de données.
• Définir la conception de ces flux de données.
• Accompagner les équipes de développements.
Rôle des architectes d’application
• Exécuter la vision des urbanistes sur les fonctions à recouvrir par une application.
• Définir la conception d’une application.
• Accompagner les équipes de développements.
Cadre de RéférenceDescription du modèle
Quatre niveaux d’architecture
• La vision métier/stratégique.
• La vision fonctionnelle/logique.
• La vision applicative.
• La vision technique.
La vision métier/stratégique
• Inventaires des besoins métiers de l’entreprise.
• Travaux sur les processus cibles.
• Définition des besoins métiers à recouvrir.
• Exemples :
• Prendre les commandes clients.
• Livrer les commandes.
• Suivre les employées en sein de l’entreprise.
La vision fonctionnelleou logique
• Définition des blocs fonctionnels pour recouvrir les besoins.
• Définition des relations entre blocs pour recouvrir les processus.
• Exemple de blocs :
• Acquérir automatiquement les commandes des clients.
• Générer les fiches de salaires.
La vision applicative• Choisir les composants pour recouvrir la vision logique.
• Il s’agit :
• d’applications à développer,
• de progiciels à paramétrer,
• de référentiels de données,
• d’externalisation
• d’applications ( Cloud Computing de type SaaS - Service As A Software),
• de processus (BPO - Business Process Outsourcing)
• de batchs,
• de flux asynchrones de traitements.
La vision applicative• Exemple :
• SAP.
• Business Object.
• Google App.
• Siebel.
• Batch comptable de fin d’exercice
• Flux de synchronization de commandes.
• Interface de e-provisionning.
• Application mobile pour le SAV.
La vision technique• Il s’agit de définit d’un point de vue stratégique
l’infrastructure nécessaire pour porter la vision applicative.
• Exemple :
• Regroupement de serveurs dans un Data Center.
• Création d’un data center par département.
• Base de données unique ou par pays.
• Détermination de la bande passante entre site.
• Solution d’exploitation et de monitoring unique.
L’application dans les entreprises
Vision métier La plus stratégique, souvent négligé.
Vision fonctionnel La plus importante, celle ou il faut faire le consensus.
Vision applicative La plus connue, celle avec la plus de pression financière.
Vision technique Peu fréquent, sur opportunité de rationalisation
OutilsDéfintions, règles de bonne pratique et logiciels
Définitions• Quartiers/ilots et blocs : sous découpage logique des
fonctions à couvrir.
• Processus : coordination d’une suite de tâches.
• Flux : traitement/synchronization d’évènements au fil de l’eau.
• La donnée de référence : données maître ou master data. Données avec une définition d’entreprise.
• Référentiel : base ou application hébergeant les données de référence ainsi que les processus de gestion de ces données.
• Legacy : application avec une date de fin de vie programmée.
Les outils : Visio
• Le plus utilisé.
• Ce n’est pas un outil de cartographie.
• Permet de faire des schémas esthétiques pour les présentations.
Les outils de cartographie : Mega, ARIS, Solu-IQ
• Des outils complets et complexe.
• Permettent de référencer les artefacts et les relations entre artefacts.
• Chaque éléments est requêtable.
• Pour des études d’impacts.
Les outils de cartographie : Mega, ARIS, Solu-IQ
•Avantage :
• La solution pour faire des études d’impacts.
• Inconvénient :
• Nécessite du temps et de la rigueur.
Les outils de cartographieMega
Bonnes pratiques
• Toujours construire les visions en fonction de la vision d’au dessus.
• Penser couverture de blocs stratégiques, fonctionnels ou applicatifs.
Bonnes pratiques :vision métier
• Prendre le temps de référencer l’ensemble des besoins de l’entreprise.
• Séparer le backoffice du front-office.
Bonnes pratiques :vision fonctionnelle
• Ne pas oublier les travaux de définitions d’entreprise des données/objets.
• Travailler avec du recul par rapport à l’existant (processus, applicatifs).
Bonnes pratiques :vision applicative
• Ne pas oublier les objets, les flux et les batchs.
• Toujours se placer par rapport à une problématique du recouvrement des blocs logique de la vision fonctionnelle.
• Il ne faut pas forcément utiliser tous les fonctions recouvertes par un progiciel.
Bonnes pratiques :vision technique
• Rester macro, il est impossible de lister tous les besoins techniques, cela sera le rôle des architectes technique.
• La cible est de définir la stratégie de mise en place des data-centers et des tuyaux.
DémarchePhases d’élaboration et rôle du « pôle urbanisation »
Le pôle urbanisation
• Des urbanistes séniors (35-60 ans) qui font les choix stratégiques et qui donne les orientations.
• Des urbanistes juniors qui s’occupe des entretiens, des inventaires, de la modélisation.
• Couramment organisés par branche métier : marketing, supply chain, achats, HR.
Des travaux collaboratifs
Vision Interne Externe
Métier Responsable MOA,Responsable de Service
Consultant Sénior Fonctionnel
Fonctionnel Référents fonctionnel, Architecte de données Consultant fonctionnel
Applicative Architecte de données, Architectes d’ Architectes Applicatifs
Commerciaux & Consultant Editeurs,
Consultant Intégration
Technique Architectes technique, Responsable d’exploitation
Commerciaux & Consultant Editeurs,
Consultant spécialisés
Elaboration de la vision métier
• Sponsoring par le top-management.
• Inventaire :
• des besoins stratégiques,
• des processus principaux de l’entreprise,
• Alignement avec la stratégie commerciale,
• Prospective.
Elaboration de la vision métier
• Modélisation des processus et besoins stratégique.
• Revues.
• Validation par le top-management.
Elaboration de la vision fonctionnelle
• Démarre à partir de la vision métier/de la stratégie d’entreprise.
• Entretiens avec les différents services impactés par chaque bloc stratégique.
• Modélisation des fonctions et des processus de manière itérative.
• Ecriture des définition d’entreprise des objets.
Elaboration de la vision applicative
• Pour chaque pan de la vision stratégique recouvert par une vision fonctionnelle, on démarre les travaux la vision applicative.
• Au niveau d’un bloc stratégique :
• Sélection des référentiels et solutions applicatives :
• progiciels (interne ou en mode SaaS),
• applications dédiés,
• outsourcing.
• Modélisation de plusieurs scénarios en prenant en compte les flux et les batchs.
Elaboration de la vision applicative
• Au niveau d’un bloc stratégique :
• [...]
• Revue par les architectes techniques.
• Etudier les coûts macroscopique.
• Revue par le top-management.
• Au niveau d’un ensemble de bloc stratégique :
• Etude des mutualisations possibles.
• Revue par les architectes techniques.
• Etudier les coûts macroscopique.
• Revue par le top-management.
Elaboration de la vision applicative
• Validation finale des solutions applicatives choisie par le top-management et le sponsor.
• Etude et modélisation poussée des objets, des flux, des batchs et des interfaces externes.
• Validation de la cible par les urbanistes.
Elaboration de la vision applicative
• A partir de la cible modéliser les étapes de transition vers cette cible. (Sans oublier les flux).
• Ces modélisation peuvent avoir des variantes par sous-système d’information :
• par pays, par zone, par filiale.
• Ces travaux détermine les dates de fin d’utilisation de certaines applications existantes.
• Ces applications sont dites « Legacy ».
• Le schéma directeur découlant de ces travaux sont :
• revues par les architectes techniques,
• revues les responsables de services,
• validation par le top management et le sponsor.
Elaboration de la vision technique
• Calculs des bandes passantes.
• Regroupement/rationnalisation dans des Data-Centers.
• Le résultat permet d’avoir le plan d’achat de l’infrastucture (SAN, Serveurs, Fibre optique, PRA, etc..).
• L’architecture d’exploitation est aussi à prendre en compte (monitoring, Gestion des incidents).
Après la création du schéma directeur
• Les problématiques techniques et de conception, les changements stratégiques vont faire évoluer le schéma directeur.
• Le pôle urbanisation devra maintenir et mettre à jour ce schéma directeur.
• Avec des revues des Dossier d’Architecture Technique (DAT), les urbanistes suivront l’exécution du schéma directeurs.
Patrons d’intégrationUrbanisation et SOA
Patrons d’intégration
“Traditional” Integration Patterns Advanced / EAI / ESB / Integration Patterns Advanced Bulk DataIntegration Patterns
IntegrationPatterns
Point to pointintegration
Brokeredintegration
Dataintegration
Directcommunication Transaction Routing Process
Orchestration Routing InformationAggregator
File transfer
P2P MOM
SharedDatabase
Remote Procedure Call
Transactional Eventnotification
Request / Reply
Aggregator
Managedprocess Propagation Replication
ETL
Patrons d’intégration
“Traditional” Integration Patterns Advanced / EAI / ESB / Integration Patterns Advanced Bulk DataIntegration Patterns
IntegrationPatterns
Point to pointintegration
Brokeredintegration
Dataintegration
Directcommunication Transaction Routing Process
Orchestration Routing InformationAggregator
File transfer
P2P MOM
SharedDatabase
Remote Procedure Call
Transactional Eventnotification
Request / Reply
Aggregator
Managedprocess Propagation Replication
ETL
SOA oriented patterns
Intégration directeTransfert de Fichier
Common file transfer protocols : FTP, SFTP, CFTP, NFS, etc …
Intégration directeTransfert de Fichier
Pros Cons
Quick & dirty.Replay is easy.Performance (low-level).
Monitoring.Reliability.Not for messaging
Best practice Worst practice
For batch mode (big nightly files to transfer).Glue to integrate a legacy application to an ESB
Messaging.For exchanges which need a sharp monitoring.For object which often evolve
Intégration directeMessagerie Asynchrone (MOM)
Well known application is MQ Series from IBM, JMS in Java’s world, MSQueue in Microsoft world.
Intégration directeMessagerie Asynchrone (MOM)
Pros Cons
Quick & dirty reliable integration Applications are coupled with the MOM technology.
Best practice Worst practice
Reliable when no data transformation is needed.Glue to integrate an application to an ESB
Exchanges with data transformation.Exchanges which need routing or which are driven business rules
Intégration directeBase de données partagée
Well known database : Oracle, SQL Server, Sybase, Mysql…
Intégration directeBase de données partagée
Pros ConsQuick & dirty.Low cost at the beginning
Database as a bottleneck. Cost increase to manage the performance issue.Impact of maintenance on the databases & the schemas.Applications are stick to database
Best practice Worst practice
Glue to integrate a legacy application to an ESB (with table only for the integration part).
Use this pattern to control the integration cost, you will pay more when you’ll migrate
Intégration directeAppel à distance
CORBA, COM, .NET Remoting, Java RMI, SOAP, XML-RPC, etc…
Intégration directeAppel à distance
Pros Cons
To delegate a function to another application.To separate the layer of an application.
Applications are coupled. Maintenance Impact. Migration Scenarios ?Availability management ?
Best practice Worst practice
The technologies deployed provide for the capability.It is a synchronous call.It is anticipated that the call would not be used in other circumstances.Response time is critical.
To build a SOA architecture
Intégration directeAppel à distance
Only few application can provide the transactional pattern: IDMS & CICS, J2EE Application Server (WAS).
http://www.flickr.com/photos/lejoe/4351511701/
Urbaniser un système d’information avec la SOA
SOA : Urbaniser avec un EAI
Intégration par événement
Intégration par événement
1 2
3
3‘
4
5
6
1 The System triggers the notification by delivering a message in its own protocol to the broker.
2 The message is transformed into a pivot format as a canonical object. It is the mapping activity.
3 The canonical object is published inside the broker message service.
3’ For replay and audit the message is stored inside the broker message store.
Intégration par événement
1 2
3
3‘
4
5
6
4 The message is routed. The routing could be based on the message content or a technical header stock to the message.
5 The message is received from the broker message service and translated to the target application format.
6 The message is published to the target application in its own protocol.
Objets Canoniques
Intégration par événement
Pros Cons
Decoupling feature.Easy to add new interface after the first project.
First project is heavy (architecture, methodology, knowledge transfer).Long term ROI.
Best practice Worst practice
Manage application migration scenario.Integrate an Information System step by step.Build a specific team to manage all the integration project.
Share practices for routing.Share & centralize pivot format/canonical object.
« Forget » to use the pivot format/canonical object which provide a functional decoupling between the application.Do not invest in the support part of the tool (monitoring, error&replay management).
SOA : Urbaniser avec un ESB
Intégration par événement avec réponse
Intégration par événement avec réponse
Pros ConsDecoupling feature.Easy to add new interface after the first project.Other system function as a centralize service.The Notify/Acknowledge variant for
First project is heavy (architecture, methodology, knowledge transfer).Long term ROI.
Best practice Worst practice
Multiple applications use the same service.Broker can insulate each of the applications from change and the service connections can be reused. .Pattern to build Service Oriented Architecture.
Synchronous (blocking) transaction and response time is critical, Remote Procedure Invocation pattern is better, Brokered Request / Reply pattern is asynchronous and may not meet the service level required by the systems involved. Do not invest in the support part of the tool (SLA monitoring, error management).
Intégration par agrégation
Intégration par agrégation
1
2
3
2 Several source application could be called, the calls are driven by routing rules.
3 All the data are aggregated in one unique message which is published to the requester application.
1 The global pattern is the same as the request reply/pattern.
Intégration par agrégation
Pros Cons
Applications delegate the complexity to the bus.
Time response for large aggregation.
Best practice Worst practiceWhen a composite response must be collected in parallel from many different target applications.
Care should be taken in synchronous (blocking) situations as it could take some time to create an aggregated response.
ESB : Les Acteurs
Business Process Management
Business Process Management Suite
Process Engine
Workflow Screen
Integration Layer
ESB or Direct To Application
Tasks Manager
User
Modélisation des processus
BPM / BPMN : Business Process Modeling / Business Process Medling Notation
Modéliser
Processus managé
1
2
3
2 The communication with the other application is based on brokered integration patterns.
3 A high level process manage the different interaction with the other application. A IHM layer could be add using the BPM Suite tools.
1 A first application trigger the process by publishing a message.
Processus managéPros Cons
Able to manage long process with or without human interaction.Make business and IT work together
Difficult if the business teams are not ready
Best practice Worst practice
Should be used when the integration environment is responsible for orchestrating the business process flow.
Begin to build managed process though the business rules are not clear.
BPM : Les Acteurs
BPM : Les ActeursLes solutions haut de gammes :
IBM WPSSoftware AGTibco iProcess / Tibco AM
BPM
Les purs-players :Pega SystemLombardiIntalio
Les Open-Sources :BonitajBPM
Les solutions en mode Cloud Computing :Run My ProcessCordys
Les solutions documentaires :LotusAlfresco
Intégration de données
Propagation
ESB, EAI
PropagationPros Cons
Loosely coupled.Each application which use the child referential is standalone.A way to balance the synchronization charge.Sharp monitoring is possible.
Like every synchronization process, the (re-)initialization process should be anticipated.
Best practice Worst practice
Synchronize referential information to the various systems that require that information.
Using it whereas the data management policies are not defined.
• This is the pattern which is usually use to synchronize critical referentials/MDM (client, product).
Réplication
Specific to each database technology..
RéplicationPros Cons
Bulk copy.Efficient to insulate a copy of the database.
Each replication process is specific to the database technology.
Best practice Worst practiceMirroring of a transactional system into an instance of the database to provide for reporting without affecting the transactional systems performance. A mobile worker downloading a work list at the beginning of the day, and uploading updates to this work list at the end of the day.
Extract Transform Load
Datastage, Talend, SQLSIS, Pervasive.
Extract Transform Load
2 Map the different data from the different sources to a target format. The mapping parameter are set in the ETL designer UI.
3 The target format is load into the target application in its own protocol.
1 Extract the information from the different sources with their own protocol.
1
2 3
1’
1’’
Extract Transform LoadPros Cons
Best player to handle mass data transformation.
Need an expert for advanced development and tuning.
Best practice Worst practice
Populate BI Data Warehouse from applications.To replace nightly batch which need a lot of data transformation
To do on event intégration.
ESB, EAI et ETL• ETL :
BatchGrosse volumétriePoint à point
Cas d'utilisation : insertion de données vers la BI.
Pour en savoir + : Talend
• ESB/EAI :
Fil de l'eauVolumétrie lisséeDécouplage
Cas d'utilisation : synchronisation de commande entre le e-commerce et un ERP.
Urbaniser avec un système de Master Data Management
Urbaniser comme un eco-système web
• Tous les blocs du système d’information ont une API.
• Les applications tactiques se basent sur l’écosystème existant.
• L’approche de Amazon.
• https://plus.google.com/112678702228711889851/posts/eVeouesvaVX
Urbaniser comme un eco-système web
Rich Interface Application
Business Dedicated API
Web Application Mobile Application
Business Dedicated API
Business Dedicated API
Conclusion Urbanisation
A retenir & Tendances
TOGAF
• TOGAF Framework
• http://www.opengroup.org/togaf/
A retenir• Rappelez vous ces notions lorsque vous concevrez des
applications.
• Il faut toujours penser recouvrement des blocs de la vue précédente.
• Très difficile à mettre en place à la création d’une entreprise.
• A mettre en place au plus tôt lors de la période de croissance de l’entreprise.
Tendances
• Raccourcissement des durée des schémas directeurs.
• La fin des ERPs «Big Elephant ».
• Vers un eco-système basé sur une plateforme d’entreprise.
• L’impact du cloud computing : des métiers qui se passe de la DSI et des schémas directeurs.
Cloud Computing
IAAS / PAAS / SAASSaaS
PaaS
IaaS
CRMHRCollabPortalECM
.Net Java / J2EEBPMS
Server NetworkStorage
Software as a Service
Platform as a Service
Infrastructure as a Service
Application en tant qu’un service
Plateforme de développement/déploiement en tant qu’un service
Infrastructure en tant que service
Délégation de ResponsabilitésSaaS
PaaS
IaaS
Le client utilise l’application
Le client développe l’application
Le client utilise l’infrastructure
Le fournisseur est responsable de l’application
Le fournisseur maintient l’OS et le serveur web
Le fournisseur maintient le réseau, le matériel et le système de virtualisation
Les acteursSaaS
PaaS
IaaS
CLoud privée/ Cloud public
Private Hybrid Public
Système de vitualisation avancé
API de configurationReversibilité
Cloud privée / Cloud publicLes responsabilités
Private Hybrid Public
SLA assuré le client
SLA assuré le fournisseur
SLA = Service Level Agreement = Qualité de service contractualisé (en interne ou avec un fournisseur)
Cloud privée / Cloud publicL’aspect comptable
Private Hybrid Public
CAPEX élevéOPEX moyen
SLA = Service Level Agreement = Qualité de service contractualisé (en interne ou avec un fournisseur)
CAPEX faibleOPEX important
Cloud privée / Cloud publicL’aspect comptable
Private Hybrid Public
PME qui cherche à rationaliser.Grands groupes.Metiers spécifiques.
Startup qui débuteSite à forte scalabilité
Cloud privée / Cloud publicLes acteurs
Private Hybrid Public
Les points à prendre en compte dans le choix
• Maturité
• SLA / Niveau de Service
• Legislation (Patriot Act)
• Reversabilité
• Sécurité
Sécurité
• Peur sur la DSI!
• C’est une illusion.
• Pour une fois on se pose la question.
• Les fournisseurs spécialisés seront meilleurs qu’une DSI classique.
Dernières questions?
Références
• http://fr.wikipedia.org/wiki/Urbanisation_(informatique)
• http://en.wikipedia.org/wiki/Enterprise_architecture
• http://fr.wikipedia.org/wiki/Systéme
• http://fr.wikipedia.org/wiki/Systémique
• http://en.wikipedia.org/wiki/The_Open_Group_Architecture_Framework