Tribunes

Florange Telecom

L'approche radicaliste de l'architecture du Web : l'assembleur

Big Dataxe

Le Big Data individuel

La comptine du cloud

Toute les tribunes

La vidéo du moment
Actualité marchés verticaux

SeLoger.com lance son application Google Glass dédiée à la recherche immobilière

par GTC
le 18/12/2014 à 06:59

Les pharmacies en ligne en questions : savoir et comprendre, pour bien consommer,
Par Mike Vandenhooft, co-fondateur de Newpharma

par giry
le 17/12/2014 à 10:55

Vous êtes plutôt montre connectée ou bracelet d'activité ?

par RED-DOLPHIN
le 12/12/2014 à 01:08

Capifrance et OptimHome vont pouvoir offrir les services de Drimki

par Petit
le 12/12/2014 à 10:45

Vous êtes plutôt montre connectée ou bracelet d'activité ?

par Mathilde
le 09/12/2014 à 10:30

Rechercher
Services
Logo_abonn Job Les derniers communiqués de presse Proposer un communiqué de presse
Fils RSS : Top 10 quotidien

Bernard Ourghanlian, direction technique et sécurité de Microsoft
Notre démarche SOA se veut pragmatique et itérative

mardi 27 mai 2008

Dans cet entretien avec Bernard Ourghanlian, CTO de Microsoft France, celui-ci commente les facteurs qui poussent les entreprises à la mise en œuvre d'une démarche SOA, donne le point de vue de sa société sur ce que recouvre ce terme, aborde le lien avec le SaaS et détaille enfin l'offre présente et à venir de Microsoft dans ce domaine. Propos recueillis par Hugo Lunardelli (www.netetcom.fr/blog)

Pour débuter cet entretien consacré à la SOA, je suggère de commencer par en donner une définition.

Bernard Ourghanlian : Vous avez raison. Je vais essayer de définir ce qu'est la SOA en situant son apparition dans le contexte organisationnel qui en est à l'origine.

 

Historiquement parlant, on peut considérer que deux générations d'organisations d'entreprises se sont succédées. La première qui part des débuts de la révolution industrielle jusqu'aux années 70 se caractérisait par la prédominance de l'offre dans une économie de pénurie, en gros la contrainte majeure qui limitait le développement d'une entreprise résidait dans ses capacités de production. Dans ce modèle, l'organisation de l'entreprise était compartimentée et constituée de silos fonctionnels tels que la production, les ventes ou encore le management qui fonctionnaient de manière relativement indépendantes. Ce qui caractérise la deuxième génération d'entreprise, qui a succédé à la première, c'est le passage à une économie d'abondance dans laquelle le marché devient progressivement un marché de renouvellement, la plupart des ménages ayant déjà été équipés dans la période précédente.

 

Dans ce nouveau contexte où l'offre peut facilement excéder la demande, la nécessité de mieux connaître ses clients et son marché de façon à produire l'offre la plus pertinente pour ses clients devient un impératif qui entraîne une refonte de l'organisation de l'entreprise.

 

L'impact de cette transformation sur le système d'information de l'entreprise se traduit par la mise en place d'une organisation matricielle par laquelle on va progressivement ajouter des strates horizontales (CRM, DRH, supply chain,...) aux applications verticales existantes telles que la production, la finance, les ventes, .... Même si certains de ces services - l'exemple de la CRM revient le plus souvent - tendent à être sous traités, il n'en reste pas moins que la résultante de ces évolutions débouche sur un  SI peu agile et difficile à faire évoluer car rigidifié au sein d'une matrice organisationnelle et fonctionnelle.

 

Dans un nouveau contexte économique marqué par la mondialisation, le salut pour nos « vieilles économies » de pays occidentaux développés ne viendra pas des uniques gains de productivité. Seule l'économie de la connaissance est susceptible de permettre à nos entreprises de concurrencer les économies émergentes en développant des produits innovants qui ne seront pas immédiatement clonés. C'est une économie de différenciation permanente à travers l'innovation.

 

