mardi 27 mai 2014

Quand le datacenter redevient stratégique

Quand le datacenter redevient stratégique




L'hybridation entre cloud externe (public ou privé) et infrastructure interne, sera donc la règle pour de nombreuses entreprises si ce n'est la majorité.
Après avoir exploré dans le billet précédent les enjeux de la maîtrise de son infrastructure logicielle (DSI et Facebook, même combat), il encore temps de soulever le capot de cette infrastructure matérielle interne a qui on va demander encore beaucoup, et de jeter le projecteur sur sa forteresse : le datacenter.
Le buzz et le marketing autour du cloud, avec la promesse d'une offre scalable en puissance et en volume de stockage, de coûts de possession réduits, et surtout de ne payer que ce dont on a besoin, nous ferait presque oublier qu'il reste encore des datacenters "à l'ancienne" loin de ces standards. En fait, c'est même la majorité des datacenters!
GreenSI a entendu cette semaine un professionnel se plaindre d'un refus de virtualisation de serveurs dans son datacenter outsourcé, car cela n'arrangeait pas son hébergeur... aussi vendeur de serveurs. Quelle imagination débordante!
Surtout quand on réalise qu'une telle approche reviendrait a renoncer à la scalabilité tant vantée ou à payer un sur-dimensionnement, pour pouvoir augmenter les ressources d'une application (sur une période courte comme une clôture mensuelle), Sans parler du bilan carbone de ce sur-dimensionnement qui serait détestable...
Heureusement, ce n'est pas la règle, et les datacenters, d'entreprises ou d'hébergeurs, sont bien entrés dans une phase de transition pour atteindre les performances du Cloud devenu le benchmark à atteindre.
Une étude (pdf) ommandée par Colt et présentée à quelques DSI dans un restaurant parisien cette semaine, révèle que l'âge moyen des infrastructures des datacenters en Europe est de 9 ans. Sachant que ces dernières années ont été propices à l'ouverture de beaucoup de capacité pour le Cloud, cela veut dire qu'un grand nombre de datacenters sont encore plus vieux que cela.
Pour Colt, hébergeur européen de services de collocation avec 20 centres de données dans 22 pays, les datacenters sont au bord d'une rupture, en tout cas d'une évolution forte pour s'adapter aux besoins à venir.
Dans le contexte des besoins tirés pas l'hybridation présentée ci-avant, et les nouveaux business modèles des entreprises qui se numérisent, les signes de cette rupture sont pour Colt,l'incapacité à prévoir les besoins de capacité et de stockage pour 63% des DSI interrogés.41% ont sous-estimé leurs besoins et 31% sur-estimés.
Et pire, les délais pour prendre des décisions sur la stratégie (expansion, consolidation...) se sont eux allongés par rapport à ce qu'ils étaient 12 mois avant. Alors si les projets de Bigdata et d'objets connectés sont bien devant nous, et amènent réellement une augmentation des capacités de stockage et d'analyse, il est temps de se poser des questions sur l'évolution de ses besoins et sur sa stratégie.
Les facteurs principaux de ces stratégies datacenters sont: 
  • l'énergie (qui influence les coûts), 
  • la localisation
  • la gestion des risques et du règlementaire,
  • et la transformation métier de l'entreprise dans les années qui arrivent.
