[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 : youen.chene@gadz.org

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