L'organisation matricielle n'est pas adaptée à l'atteinte de cet objectif. Il s'agit de dépasser ce modèle pour aboutir à une organisation cellulaire dans laquelle les composants du SI sont lâchement couplés. C'est ce qui permettra de déboucher sur ce que l'on pourrait appeler « l'entreprise en réseau », dont les unités fonctionnelles sont relativement indépendantes et qui suppose un couplage beaucoup moins rigide entre ses modules constitutifs. Ce sont les besoins liés à ce nouveau type d'organisation qui sont à l'origine de l'architecture SOA qui vise à adapter le SI en lui donnant l'agilité requise. C'est donc ce nouveau modèle d'organisation qui donne à la SOA sa légitimité.

 

Pour répondre à votre question donc, la SOA, c'est « une démarche de conception qui s'appuie sur les investissements existants pour créer de nouvelles applications flexibles et mieux alignées avec les besoins métiers. » D'une manière générale, la SOA doit être vue comme un moyen, pas comme une fin.

 

L'organisation des entreprises aujourd'hui est très éloignée de cette vision. Celles-ci reposent très largement sur des modèles hiérarchiques et sur une vision taylorienne de l'organisation du travail.

 

Concernant le SOA, s'agit-il aujourd'hui d'une réalité ou de hype ?

BO : S'agissant de SOA, beaucoup d'erreurs sont commises dans l'approche. On trouve ainsi fréquemment une vision purement technologique ou au contraire purement service de la SOA. A mon sens, la SOA est une philosophie de conception indépendante de tout produit, technologie ou tendance de l'industrie : c'est une approche, un ensemble de moyens mis au service d'une orientation services du SI.

 

Une autre idée reçue fréquemment rencontrée consiste à croire que SOA ne concerne que les services Web, alors que toute application existante a vocation à participer dans une approche SOA. A noter que ce que l'on appelle SOA aujourd'hui existe depuis de nombreuses années au sein de technologies telles que l'EDI ou CORBA qui étaient des exemples d'architectures orientées service.  

 

On peut également rattacher à ce mouvement les offres EAI (Enterprise Application Integration) de la fin des années 90 qui avaient un objectif similaire de connecter les briques de base du SI. Ces offres, comme celles de Tibco ou encore Webmethods,  à l'origine basées sur des spécifications propriétaires, ont été remises en cause par l'arrivée de SOAP au début de cette décennie. On a vu par la suite ces vendeurs intégrer SOAP dans leur offre en remplaçant leur bus par un ESB (Enterprise System Bus) reposant sur des standards de services Web (WS-*, BPEL).

 

Certains acteurs disent qu'ils ont une offre SOA, mais à mon sens chaque approche doit être différente. Si j'osais une comparaison, je dirai que les offres de SOA peuvent se comparer à des flocons de neige et à leur trompeuse apparente similitude. Autrement dit, il est difficile de parler d'une « architecture SOA de référence ».

 

Sur le marché, en matière de SOA, on observe essentiellement deux approches : une vision « top down » qui consiste à vouloir ré-architecturer le SI, ce qui nécessite beaucoup de méthode, bien souvent lourde et coûteuse à mettre en œuvre et qui aboutit souvent, lorsque les projets sont finalisés, au fait que les attentes des utilisateurs sont maintenant différentes ; et une démarche bottom-up qui consiste à partir de l'existant et à vouloir intégrer l'ensemble des composants, ce qui risque de conduire à un « paquet de nouilles » sans réussir à mettre en place un véritable alignement de l'informatique avec les métiers de l'entreprise.

 

Notre démarche, dite « middle-out », se veut pragmatique et itérative. Il ne s'agit pas de révolutionner le SI mais de raisonner domaine fonctionnel par domaine fonctionnel. Il faut définir précisément l'objectif métier puis travailler de façon itérative pour atteindre cet objectif en tirant des bénéfices à chaque itération. Pour chacun de ceux-ci, considérons la satisfaction des besoins et faisons en sorte d'exposer chaque fonction sous forme de service. Une fois ce travail effectué, il sera possible d'envisager une recomposition. Ces services composites seront ensuite consommés par d'autres applications ou directement par les utilisateurs. Procédons de la sorte domaine fonctionnel par domaine fonctionnel et petit à petit développons une nouvelle architecture.

 