Depuis les révélations de Snowden sur les indiscrétions de la NSA, la localisation de ses données devient un facteur important à prendre en compte pour l'évolution de son infrastructure interne. Des affaires qui ont été du pain béni pour les hébergeurs qui avaient misé sur une offre nationale ("cloud souverain").
Mais quand on est une PME avec des clients en Espagne, en France et en Italie, l'offre "nationale" atteint sa limite. Surtout si le réglementaire s'en mêle et impose de garder ses données clientèles dans chaque pays d'origine. C'est peut-être un futur avantage a court-terme pour les hébergeurs pouvant offrir de la multi-localisation en Europe. A moyen terme, on mesure en cette période d'élections européennes, l'importance de l'Europe et de sa capacité a créer un environnement de confiance européen pour nos données et les protéger des indiscrétions des américains pour ne citer qu'eux..
L'annonce en Février dernier de l'américain Salesforce, pour ouvir un datcenter en France, (mais également en Allemagne et UK) est aussi un signe de cette tendance qui impacte aussi le SaaS, d'avoir ses données le plus près du siège de l'entreprise. Celui prévu à Londres venant d'ailleurs d'ouvrir cette semaineLes extensions de capacités ne vont vraisemblablement pas conduire a des datacenters plus grands, mais a des datacenters mieux répartis.
L'infrastructure devient stratégique. C'est l'actif majeur de sociétés comme AmazonFacebook ou Google pour se différencier par rapport a des sociétés plus traditionnelles auxquelles elles "siphonnent" les revenus publicitaires ou commerciaux. La réorganisation dans les télécoms n'y est pas étrangère, ces derniers étant devenus de simples fournisseurs d'accès pour les clients des premiers, car la valeur est passée dans les services produits par leurs datacenters à haute performance utilisés par des centaines de millions d'utilisateurs.
Alors ne restons pas trop les bras croisés dans le virtuel où le marketing du Cloud aimerait nous endormir, et posons nous les bonnes questions sur le physique, et sur l'évolution de nos besoins en terme de capacité et de stockage, et surtout : au fait elles seront où nos données demain?

vendredi 9 mai 2014

Gestion de l'infrastructure: Facebook et DSI, même combat !

Gestion de l'infrastructure: Facebook et DSI, même combat !

F8 est la conférence de Facebook pour les développeurs, qui s'est tenue à San Francisco, la semaine dernière. 

Un moment important pour annoncer les nouvelles fonctionnalités et pour convaincre tout un écosystème, que Facebook reste la plateforme de référence sur laquelle il faut porter ou développer des applications, de préférence avec une composante sociale à dans ces applications (Zinga Poker,Candy Crush Saga, ..) 

Quel attrait pour les développeurs? Accéder au milliard et plus d'utilisateurs actifs de Facebook pour monétiser leurs applications et surtout leur à leurs données et au "social graph" sur lequel toute la plateforme de Facebook est construite.

L'alternative à Facebook pour un développeur? L'écosystème Apple Store ou Android ou Chrome chez Google. Donc la concurrence est rude, sans oublier Windows 8 qui sait que ce n'est pas simple pour convaincre de développer aussi sur la plateforme de Microsoft.

Benoit Darcy a traité cette semaine sur ZDnet ce qu'il fallait retenir de cette conférence F8. GreenSI a envie d'y revenir pour en tirer des enseignements pour les DSI et pour l'évolution des SI.

La DSI aussi a un écosystème technique

Car après tout, le DSI a lui aussi à convaincre un écosystème composé de métiers de partenaires (clients, fournisseurs); de continuer à développer ou à minima d'intégrer les prochaines applications de l'entreprise sur le SI qu'il gère. Car il est loin le temps ou les métiers n'avaient d'autre possibilité pour supporter leurs opérations, que de passer de façon incontournable par la DSI :
  • Aujourd'hui le SaaS est une alternative crédible à l'installation de progiciels "in house" et est en forte croissance.
  • Et puis le SI s'ouvre de plus en plus, avec pour certains la création d'écosystèmes de développeurs comme CAStore chez Crédit Agricole, le premier site d'applications bancaires co-crées avec des acteurs en dehors de la DSI et financées par un modèle économique innovant. Intéressant de voir, que comme Facebook, c'est le mobile et la volonté d'aller vite qui a poussé le Crédit Agricole a ouvrir ses données et permettre le développement d'applications mobiles par des tiers.
  • Et bientôt les DSI du secteur public vont aussi devoir adopter l'opendata et grandir le nombre d'autres SI, abonnés à leurs données, avec des licences opendata et peut être demain des niveaux de service.
Alors profitons de l'expérience de Facebook et regardons la conférence F8 sous l'angle de l'évolution du SI avec un nouvel écosystème.

Facebook, une plateforme qui quitte l'adolescence

Le motto de Facebook pour les développeurs était "Move fast and break things !".


