samedi 31 août 2013

Résistance dans les nuages

English: Diagram showing overview of cloud com...
Diagram showing overview of cloud computing including Google, Salesforce, Amazon, Axios Systems, Microsoft, Yahoo & Zoho (Photo credit: Wikipedia)

Résistances au changement rencontrés sur des solutions à base de "cloud computing"

Taxonomie du "cloud computing"

On distingue à ce jour trois principales typologies dans le paradigme "cloud computing" allant de la partie la plus basse d'une architecture (IaaS - Infrastructure as a service) en passant par la notion de plateforme technique (PaaS - Platform as a service) et jusqu'à la partie la plus haute (SaaS - Software as a service). Quelque soit le niveau considéré, j'observe de fortes résistances au changement dans l'adoption de ces nouveaux concepts d'architecture que j'attribue à plusieurs facteurs décrits succinctement ci-dessous.

Confidentialité des données

Parmi les différentes réticences que je rencontre vis-a-vis d'une architecture basée sur du "cloud computing", la question de la confidentialité des données se trouve fréquemment au centre du débat.
Il est bien compréhensible que l'éventualité d'héberger chez un fournisseur externe à l'entreprise les données stratégiques (portefeuille client, documents de toutes sorte - de la présentation en clientèle en passant par les contrats ou les documents juridiques) puisse constituer un sujet de préoccupation majeure des décideurs de l'entreprise auquel les acteurs du "cloud computing" tentent de répondre par différentes certifications toutes plus "ISO" les unes que les autres.

Pour ce qui me concerne, j'observe que de nombreuses entreprises ont hébergé depuis des années leurs données sensibles dans des centres d'hébergement externes sans pour autant s'inquiéter de l'accessibilité à ces données par les équipes de production, par nature externes à l'entreprise cliente.

Dans le cas du modèle SaaS, si la confidentialité s'avère être un pré-requis fort, je suggèrerai alors de traiter ce sujet à l'aide de systèmes de cryptage des données stockées au niveau des applications clientes de manière a assurer l'accès aux informations au seuls utilisateurs ayant les habilitations nécessaires et suffisantes.
Ce modèle peut fonctionner des lors que l'intranet de l'entreprise est à l'origine des données sensibles. Celles-ci sont alors générées, puis cryptées localement puis transmises ensuite a la plateforme "cloud computing".

A l'inverse, à l'extraction des données, celles-ci sont récupérées localement puis décryptées.
On comprend des lors tout l'intérêt d'une solution SaaS proposant une interface de service riche permettant une personnalisation des services d'accès au données et par là-même la mise en oeuvre de cette mécanique de façon transparente pour l'utilisateur.

Dépendance envers le fournisseur