D'abord, « Exposer » ; cela veut dire exposer de manière native ce que l'on maîtrise ou bien, au travers de connecteurs, ce que l'on ne maitrise pas ou plus (ERP, mainframe). Ceci est assez proche des démarches d'intégration, avec le besoin d'exposer des services ; ici, peu importe les technologies : Services Web, Messages WebSphere ou MSMQ, flux XML sur mesure, ... Ensuite « Composer », c'est-à-dire assembler ces services élémentaires. Cet assemblage se fera à un niveau local au sein d'une application ou bien au sein d'une plate-forme spécialisée dans l'orchestration, par exemple avec BizTalk Server pour ce qui concerne Microsoft. Enfin, « Consommer » ; ici, les expériences utilisateur potentielles sont multiples, il est hors de question de privilégier un canal plutôt qu'un autre, puisque un investissement SOA est essentiellement rentabilisé par son potentiel de réutilisation et de flexibilité : c'est donc l'utilisateur et le métier concerné qui fixent les besoins.

 

Cette approche ne va-t-elle pas à l'encontre de la structuration du SI qui fait suite à la mise en place d'un ERP ?

BO : Un ERP qui a pour conséquence une rigidification des services transverses de l'entreprise risque de conduire à une catastrophe. Le processus long et coûteux qui consiste à déployer un ERP comprend notamment la formulation explicite des processus de l'entreprise. Ces processus bien souvent « appartenaient » à certains collaborateurs et leur formalisation a le mérite de les rendre pérennes. En ce sens, la mise en œuvre d'un ERP est utile. A contrario, si ces processus deviennent trop rigides, il y a problème, le niveau d'agilité attendu risque de ne pas être atteint. C'est ce que je disais tout à l'heure à propos de la deuxième génération d'entreprises.

 

Ce sont souvent les grandes entreprises qui ont le plus besoin d'une approche SOA qui réponde au manque de souplesse des ERP (ceci ne veut pas dire qu'une approche SOA ne concerne que les grandes entreprises, même si ce souvent elles qui en ont le plus besoin). Prenons l'exemple d'une entreprise qui décide d'externaliser une ligne de production. Si cette évolution n'avait pas été prévue à l'avance, cette décision risque d'être très lourde à mettre en place du point de vue du SI.

 

Où en sont les entreprises de leur réflexion en matière de SOA ?

BO : La plupart des entreprises ont amorcé une réflexion dans ce domaine mais nous n'en sommes qu'aux balbutiements. SI l'on en croit une enquête que nous avions menée auprès de grands clients français l'année dernière, seulement 1/3 des entreprises avait lancé une réelle démarche en ce sens. Qui plus est, l'essentiel des budgets IT étant absorbé par la maintenance de l'existant, il reste généralement peu de moyens pour mettre en place de nouveaux projets.

 

Réfléchir à une démarche SOA n'implique t'il pas de prendre simultanément en compte l'approche SaaS (Software as a Service) ?

BO : Une démarche SaaS consiste souvent à externaliser certains services, certaines fonctions de l'IT. En fait, ces deux approches SOA et SaaS s'exercent dans une sorte de continuum.

 

Aujourd'hui, une réflexion SOA « classique » implique que tout ou partie des services concernés résident à l'intérieur du pare feu, ce qui suppose que les processus métiers correspondant s'y prêtent.

 

Supposons l'exemple d'une entreprise dont la valeur ajoutée réside essentiellement dans la conception, la capacité de créer des produits innovants. Une fois le produit conçu, cette entreprise se tournera vers un sous-traitant pour la production ce qui implique que l'ERP de production se trouve chez celui-ci. Il faudra alors intégrer les données de production de ce partenaire avec le marketing et les ventes de l'entreprise conceptrice.

 