Le social développant des modèles en rupture, la vitesse a toujours été la priorité pour Facebook. Pourvu qu'elle amène le succès de nouveaux usages et de nouvelles applications. Un succès qui se compte en dizaines de millions d'utilisateurs chez Facebook, en millions de dollars de publicité et surtout en revenus non négligeables pour les développeurs.

Mais à cette échelle, la vitesse amène parfois des bugs, euh souvent, non finalement tout le temps ;-)

Régulièrement Facebook organise une "chasse aux bugs" (Bug Bounty) pour ceux qui relèvent de la sécurité de la plateforme et sont donc les plus prioritaires. Les développeurs qui les identifient sont largement récompensés, jusqu'à plusieurs dizaines de milliers de dollars pour les meilleurs.

Un équilibre entre vitesse de lancement et travaux de mise au point, s'est donc mis en place. Et ce malgré quelques bugs majeurs, comme celui du 21 octobre 2013 (2h d'arrêt mondial) et des centaines de remontées d'utilisateurs en permanence sur les forums, pour indiquer des fonctionnalités qui ne marchent pas dans les milliers d'applications qu'ils peuvent installer sur leur page Facebook.

Mais lors du dernier F8, Mark Zuckerberg a remis en cause ce motto, et appelé a plus de qualité dès la première version

Car finalement la vitesse se payait dans la durée et obligeait ensuite a perdre du temps pour corriger a grande échelle ("What we realized over time is that it wasn't helping us to move faster because we had to slow down to fix these bugs and it wasn't improving our speed"). 

Un discours qui ne surprendra pas un DSI, qui connait bien la décision difficile à prendre dans un projet au moment de la recette: la validation (ou pas) de la mise en production.

Et puis, fini les corrections et les changements de dernière minute qui impactent en permanence l'écosystème. Les développeurs demandent de la stabilité (2 ans) pour se connecter à la plateforme Facebook et à ses API .
En échange, les correctifs de bugs devront être produits dans les 48h, car la moindre qualité des applications développés par des tiers, rejailli sur l'image de Facebook.

Et comme la tendance de fond est que les usages des réseaux sociaux entrainent leurs utilisateurs sur le mobile, Facebook n'a pas d'autre choix que de maîtriser une plateforme mobile plus fragmentée (iOS, Android,  Windows8) et plus complexes que le web, et d'y amener aussi son écosystème. 

Après l'adolescence voici venu pour Facebook l'age de la raison, peut être, en tout cas celui de la mobilité. Et pour marquer les esprits, un nouveau motto est lancé : "Move fast with a stable infra".
 
La stabilité de la plateforme ne doit plus être sacrifiée pour aller vite.

Facebook et DSI, même combat ?

Car de par sa taille, Facebook n'est plus une startup depuis longtemps et se heurte à la problématique de l'évolution de son système d'information de production. Avec une expérience certaine sur le "move fast" par rapport à une DSI, sur la capacité à travailler avec un écosystème, mais néanmoins un modèle de stabilité à trouver pour sa plateforme. 

De son côté la DSI a toujours été reconnue pour la stabilité de son SI, que ce soit pour l'interconnexion des applications (même sans API) ou pour l'exploitation de son infrastructure. C'est même un reproche qu'on lui fait souvent quand on lui demande d'aller plus vite pour tester de nouveaux produits, car la stabilité est érigée en principe. Mais dans une économie qui accélère avec la mondialisation, la stabilité n'a pas toujours été vue comme un avantage. La conférence F8 lui redonne une certaine valeur.

Mais cette stabilité doit maintenant rimer avec :
  • vitesse de réalisation de nouvelles applications,
  • ouverture vers un écoystème (y compris les applications en SaaS et quelques offres de startups)
  • et bien sûr la mobilité. Et pour cette dernière la combinaison gagnante  est certainement mobile + data, comme l'a montré le dernier billet de GreenSI, "Mobile first".
La cible à moyen terme semble donc être la même pour Facebook et la DSI : la capacité à gérer une infrastructure stable, en collaboration avec un ecosystème, qui permettra l'innovation et la vitesse d'exécution. Ce qu'illustre GreenSI avec le schéma suivant :