L'utilisation d'un mode "cloud computing" induit par essence une dépendance envers le fournisseur de service.
Cette dépendance n'est en aucun cas un facteur propre au "cloud computing" et à ce titre doit être gouvernée de la même manière que pour tout autre fournisseur de service. En conséquence, celui-ci doit être scrupuleusement sélectionné suivant des critères:
  • Techniques (pertinence de la solution)
  • Économiques (pérennité de l'entreprise)
  • Contractuels (SLA, pénalités, conditions de retrait)
On comprend bien entendu que le troisième point est essentiel dans le cadre d'une architecture utilisant des services "cloud computing", et il convient de prendre en compte dès l'origine l'ensemble du cycle de vie de la solution conçue:
  1. La mise en oeuvre de la solution, en spécifiant les responsabilités de chacun, en particulier en ce qui concerne la qualité de service attendues, qui induira directement le SLA mis en oeuvre dans le cadre de la solution.
  2. Le fonctionnement courant de la solution avec les rapports attendus en regard du SLA établi et les pénalités induites en cas de non respect de la qualité de service contractualisée.
  3. Les conditions de mise en oeuvre du décommissionement de la solution, prenant en compte la reprise des données sous un format utilisable par le client (donc potentiellement plus fonctionnel que technique en terme de normalisation).

Changement d'un modèle "build" en modèle "buy"

Ce troisième point est vraisemblablement l'un des facteurs de résistance majeur que j'ai eu l'occasion de rencontrer.
Face à des équipes constituées incluant des techniciens aguerris ayant produit et maintenu dans le passé des systèmes ayant fait leur preuve, il est délicat de convaincre que la plus-value de ces équipes dans le futur sera mesurée sur la capacité, non plus à construire et à maintenir, mais sélectionner, contractualiser, mesurer et dans une plus large optique gouverner la relation à leur fournisseur.
Pour autant, il ne faut pas y voir à mon sens la mort de la compétence technique mais plutôt sa transformation, celle-ci restant essentielle à l'achèvement des taches cites plus haut.

De la même façon que l'imprimeur n'a pas besoin de connaitre en détail le processus de fabrication du papier pour gérer ses fournisseurs, son métier requiert de lui qu'il connaisse les différents types de papier ainsi que le celui qui convient à son besoin.
La difficulté qui apparait dès lors que l'on essaie de mettre en oeuvre une architecture basée sur des solutions de type "cloud computing" est de pouvoir répondre à des questions du type:
  • Pourquoi acheter chez quelqu'un d'autre ce que l'on peut faire en quelques jours en interne?
  • Pourquoi donner un revenu récurrent à une société externe plutôt que construire une solution interne?
A la première question je répondrai principalement que l'objectif est:
  1. De s'appuyer sur une expérience externe dans des domaines qui ne sont pas le coeur de métier de l'entreprise.
  2. De s'assurer d'une capacité de maintenance et d'évolution des services achetés en dehors des capacités d'investissement de l'entreprise.
A la seconde, qu'il convient de prendre en compte l'ensemble des coûts d'une solution construite en interne, c'est à dire en particulier:
  1. Les coûts de construction;
  2. Les coûts de maintenance;
  3. Les couts d'hébergement;
  4. Les coûts de décommissionnement de la solution.

Conclusion

Je ne sais pas dire à ce jour si le "cloud computing" est la panacée en matière d'architecture de système. J'observe simplement que bon nombre de réticences rencontrées habituellement ne me paraissent pas réellement fondées des lors que l'on accepte les transformations inhérentes à ce modèle.
Pour ma part, j'utilise des services de ce type depuis bien longtemps à titre personnel. Google Doc, Cavus vinifera (pour les oenophiles), Flickr et autres dropbox ne sont finalement que des appendices virtuels de mon ordinateur / réseau personnel.

Related articles

Impact organisationnel du "cloud computing"

De l'architecture à la gouvernance

Alors que l'architecture d'entreprise commence tout juste à s'imposer au sein des directions informatiques des grandes entreprises, celle-ci voit, avec l'arrivée du "cloud computing", ses missions muter de façon fondamentale.
Historiquement fournisseur de services IT au sein de l'entreprise, les directions informatiques ont de plus en plus un rôle de garant du bon usage des ressources budgétaires IT en regard des objectifs stratégiques de l'entreprise. Avec l'arrivée des modèles SaaS, IaaS et autres composants du "cloud computing", il est désormais indispensable de prendre en compte dans les équations de ROI les hypothèses d'achat de prestations de services IT au même titre que ce qui est effectué dans d'autres domaines support (logistique par exemple). Autrement dit, pourquoi construire en interne ce que d'autres font mieux et depuis plus longtemps?

Avec l'arrivée du "cloud computing", le rôle de l'architecte d'entreprise ne se cantonne plus des lors à concevoir des solutions "in-house", mais également de comprendre au plus près le besoin utilisateur afin de sélectionner les meilleures alternatives du marché en termes d'offre de services, de plateforme ou même d'hébergement. Ce choix doit non seulement prendre en compte des besoins fonctionnels, mais également non fonctionnels: (disponibilité, performances, ergonomie, stabilité...) qui devront se traduire par l'établissement d'un SLA dont les termes devront être mesurables et potentiellement soumis à pénalités en cas de non respect.

De fournisseur de service support, l'architecte d'entreprise - tout en restant le garant des services rendus - se place par conséquent en tant que consommateur, voire acheteur et ne peut par conséquent faire l'impasse sur les aspects contractuels qui le lient à ses fournisseurs.

Par ailleurs, en tant que garant de la bonne allocation budgétaire des services IT, ils se doit de se pencher de près sur les ROI des services consommés afin de détecter les sources d'économie potentielles pour l'entreprise par une baisse de niveau de service requis (SLA moins onéreux) voire la remise en cause des fonctionnalités fournies lorsque celles-ci présentent un coût trop élevé vis-à-vis du gain métier escompté.

La notion de cloud computing allant de paire avec un modèle économique à coût récurrent pour l'entreprise, la notion de ROI devient critique. En effet, on considère généralement dans une approche "in-house", le modèle économique est essentiellement constitué des coûts d'acquisition et des couts de maintenance (de l'ordre de 15% du cout d'acquisition en annuel). Le modèle en "cloud computing" est pour sa part bien souvent linéaire dès le départ ce qui amène a un point d'équilibre (entre l'année 3 et 4 sur le diagramme ci- dessous) qu'il convient de connaître au plus tôt afin de négocier au mieux les coûts d'une solution SaaS ainsi que les conditions de sortie.