Pour qu'une telle intégration se fasse sans difficultés, il est nécessaire de rendre l'ERP « débrayable » du SI. Le choix de sous-traiter la production doit être une décision business et non pas une contrainte de l'IT.

 

Les deux approches SOA et SaaS sont l'expression du fait que le même fonctionnel peut être soit chez moi, soit à l'extérieur. Une approche SaaS suppose que le SI s'y prête et donc, dans une large mesure, qu'une restructuration de type SOA soit intervenue au préalable.

 

Prenons l'exemple d'une solution CRM outsourcée. Dans la plupart des cas, la messagerie de l'entreprise reste en interne ce qui se traduit souvent par une mauvaise intégration des contacts clients entre les deux systèmes. Ceci aura pour conséquence l'obligation de dupliquer les contacts entre les deux applications, ce qui risque de se traduire par une lourdeur inutile, des incohérences entre les deux bases de référence et des réticences des utilisateurs à l'adoption de cette solution. L'intégration entre fonctions IT hébergées en interne et externe doit être pensée au départ.

 

Ceci étant posé, comment peut-on définir l'offre SOA de Microsoft ?

BO : En fait, comme je l'ai dit plus haut, une SOA n'est pas une technologie. Cependant Microsoft propose un certain nombre de briques de base technologiques permettant de mettre en place une approche SOA ; ceci permet de construire une solution autour de cette approche en utilisant un certain nombre de briques disponibles et notamment .NET, BizTalk Server, Visual Studio, etc.

 

Notre approche consiste à proposer cinq piliers fondamentaux : orientation service, expérience utilisateur, workflow, fédération d'identité, fédération des données qui reposent sur un management et une gouvernance intégrée, tout en étant mis en œuvre à travers des outils de développement et de modélisation intégrés.

 

Ainsi, en termes d'orientation service, Windows Communication Foundation (WCF), BizTalk Server et sa palette de connecteurs, Host Integration Server, MSMQ constitueront les briques de base ; pour ce qui est de l'expérience utilisateur, OBA (Office Business Application), ASP.NET, WinForms, WPF (Windows Presentation Framework), Silverlight, les Smart Clients, le Compact Framework, Live Meeting, SharePoint, Groove,... constitueront les briques de base. Idem pour ce qui est de WWF (Windows Workflow Foundation),  BizTalk Server, Office System, les applications métier pour le workflow et le BPM. Etc., Etc. Jusqu'à la fédération des données et à l'approche MDM (Master Data Management) que propose désormais Microsoft depuis son acquisition de Stratature.

 

Bien sûr, Microsoft peut également, à travers sa division services et ses partenaires, accompagner ses clients dans la mise en œuvre d'une approche SOA ; par exemple, en termes de stratégie métier, Microsoft Services propose une approche appelée Microsoft Services Business Architecture (MSBA)  qui consiste en une méthodologie d'identification et de catégorisation des fonctions métiers (capacités métiers et non processus) qui sont assurées au sein de l'organisation.

 

Pour revenir à l'exemple de BizTalk Server, ce dernier dispose de nombreux connecteurs qui vont au-delà d'un ESB (Enterprise Service Bus) puisque ces connecteurs permettent de connecter des systèmes à la fois à l'intérieur de l'organisation mais aussi entre les organisations. On peut donc considérer que ce concept d'ESB soit en voie d'être dépassé et remplacé par la notion d'Internet Service Bus (ISB) qui se charge de la coordination des services et des processus entre différents intervenants internes et externes et pas seulement de la coordination interne à l'entreprise. Dans un tel contexte, tout ou partie de l'application peut s'exécuter « dans le nuage » (« cloud computing ») et potentiellement, l'utilisateur final développera sa propre application pour accéder aux applications « dans le nuage » (il consomme des services).

 

En fait, si l'on considère qu'existe un continuum complet entre SOA, SaaS, ou plutôt comme nous le préférons, « Software + Services », il faut arriver à être capable de considérer que son Intranet est désormais constitué par l'Internet.

 

Pouvez nous décrire le futur de votre offre dont le nom de code est Olso ?

