Défaut: Architecture business_model Cloud Computing Entreprise-2.0 grammatisation REST système_d'information Web-2.0 Web-Solutions
by Christian
10 comments
Nom de code : Exodus
Exodus est le nom de code que je donne à un processus de grammatisation dans lequel toutes les entreprises sont engagées, qu’elles en aient conscience ou non.
De quelle exode s’agit-il ?
Il s’agit de l’exode des données des systèmes d’information legacy vers le web. C’est la migration des données, non pas de telle application vers telle autre application, mais des applications vers le web.
Le web est la plateforme dit-on. Mieux que çà, le web est le milieu, l’environnement dans lequel des plateformes commencent à se constituer. La tendance majeure, qui correspond à un vrai changement de paradigme, c’est d’avoir les données sur web. Nous allons vers un web of data :
- avec le web 2.0, ce sont les données fournies par les utilisateurs qui ont commencé à migrer sur le web ; une toute nouvelle économie est naît, bousculant la plupart des acteurs économiques traditionnels.
- avec le SaaS, pour les entreprises, ce sont des données de l’entreprise qui sont sur le web : data on the web. Et tout les éditeurs traditionnels de logiciels doivent faire en ce moment des choix cruciaux, quand ce n’est pas déjà fait).
- avec le Web 3.0 et le Semantic Web, c’est le « web of data » qui se constitue, et ce n’est pas seulement des datas sur le web.
La référence biblique à l’Exode est bien évidemment voulue, mais c’est ici une version moderne, technologique, industrielle et économique qui se joue.
Au départ, et pour les systèmes d’information des entreprises, il y a donc les « dix plaies de l’égypte » :
- Des systèmes dont les coûts de maintenance deviennent insupportables.
- L’incapacité à provoquer des échanges et des partages : quand les données ne se mélangent pas, les pratiques ne peuvent pas suivre.
- Des projets pharaoniques qui explosent les budgets et qui, pour une majorité d’entre eux, n’aboutissent jamais, ou accouchent d’une souris.
- Une frustration croissante des utilisateurs internes qui se demandent « pourquoi à la maison avec les service web 2.0 c’est si simple » ?
- Des contraintes à n’en plus finir où, pour être compliant, il faudrait ne jamais se logger au SI de l’entreprise.
- L’accès à l’information qui relève plus de l’archéologie que d’une « user expérience » apportée par les services 2.0.
- Des prestations de codage et de recodage des tuyaux entre des applications qui n’utilisent pas la même sémantique
- Des fuites de l’information avec des salariés qui utilisent des solutions web hors du système d’information, mais avec des données de l’entreprise.
- Des données difficilement accessibles en situation de mobilité.
- Une perte d’intérêt et de motivation généralisée dans l’utilisation du système d’information, alors même que les ressources humaines s’éfforcent de trouver des leviers pour redonner de la motivation aux salariés.
Puis virent les 10 commandements :
- La simplicité toujours tu choisiras
- L’hébergement des données n’est pas ton métier, toujours tu étudieras l’opportunité de faire héberger tes données par un tiers.
- La visibilité budgétaire tu privilégieras, et seul le coût d’usage et par utilisateur tu mesureras.
- Ne réinvente pas ce qui est déjà fait et qui est proposé par un acteur bénéficiant des coûts induits par une économie d’échelle.
- L’information est un capital, et comme tout capital il doit circuler ; jamais dans des bases de données propriétaires tu ne les enfouiras. Tu passeras de la logique applicative à la logique informationnelle.
- Les clés de ton système d’information à un ERP jamais tu ne confieras.
- De la tentation d’architecture de service en SOAP tu te méfieras, car les architecture REST seules sont réalistes et scalables.
- Des solutions grand public tu te rapprocheras le plus.
- Le web est la plateforme des plateformes, et sur elle tu construira ton système d’information.
- Les données sont faites pour être échangées, combinées : vers des mashups de données structurées tu t’engageras, et sur les APIs tu seras vigilant.
Une exode, ce n’est pas un « switch », et ce n’est pas en un claquement de doigt que cela se fait. Il faut scanner l’ensemble de ses processus (IT, fonctionnels, métiers) et, pour chacun d’eux, identifier les opportunités (financières et fonctionnelles) de basculer les données sur le web.
Quand je dis « sur le web », cela veut dire en conformité avec l’architecture du web. Cela peut être un intranet en interne, en hébergement externe ou directement sur le web dans les data center d’une solution SaaS (software as a Service).
Ce qu’il faut c’est :
- S’assurer que les architectures soient full web (et pas seulement webisées pour faire de l’affichage en html)
- Les services doivent être les plus simples et unitaires possibles : comme me le faisait remarquer Louis Naugès, si un service de gestion RH (en mode SaaS par exemple) propose en même temps un service de calendrier, et bien ce n’est pas bon. Vous en avez déjà un, Google Calendar par exemple, donc demandez à ce que cette fonction soit déconnectée du service. Vous devez maîtriser l’unité des services web et ne pas vous la laisser imposer.
- Vous vous souvenez de ces ERP qui valorisaient l’intégration des services, le tout intégré ? Et bien là, c’est le tout désintégré. Chaque service ne doit faire que ce qu’on lui demande, posséder de bonnes APIs, en mode REST (puisqu’on sait que si les APIs sont ce que les DRM sont à la musique, alors les APIs Restfull sont les les « mp3 » des APIs).
Dernier point ; lorsque l’on parle de Software as a Service (SaaS) il faut faire des distinctions car, la nuit, « tous les SaaS sont gris ».
En apparence, tout est SaaS : Google doc, Facebook, Salesforce, etc. Ce n’est que lorsqu’on se place du point de vue du programmeur que des distinctions éclairantes apparaissent. C’est ce qu’a mis en lumière Marc Andreessen en distinguant trois niveaux de « plateformes » web.
Appliqué au SaaS, cela donne :
1. SaaS d’accès en lecture et écriture -> Accès aux données (Google, eBay, Flickr)
Ce niveau 1 du Saas vous offre un SDK pour travailler avec les données via les APIs
2. SaaS de plugin -> Accès aux fonctionnalités (facebook)
Ce niveau 2 du SaaS vous offre un SDK pour réaliser des Plugins qui introduisent des fonctionnalités dans une offre SaaS et vous offre une audience (en contre partie, comme le signalait Aurélien, vous travaillez à la constitution du graphe social).
3. Platform as a service (PAAS) -> Accès à la plateforme (SalesForce, Amazon avec EC2 et S3)
Ce niveau 3 du SaaS vous offre un SDK une réelle plateforme qui héberge et fait tourner votre code.
Exodus est donc un programme planétaire qui vise à migrer les données sur la terre promise qu’est l’architecture web. Le web étant alors compris comme une gigantesque base de données.
C’est un processus de grammatisation car il discrétise les services, les simplifie et nous fait reconsidérer toute notre grammaire du numérique, c’est à dire aussi celle de nos/vos usages.
Mon dieu Christian, mais tu veux ATOMiser les SI 😉
[Reply]
Pour avoir défriché le chemin de cet exode depuis 5 ans (à l’époque on faisait du REST sans le savoir…), j’avoue qu’il m’est difficile d’entrevoir un autre avenir pour les systèmes d’information. Simplicité, souplesse, fiabilité par dilution du risque, facilité de maintenance par l’autonomie des briques métier élémentaires, je n’y vois a priori que des avantages.
Sur le terrain de l’exploitation, les résultats sont plus nuancés. Le web est la plate-forme, mais il n’a pas les outils qu’il mérite. En dehors du sujet classique des navigateurs web qui ne respectent pas les standards (quid des verbes REST put et delete ?), facilement contourné par l’arrivée de nouveaux clients (RIA, RDA, RMA…), le monde de l’entreprise à des contraintes fortes : cohérence des interfaces et processus métier, sécurité des échanges, confidentialité des données, traçabilité des actions, disponibilité de la connexion, santé financière des prestataires…
Le web, oui. REST, oui. L’externalisation totale des processus métier, non. Le SaaS a un avenir tout tracé mais il serait suicidaire de ne le pratiquer que par l’intermédiaire de services en ligne. Ce serait passer d’un piège à un autre, passer du format propriétaire des données au contrôle externe des données et de leurs échanges.
Malgré tout, je ne vois pas cela comme un obstacle, mais comme une opportunité de sortir le web de sa préhistoire pour le doter, enfin, d’outils et de pratiques à sa mesure. Il reste de quoi s’amuser !
[Reply]
Bravo, Christian, pour cette analogie et cette analyse percutante et sans concessions des « maux » des SI existants.
Nous aurons besoin de beaucoup de « Moïse » pour aider les entreprises à traverser la tourmete et trouver le chemin du succès et de la terre promise sous forme de
xaaS ( Tout en services !)
Encore bravo !
[Reply]
[…] Puisque le tendance est de mettre le système d’information “on the cloud”, le top départ de l’exode des données sur le web est donné. Sur la ligne de départ du Hardware as a Service (j’exclue le SaaS car tous y sont à présent depuis l’annonce de l’offre Fusion par Oracle) : […]
[…] Cela va donner le top départ d’une accélération dans l’exode des données et des services du système d’information legacy vers le coud computing et le SaaS. Google avait choisi la France pour lancer son offre à destination des entreprises il y a un an, ce n’était pas un hasard : il y a une maturité des grandes entreprises françaises sur ce sujet qui est surprenante. […]
by Christian Fauré » Blog Archive » SUN bascule la totalité de son informatique “on the cloud”
[…] Un exemple particulièrement rapide dans la mise en oeuvre de l’exode des données que j’avais évoqué. […]
Pourquoi s’obstiner à classer les plateformes dans ces trois catégories qui sont toutes plus « enfermantes » les unes que les autres ? Si Andreessen a été révolutionnaire en son temps, il est aujourd’hui complètement has been, excusez l’expression. Il y a un quatrième type de plateforme, le seul véritable, c’est le web lui-même auquel il manque juste quelques standards permettant d’améliorer la portabilité des données et l’intéropérabilité des services. Construisons ces standards et arrêtons de vouloir capturer le web dans des plateformes propriétaires qui ne mèneront à rien sur le moyen terme.
[Reply]