Pour Facebook, la question est de redéfinir ce qui doit être stabilisé. Les API certainement, le social graph, le système de login qui maintenant accepte un accès anonyme... bref, une infrastructure qui va devoir quitter le domaine du "move fast" pour plus d'industrialisation.
Pour la DSI, la question est de trouver les domaines où elle doit aller vite et les boulets qui l'empêche de le faire. Et en le faisant elle rejoint la problématique de l'écosystème de Facebook.

Pour la DSI, le "boulet" c'est... l'ERP !

Dans le dernier billet sur l'évolution de l'ERP (les ERP se portent bien, mais qu'en pensent leurs clients?), GreenSI a mis en avant le fait que :
  • peu de clients sont vraiment satisfaits de leur ERP,
  • les coûts des ERP sont de plus en plus "challengés" surtout quand ils n'amènent pas plus de productivité,
  • le support du monde mobile (et des "devices" qui vont avec) est une exigence de plus en plus forte de la part des utilisateurs et pas toujours disponible,.
Car le risque, c'est que même si la DSI adopte des approches agiles et ouvertes pour booster l'innovation et accélérer les nouvelles applications demandées, elle buttera doublement sur la rigidité de l'ERP :
  • qui piège des données, sans les exposer au reste du SI alors que moins de 20-30% des salariés ont un accès à l'ERP,
  • qui couvre des domaines qui maintenant demandent plus de flexibilité qu'avant.
L'un des boulets de la DSI, qui va freiner ses initiatives "move fast", c'est donc l'ERP, ou tout simplement la vision d'un SI totalement intégré, la promesse de l'ERP.
Bien sûr l'ERP a aussi ses avantages, quand il a été bien implémenté: comme des processus bien outillés qui amènent de la productivité ou une base unique pour l'analyse des couts de façon transversale.

Alors quand garder l'ERP et quand en sortir pour retrouver de l'agilité ?
Tout est une question d'architecture... en couches

C'est la question à laquelle Gartner a donné une réponse en 2012 avec la démarche "PACE layers" (couches en fonction du "rythme"). Une méthodologie pour classer les applications afin d'avoir une gouvernance et des processus de développement différenciés en fonction de la vitesse d'évolution attendue (y compris une organisation des équipes).
Une méthodologie pensée pour le SI mais qui devrait aussi intéresser Facebook pour identifier le "coeur stable" de sa plateforme.

L'idée de segmenter le SI en couches en fonction du "rythme" d'évolution attendu est intéressante pour repenser sa stratégie d'application d'entreprise, en offrant vitesse sans pour autant sacrifier l'intégration , l'intégrité et / ou la gouvernance applicative. Mais pas partout. C'est ça le degré de liberté qui donne de la souplesse.Les trois couches que Gartner propose d'identifier dans les SI sont :

  • Les systèmes d' enregistrement - qui prennent en charge le traitement des transactions de base et de gèrent les données de base essentielles de l'organisation . Le taux de variation est faible , parce que les processus sont bien établis , commune à la plupart des organisations, et sont souvent soumis à des exigences réglementaires .
  • Les systèmes de différenciation - qui permettent des processus uniques ou des capacités spécifiques à l'industrie . Ils ont une durée de vie moyenne (de un à trois ans ) , mais doivent être reconfigurés souvent à s'adapter à l'évolution des pratiques commerciales ou les exigences du client .
  • Les systèmes d'innovation - de nouvelles applications qui sont construites sur une base ad hoc pour répondre aux besoins des entreprises nouvelles ou des opportunités . Ce sont généralement des projets de cycle de vie court (de zéro à 12 mois) en utilisant les ressources du ministère ou à l'extérieur et des technologies de consommation de qualité .
 
Cette classification dépend bien sûr de l'entreprise. Dans telle entreprise aux contrats signé à long terme, un système commercial peut être dans la catégorie "enregistrement" car la majorité de la relation commerciale sera relationnelle avec peu de décideurs, alors que dans une autre entreprise ce sera un "système d'innovation" car il devra être très réactif et identifier de nouveaux prospects en temps réel sur les réseaux sociaux.

Pour revenir à l'infrastructure (serveurs, ...) elle prendra en compte aussi cette classification plus facilement pour isoler les types de SI sur des environnements dédiés ce qui n'etait pas possible avec un ERP tout intégré.

Pour restructurer votre ERP, vous aurez compris qu'il ne faudra pas en rester aux acronymes bien pratiques qui ne veulent rien dire (CRM, PLM,,...) mais descendre au niveau de modules fonctionnels plus ciblés et plus cohérents (comme par exemple "la saisie des commandes" qui peut bénéficier d'une approche mobile, alors que le "traitement des commandes" lui n'est qu'un système d'enregistrement).

Avec cette démarche, la priorité qui semble maintenant se dégager, c'est bien la "déconstruction de l'ERP" fourre-tout, pour la prise en compte des rythmes d'évolutions dans les différentes parties du SI. 

C'est aussi un signal que la DSI va passer d'un monde piloté par des éditeurs  qui imposait des produits, a un monde piloté par une infrastructure, cloud, mobile et sociale, utilisée par tout un écosystème.

Les ESN (SSII) qui se sont laissé prendre la majeure partie de la marge par les éditeurs d'ERP ces dernières années, pourraient en tirer un avantage si elles savent développer leurs compétences sur ces nouvelles plateformes et valoriser leur savoir faire d'intégration, dans un monde des affaires en train de se numériser.

dimanche 4 mai 2014

SEPA : fin de la saga ?

SEPA : fin de la saga ?


En décembre 2013 GreenSI ne voyait pas trop comment la date fatidique du 1er février pour la migration de tous les échanges de prélèvements et virement au nouveau format européen SEPA - Single European Payment Area - pouvait être tenue (SEPA, c'est pas prêt !).

Sans surprise l'échéance de février 2014 a été repoussée de 6 mois par la Commission Européenne, même si la date du 1er ne changeait pas officiellement (SEPA: quand c'est pas prêt... c'est repoussé !). Dans la pratique cela voulait dire que ceux qui n'étaient pas prêts n'ont pas eu de rejets de leurs prélèvements ou virements quand il n'étaient pas au nouveau format SEPA.

Rétrospectivement, quand on se souviens que le 16 Janvier Orange s'est fait pirater 800.000 comptes de ses clients (dont les emails), on ne peut que frémir à l'idée de l'opération de phishing qui aurait pu avoir lieu dans un contexte de millions de prélèvements rejetés.
 
Il suffisait d'envoyer de (faux) messages emails à ces clients piratés pour leur demander de rectifier leur coordonnées bancaires sur un (faux) site orange, la TV et la presse se chargeant de crédibiliser l'opération en relatant les premiers rejets SEPA. Car la communication d'Orange a été pour le moins mal gérée et ne s'est faite que le 30 janvier et les explications finales le 3 février. Pile-poil dans la période de bascule SEPA. A part les pirates et Orange, personne n'aurait pu savoir (Piratage des clients d'orange, une communication désastreuse). A se demander même si ce n'était pas l'idée initiale des pirates...

Depuis, les travaux se sont accélérés et le taux de prélèvements au bon format a beaucoup progressé (90,62%) comme celui des virements (93,47%) mais qui était lui moins en retard. La situation est proche de la fin la migration. 

Mais sans aucun doute il fallait bien ce décalage de 6 mois vu la courbe !

Attention maintenant. Car on sait bien que ce sont les derniers fichiers qui sont les plus difficiles à migrer. Souvent, ce retard cache une autre difficulté dans les entreprises, comme par exemple d'avoir perdu les sources du programme qui génère les fichiers de prélèvements, ou d'être sur une ancienne version de progiciel non maintenue et donc sans mise à jour...

Le Comité SEPA qui s'est réuni le 30 avril (communiqué) appelle maintenant les retardataires à mettre tout en œuvre pour respecter l'échéance du 1er aout (1er février + 6 mois) pour qu'on puisse enfin annoncer la fin d'une saga qui a commencée il y a plus de 7 ans le 5 décembre 2007 avec la publication d'une directive européenne.

Donc si vous êtes dans les retardataires et que vous voulez éviter les désagréments des rejets dans les virements des salaires, des fournisseurs ou des prélèvements de vos clients, vous savez ce qu'il vous reste à faire avant de partir en vacances !