BO : « Oslo » est le nom de code d'un ensemble d'investissements technologiques dont le but est de considérablement simplifier la conception, la construction, la gestion et le passage à l'échelle d'applications orientées service qui peuvent couvrir à la fois l'entreprise et l'Internet. La première version d'Oslo sera délivrée au travers des prochaines versions des produits constitutifs de la plateforme applicative de Microsoft : Visual Studio « 10 », System Center « 5 », BizTalk Server « 6 », BizTalk Services « 1 » et .NET Framework « 4 ».

 

Avec Oslo nous avons deux objectifs :

Concernant la modélisation, nous souhaitons faire des modèles un des objets essentiels du SI. Aujourd'hui, on commence d'utiliser les modèles au sein de l'architecture des SI (approche MDA - Model Driven Architecture) mais ces modèles vivent en silo. Chaque silo a son propre ensemble d'outils, ses propres langages de modélisation (souvent centrés sur UML cependant), sa propre façon de stocker et de partager les modèles, sa propre façon d'utiliser ces modèles, etc. L'existence de ces silos pose un certain nombre de problèmes. Tout d'abord, les silos créent des barrières de communication entre les différents rôles (architectes, concepteur, développeur, testeur, utilisateur, fonctionnel métier,...) pendant tout le cycle de vie de l'application. Par ailleurs, l'existence de plusieurs outils et de plusieurs façons de décrire les modèles crée une complexité inutile. Enfin, avoir des modèles qui vivent leur vie de manière isolée signifie qu'il n'y a pas moyen d'avoir une vision unique de l'application, de bout en bout.

 

Tant que ces silos existeront, la modélisation restera à la périphérie du développement d'applications. Nous construisons un langage de modélisation à usage général (fondé sur la notion de métalangage et de DSL - Domain Specific Language), des outils et un référentiel pour créer un pont entre tous les modèles au sein d'une application afin de faire en sorte que la modélisation joue un rôle central dans le développement des applications. En effet, au sein d'Oslo, les modèles ne feront pas ce qu'ils font aujourd'hui, à savoir un moyen de décrire l'application ; ils seront l'application elle-même.

 

Un modèle devient donc un programme à part entière et est donc exécutable. Ceci représente une rupture fondamentale vis-à-vis  des approches MDA et UML et des approches classiques. A mon sens et c'est un avis personnel, même si nous continuons de le supporter, UML est condamné à terme, car le « U », dans sa vocation universelle, n'a pas de sens. La modélisation au contraire doit s'adapter au contexte, au métier et à l'utilisateur.

 

Concernant les langages utilisés pour la définition de ces modèles, nous travaillons sur la notion de DSL, de langage spécifique au domaine (métier) et sur la façon d'instancier l'application au sein d'un modèle graphique qui sera couplé avec la future version de BizTalk afin de pouvoir modéliser également les processus, ainsi que sur un nouveau langage dont le nom de code est « D » et qui est un langage permettant de développer le contenu d'un référentiel d'entreprise avec la capacité de gérer le cycle de vie des modèles.

 

Il n'y pas à ce jour de stratégie commerciale bien définie autour d'Oslo ; comme je l'ai indiqué, on trouvera des constituants de cette vision au sein de différents produits (Visual Studio, System Center, BizTalk...).

 

La stratégie SOA est coordonnée par la Connected System Division (CSD) qui comprend un millier de personnes et qui est en charge de BizTalk Server, WCF, WWF, la mise en œuvre des Web Services,.... A sa tête se trouve Robert Whabe, à l'origine notamment de la stratégie services Web au sein de Microsoft.

 

Nous communiquerons plus en détail sur Oslo et son calendrier à l'occasion de la PDC (Professional Developper Conference qui se tiendra fin Octobre à Los Angeles (hl)).

 

 

********************************************************************************
Hugo Lunardelli exerce une activité d'analyste et de consultant autour de l'offre et du licencing de Microsoft. Il anime « A propos de Microsoft et d'autres sujets », un blog consacré au décryptage de la stratégie de l'éditeur (www.netetcom.fr/blog)

Les 10 derniers articles mis en ligne