On le voit, au delà des connaissances techniques essentielles de l'architecte d'entreprise, l'apparition sur le marché d'offres de services à tous les niveaux de l'architecture amène ce dernier à se pencher sur des problématiques qui relevaient jusqu'alors plus de la gouvernance IT que du pur cadre technique.

Related articles

Sur le web 3.0, tout le monde sait que vous êtes un chat...

Pour la mise en place d'une gouvernance éthique mondiale du web


Il semblerait que Georges Orwell ne fasse plus recette presque 30 ans après 1984. Les adolescents s'exposent sur les réseaux sociaux comme ils le feraient dans l'intimité. Leur "smart" phone offrent à leur tribu les moyens de les géo-localiser en permanence. Leur web est omniscient, omniprésent. Il leur ouvre une fenêtre quasi-unique sur le monde, sur la culture. Ils sont prêts.

Prêts à l'avènement du web 3.0. Prêts à l'arrivée du web sémantique qui reliera non plus seulement les hommes mais étendra la notion de ressource aux objets de notre quotidien. Prêts à se voir représentés sous la forme de réseaux d'informations atomiques en nombre quasi-infini dont la puissance réside, moins par les informations elles-mêmes que par les liens entre celles-ci. Prêts à accepter de voir la frontière tenue qui subsiste encore entre le monde réel et le monde virtuel se désagréger définitivement.

La question que je me pose est la suivante: suis-je prêt à vouloir ceci pour mes enfants? suis-je prêts à les exposer à toutes les dérives marketing, commerciales et dans un scénario plus catastrophique, totalitaires. Suis-je prêts à voir mes enfants fichés, numérisés, sans savoir quelle sera l'utilisation ultime qui sera faites de ces informations?

Tout récemment encore, en interrogeant un spécialiste du web 2.0 sur l'évolution de celui- ci vers un web 3.0 et la nécessité d'une gouvernance éthique de ce dernier, je me suis entendu répondre quelque chose comme "le web 3.0 n'existe pas, ou alors je ne l'ai pas rencontré". Or cette simple négation me semble porter en elle-même tout le caractère insidieux de cette évolution.

Révolutionnaire dans ses conséquences, cette évolution est le fruit que d'évolutions techniques et comportementales. Évolutions techniques tout d'abord, permettant la modélisation, le traitement et l'analyse d'un nombre de plus en plus important de données élémentaires. Évolutions comportementales ensuite, conduisant tout un chacun à donner à des fournisseurs de services dont on ne sait finalement que peu de choses sur les objectifs in fine des données de plus en plus personnelles (nom, prénom, date de naissance, adresse, mais également orientation politique, religieuse...).

Des démarches telles que l'"open data" me laissait entrevoir une évolution positive et citoyenne des ressources numériques. Hélas, celle-ci n'est rien ou peu de chose, si elle n'est combinée à une analyse croisée entre des données "ouvertes" et des données d'ordre privées (agenda, préférences personnelles, geo-localisation...). En d'autres termes, je ne crois en l'"open data" qu'une fois le web sémantique établi.

On l'aura compris, la tournure prise par le web actuellement me pose question et me semble inéluctable. Je ne crois pas plus qu'un rejet définitif de cette évolution serait une solution. En revanche, il me paraît d'ores et déjà nécessaire sinon indispensable de mettre en oeuvre la gouvernance éthique globale qui permettra de s'assurer a l'avenir du bon usage fait par les uns et les autres des données personnelles manipulées.

Il est encore temps car sous le web 2.0, personne ne sait que vous êtes un chat...