Alors que le fonctionnement des entreprises doit s’avérer plus résilient que jamais, l’augmentation globale du télétravail devient un défi majeur pour les équipes sécurité ! L’ouverture massive des connexions à distance et l’exposition accrue d’applications vers l’extérieur créent des opportunités pour les cybercriminels. Dans ce climat d’urgence et de stress, l’ingénierie sociale s’en retrouve également facilitée. Enfin, il s’ajoute à ces éléments les difficultés et tracas du quotidien, qui freinent la réactivité des équipes chargées de superviser les systèmes et d’intervenir en cas d’incident.

Ainsi, nous tenions en particulier à partager la campagne de sensibilisation que nous avons créé dans ce contexte. Retrouvez ci-dessous, la chronique « Martine fait du télétravail pendant le COVID-19 » !

Saison 1

 

Hors-série « Chiffrer un document »

Saison 2

Hors-série « Détecter le phishing »

Episode final

Cet article [COVID-19] Martine fait du télétravail ! est apparu en premier sur RiskInsight.

Le marché BDaaS en pleine expansion

Le terme BDaaS désigne les services d’analyse de mégadonnées utilisant l’hébergement Cloud. Il couvre l’ensemble des offres Cloud computing traditionnelles : IaaS, PaaS, SaaS.

• D’un côté, on retrouve les offres IaaS dédiées Big data: mise à disposition de serveurs optimisés pour Hadoop essentiellement (OVH, IBM Softlayer, Microsoft Azure …).
• De l’autre, les offres PaaS Big data: plateformes permettant aux utilisateurs de déployer des applications distribuées et qui s’appuient nécessairement sur un stockage Cloud constituant parfois une offre à part entière : ainsi, Azure HDInsight utilise BLOB Storage et Amazon EMR, S3.
• Enfin, il y a les offres SaaS Big data de deux 2 types :
  • celles permettant l’analyse et la data visualisation (Tibco, Splunk, Altiscale, Datameer) de grandes quantités de données en s’appuyant sur des moteurs d’exécution distribués,
  • celles répondant à des besoins métiers d’extraction d’information de gros volumes de données (ex. : offre d’eReputation s’appuyant sur l’analyse sémantique de réseaux sociaux pré-connectés comme twitter).

Au sein de ce marché pluriel, le modèle PaaS Big data s’impose comme la catégorie de solutions la plus en vue aujourd’hui. On y retrouve notamment EMR d’Amazon, Big Query de Google, ou encore HDInsight de Microsoft, tous les trois déjà bien matures. Par ailleurs, d’autres fournisseurs projettent de commercialiser des offres BDaaS en 2015. C’est le cas de Numergy et Oracle. Enfin, des start-ups se positionnent aussi sur le marché, à l’image de Qubole.

Panorama du marché BDaaS – copyright Solucom

PaaS Big data versus plateformes on premise

Le PaaS Big data offre des avantages significatifs parmi lesquels on retrouve :

• La mise à disposition immédiate de ressources et le paiement à l’usage sans investissement initial : ce duo gagnant permet de se soustraire à des dépenses d’investissement particulièrement élevées pour un projet Big data et il simplifie le set up et la montée en charge des architectures Big data. Nul besoin de planifier l’allocation de capacité, le time-to-delivery est ici minime.
• Une complexité réduite : les architectures PaaS sont créées en quelques clics par paramétrage. Un réel avantage pour le Big data qui utilise des technologies distribuées nouvelles et complexes.

Néanmoins, l’adoption du BDaaS pose la question de la sécurité, en particulier de la confidentialité des données : d’après une enquête menée en 2014 par PAC CloudIndex[2], près de 50% des entreprises sollicitées affirment avoir des craintes quant à la sécurité des données stockées dans le Cloud. Toutefois, il est important de souligner que ces risques ne sont pas nécessairement plus élevés que sur des infrastructures on-premise. Il convient donc de s’assurer que les fournisseurs cloud utilisent des services garantissant la confidentialité et l’intégrité des données (chiffrement des données stockées et des flux, mécanisme d’authentification forte…). Par ailleurs, plusieurs certifications garantissent la mise en place de bonnes pratiques de sécurité par les offreurs Cloud (ISO27001, CSA STAR, SSAE 16…).

C’est ce qui pousse la plupart des entreprises à choisir un déploiement hybride combinant les ressources d’un Cloud public et d’un Cloud privé.

Les principaux cas d’usage du BDaaS

3 cas d’usage sont moteurs dans l’adoption du BDaaS :

• Le POC (Proof Of Concept) : le Big data poursuit son émergence, les entreprises continuent les expérimentations. Il n’est pas toujours évident d’une part de dimensionner son infrastructure et d’autre part  de parier sur l’atteinte des objectifs. Le Cloud permet de se lancer sans engagement.
• La gestion de pics de charge : l’entreprise utilise des clusters temporaires pour des besoins ponctuels et les détruit ou éteint lorsque le pic de charge est passé (un traitement sur des milliers de nœuds pour valider une hypothèse par exemple). Mais l’immédiateté a ses limites : le traitement s’exécute sur des volumes de données qu’il faut évidemment provisionner.
• Le Plan de reprise d’activité (PRA) : l’entreprise synchronise les données de la production vers une plateforme Cloud public prête à démarrer à tout moment en cas de problèmes. Ce qui lui évite un nouvel investissement pour sa plateforme de PRA.

Le BDaaS apparaît ainsi comme un moyen de se lancer dans l’analyse des mégadonnées plus rapidement, à moindre coût pour des usages ponctuels et avec plus de flexibilité.  Il lève les freins inhérents aux projets Big data que sont par exemple un retour sur investissement incertain et la complexité des nouvelles architectures. Reste le sujet de la confidentialité des données dans le Cloud qui peut être mis sous contrôle par le biais d’une analyse de risque. 

[1] L’offre EMR a été créée en 2009, Big Query en 2012, HDInsight en 2012.

[2] Source : http://www.cloudindex.fr/sites/default/files/PAC%20CloudIndex%20-%20Analyse%20juin%202014.pdf

Cet article Big data et Cloud computing : le pari gagnant des offres BDaaS ? est apparu en premier sur RiskInsight.

Un changement de modèle d’exploitation pour industrialiser et sécuriser le SI

Les infrastructures convergées permettent-elles de gagner de l’argent ? La réponse n’est pas évidente. Bien souvent le prix de ce nouveau bloc d’infrastructure est plus élevé que la somme de chaque élément qui le compose. Mais alors comment faire des économies avec un produit qui coûte plus cher ? Tout simplement parce que le gain promis par les fournisseurs d’infrastructures convergées ne s’appliquent pas aux dépenses d’investissement (CAPEX) mais aux dépenses d’exploitation (OPEX).

La manière d’opérer ces infrastructures est différente et facilite leur administration et leur exploitation dans le temps. En effet, la matrice de compatibilité des composants garantie par le fournisseur et le processus de validation en usine permettent de sécuriser et de faciliter les projets de mise à jour et d’intégration des équipements. Cela favorise naturellement le maintien en conditions opérationnelles des infrastructures et permet d’obtenir un gain en coûts récurrents.

Considérer un bloc d’infrastructures convergées comme une brique d’infrastructure élémentaire permet de faciliter la gestion du datacenter et du processus de capacity planning. De fait, il est important de standardiser une configuration complète de bloc, utilisant l’intégralité des emplacements disponibles et définissant l’ensemble des composants. Il est en effet essentiel de favoriser la scalabilité horizontale (scale-out par duplication de bloc standard) plutôt que la scalabilité verticale (scale-up par augmentation des ressources internes de chaque bloc). Ainsi, on déploie un bloc prêt à l’emploi disposant d’une certaine quantité de ressources que l’on active et que l’on paye en fonction de ses besoins et usages. Cela est aujourd’hui possible grâce au modèle de facturation des fournisseurs. De plus, cela apporte de la flexibilité à la DSI pour accueillir des besoins non prévus au portefeuille projets en activant simplement de nouvelles ressources. Par conséquent, les délais projets sont réduits par la suppression de l’étape d’acquisition du matériel. Le processus de capacity planning se voit alors piloté efficacement tout en limitant les coûts à la consommation des ressources.

Les infrastructures convergées permettent également de simplifier l’architecture globale du datacenter en créant une « zone franche » d’infrastructure indépendante et auto-suffisante. Les interactions entre les différentes couches d’infrastructures sont alors maîtrisées, contrôlées et contenues dans des « blocs » qui proposent des ressources informatiques standardisées.

Cette « zone franche » est accessible par un seul point d’entrée. Cette interface unique permet d’opérer et d’administrer l’ensemble des ressources disponibles par bloc ou sur l’ensemble de la zone. La création d’une équipe mutualisée, multi compétences, enrichie de profils d’architectures transverses permet de s’affranchir du modèle historique en silo. Cela permet de renforcer le maintien en condition opérationnelle des infrastructures. De plus, les risques d’incidents peuvent être limités à condition qu’un chantier de convergence et d’industrialisation des processus d’exploitation soit mené.

L’apport des infrastructures convergées pour impulser une stratégie DSI « Cloud Broker »

Les infrastructures convergées représentent un investissement idéal pour commencer à placer la DSI en tant que fournisseur de Cloud privé car ces nouvelles infrastructures vont permettre de bénéficier d’un socle de ressources standardisées. Le mode d’administration entraîne également une industrialisation et une consolidation des processus d’exploitation. De plus, l’ensemble des infrastructures sont pilotées à travers une interface centralisée. On rassemble ici certaines qualités propres au Cloud computing mais il manque certains éléments essentiels permettant de tirer toute la puissance des infrastructures convergées :

• Le design et la définition d’une offre de services à proposer aux clients ;
• L’orchestration et l’automatisation des services afin de répondre immédiatement à la demande ;
• Un portail de gestion et de suivi des demandes.

Le CMP (pour Cloud Management Platform) est l’outil qui va permettre de construire un Cloud privé IaaS (Infrastructure-as-a-Services) et PaaS (Platform-as-a-Service) reposant sur les infrastructures convergées. La standardisation des infrastructures et la console de gestion centralisée va faciliter le projet d’intégration avec le CMP. Ce Cloud privé constituera les premières offres de services proposées par la DSI. Celle-ci se placera en tant que fournisseur de services à valeur ajoutée pour le Métier.

Dans un premier temps, ce nouveau catalogue de services s’attachera à proposer des offres de la DSI, hébergées en interne et adaptées aux besoins du Métier. Ensuite, ce catalogue pourra progressivement être étendu et enrichi en proposant des services Cloud privatif ou public. Ainsi, il sera possible de mettre en place un nouveau modèle de refacturation basé sur la consommation de services interne ou externe proposés par la DSI (Cloud hybride).

La mise en place de cette stratégie « Cloud Broker » nécessite un programme de transformation à part entière composé de plusieurs grands projets transverses : standardisation du socle technique, normalisation et création d’une offre de services, construction d’un Cloud privé, définition d’une stratégie Cloud, chantier de refacturation, etc…

S’appuyer sur un Cloud privé maîtrisé et fonctionnel reposant sur des infrastructures convergées fournira un accélérateur et un levier de transformation pour impulser cette nouvelle stratégie au sein de l’entreprise.

De nouvelles opportunités sous réserve de conduire un programme de transformation

Pour conclure, les infrastructures convergées permettent de limiter les risques d’incidents synonymes d’indisponibilité et de pertes financières potentielles. Elles diminuent le time-to-market et permettent de mettre en place de nouveaux services à valeur ajoutée à destination du Métier. De plus, la standardisation des infrastructures et des processus représentent un levier fort pour l’industrialisation du SI et l’amélioration de la performance économique de la DSI. Pour autant, cela implique des changements majeurs dans le SI et dans la façon de l’opérer. L’ensemble des chantiers de transformation devront néanmoins  être pilotés de manière transverse par la DSI pour tirer tous les bénéfices des infrastructures convergées. Êtes-vous prêts à sauter le pas ?

Cet article Infrastructures convergées : un 1er pas vers un SI Cloud-Ready ? est apparu en premier sur RiskInsight.

Néanmoins, choisir l’approche adéquate et investir sur une ou des solutions reste une étape complexe. Regardons de plus près le menu, et observons les différents types d’offres aujourd’hui disponibles et leur intérêt en fonction des usages.

Le Big data casse les limites traditionnelles : tout est dans la puissance du nombre

Traditionnellement, les architectures techniques sont construites à partir de serveurs « standalone». À gros besoins, gros serveurs. En d’autres termes, plus le besoin de puissance ou de stockage est important, plus les serveurs utilisés sont robustes. Mais, cette approche a une limite finie et ne permet pas de gérer les très grands ensembles de données.

Avec le Big data on change de paradigme : le concept clé des architectures Big data est la distribution ! On distribue les données et les traitements sur un nombre virtuellement infini de ressources. On exploite la puissance du nombre. C’est la clé pour casser les limites traditionnelles et accéder à une capacité de stockage et de traitement sans limites. L’ensemble des offres Big data repose sur ce principe.

Quelles sont les formules au menu du jour ?

La 1^ère formule s’appuie sur le Best Of breed.  Il s’agit ici de faire du Big data en intégrant et capitalisant sur ses ressources IT. Comment ? L’entreprise se construit un environnement distribué en agrégeant ses infrastructures conventionnelles via l’intégration d’une distribution logicielle Big data (de type Hadoop par exemple). N’ayant pas d’investissement matériel, le coût d’investissement pour ce type d’offre reste raisonnable mais engage les entreprises à monter en compétence pour concevoir et mettre en place la nouvelle plateforme.  Ce type de solution est principalement destiné aux entreprises avec un besoin d’évolutivité et d’appropriation fort. Les banques d’investissement en sont un excellent exemple par leur nécessité d’expérimentation permanente, qui les force à innover pour répondre aux enjeux métiers.

La seconde formule s’appuie sur les offres d’« Appliance Big data» : le vendeur va proposer à ses clients une infrastructure sur étagère où matériel et logiciels sont intégrés, pré-configurés et optimisés. C’est une boîte noire, mais l’architecture interne s’appuie sur la logique de distribution : elle encapsule des dizaines de petits serveurs. Ce modèle a le désavantage d’avoir un coût d’investissement élevé mais délivre une efficacité opérationnelle immédiate : il s’adresse principalement aux entreprises qui recherchent cette efficacité et qui sont en capacité de cadrer leurs besoins avec le vendeur.

La dernière offre est légitimement le Cloud. Pourquoi le Cloud ? Et bien parce qu’il est le plus à même de mettre à disposition des entreprises un nombre de ressources presque illimité. On distingue deux offres : celles de type « IaaS » où l’entreprise intégrera elle-même « sa distribution Big data » aux infrastructures louées dans le nuage. Mais, la tendance est plutôt au « BDaaS » (Big data as a Service) : le nuage provisionne un environnement Big data intégré, opérationnel et élastique. L’intérêt de ces offres Cloud est le coût (à l’usage) et la rapidité de mise en place, qui en fait une cible parfaite pour des usages de type POC afin de tester la valeur du Big data pour l’entreprise. Pour les prototypes opérationnels, des questions autour de la sécurité et des données peuvent se poser et les rendre moins attrayantes.

Au final, les socles d’exécution Big data sont bien là ! Le choix de l’un d’entre eux nécessite dans tous les cas une phase d’analyse des besoins et des enjeux afin de trouver l’optimum économique au regard des usages.

Cet article Au menu du Big data, 3 formules : à intégrer, packagé ou dans le nuage est apparu en premier sur RiskInsight.

 iPaaS : quelques cas d’usages à considérer

Les DSI doivent répondre à différents cas d’usages d’intégration, auxquels le Cloud est lié: des applications Cloud à intégrer entre elles ou avec le SI interne, une intégration avec des partenaires ou filiales et enfin un débordement du SI vers le Cloud.

Ces cas d’usages se traduisent par des besoins d’échanges de fichiers de grandes tailles en différés, de messages au fil de l’eau, d’appels de services synchrones… Les systèmes d’échanges assurant alors les fonctions de transfert, routage, transformation et connectivité aux applications dans le Cloud et dans le SI interne.

Trois typologies de déploiement permettent de supporter ces cas d’usages

Le plus naturel consiste à utiliser un système d’échange existant on-premise (SI interne). L’intégration avec les applications dans le Cloud est faite via des connecteurs spécifiques (particulièrement pour le SaaS). Mis en œuvre initialement pour une intégration majoritairement interne au SI, le système d’échange est utilisé pour l’intégration avec le Cloud. Ce choix n’est pertinent que pour un nombre restreint d’applications Cloud, sans échanges importants entre elles.

Avoir une plateforme unique d’échange dans le Cloud public est une autre typologie possible. Elle sera alors principalement utilisée pour l’intégration entre applications dans le Cloud.  Elle peut également être utilisée pour devenir le point unique d’échanges avec des partenaires et filiales. Toutefois, le passage systématique par le système d’échange dans le Cloud pour l’intégration d’applications internes au SI peut être rédhibitoire (volume, latence…). Ce peut être un choix uniquement tactique, pour une adoption rapide.

L’utilisation de deux systèmes d’échanges en « miroir », un dans le SI (potentiellement existant) et un autre dans le Cloud, est la typologie la plus avancée. Il n’y a alors qu’un lien unique entre les deux plateformes, donc un seul point d’entrée dans le SI interne sur lequel la sécurité est renforcée. Elle permet de couvrir efficacement l’ensemble des échanges internes et Cloud.  Une gouvernance des échanges est ici indispensable pour maîtriser leur répartition entre les deux plateformes. Des réponses doivent également être apportées pour assurer la consolidation de la supervision, le déploiement des flux…

Au final, le choix de typologie dépend avant tout de l’existence de systèmes d’échanges au sein du SI et du nombre d’applicatifs dans le Cloud à la cible.

Un marché de l’iPaaS hétérogène

L’iPaaS est une suite de services Cloud supportant ses caractéristiques principales : self-service, élasticité, mesurable et mutualisation des ressources. Il permet l’intégration entre des éléments du Cloud et on-premise et peut assurer différentes typologies d’intégration : processus (BPM, workflow…), services (ESB / SOA), applications et données (ETL).

Dans les faits, les solutions iPaaS n’ont pas toutes ces caractéristiques clés, et peuvent être de différentes natures :

D’un côté, il y a les pure players de l’intégration Cloud. Leurs solutions sont construites sur le modèle du Cloud, ils en respectent les préceptes. Leur maturité est cependant encore à challenger dans un marché qui n’est pas encore entièrement consolidé. De l’autre, il existe des solutions n’ayant aucune caractéristique Cloud mais ayant des connecteurs vers les grands noms du SaaS (Salesforce, WorkDay…). Elles servent avant tout d’accélérateur pour une connexion simplifiée. Mais il ne faut pas non plus mettre de côté les solutions classiques on-premise d’éditeurs historiques de l’intégration directement déployées sur une offre PaaS. Ces solutions ont pour elles leur maturité acquise dans l’intégration interne au SI. En revanche les caractéristiques du Cloud ne sont pas toutes assurées…

Il est donc nécessaire de prendre en compte son existant afin de faire les choix les plus pertinents.

Quel chemin emprunter pour aller vers le Cloud ?

Le chemin vers l’intégration Cloud peut prendre différentes voies selon l’existant en termes d’échanges au sein du SI de l’entreprise. Pour un SI déjà outillé avec une ou plusieurs plateformes d’échanges, ce qui est le cas chez les grands comptes, il est important de capitaliser sur celles-ci en se concentrant sur deux problématiques clés. La première : est-ce que la solution propose des connecteurs Cloud vers les applications SaaS utilisées, ou même un framework de développement pour s’adapter à toute application SaaS ? La seconde : est-ce que la solution est proposée par l’éditeur dans une version iPaaS ? Cela permet de mettre en œuvre une typologie de déploiement en miroir, tout en conservant les mêmes compétences internes.

Si l’extension du SI vers le Cloud n’entraîne pas une rupture des architectures d’échanges inter-applicatifs déjà en place (SOA, EDA…), il sera cependant nécessaire de décliner les patterns établis afin de tirer entièrement parti des promesses du Cloud et de prendre en considération ses contraintes.

Cet article L’iPaaS, pourquoi ne peut-on pas faire l’impasse ? est apparu en premier sur RiskInsight.

Les 4 clés de l’intégration des services Cloud

1 – Une intégration des données sans couture

Avec l’utilisation de services Cloud, on exacerbe le besoin de mettre en place des plateformes transverses d’échanges entre les différentes ressources, qu’elles soient Cloud ou internes. Cette problématique est essentiellement présente lorsque l’on s’appuie sur des services SaaS.

Il s’agit ainsi soit d’étendre les plateformes d’échanges traditionnelles aux services Cloud si elles offrent des connecteurs vers les interfaces (API) des applications Cloud, soit de s’appuyer sur des services d’échanges relais (Cloud ou internalisés), qui masqueront la complexité des interfaces et de leur évolution.

2 – Une gestion centralisée des identités

Celle-ci est essentielle pour fournir aux utilisateurs un accès sans couture à l’ensemble du SI, qu’il soit en mode Cloud ou non. Elle doit notamment permettre de gérer le cycle de vie des comptes utilisateurs (décommissionnement, gestion du mot de passe…).

Cet aspect est trop souvent négligé. Il arrive par exemple de laisser des accès ouverts à des employés ayant quitté la société, l’exposant à de la surfacturation et à d’importantes brèches de sécurité. La DSI doit donc mettre en œuvre une gouvernance des identités globale ainsi que l’outillage adéquat.

3 – Des référentiels communs de service management

Pour que la DSI puisse garantir les niveaux de services de l’outil informatique (disponibilité, impact des changements, capacité d’évolution…), il est nécessaire qu’elle puisse intégrer les services Cloud à ses référentiels de service management. Ils auront notamment un rôle primordial pour gérer les changements. En effet, les services Cloud évoluent constamment, en cycle rapide, sans que les clients puissent s’y opposer. Les analyses d’impacts doivent donc être précises et le plus automatisées possible. Pour s’adapter au Cloud, les référentiels devront intégrer des ressources fournies en mode as-a-Service, pour lesquels les aspects de localisation ou de dépendance à des ressources physiques ne sont pas connus.

4 – Des portails de services par usage

L’une des composantes essentielles du Cloud est l’aspect self-service. Pour optimiser l’apport des services Cloud, il est primordial de limiter le nombre de points d’entrées pour les demandes de ressources, les déclarations d’incidents et le suivi des consommations, et ce quel que soit le nombre de fournisseurs.

En revanche, il n’est pas nécessaire de se limiter à une seule interface globale pour l’ensemble des services de la DSI. Il s’agit ici de fédérer les différents portails de services qui seront instanciés par typologie d’usage et de population. Pour ce faire, il faut anticiper au plus tôt une cible globale d’intégration puis s’appuyer sur un outillage adapté aux services souscrits et à l’existant. Cet outillage est à déployer progressivement à l’occasion de chaque projet Cloud jusqu’à atteindre la cible.

Une stratégie d’outillage à définir en fonction de la stratégie Cloud

La cible d’outillage sera à définir en fonction de la stratégie Cloud. Dans une stratégie à dominante SaaS, le challenge majeur sera d’intégrer sans couture les nouvelles applications au SI. Il faudra donc en priorité traiter les problématiques d’intégration de données, la gestion unifiée des identités et le portail de services. Si la stratégie Cloud est essentiellement IaaS, les enjeux seront plutôt liés à la gestion de ce nouveau parc de ressources. Il faudra alors se doter rapidement d’un outillage permettant d’adresser la problématique de service management.

Deux types d’acteurs constituent actuellement le marché de l’outillage Cloud, qui est en phase d’évolution rapide. D’un côté, des startups aux offres fonctionnellement riches mais dont la pérennité n’est pas toujours assurée. De l’autre, des fournisseurs traditionnels avec des offres qui sont soit balbutiantes, soit issues de rachats récents, donc peu intégrées au reste de leur gamme et en passe de subir des évolutions majeures.

Ces solutions n’étant pas pleinement satisfaisantes, deux stratégies de déploiement s’offrent aux entreprises.

Si l’on est dans un rythme d’adoption du Cloud plutôt lent, mieux vaut temporiser en s’appuyant sur l’outillage existant et en l’adaptant au cas par cas. Par exemple, des transferts de fichiers non automatisés peuvent suffire dans un 1er temps pour assurer le provisioning des identités. Cette stratégie évite d’investir dans des solutions peut-être non pérennes, au prix d’un surcoût modéré en opérations.

En revanche, si l’on souhaite adopter une démarche volontariste et cadencée vers le Cloud, il n’est plus possible de temporiser au risque de voir exploser ses coûts d’opérations. Il faut donc expérimenter ce que le marché sait fournir ! L’outillage Cloud-ready, qu’il permette l’intégration de données, la gestion des identités et le service management ou offre un portail de service, embarque de toute façon un ensemble de connecteurs vers  les fournisseurs du marché. Charge ensuite à l’éditeur de la solution de les maintenir à jour en fonction des évolutions apportées par les fournisseurs Cloud.

Dans tous les cas, un impératif : rester en veille permanente pour adapter sa stratégie aux évolutions des standards, à leur niveau d’adoption par le marché et aux mouvements de consolidation.

Cet article Sans maîtrise, le Cloud n’est rien… est apparu en premier sur RiskInsight.

Des choix tactiques à court terme assez homogènes…

Il n’est pas surprenant aujourd’hui de voir bon nombre de DSI s’orienter vers les mêmes services Cloud, comme la mise à disposition de machines virtuelles ou de plateformes web, ou encore la messagerie en mode SaaS. Les travaux déjà réalisés en matière de virtualisation des infrastructures, d’externalisation des opérations IT et de standardisation des architectures web simplifient du reste l’évolution vers ce type de services.

Déployer de tels services relève plutôt d’une approche tactique, qui permet à la DSI d’obtenir des succès rapides et de démontrer sa capacité à offrir des services de type Cloud, tout en commençant à se confronter à ses impacts et à la réalité des offres du marché.

 …en attendant une stratégie Cloud plus spécifique

Ces services ne constituent toutefois qu’une 1^ère étape, la stratégie Cloud de chaque entreprise devant se bâtir sur une analyse plus fine du patrimoine SI de l’entreprise, application par application, comme l’illustre notre « arbre de décision Cloud » (voir schéma).

 Cette analyse peut se faire dès à présent par le biais de l’incubateur Cloud qui, au fur et à mesure qu’il identifiera les périmètres éligibles, sera en mesure de bâtir un catalogue de services cibles et une roadmap permettant de rythmer l’adoption des services Cloud. Voici les grandes étapes de la démarche à suivre pour y parvenir :

• Identifier les applications et services IT éligibles au Cloud en évaluant la valeur apportée à l’entreprise, le niveau de confidentialité des données manipulées et le niveau de spécificité du système ;
• Rechercher des services SaaS pour les applications ou services dont l’usage peut être standardisé et dont la criticité (business ou sécurité) n’est pas bloquante pour envisager une évolution vers le Cloud ;
• Envisager le passage au PaaS ou au IaaS lorsqu’aucun service SaaS n’existe sur le marché ;
• Renforcer le niveau de standardisation des socles logiciels et techniques des applications aujourd’hui trop spécifiques à l’entreprise pour pouvoir trouver leur équivalent dans le Cloud.

Le marché étant dans une dynamique d’évolution rapide et perpétuelle, cette approche est à réitérer régulièrement et à enrichir d’une veille permanente sur les acteurs et les offres Cloud. Au-delà de la maturité des offres du marché, des critères plus spécifiques à l’entreprise peuvent influer sur son rythme d’adoption du Cloud. Ainsi, un niveau élevé d’industrialisation et d’externalisation facilitera et accélérera la transition vers des offres Cloud. De même, l’arrivée à échéance de contrats existants ou l’obsolescence de certaines solutions ou applications seront des opportunités d’évolution vers le Cloud, sans oublier bien sûr des ruptures plus fortes dans la stratégie de l’entreprise (forte réduction des coûts, fusion ou désimbrication de pans entiers du SI…).

Autant de facteurs qui, bien pris en compte, permettront d’aboutir à une stratégie Cloud spécifique et efficace !

Une cible hybride à anticiper

De même qu’il n’existe pas de stratégie Cloud unique applicable à toute entreprise, il est impossible d’identifier l’intégralité des services qui s’appuieront sur des offres Cloud à moyen terme, tant le marché est dynamique aujourd’hui. En revanche, une chose est sûre : le SI cible sera hybride et les services Cloud devront être parfaitement intégrés au SI traditionnel.

Alors préparez-vous ! En parallèle du déploiement des premiers services Cloud, plusieurs chantiers techniques et organisationnels transverses sont à lancer dès maintenant. Ces chantiers doivent permettre de maîtriser la prolifération des services Cloud et de faire face à un SI de plus en plus éclaté, tant géographiquement qu’en termes de responsabilité. Il s’agit en premier lieu de définir un cadre d’adoption des services Cloud (règles d’éligibilité, politique de sécurité, clauses juridiques et contractuelles) et de bâtir un socle d’intégration et de pilotage de ces services (architecture d’interconnexion, portail(s) self-service, Cloud Management Platform…). Ces évolutions majoritairement technologiques doivent s’accompagner d’une redéfinition des modalités de pilotage économique des services IT et de la définition d’un plan d’évolution des compétences, pour que la transition vers des services IT à l’usage s’opère en douceur au sein de l’entreprise, tant pour la DSI que pour les Directions Métiers.

Ainsi, la DSI se positionnera peu à peu comme un Cloud broker, proposant à ses utilisateurs (clients finaux, collaborateurs de l’entreprise ou équipes projet IT) des services accessibles au travers d’un ou plusieurs portails et offrant les moyens techniques (intégration, sécurité, pilotage) et humains (conseil, support, accompagnement au changement) nécessaires pour garantir l’usage de ces services dans de bonnes conditions.

Ces chantiers transverses doivent faire partie intégrante de la stratégie Cloud, au risque de ne pouvoir garantir la cohérence du SI à moyen terme…

Cet article Les clés d’une bonne stratégie Cloud : combiner approche tactique et vision stratégique est apparu en premier sur RiskInsight.

La standardisation est l’une des caractéristiques du Cloud. Si l’entreprise veut en tirer tous les bénéfices, opérationnels comme économiques, elle doit accepter et faire accepter aux utilisateurs un degré de standardisation important. Le déploiement du Cloud en entreprise implique un changement de posture pour la DSI et une évolution radicale dans les mentalités, au sein des équipes informatiques comme du côté des Métiers.

Le challenge principal pour les équipes de maîtrise d’ouvrage et de conception du SI va avant tout être de trouver le bon point d’équilibre entre les besoins de personnalisation des services Cloud et le niveau de standardisation imposé par les fournisseurs.

En outre, les équipes informatiques vont devoir apporter toute leur expertise pour mettre en cohérence des Clouds multiples et ainsi former un SI homogène. Bien qu’habituées à des environnements complexes, elles devront également intégrer un cadre moins flexible qu’auparavant.

Faire évoluer les fonctions techniques

Avec le développement du Cloud, la spécialisation des compétences est de moins en moins d’actualité : la tendance est au profil multi-généraliste. On le voit par exemple avec la mise en place de services SaaS, comme la bureautique et la messagerie : le besoin d’experts techniques sur ces périmètres auparavant internalisés est de plus en plus faible.

Avec un SI hybride, intégrant des services Cloud et des composants hébergés en propre, la coordination technique devient un enjeu majeur. Ce sera tout particulièrement le cas sur des actions opérationnelles comme la mise en œuvre des changements ou la résolution des incidents. La présence de ces profils techniques, capables de comprendre ce SI multi-facettes et de coordonner les fournisseurs, constituera même très vite un impératif pour la DSI.

On assistera aussi à la montée en puissance de profils techniques très spécifiques, conséquence directe de l’évolution de l’architecture du SI dans le contexte Cloud. Les compétences d’intégration technique des SI (architecture, orchestration, intégration de données, etc.) vont ainsi être amenées à se développer, avec un objectif clé : garantir la cohérence du SI. Des compétences sécurité (fédération d’identité, gestion des habilitations) vont également se développer.

Renforcer les fonctions de management des services

Le phénomène d’externalisation, croissant ces dernières années, a poussé au développement de compétences de pilotage des activités externalisées, mais aussi à une réduction de la prise en charge en interne des activités opérationnelles de la DSI (production, développement…).

Cette transition du « faire » au « faire faire » est encore plus marquée dans un contexte Cloud, où le niveau de standardisation requis va imposer à la DSI d’industrialiser encore plus ses activités. Les démarches de définition et de mise en place de services et de lignes de services ont conduit à l’apparition de fonctions de type « Service Manager » ou « Service Delivery Manager », dont le rôle est de coordonner la production du service et sa bonne fourniture au client.

Ces rôles doivent fortement se renforcer sur le pilotage des volumes consommés afin d’accompagner avec proactivité les clients dans la gestion de leur demande. De cette manière, les service managers peuvent être responsabilisés sur l’équilibre économique de leur service et plus seulement sur les engagements de qualité de service et de performance opérationnelle.

Anticiper dès aujourd’hui les impacts RH du Cloud

Il est crucial de bien accompagner la transition des compétences associées aux externalisations croissantes induites par le Cloud. Une méthode classique consiste à mettre en place une démarche de Gestion Prévisionnelle des Emplois et Compétences (GPEC), aussi connue sous le nom de Talent Management.

Pour analyser l’impact RH lié au Cloud, les DSI doivent justement se doter d’une véritable cartographie de ces emplois et compétences. Les déformations RH provoquées à court terme par les décisions connues en matière de Cloud peuvent ainsi être évaluées et faire l’objet de plans d’actions de redéploiements optimaux.

Par ailleurs, une identification des impacts potentiels à moyen / long terme doit être réalisée. Elle permet d’évaluer les plans d’actions RH et management à dérouler en matière de mobilité, formation, gestion de carrière et objectifs. Autant de transformations à prendre en compte.

Cet article Cloud : une nécessaire transformation des compétences et des pratiques est apparu en premier sur RiskInsight.

Des missions au service d’une adoption progressive du Cloud

En mettant en place un incubateur Cloud, la DSI se donne les moyens de piloter la trajectoire et le rythme de la transformation qu’induit le Cloud. Elle peut aussi promouvoir l’usage des services Cloud qui permettront de combiner au mieux innovation, maîtrise financière et maîtrise technique du SI.

Dans ce cadre, l’une des priorités de l’incubateur est de se faire connaître, de promouvoir son action afin de capter au plus tôt les initiatives Cloud qui pourraient émerger. Ceci fait, son leitmotiv doit être de favoriser ces initiatives en facilitant le déploiement et l’intégration de ces nouveaux services dans le SI.

Pour cela, il doit jouer un rôle de conseil et de contrôle dans le cadre des projets, pour anticiper d’éventuels écueils techniques ou juridiques réels, mais aussi permettre de relativiser un certain nombre de risques ou de freins non justifiés.

Il diffuse également son expertise et ses retours d’expérience issus d’initiatives précédentes, pour sensibiliser les Métiers et les équipes de la DSI aux impacts du Cloud. Ceux-ci concernent aussi bien le SI (problématiques d’intégration et de réversibilité, décommissionnement de l’existant pour justifier le ROI de l’initiative…) que l’utilisation des services (limitations fonctionnelles liées à l’usage d’une solution standard, perte de maîtrise sur les processus d’évolution et de gestion des changements…).

Ensuite, en s’appuyant sur une veille marché active, il identifie les périmètres du SI éligibles au Cloud et promeut les nouveaux usages porteurs de valeur pour l’entreprise.

Enfin, il a vocation à préparer la transformation de la DSI et du SI pour passer à l’ère du Cloud. Il animera ainsi les réflexions autour des évolutions et de l’outillage nécessaires à la DSI pour maîtriser les impacts du Cloud sur les plans suivants : compétences et organisation, modèle économique et pilotage des coûts, garantie de la qualité de service et de la sécurité sans oublier la mise en cohérence et l’homogénéité du SI.

Si son action est efficace, l’incubateur favorisera un passage en douceur vers une gestion industrielle des services Cloud par les équipes de la DSI.

Une structure visible et agile…

Pour assumer pleinement son mandat, l’incubateur doit bénéficier d’un haut niveau de sponsorship et d’un rattachement transverse au sein de la DSI pour être légitime et connu des Métiers.

Il doit également avoir la capacité de mobiliser les ressources de la DSI, sans pour autant s’inscrire totalement dans le cadre des processus classiques de la DSI. Ainsi, il sera en mesure d’accélérer et de favoriser les  initiatives, en  particulier lorsque le service Cloud concerné est en phase d’expérimentation ou de pilote. C’est la seule façon pour l’incubateur de réussir à ancrer la DSI dans l’adoption du Cloud et la seule façon de démontrer la valeur ajoutée que la DSI peut apporter aux utilisateurs. À l’image d’une cellule « Innovation », c’est au travers de la réussite durable des initiatives qu’il aura accompagnées et du changement d’image de la DSI qu’il aura véhiculé que l’incubateur prouvera sa propre valeur et justifiera l’investissement qu’il représente.

…mobilisant de larges compétences regroupées sur quelques personnes

Afin de conserver l’agilité nécessaire, l’incubateur doit rester compact : 3 à 5 personnes. En revanche, le succès de l’incubateur repose avant tout sur la qualité du casting de ces personnes.

Pour mener à bien les missions de l’incubateur, les profils à cibler sont ceux alliant compétences IT larges et parfaite connaissance de l’entreprise et disposant d’un leadership fort pour promouvoir de nouveaux usages et de nouvelles pratiques. De tels profils sont généralement des ressources critiques et libérer une partie de leur temps pour qu’ils se consacrent à l’incubateur est un réel investissement.

Cet investissement est un impératif pour la DSI. Même si l’appel à de la prestation externe est envisageable pour apporter compétences techniques et connaissance des offres Cloud, il n’est pas suffisant pour assurer la maîtrise de l’organisation et de l’existant de l’entreprise.

Si les bonnes ressources ne sont pas disponibles en nombre suffisant, mieux vaut privilégier le caractère compact de l’équipe à la couverture exhaustive des compétences nécessaires.

Quelles actions pour débuter ?

La priorité doit être donnée à l’accompagnement des initiatives qui permettront d’obtenir des quick wins visibles par le Métier et aux actions de communication valorisant les apports du Cloud et de l’incubateur. C’est par ce biais que l’incubateur pourra réellement être l’avant-poste de la transformation induite par le Cloud.

Deux éléments nous semblent essentiels à produire immédiatement par l’incubateur : un kit de sensibilisation aux bénéfices et aux impacts du Cloud (paiement à l’usage, localisation des données, évolution des relations DSI / Métiers…) et le catalogue des services Cloud déjà déployés ou à venir.

Une chose est sûre, l’objectif n’étant pas de pérenniser son existence dans l’organisation, l’incubateur doit avancer vite et donner la priorité à l’action et non à la réflexion !

Cet article Aller vers le Cloud oui, mais comment légitimer la DSI ? est apparu en premier sur RiskInsight.

La problématique n’est pas simple. L’architecture IT locale des entreprises rend de nombreux services – services aux utilisateurs (fichiers, messagerie, impression…), services techniques (télédistribution d’application, antivirus, annuaire et authentification, services réseaux…) ou encore hébergement d’applications. S’ajoute à cette première complexité l’hétérogénéité des sites distants : nombre d’utilisateurs, bande passante réseau, usages et niveaux de service différents selon les besoins métiers…

Quelles sont les solutions techniques disponibles pour s’affranchir des serveurs locaux ? Quel impact sur l’expérience utilisateur et sur l’exploitation des services ? Sur le réseau ? Voici 3 clés pour réduire le coût de vos infrastructures locales.

Des quick-wins pour les petits sites

Dans la plupart des cas, supprimer les serveurs locaux sur les plus petits sites suffit à dégager des économies substantielles sans investissement notable. La première étape est donc la rationalisation.

Comment faire ? On supprime par exemple les serveurs locaux et, pour limiter l’utilisation de la bande passante WAN, on déporte les services directement sur les infrastructures locales existantes, comme par exemple les postes de travail. On parle alors de relais locaux.

La fonctionnalité Windows BranchCache – disponible depuis Vista / WS2008 – est un premier exemple. Il s’agit d’une sorte de mode peer-to-peer : les postes de travail adoptent le rôle de relais à la fois pour les fichiers utilisateurs, les packages SCCM, les mises à jour ForeFront… Ce type de solution est également disponible en dehors du monde Microsoft (fonction GUP de l’éditeur Symantec par exemple). Attention toutefois, ces fonctionnalités ont des limites et nécessitent un paramétrage fin : gestion des pics de charge, monitoring des stations relais, sécurité…

Concernant les services d’impression, le Direct IP Printing – transmission directe sans serveur d’impression du job d’impression vers une imprimante – se développe. Windows 8 prend d’ailleurs en compte cette tendance en offrant nativement la fonctionnalité (Branch Office Direct Printing). Toutefois, l’installation des imprimantes et la gestion des drivers en mode Direct IP Printing doit être repensée pour éviter de générer une surcharge sur le helpdesk. Il est alors intéressant de considérer l’utilisation d’un outil spécifique pour adresser ces problématiques.

Il est également envisageable dans certains cas de remplacer les serveurs locaux par des appliances nécessitant une administration moins lourde qu’un serveur classique – notamment pour jouer le rôle de relais de télédistribution ou de cache pour les fichiers.

Pour aller plus loin, une centralisation des services IT nécessaire

Si la centralisation de ces services est plus classique et à présent maîtrisée pour des services tels que l’annuaire d’entreprise (Active Directory..) ou les services réseaux (DHCP, DNS…), cela reste bien souvent un challenge quand on aborde la question de l’accès aux fichiers et de leur restauration. Jusqu’à présent, la présence de serveurs locaux historiques était bien souvent expliquée par le besoin d’avoir un serveur des fichiers en local pour éviter les latences.

Dans cette optique de centralisation, la bande passante disponible devient donc un élément clé. Une étude site par site de cette dernière s’avèrera souvent nécessaire, sous peine d’altérer l’expérience utilisateur.

Un upgrade du réseau WAN pour augmenter sa bande passante reste possible et devient aujourd’hui de plus en plus accessible économiquement. À défaut, des boitiers de compression / cache réseau peuvent également être installés sur certains sites.

Quelques adhérences à garder à l’esprit pour ce type d’initiatives : la nécessité de redimensionner les infrastructures centrales et la difficulté de mutualiser boitiers de cache avec appliances réseaux hybrides.

Cloud et virtualisation pour un résultat optimal

Pour espérer un gain encore plus important, la refonte des infrastructures locales doit se faire dans le cadre d’une approche plus en rupture, poussée par des choix stratégiques et technologiques forts, tels que la virtualisation ou l’adoption de services Cloud. Ces choix ne sont pas neutres en termes de réseau et posent immédiatement la question de la disponibilité des services en mode déconnecté.

Le Cloud est également une possibilité lorsqu’il s’agit de services techniques. On pourra citer Windows Intune, qui embarque à la fois le patch management Microsoft (WSUS) pour la télédistribution d’application et l’antivirus ForeFront. Mais il faudra toutefois se poser les questions suivantes : en cas de bande passante WAN limitée, est-il judicieux d’en consacrer une partie à des services techniques ? Et si oui dans quelles proportions ?

Des services d’impression dans le Cloud – privé ou public – se développent également. On pourra citer Google Cloud Print – où les serveurs d’impression sont dans les datacenters du géant américain. Des limitations importantes existent encore (compatibilité des types de fichiers et des imprimantes) mais on répond ainsi à certains besoins liés à la mobilité (lancement d’une impression sur une imprimante corporate depuis une tablette…).

Le VDI supprime quant à lui le besoin de délivrer des services locaux de télédistribution ou d’antivirus par exemple, les postes étant eux-mêmes déjà centralisés. Toutefois, encore implémenté chez seulement 2 à 3 % de nos clients de manière massive, le VDI peut rarement être mis en place sur l’ensemble d’un périmètre client.

Pour mettre en place ces approches, le réseau devient le nerf de la guerre. Une stratégie innovante en la matière consiste à implémenter des réseaux hybrides, permettant de faire passer directement certains flux vers internet, là où ils transitaient auparavant par le WAN. Cette solution devient particulièrement pertinente lorsque des services sont sourcés dans le Cloud : accès direct aux serveurs dans le nuage, meilleure bande passante et diminution des coûts. Attention toutefois à la maitrise des flux (priorisation des flux, redondance des liens…).

On l’aura compris, l’arrivée à maturité des technologies (réseaux, infrastructures de gestion de l’environnement de travail, virtualisation) et l’arrivée de services techniques Cloud permet aujourd’hui d’aller chercher plus facilement des économies par une démarche de rationalisation et de centralisation partielle des services. Pour aller jusqu’à la centralisation complète des infrastructures locales, il est inévitable d’élargir l’étude pour considérer le même type d’initiative autour du poste de travail lui-même, tout en cherchant à optimiser la consommation du réseau WAN de l’entreprise qui permettra au passage de faciliter l’adoption de services Cloud. Préparez-vous, la Digital Workplace arrive !

Cet article Et si on supprimait tous les serveurs d’infrastructure locaux ? est apparu en premier sur RiskInsight.

Déchiffrer la complexité des modèles fournisseur

La maîtrise de la facturation du fournisseur constitue le 1^er pilier de ce pilotage. De prime abord, le système de facturation du Cloud peut paraître simple : prix à l’unité, facturation au volume. Ce mode de fonctionnement peut cependant générer des surprises au bout de quelques cycles de facturation. En effet, le modèle contractuel embarque fréquemment des éléments structurants tels que les volumes ou montants minimaux, ou encore les effets de seuil. De telles clauses induisent des risques pour la DSI : si la demande du Métier n’est pas au rendez-vous, l’équilibre économique du service pourrait ne pas être atteint.

Avant de contractualiser, une attention particulière doit par conséquent porter sur la compréhension du modèle économique du fournisseur, et notamment sur les services et options qui sont les plus rentables pour ce dernier. En effet, les tarifs de service  anormalement bas pourront cacher des options coûteuses qui s’avéreront finalement nécessaires (extension de volumes de stockage, frais d’interconnexion, etc.).

Construire des scénarios d’utilisation des services

La réflexion sur l’équilibre économique doit amener à piloter les recettes de la DSI et implique donc de bénéficier d’une vue au plus juste des besoins du Métier, présents et futurs. Il s’agit, pour la DSI et ses clients, de construire et de suivre une projection de l’évolution des volumes d’utilisation des services Cloud, et si nécessaire de formaliser des scénarios d’évolution. Cette concertation DSI / Métiers permet d’obtenir un engagement mutuel entre la DSI et les Métiers.

Cette connaissance permettra à la DSI de souscrire au service Cloud le plus adapté, d’évaluer le seuil de rentabilité de ce service, et de mettre en place une facturation à l’usage permettant l’équilibre économique. Pour le Métier, cette collaboration permettra de disposer d’un certain degré de maîtrise financière de ses dépenses informatiques.

Les scénarios d’utilisation des services constitueront in fine des entrants précieux dans la démarche de construction budgétaire, pour les Métiers comme pour la DSI.

Accompagner le Métier dans la gestion de sa demande

La mise en place d’outils ergonomiques pour l’accès au Cloud (portails self-service par exemple) et l’amélioration de la qualité ont pour effet de faciliter l’accès aux services informatiques pour les utilisateurs, qui ont ainsi naturellement tendance à en augmenter leur utilisation : cette amélioration de l’offre conduit à une demande accrue.

La facturation à l’usage par les fournisseurs, associée à cette augmentation de la demande peut d’ailleurs induire une augmentation de la facture globale des services Cloud. Sans freiner la productivité des Métiers, la DSI se doit de les accompagner et les conseiller, en mettant à leur disposition des outils de suivi de l’usage des services IT.

Il s’agit avant tout de donner un maximum de visibilité au Métier sur ses consommations :

• Refacturer au Métier peu de temps après les consommations réelles, au mois par mois ;

• Produire un reporting opérationnel de l’utilisation des services, intégrant notamment un suivi des volumes consommés par rapport aux volumes prévus, et un système d’alertes en cas de surconsommation (et également de sous-consommation) ;

• Analyser cette consommation avec les Métiers pour ajuster les priorités et prévisions d’utilisation future.

Il est également recommandé de fournir les systèmes techniques de gestion de la demande (portails selfservice, outils de workflow), permettant au client de valider les besoins de ses utilisateurs.

Cet accompagnement de la demande constitue un véritable service fourni par la DSI, qui ne serait pas accessible en cas de souscription des services Cloud directement par les Métiers. Ces derniers n’ont en effet pas d’objectif régalien de maîtrise globale des coûts IT : il s’agit donc pour la DSI de valoriser l’image de ce service, qui constitue un réel élément différenciant.

Le Cloud ? Une raison supplémentaire de faire travailler main dans la main DSI et Directions Métiers !

Cet article Garantir l’équilibre économique de la DSI à l’ère du Cloud est apparu en premier sur RiskInsight.

Une adoption motivée par réduction des coûts et recherche d’agilité

Malgré la dynamique du marché et la promesse de gains sous-jacente, les DSI des grandes entreprises tardent à se mettre en mouvement, réagissant plus au Cloud qu’elles ne l’anticipent. Elles le privilégient essentiellement pour des usages à risques techniques limités et à ROI rapide, principalement en IaaS et en SaaS.

SaaS : une utilisation massive des services standardisés

Le SaaS est aujourd’hui le principal vecteur d’adoption du Cloud. L’adoption du SaaS est centrée sur les fonctions support dont l’usage est standardisé (bureautique, messagerie, CRM, paie…). Le SaaS est également fortement sollicité pour les services de sécurité (antivirus, proxy, services de tests d’intrusion…) qui nécessitent une puissance de calcul importante, des évolutions en cycle court ainsi qu’une disponibilité maximale pour des employés de plus en plus mobiles.

PaaS : une adoption encore confidentielle

C’est le segment le moins bien appréhendé par les grands groupes aujourd’hui. Il correspond à la fourniture d’une plateforme d’exécution de code informatique. Il permet la mise à disposition d’une application en limitant très fortement les opérations sur les couches sous-jacentes (systèmes, bases de données, serveurs d’applications…). Le PaaS reste aujourd’hui cantonné chez les grands comptes à des usages « jetables », comme des prototypes ou des sites web temporaires (événementiels).

IaaS : des déploiements essentiellement en mode « privé »

Le modèle IaaS, fourniture de machines virtuelles (VMs) et ressources associées depuis un Cloud, qu’il soit public ou privé, permet d’introduire davantage d’agilité. Les grandes entreprises déploient aujourd’hui beaucoup de IaaS privés, dans l’optique de capitaliser sur leurs compétences internes et leurs investissements en infrastructures. De son côté, le IaaS public est mis en œuvre de façon très ciblée, par exemple pour une filière web, ou dans une logique de « bac à sable ».

Pour autant, grâce à la consolidation à grande échelle, c’est le modèle public qui permet d’obtenir les gains fonctionnels et financiers les plus importants. C’est pourquoi les stratégies de déploiement de IaaS privés sont ou doivent être considérés comme une étape sur une trajectoire plus ou moins long terme de généralisation d’IaaS public.

Un avenir qui promet plus d’innovation et de valeur ajoutée

La 1ère phase d’adoption du Cloud est motivée par la recherche d’économies et l’optimisation du niveau d’agilité. Ces prochaines années, le marché devrait évoluer pour offrir des solutions avec une valeur ajoutée de plus en plus forte, pour répondre à la fois aux offreurs en quête de relais de croissance et aux entreprises utilisatrices souhaitant optimiser leur marge en se recentrant sur leur cœur de métier.

Le SaaS devrait s’imposer dans les entreprises comme le choix par défaut. Les éditeurs de logiciels vont proposer de manière systématique leurs solutions en mode SaaS, en partenariat avec les fournisseurs IaaS. Ils s’assureront ainsi des revenus constants et proposeront à leurs clients des services très industrialisés, flexibles et au meilleur coût.

L’usage du PaaS devrait exploser lorsque les problématiques de portabilité des applications, bien souvent surestimées, seront résolues. Il devrait alors devenir le socle d’exécution par défaut de toutes les applications qui ne seraient pas consommées en SaaS. Ces plateformes vont s’enrichir pour fournir aux développeurs un maximum d’accélérateurs et de nouvelles possibilités (composants et connecteurs pré-packagés, services de sécurité, réseaux de distribution de contenus… ) et donc en faire un choix par défaut dans les filières de développement.

Par ailleurs, les éditeurs de progiciels devraient rapidement proposer leurs solutions en mode pré-packagé pour les plateformes PaaS du marché. Le IaaS devrait perdurer pour adresser des besoins applicatifs très spécifiques. Mais il ne permettra pas d’aller chercher toutes les économies d’échelle d’une approche Cloud.

 Ce sont le SaaS et le PaaS qui porteront le marché demain.

Cet article Le Cloud : quelle réalité marché derrière les nuages ? est apparu en premier sur RiskInsight.

Un schéma directeur IT au service de la transformation de votre entreprise !

Démarche stratégique, un schéma directeur  vise à mettre en cohérence une large palette de problématiques opérationnelles, thématiques et économiques afin de définir la vision cible à long terme (généralement 5 ans) du SI. Il existe différents types de schémas directeurs mais tous se doivent de traiter des sujets tels que les orientations stratégiques, l’évolution du budget informatique, l’organisation, la gouvernance du SI et bien entendu les différents aspects techniques liés au SI.

Or, tout projet de transformation, y compris ceux répondant à des problématiques métiers pures, a des impacts sur les infrastructures et les socles logiciels du SI. L’automatisation d’un processus métier ou l’évolution d’une application métier implique ainsi des mises à jour plus ou moins profondes des infrastructures ou des socles sous-jacents (mise à jour du système d’exploitation par exemple). Poussées par une logique émergente de centre de profits, certaines DSI prennent même les devants. Elles repensent leur existant à l’occasion d’un schéma directeur infrastructures pour redéfinir leur  fonctionnement, leurs infrastructures et leurs socles logiciels tout cela dans une cible cohérente en vue d’améliorer le service rendu, leurs coûts et préparer l’avenir.

Un schéma directeur IT aux gains multiples

La définition d’une cible pour les infrastructures et de sa trajectoire associée dans le cadre d’un schéma directeur infrastructures est porteuse de différents types de gains.

Tout d’abord, il y a les gains techniques et opérationnels : la rationalisation des briques de base du SI et l’adoption de standards apportent un meilleur service avec une moindre variété de solutions ; un catalogue de solutions mieux défini permet de concevoir plus simplement les architectures avec une meilleure garantie de services. C’est là aussi par conséquent l’occasion de proposer des solutions techniques innovantes aux projets et aux Métiers.

Bien entendu, autres gains non négligeables, la problématique des coûts ! Pourquoi ? Ne serait-ce que parce que les coûts liés à l’obsolescence peuvent dépasser les coûts d’investissement annuels de remplacement des infrastructures : traiter cela, c’est déjà dégager de nouvelles marges de financement. Sans compter que le schéma directeur apporte une meilleure visibilité et une meilleure anticipation des investissements. Enfin, en rationalisant les infrastructures, on réduit la variété des solutions et ainsi le nombre de fournisseurs avec à la clé une possible massification des commandes.

Les gains humains ne sont pas non plus en reste. Mettre en place une trajectoire d’évolution des infrastructures peut être l’opportunité d’une nouvelle organisation mettant en valeur les compétences des différents acteurs. Elle est aussi l’occasion de communiquer auprès des équipes et d’insuffler une nouvelle dynamique autour d’un projet fédérateur, porteur de perspectives.

Quelques clés pour réussir son schéma directeur IT

 La crédibilité d’un schéma directeur dépend en grande partie de sa pertinence et celle-ci ne peut être garantie sans avoir pris en compte les réalités de l’entreprise. Différentes approches sont possibles et une méthodologie telle que SOI (Service Oriented Infrastructure) offre un cadre d’analyse et de formalisation permettant une approche structurée et exhaustive des composants du SI.

Si la participation des différents acteurs (du SI comme des métiers) est fondamentale, deux travers sont à éviter : aborder cette démarche comme un audit ce qui fausserait la collecte d’informations ou l’effet « lettre au Père Noël » où chacun liste ses souhaits et s’attend à les voir exaucés.

La définition d’une cible d’évolution du SI est finalement  toujours un compromis entre différents facteurs tels que l’existant, les besoins et les souhaits recueillis, la stratégie de l’entreprise dans sa globalité, l’état de l’art et les bonnes pratiques sans oublier la capacité à réaliser les changements notamment sur les plans budgétaires, techniques et humains.

La dernière étape d’un schéma directeur consiste à formaliser cette trajectoire de transformation à travers différents chantiers, à les coordonner dans une perspective temporelle en y intégrant les aspects budgétaires, humains ainsi que les contraintes métiers et projet. La validation du plan de transformation doit se faire à haut niveau (DG, DSI…). Parmi les différents chantiers, il en est un stratégique qui doit ouvrir et fermer la marche : la gouvernance de l’implémentation du schéma directeur. En effet, elle en assure le pilotage, la cohérence, permet d’en assurer le rythme et gère l’adaptation de l’ordonnancement des chantiers et de leurs projets.

Le changement, c’est maintenant !

Avez-vous le choix aujourd’hui de ne plus toucher aux infrastructures de votre SI pendant les 5 ans à venir ? Le carrousel des technologies combiné avec l’évolution de l’entreprise ne le permettront pas. Un schéma directeur infrastructures est l’occasion de reprendre le contrôle de l’évolution des éléments fondamentaux du SI, de ses niveaux de service et de ses coûts mais c’est aussi une formidable opportunité de dynamiser et de fédérer des équipes souvent plongées dans l’opérationnel au quotidien. Il est nécessaire de s’inscrire dans une nouvelle hygiène de gestion proactive des infrastructures du SI afin de garantir l’adaptation permanente du SI aux besoins et à l’évolution de l’entreprise.

Cet article Pour mettre sous contrôle durablement les fondations de votre SI, pensez schéma directeur IT ! est apparu en premier sur RiskInsight.

Le datacenter d’hier à aujourd’hui

Le modèle de datacenter traditionnel est divisé en 3 couches de service. Tout d’abord, il y a l’hébergement, qui intègre la fourniture d’énergie électrique / de climatisation, les raccordements « réseau » et « télécom », sans oublier la sécurité physique. La 2^ème couche est l’infrastructure qui comprend de son côté les infrastructures mutualisées (réseau, stockage, sécurité, sauvegarde…) et les serveurs dédiés aux applications. Enfin, la dernière couche est celle de l’infogérance : MCO*, administration, suivi des niveaux de services…

Les datacenters consolidés et externalisés tels que nous les connaissons sont nés de 2 grandes mutations :

• Le passage de salles informatiques décentralisées et dont la sécurisation des accès est faible vers des datacenters consolidés a d’abord permis de mieux répondre aux besoins croissants d’hébergement et de sécurité tout en réduisant les coûts du fait de la rationalisation des moyens humains et matériels.
• L’accélération de la croissance des besoins d’hébergement (capacité et disponibilité des infrastructures primaires) et du cycle de vie des applications ainsi que la volonté des grands groupes de se recentrer sur leur cœur de métier ont ensuite généré  l’externalisation des services d’hébergement et infogérance.

Les limites du datacenter actuel

Aujourd’hui, le datacenter traditionnel peine parfois à satisfaire les besoins des grands groupes.

Les coûts et les délais d’activation de nouveaux services sont importants. Le service d’opérations n’est plus suffisamment agile pour répondre aux exigences de flexibilité demandées par les Métiers.

Par ailleurs, la gestion en interne du socle IT force les DSI à s’engager à long terme sur leurs choix de technologies et à conserver en interne les compétences ad hoc. Dans ce contexte de réduction des coûts, ce modèle consommateur de CAPEX ne permet pas aux DSI d’atteindre leurs objectifs.

Enfin, l’évolution, toujours plus grande difficilement prévisible, des besoins d’hébergement rend difficile le dimensionnement des datacenters qui sont conçus pour une durée de 10 à 15 ans.

Des services clouds qui dépassent ces limites…

Le Cloud computing est pour ainsi dire l’évolution du modèle de datacenter traditionnel vers une approche orientée service. Le client commande des ressources packagées sous la forme d’un service (IaaS, PaaS ou SaaS) et ne se préoccupe pas des technologies qui les supportent.

Il est plus souvent vendu sous forme de Cloud privé, infrastructure dédiée dont l’usage est exclusif à une organisation, ou sous forme de Cloud public, infrastructure mutualisée et ouverte à tous.

Le Cloud, de par ses caractéristiques, semble en effet plus apte à répondre aux attentes des DSI, car il s’avère :

• Agile : le cycle d’activation des nouveaux services est court, de l’ordre de quelques heures à comparer à 3 ou 4 semaines pour le datacenter traditionnel (possible réduction des délais avec la virtualisation)
• Élastique : la capacité du SI s’adapte à la demande du client donnant l’impression d’infini
• Simple à gérer : l’approche « unité d’œuvre » permet de transférer la complexité technique et financière du SI au fournisseur. De plus, la facturation à l’usage optimise les coûts du service
• Conçu dans l’optique de qualité de service grâce à la standardisation de son modèle

… sans pour autant être illimités eux-mêmes !

Certes standardisées et performantes, les offres Cloud nécessitent souvent une adaptation préalable du client, qui peut se révéler coûteuse et chronophage. Aujourd’hui seuls des périmètres standardisés du SI s’avèrent de fait éligibles au Cloud. Cette éligibilité restreinte, ainsi que la complexité accrue pour rendre les SI interopérables, pouvant au final faire du Cloud un élément complexifiant le SI plus qu’il ne le simplifie. Par ailleurs, la capacité du Cloud à respecter les contraintes de confidentialité et de localisation des données imposées par les réglementations (données personnelles…) pose encore question.

Enfin, la perte de la maîtrise du SI en interne de bout en bout inhérente au Cloud effraie beaucoup les DSI. La dépendance au fournisseur est grande et la réversibilité est encore floue.

Quels services de datacenter pour demain ?

Malgré les freins qui sont inhérents au Cloud et à anticiper, du fait de ses nombreux avantages, ce dernier se développe, même si principalement sous forme « privée » ou sur des périmètres restreints. La mouvance vers le Cloud passera par deux étapes.

Dans un premier temps, le mouvement va préférentiellement s’opérer du datacenter traditionnel vers le cloud privé, qu’il soit interne ou externe. Ce mouvement sera naturel dans le cas des services infogérés externes, notamment par l’évolution des contrats vers une approche orientée service. Pour les datacenters internes, il sera provoqué par les pressions des Métiers sur la DSI pour l’implémentation d’un service moins coûteux et plus lisible. Ces premières implémentations participeront à la levée des freins à l’adoption du cloud, ce qui permettra le développement du Cloud public dans un second temps.

Même si le cloud risque de faire perdre des parts de marché au datacenter traditionnel, l’avenir n’est pas à la disparition mais à la cohabitation. De son côté, le datacenter traditionnel restera présent pour les infrastructures spécifiques (Mainframe ZOS, AS400…) ou dans le cas d’un SI très spécifique. Le Cloud privé quant à lui sera exploité dans le cas de SI standards ou standardisables mais contenant des données stratégiques. Enfin, le Cloud public fera loi dans le cas de SI standards ou standardisables dont les données manipulées sont non stratégiques et non confidentielles et dont le besoin d’intégration avec les infrastructures hors du Cloud est faible.

Cet article Datacenter contre cloud computing : mort programmée de l’hébergement en datacenter « traditionnel » ? est apparu en premier sur RiskInsight.

Le contexte ambiant laisse du reste peu de place à l’anticipation… Les DSI doivent assurer les transformations du SI dans des délais toujours plus courts. Un nouveau marché peut être gagné, un nouveau besoin métier émerger sans que la DSI n’ait beaucoup de temps pour étudier les impacts sur le SI existant et mettre en œuvre la solution adéquate. Comment par exemple absorber en quelques mois une augmentation de 100% du volume de données traitées et faire face à des problématiques de scalabilité horizontale et verticale ? En voici quelques clés.

Gagner du temps en conjugant  les solutions techniques du marché

Le Cloud public est séduisant sur le papier, la scalabilité étant assurée par l’hébergeur du service. Cette solution est du reste à privilégier pour des services ayant peu de dépendances avec d’autres applications du SI (application RH, gestion de trésorerie…). La migration de la totalité d’un SI vers ce type d’offres, sans déjà posséder un Cloud hybride, s’avère en effet très difficile dans des délais serrés.

Les solutions intégrées, de leur côté, incluant à la fois le matériel et le logiciel, sont pertinentes lorsque le parc applicatif (serveur d’applications ou bases de données) est homogène et que le besoin de montée en capacité concerne plusieurs applications. L’investissement est bien sûr conséquent et le choix structurant pour le SI, mais le gain de temps n’est pas négligeable lors de la mise en œuvre. De plus, ces solutions comportent des mécanismes permettant d’activer de la puissance supplémentaire à la demande, ce qui laisse plus de souplesse pour effectuer le dimensionnement initial des infrastructures.

La virtualisation est pour finir une solution plus adaptée en présence d’un parc applicatif hétérogène et fractionné. Les mécanismes fournis par les éditeurs, notamment la copie de machine virtuelle, sont des accélérateurs pour la création des différents environnements d’une même application. La montée en charge des systèmes est quant à elle facilitée grâce au mécanisme permettant d’ajouter de la mémoire et des processeurs virtuels en quelques clics. Le rajout d’un nouveau nœud dans un cluster existant reste également une opération simple et maîtrisée par les exploitants. La virtualisation est en un mot de loin la solution privilégiée par les clients devant faire évoluer un existant.

Anticiper et sécuriser la transformation grâce au capacity management

La souplesse et les gains de temps offerts par les solutions présentées précédemment ne doivent pas faire oublier l’importance d’évaluer les besoins en capacité et performance.

Les services sollicitant fortement les processeurs ou la mémoire (bases de données à forte volumétrie, batchs, calculs scientifiques…) ne sont pas les candidats idéaux pour la virtualisation. Il faudra donc dimensionner les futurs serveurs physiques exécutant ces applications avec minutie.

Concernant les chantiers de refonte du SAN et du cœur LAN, notre marge de manœuvre est également réduite, ces éléments centraux étant difficilement évolutifs sans impacter la production. Le capacity management s’avère dans ce cas indispensable pour déterminer si ces équipements doivent être remplacés pour supporter la montée en charge du SI.

In fine, face à des délais serrés, la capacité à s’appuyer et à conjuguer les solutions technologiques du marché  et la connaissance de son parc matériel au travers du capacity management sont les leviers clés pour augmenter sereinement la capacité du SI.

Pour autant, il est essentiel de garder en tête que nul chantier ne peut être mené à bien sans l’implication et la fédération des acteurs aussi bien IT que Métiers qui doivent travailler ensemble à la réussite de ce projet. Pour relever le défi c’est bien ce triptyque gagnant qu’il faut mettre en œuvre.

Cet article Doubler les capacités du SI en 6 mois : prêts à relever le défi ? est apparu en premier sur RiskInsight.

Le cloud public, moins cher mais non nécessairement moins sécurisé, commence à séduire ces mêmes comptes et non plus seulement les TPE et PME, notamment pour des environnements non critiques ou demandant une forte agilité.

Et si l’’avenir n’était pas le cloud, mais les clouds ?

La proposition de valeur du cloud hybride

Chaque modèle de déploiement (privé, privatif, public) a ses avantages (personnalisation et contrôle des données dans le cloud privé, prix et scalabilité dans le cloud public) et ses inconvénients (coûts d’investissement pour le privé, moindre contrôle des données dans le public). Le cloud hybride consiste en l’utilisation de plusieurs clouds afin d’en maximiser les bénéfices selon les besoins de l’entreprise.

Parmi les grands cas d’usage de l’approche hybride, l’on retrouve :

• La répartition d’applications sur plusieurs clouds suivant leurs besoins (criticité des données, élasticité et agilité, etc.) permettant de profiter du « meilleurs des deux mondes ». L’entreprise pourra par exemple utiliser un cloud public pour des environnements web faiblement couplés au SI et un cloud privé pour des environnements hébergeant des données métiers critiques. Il s’agit du cas d’usage le plus fréquemment rencontré.
• Le « cloud burst » permettant d’absorber des pics de charge en faisant déborder son infrastructure privée vers un cloud public ou privatif. Cela permet notamment de compenser l’élasticité moindre du cloud privé pour des besoins ponctuels.
• La répartition des tiers d’une application : les couches applicatives et base de données hébergées dans un cloud privé tandis que la couche de présentation sera sur un cloud public (elle ne gère pas de données critique et requiert une forte élasticité)
• L’optimisation des coûts et les performances en utilisant plusieurs fournisseurs de cloud public et en choisissant, en temps réel, le plus avantageux.

Cependant, sans un bon outillage, les coûts induits par la gestion de plusieurs clouds peuvent constituer un réel frein à l’adoption.

Comment piloter un cloud hybride ?

Le Cloud management platform (CMP) fournit à la DSI une interface de gestion unifiée vers de multiples fournisseurs de cloud.

Si de nombreux  outils existent, deux grandes approches se distinguent :

1 – L’approche « Open » : liberté et réversibilité

Cette approche se base sur l’utilisation de plate-formes de gestion de cloud privé comme le très en vogue OpenStack (mais aussi Cloudstack ou Eucalyptus) permettant l’extension de son infrastructure sur un Cloud Public, ou sur des solutions logicielles comme Scalr ou Dell Multi-Cloud Manager (ex-Entratius). Une entreprise pourra ainsi bénéficier d’une grande liberté dans le choix des clouds à piloter (et de fait d’une meilleure réversibilité), tout en limitant ses investissements et en gardant une certaine souplesse dans la personnalisation de l’outil.

Cependant sa complexité de mise en œuvre peut parfois être un frein au déploiement et grever le TCO (total cost of ownership) de la solution (coûts OPEX d’ingénierie notamment). D’autre part, la sécurisation de cette solution, partiellement ouverte sur internet (pour piloter un ou plusieurs clouds publics) reste à la charge de l’entreprise, ce qui pourra refroidir les responsables de la sécurité.

La solution de simplicité pourra alors se trouver dans l’approche « constructeur ».

2 – L’approche « Constructeur » : extension de l’hyperviseur et de son outil de gestion

On a pu voir ces derniers mois de grands constructeurs comme Microsoft et VMware ouvrir leurs Clouds publics et dévoiler leur stratégie : proposer à leurs clients utilisant leur hyperviseur (respectivement Hyper-V et vSphere) de basculer de façon transparente sur leur cloud public ou celui d’un tiers.

Il s’agit pour l’entreprise de s’appuyer sur son existant, sans déploiement supplémentaire et sans bouleverser son organisation. Elle bénéficie de nouvelles fonctionnalités tout en préservant une sécurisation forte.

Cependant le risque de « Lock-in » chez un constructeur n’est pas neutre et la réversibilité sera nécessairement plus difficile qu’avec un outil indépendant. De plus les coûts d’utilisation du cloud public seront souvent plus élevés et les besoins spécifiques de l’entreprise (la personnalisation de l’outil) plus difficiles à faire passer.

S’outiller pour anticiper les changements futurs

L’usage du cloud par les entreprises, dans une stratégie hybride, va se généraliser dans les années à venir, et les changements induits sont multiples. Il est donc nécessaire de les anticiper et de s’y préparer. Pour cela, il est important pour l’entreprise de commencer à aligner ses processus et à réfléchir à sa stratégie d’outillage.

Cependant les outils de pilotage unifiés étant encore peu matures, seules les entreprises allant très fortement vers le cloud ont intérêt à s’outiller immédiatement (pour éviter une explosion de leurs coûts d’opérations). Les entreprises moins pressées, elles, pourront attendre que les outils soient plus mûrs et se limiter pour l’instant à une veille active.

Dans tous les cas réfléchir à sa stratégie d’outillage n’est plus une option, il s’agit de préparer l’avenir !

Cet article Quelles vertus au Cloud hybride ? est apparu en premier sur RiskInsight.

Le Cloud impose-t-il une évolution forcée ?

Le Cloud simplifie l’accès à l’outil informatique en focalisant l’énergie de l’utilisateur sur le choix du service plutôt que sur la démarche de mise en œuvre. Cette facilité d’accès à des services « clé en main » peut inciter les Métiers de l’entreprise à traiter directement avec les offreurs Cloud sans impliquer la DSI. Pour contrôler l’adoption des services Cloud, la DSI doit devenir un acteur incontournable de ses Métiers : non pas en s’imposant mais bien devenant un partenaire légitime du Métier, apporteur de valeur ajoutée aux services Cloud.

Une priorisation des chantiers nécessaire

Le Cloud n’est pas qu’un outil technique à destination de la DSI seule. Il est essentiel de mettre en place sa stratégie Cloud en impliquant la Direction de l’entreprise pour prendre en compte l’existant et les besoins à venir, en déduire le périmètre éligible et enfin choisir ses modèles de sourcing (Public et/ou privé) et le type de Cloud (IAAS, PAAS et/ou SAAS) adapté aux cas d’usage. Deuxième étape pour la DSI : promouvoir cette stratégie auprès des Métiers avec ses sponsors en valorisant les apports de la démarche et en éclairant les contraintes liées à son utilisation.

A ce stade la DSI devra choisir entre 2 positionnements :

1) Un accès direct des métiers aux fournisseurs Cloud

La DSI ne porte pas la responsabilité du choix des fournisseurs mais apporte son expertise sur les dimensions :
•    Contractuelles, en mettant à profit l’expérience de la DSI pour définir les engagements en matière de niveau de service, de traçabilité, de pilotage des coûts…
•    Techniques, en accompagnant les projets sur l’intégration des services Cloud dans le SI de l’entreprise tout en respectant les contraintes internes de sécurité et d’échanges de données
•    Légales, en apportant sa connaissance des contraintes liées à l’hébergement des données (données personnelles, données sensibles d’entreprise, législation française, contraintes sectorielles…)
•    De réversibilité technique et opérationnelle, pour préparer en amont le désengagement d’un fournisseur.

2) Une DSI « broker de Cloud »

La DSI se positionne comme l’interlocuteur unique à la fois du Métier et des fournisseurs Cloud.  Le rôle d’expertise reste d’actualité et voit son périmètre étendu par une fonction de gestion des  relations clients et fournisseurs. La DSI est alors en responsabilité :
•    D’intégrer des services Cloud technique ou métier au catalogue de la DSI
•    De piloter et de garantir la qualité des services exposés par la DSI
•    De définir et de mettre en place les outils permettant une intégration au SI des services Cloud (IAM, échanges, service management…)
•    De faire évoluer ses processus internes pour fournir un service utilisateur unifié indépendamment des modes de sourcing
•    Et bien sûr, de fournir ces services Cloud au meilleur coût du marché à ses utilisateurs !

Bien que la stratégie de positionnement soit à définir suivant le contexte particulier de chaque entreprise, une majorité aura intérêt à adopter un positionnement « broker de Cloud ». Ce positionnement permettra de définir une stratégie IT globale cohérente entre les besoins internes et les possibilités offertes par les fournisseurs. Elle permettra ainsi de tirer toute la valeur économique et qualitative d’une approche Cloud par le biais d’achats massifiés et intégrables de manière standardisée au SI.

Les « temps métiers » et les « temps IT traditionnels» n’ont plus la même échelle, le Cloud est un des vecteurs de transformation qui permet de contribuer à la performance globale de l’entreprise. Néanmoins, pour combler ce décalage, la DSI doit être en perpétuelle transformation pour fournir les moyens nécessaires aux ambitions de l’entreprise.

Cet article Le Cloud computing : vers une DSI orientée service ? est apparu en premier sur RiskInsight.

Le pilotage économique : une problématique à dimensions multiples

Le pilotage économique ne doit pas se limiter à un exercice comptable, consistant à définir les modalités de refacturation des coûts aux clients. Il est nécessaire de considérer plusieurs dimensions : la structuration de l’offre de services, le modèle de costing et de pricing sans oublier la mise en place de nouveaux rôles pour piloter de manière cohérente la performance économique et opérationnelle.

Si la mise en œuvre de chaque dimension peut se faire de manière indépendante, elles doivent être pensées globalement pour des raisons de cohérence et de synergie. Sans cela, difficile d’imaginer une réconciliation possible des visions DSI et contrôle de gestion !

Comment structurer l’offre de services de la DSI ?

Qu’il s’agisse d’une DSI groupe, qui a comme clients des « DSI métiers », ou d’une DSI métier qui a comme clients des « Métiers », l’une des premières étapes est la définition et la formalisation de son offre de services.

Si une telle démarche n’est pas nouvelle et se développe depuis quelques années, commence à émerger une certaine « standardisation » dans le découpage des familles et sous-familles de services.

Au total, on peut généralement dénombrer une cinquantaine de services sur l’ensemble du périmètre de la DSI, hors applications, lesquelles compte-tenu de leur nombre, sont souvent listées en dehors du catalogue et classées par domaine fonctionnel ou par profil utilisateurs.

L’intérêt de présenter au métier un tel découpage est double :

• Pédagogique : faire comprendre les différentes couches qui interviennent dans la production des services, notamment les couches techniques qui sont les moins visibles (pour expliquer les montants facturés). Exemple, le prix du poste de travail qui est constitué à la fois :
  – du matériel et des logiciels bureautiques (partie visible du client) ;
  – mais également des serveurs bureautiques et de la sécurité, avec les prestations d’administration associées.

• Modulaire : laisser la possibilité de souscrire à une partie seulement des services, lorsque le métier fait déjà intervenir d’autres fournisseurs.

Méthode ABC : des limites…

L’approche la plus connue est la méthode ABC (Activity Based Costing). Elle consiste à répartir l’ensemble des charges (« les ressources ») sur les processus opérés par la DSI (« les activités ») et sur les différents services délivrés par la DSI. L’allocation des coûts au travers du modèle repose sur la définition d’inducteurs ou « cost drivers ».

L’inducteur est une mesure qui reflète les variations d’intensité d’une activité, il tend à faire le lien entre son coût et ses caractéristiques opérationnelles. Le choix des inducteurs au sein du modèle doit à la fois répondre à des contraintes de faisabilité et avoir du sens d’un point de vue métier, ce qui peut nécessiter quelques concessions pour garantir l’exploitabilité opérationnelle du modèle.

Mais outre la complexité de mise en œuvre et la lourdeur liée à son administration opérationnelle, les principales limites du modèle sont les suivantes : la refacturation des services à leur coût de production d’un côté, la facturation a posteriori des clients (ce dernier point explique en grande partie l’insatisfaction des métiers par rapport à la DSI, qui est souvent considérée comme insuffisamment performante et trop coûteuse).

… à dépasser !

Il existe une autre approche, qui sans complètement remettre en cause la démarche ABC, est plus facile à mettre en place et répond davantage à des besoins de benchmarks.

Il s’agit de facturer le maximum de services aux « prix du marché ». En effet, pour une majorité des services présents au catalogue, il est possible d’afficher un prix d’unité d’œuvre (UO) en cohérence avec ce qui est pratiqué sur le marché.

Cela concerne essentiellement les services aux utilisateurs et les services techniques, pour lesquels les UO et les prix unitaires associés tendent à se standardiser. Seuls les services applicatifs relatifs aux applications développées en spécifique continueront à faire l’objet d’une refacturation au coût de production. La part des services concernés pourrait cependant se réduire avec le temps, en raison du développement des applications en mode cloud.

Cette démarche permet ainsi à chaque client, en travaillant en collaboration avec la DSI, d’anticiper beaucoup plus facilement la traduction de toute décision business sur son budget IT. La compréhension de l’offre de services, avec une grille tarifaire claire (un prix unitaire par UO), permet d’estimer la facture globale à partir des quantités prévisionnelles de chaque service.

Cet article Comment réussir le pilotage économique de la DSI ? est apparu en premier sur RiskInsight.

Des offres PaaS de 1ères générations à faible maturité…

Les premières offres PaaS, lancées en 2010, constituaient une proposition souvent :

• Limitée, avec un nombre restreint de langages de programmation et d’environnements d’exécution supportés.

En exemple, les premières versions du PaaS Heroku (de SalesForce) supportaient uniquement le langage Ruby; le PaaS Cloudfoundry.com (de Pivotal) supportait uniquement les langages Java et  Ruby.

• Intrusive, avec une adaptation / réécriture de l’application presque systématique.

Nous pouvons prendre l’exemple d’Amazon qui propose le service SGBD (système de gestion de base de données) spécifique  SimpleDB ou Google qui propose le service propriétaire Google’s Big Table sans oublier leur moteur d’exécution propriétaire : « Google App Engine ».

• Verrouillée (lock-in éditeur), avec un manifeste désintérêt pour l’interopérabilité et la portabilité entre les différentes offres et une volonté des éditeurs d’imposer leurs propres standards.

… et ne couvrant que partiellement les besoins réels des entreprises

Les PaaS de 1ères générations offraient des services peu adaptés aux besoins complexes des entreprises. Au-delà des limitations techniques (citées précédemment), on a pu regretter que ces premiers PaaS :

• Proposent une offre de services incapables de répondre aux exigences et contraintes demandées respectivement par les études et la production et ce notamment en termes de SLAs (confidentialité des données, traçabilité, etc.)

• Impliquent une réversibilité complexe en cas de changement d’offres ou d’internalisation des applications (souvent d’ailleurs pas proposée par les fournisseurs de ces offres).

• Répartissent de manière floue les rôles et responsabilités entre le fournisseur de services et le client.

• Aient une présence limitée de support en France, pourtant nécessaire à l’accompagnement des projets.

Un repositionnement efficace des fournisseurs PaaS

Face au manque d’adhésion des PaaS de 1ères générations, de nouvelles offres ont émergé et un repositionnement a été opéré par les fournisseurs. La nouvelle génération s’aligne enfin avec les vraies attentes des entreprises. Les initiatives en cours s’orientent vers des offres :

• Polyglottes (multi langages) et multi-plate-formes

Salesforce a par exemple enrichi son offre Heroku par le support de nombreux langages (Ruby, PHP, JavaScript, Java), ou encore Cloudfoundry.org supporte maintenant plusieurs langages et frameworks de développements comme  Java, .Net, Ruby, PHP, Python, Scala.

• Spécialisées par cas d’utilisation

En exemple, Cloudbees propose deux offres complémentaires :

– Une offre destinée au développement, où l’unité de facturation est le nombre de build opéré.
– Une offre destinée à l’exécution, où l’unité de facturation est une configuration de la mémoire disponible pour l’application

• Sensibles aux normes et standards (en cours de spécification)

Plusieurs initiatives de standardisation sont en cours sur le périmètre PAAS. Nous pouvons noter en exemple : CAMP, TOSCA ou encore Cloud Foundry Core.

Un virage à prendre ?

Contrairement à une adoption généralisée des services SaaS (déjà utilisés en entreprise depuis une dizaine d’années) et facilitée pour les services IaaS (entreprises ayant généralement atteint un niveau de virtualisation assez poussé pour faciliter le passage vers le modèle IaaS), les entreprises optent pour une attitude prudente vis-à-vis des services PaaS, privilégiant une stratégie d’adoption à deux vitesses :

• Une adoption immédiate des offres PaaS pour des :

– Applications non cœur de métier ;
– Applications non pérennes (jetables) ;
– Prototypes ;
– Bacs à sable innovants.

L’idée est de favoriser des solutions non limitatives en termes de technologies.

• Une adoption après études d’opportunités, choix de solutions et prototypage pour les applications cœur de métier.

Références

Études : Net MediaEurope (Juin 2012),

Normes et standards

• CAMP – https://www.oasis-open.org/news/pr/camp-tc
• TOSCA – https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=tosca
• CF Core – http://core.cloudfoundry.org/definition

Offres

• Heroku – https://www.heroku.com/
• Cloud Foundry – http://www.cloudfoundry.com/
• SimpleDB – http://aws.amazon.com/fr/simpledb/
• Google App Engine – https://appengine.google.com/
• Cloudbees –  http://www.cloudbees.com

Cet article Le PaaS, une solution d’avenir. Comment franchir le pas ? est apparu en premier sur RiskInsight.

L’efficience de cette transformation, et donc par extension la sobriété énergétique des datacenters est, depuis quelques années déjà, un enjeu majeur, plaçant le  green datacenter sur la plus haute marche de maturité du green IT aujourd’hui.

Green datacenter : le règne sans partage du PUE serait-il arrivé à échéance ?

Le PUE ou Power Usage Effectiveness est le principal indicateur utilisé pour mesurer le rendement énergétique d’un datacenter en effectuant le rapport entre la consommation électrique totale et la consommation des équipements informatiques.

Son utilisation s’est largement répandue, amplifiée par des objectifs de marketing et de communication, ce qui a permis de mettre l’industrie du datacenter sur la voie de l’efficacité énergétique. Cependant, il présente encore plusieurs limites :

• Il se concentre sur l’efficacité énergétique mais néglige d’autres aspects qui entrent dans l’évaluation d’un green datacenter comme les émissions de gaz à effet de serre ;
• Il reste souvent théorique, son calcul se basant sur la charge maximale de l’installation, ce qui est rarement le cas au lancement ou pendant les premières années d’exploitation de celle-ci ;
• Enfin, lorsqu’il est mesuré, il ne l’est pas toujours de manière homogène (pas de distinctions en termes de disponibilité ou d’emplacement géographique). Par conséquent, un site offrant une très haute disponibilité verra son PUE pénalisé par la redondance de ses équipements techniques.

Le PUE n’est donc aujourd’hui plus suffisant pour évaluer l’impact environnemental d’un datacenter et l’est encore moins pour comparer des datacenters sur ce critère.

Sur quels nouveaux indicateurs évaluer le Green Datacenter ?

Pour mesurer la durabilité d’un datacenter, tout son impact environnemental doit être pris en compte. Le consortium « The Green Grid » à l’origine du PUE, a ainsi validé la définition de trois nouveaux indicateurs pour mieux évaluer cet impact :

• Le Carbon Usage Effectiveness (CUE) mesure les rejets de CO₂ associés à un datacenter, permettant de prendre en compte son impact environnemental et pas seulement énergétique (ex : les rejets liés aux tests de groupes électrogènes diesel) ;
• Le Green Energy Coefficient (GEC) définit le pourcentage d’énergie renouvelable utilisée par le datacenter. Il complète le PUE, en apportant des informations sur la façon dont l’électricité consommée est produite.
• Le Energy Reuse Factor (ERF), permet de mesurer la quantité d’énergie réutilisée à la sortie d’un datacenter, qui peut prendre plusieurs formes, comme la réutilisation de la chaleur dégagée par exemple. Cette énergie était parfois abusivement intégrée dans la mesure du PUE, donnant des résultats incohérents (PUE<1).

L’ambition derrière l’adhésion de la communauté autour de ces indicateurs est d’encourager leur adoption pour faire de l’efficacité environnementale un composant central de la définition du datacenter de demain.

Et si le futur des datacenters était le green cloud ?

L’énergie IT produite par les datacenters est de plus en plus consommée en mode cloud pour s’adapter aux demandes des utilisateurs de services disponibles 24h sur 24, partout dans le monde.

Cela représente aussi un avantage d’un point de vue écologique. En effet, les indicateurs décrits permettent de mesurer et donc d’améliorer unitairement l’efficacité d’un datacenter.

Avec les opérateurs cloud globaux, les datacenters sont mutualisés. En utilisant des équipements et des logiciels adaptés, il est donc possible de rationaliser et répartir plus efficacement les ressources à une nouvelle échelle pour produire ces services au meilleur coût, y compris environnemental. À titre d’exemple, Google estime qu’une entreprise utilisant leurs solutions Cloud Google Apps réaliserait une économie de l’ordre de 65% à 85% d’énergie par rapport à la fourniture en propre de services équivalents.

Dans une situation économique qui reste difficile, le Cloud computing peut représenter une réponse crédible à la fois aux enjeux de développement et aux enjeux de responsabilité environnementale des entreprises, à condition de réussir son intégration dans leurs écosystèmes IT.

Pour en savoir plus sur le cloud computing.

Cet article Le cloud computing : avenir du green IT ? est apparu en premier sur RiskInsight.

Mettre en œuvre une architecture spécifique pour assurer la « libération » des données

À  l’heure d’ouvrir ses données internes au grand public, l’administration ou l’entreprise se doit de mener une réflexion sur les données qu’elle souhaite ou non « libérer », sur les impacts juridiques de cette libération ou encore sur les conditions d’utilisation de ces données (mode de publication, licence d’utilisation éventuelle).

Mais elle doit également mesurer l’impact de cette libération de données sur son système d’information et réfléchir à l’architecture qu’il faut  mettre en œuvre afin de permettre :

• L’identification et l’extraction des données depuis les différents back-offices des domaines applicatifs ;
• La consolidation et le stockage en central de ces données ;
• Le traitement et le formatage de ces données pour assurer le niveau de qualité attendu ;
• La diffusion et la publication de ces données une fois traitées et remises dans un format exploitable et non propriétaire.

Réutiliser des  outils existants pour extraire et traiter les données

Après identification et sélection par chaque domaine applicatif des données utiles sur son périmètre, il convient au domaine de mettre en œuvre l’ensemble des règles de gestion permettant le filtrage et l’extraction de ses données avec le niveau de qualité attendu. Ces données sont alors transportées jusqu’à un « entrepôt » de stockage centralisé où elles sont consolidées, homogénéisées, (re)nettoyées et/ou formatées avant leur publication.

Pour l’ensemble de ces actions de filtrage, d’extraction, de transformation et de chargement des données, des outils déjà présents dans le SI peuvent être utilisés :

• Mutualisation des activités de sélection et d’extraction des données avec les outils de l’architecture décisionnelle ;
• Transformation et chargement des données via les ETL de l’entreprise ;
• Utilisation des outils de MDM (Master Data Management) pour les étapes de nettoyage et de formatage des données.

Maîtriser l’historisation pour rationaliser les volumétries traitées

Dès l’étape de stockage en central des données, il est tentant de mettre en œuvre des mécanismes d’historisation des données afin de garder une trace des différents états de l’entrepôt de données. Cependant cette option, dont le besoin n’est pas toujours justifié, a un impact réel sur la volumétrie et sur les traitements.

Aussi, une seconde stratégie très répandue consiste à remplacer les données par la dernière version dans l’entrepôt et à ne conserver un historique qu’au niveau de la publication, une fois toutes les étapes de transformation terminées.

Choisir le mode de publication en fonction du niveau de fraîcheur de données

Pour la plupart des données ouvertes publiées (horaires des transports par exemple), un haut niveau de fraîcheur n’est pas nécessaire. Aussi, la méthode de publication par fichiers est privilégiée car elle n’impose que peu de contraintes bien que certaines bonnes pratiques soient fortement conseillées :

• La limitation de la taille maximale des fichiers à quelques Mo afin de faciliter leur consommation par les utilisateurs ;
• L’utilisation de formats comme xHTML, XML ou JSON plutôt que CSV car ces formats peuvent être enrichis d’attributs sans conséquence sur les consommateurs.

Cependant, dans certains cas, où le niveau de fraîcheur des données attendu est trop important, le fonctionnement par fichiers se révèle insuffisant. D’autres méthodes plus complexes et onéreuses doivent alors être considérées. Ce sera notamment le cas pour les données « temps réel » (retards de trains…) pour lesquelles on privilégie l’exposition de services de consultation des données stockées dans l’entrepôt (Web services SOAP, services REST…)  ou encore pour les données nécessitant la mise en œuvre de service de visualisation avancée (géolocalisation…).

Sélectionner le mode d’hébergement de la plate-forme de publication en fonction des enjeux d’isolation et de scalabilité

La plate-forme de publication des données ouvertes étant accessible au public, elle doit être isolée du reste du SI pour des raisons de sécurité. Une nouvelle infrastructure est donc généralement à construire soit en interne, soit auprès d’un hébergeur externe.

De plus, comme il est compliqué d’anticiper le taux de consommation des données ouvertes publiées et donc le degré d’utilisation de la plate-forme, faire appel aux offreurs Cloud pour un tel hébergement est fréquent et favorise une plus grande scalabilité des plates-formes de publication.

Si l’Open data a pour vocation d’être l’un des principaux facilitateurs du développement de l’économie numérique, elle n’est pour autant pas sans conséquence sur l’architecture ou la sécurité du SI des producteurs de données. Alors, libérer les données ? Oui… mais à quel prix : l’entreprise dispose-t-elle des outils et offres nécessaires ? A-t-on bien mesuré la complexité de l’ouverture des données du SI ? Autant de questions à se poser pour considérer avec efficacité cette problématique.

Cet article L’Open data : quels enjeux pour le SI des producteurs de données ? est apparu en premier sur RiskInsight.

Mais si le transport du FCoE n’était pas le principal enjeu de la Fabric Ethernet, ce nouveau « super LAN » pour les Datacenters d’aujourd’hui ? En effet quels sont les drivers du marché actuellement ? Certainement pas FCoE mais plutôt le Cloud Computing et notamment dans ses déclinaisons « privées » !

Des infrastructures datacenter mises à mal par la tendance Cloud

C’est la démarche Cloud computing privé qui tire actuellement l’évolution des infrastructures datacenters en bouleversant les modèles établis et poussant à la fois  la mise en place de VLANs (Virtual LAN) étendus au travers du datacenter et des débits plus élevés entre chaque point du réseau. La matrice de flux et les débits au sein du datacenter ont changé radicalement, d’une part du fait de la consolidation serveurs engendrée par la virtualisation et, d’autre part, à cause de la mobilité des machines virtuelles au sein du datacenter.

Les constructeurs de solutions Cloud ont donc dû innover : contraints par des infrastructures LAN historiques très statiques et hiérarchiques, ils ont intégré des solutions permettant de s’affranchir des limites des LAN existants actuellement, tel le Distributed Virtual Switch de VMWare qui ajoute une couche d’abstraction au-dessus des LAN physiques.

Le Cloud a dû innover pour contourner les limites des LAN traditionnels et séduit par sa démarche basée sur l’automatisation et la souplesse.

Une évolution nécessaire pour répondre aux enjeux…

Le LAN du Datacenter ne doit donc plus rester statique et être un frein à la mise en œuvre d’infrastructures de Cloud.

L’enjeu de la Fabric Ethernet est ainsi double : non seulement le LAN doit être étendu sans contrainte de débit ou de localisation géographique des ressources dans le datacenter,  mais il doit également permettre d’apporter une exploitabilité bien supérieure.

Cette amélioration de l’exploitabilité passe par plusieurs éléments : une augmentation de capacité simplifiée (plug & play) et une automatisation de certaines opérations (application d’un profil de configuration sur le port LAN sur déplacement de machine virtuelle par exemple).

Surtout, on ne doit plus administrer un LAN datacenter boîte par boîte, ce qui est consommateur de temps et source d’erreurs.

Certains constructeurs LAN ont d’ores et déjà intégré cette nouvelle donne directement  au sein de l’infrastructure LAN, comme Brocade dans une certaine mesure mais surtout Juniper avec sa QFabric ou encore l’initiative autour de d’OpenFlow et plus généralement, des « SDN » (Software Defined Networking).

D’autres constructeurs privilégient l’ajout d’une couche d’orchestration globale (Network Services Manager chez Cisco).

…avec un impact organisationnel

Cette approche vers un unique point d’administration amplifie toutefois l’impact d’une erreur humaine ou d’un bug. Les processus d’exploitation ainsi que le niveau des exploitants devront être adaptés s’ils ne le sont pas déjà, voire s’appuyer sur des outils de workflow de plus en plus souvent proposés par les équipementiers ou éditeurs, pour intégrer des étapes de validation des changements.

Une montée en compétence nécessaire des exploitants du LAN DC mais des changements allégés : un shift de la quantité vers la qualité des exploitants

En conclusion… vers une révolution de velours ?

C’est bel et bien une révolution, certes lente, qui est en marche au sein des LAN Datacenter… dans un silence assourdissant car complètement masqué par d’autres sujets qui font le buzz…

Mais le LAN Datacenter est encore loin d’avoir fini sa mutation, démarrée sous l’impulsion de la vague Cloud… et ce nouveau LAN, cette « Fabric Ethernet », n’est bien sûr pas indispensable dans  tous les contextes –   les « anciennes » architectures ont encore de beaux jours devant elles – mais c’est le seul à même de répondre de manière pertinente aux nouvelles évolutions du SI et à la souplesse et la réactivité qu’elles imposent.

Cet article Et si la « Fabric Ethernet » ne se limitait pas au FCoE ? est apparu en premier sur RiskInsight.

L’offshore implique un engagement pluriannuel qui refroidit les DSI en temps de crise

Un tout premier élément de réponse réside simplement dans le fait que, contrairement à une idée reçue, les DSI ont plutôt tendance à ralentir ou retarder leurs opérations d’outsourcing en période de crise. La taille et le nombre d’opérations a ainsi significativement baissé sur l’année 2012 par rapport à 2011 (la baisse serait de l’ordre de 19 % au niveau mondial selon le cabinet Everest Group). Et ce ralentissement est d’autant plus significatif que le marché avait déjà marqué un sérieux coup de frein en 2011.

La raison de cette tension sur le marché de l’externalisation est assez simple : en période de crise, les entreprises sont beaucoup plus frileuses à signer des contrats pluriannuels. En effet, la mise en œuvre de ces contrats nécessite généralement des investissements importants. Investissements que les DSI ne sont pas en mesure de prendre (ou de justifier) en période de crise, et qui vont venir « dégrader » le ROI de l’opération, les gains économiques n’intervenant qu’à moyen terme, et donc pas sur le budget de l’année suivante. Il est clair que ce ralentissement a un impact sur la progression de l’offshore. Les grandes SSII « indiennes » tablent ainsi sur une croissance beaucoup plus faible de leur chiffre d’affaires en 2012 par rapport aux exercices précédents.

On peut pourtant se demander si ce ralentissement global du marché de l’outsourcing ne porte pas en lui le germe d’une augmentation de la part d’offshore dans les services IT. Ne serait-ce que sous l’impulsion des grandes SSII américaines et européennes qui, déjà très largement implantées dans les destinations offshores, pourraient accélérer le mouvement pour préserver leurs marges.

Des chiffres qui sous-estiment la réalité du marché

Il est cependant extrêmement difficile de savoir précisément quelle est la part de l’offshore dans les services IT. Le SYNTEC n’a d’ailleurs publié aucun chiffre sur le sujet depuis 2008 ! Selon les cabinets d’étude, cette part varie de 5 à 10% sur le marché français en 2012, et certains annoncent que l’offshore représentera 15% des services IT en 2014. Il semble assez clair que cette part est aujourd’hui sous-estimée. Un grand nombre d’études ne prend en compte que les prestations externalisées directement en offshore, faisant ainsi abstraction de la réalité opérationnelle. Les grands prestataires de services IT ont ainsi tous mis en place des modèles de production mondialisés dans lesquelles des « usines » onshore, nearshore et offshore interagissent entre-elles pour délivrer les services. Nombreuses sont également les SSII occidentales qui sous-traitent certaines activités auprès d’acteurs offshores locaux. Par ailleurs, les effectifs offshores des plus grandes SSII occidentales représentent déjà souvent plus de 30% de leurs effectifs totaux. Enfin, l’apparition de toutes les offres de type cloud, où par essence, les services sont délivrés par une main d’œuvre dont la localisation est complètement transparente pour les clients vient encore perturber la donne.

L’offshore : une solution à anticiper !

Finalement, en cette période de crise, le véritable frein à la progression de l’offshore dans la part des services IT se situe chez les donneurs d’ordre. D’abord parce que les impacts sociaux et la montée des tendances protectionnistes (on l’a vu récemment aux États-Unis) peuvent ralentir (voire ajourner) la mise en œuvre de ce qui est vécu comme une délocalisation dans l’opinion publique. Mais surtout parce que faire le choix de l’offshore ne peut pas être un choix purement opportuniste. Ce choix nécessite en effet de faire évoluer l’organisation de la DSI ainsi que sa stratégie de sourcing pour s’adapter aux spécificités de ce marché (différences culturelles, services standardisés, gouvernance et pilotage renforcé…). La courbe d’apprentissage n’est pas simple et les échecs restent assez nombreux tant d’un point de vue opérationnel, que d’un point de vue économique (notamment si on n’a pas anticipé sur le coût complet des services).

L’offshore ne peut donc être un choix de crise que si la DSI si est préparée en amont.

Cet article La crise profite-t-elle à l’offshore ? est apparu en premier sur RiskInsight.

1 – Comprendre le cloud et démystifier ses complexités

L’actuel CloudWashing ne facilite pas la compréhension des différents modèles de services et des bénéfices réels que les grands comptes peuvent en tirer. C’est pourquoi, il est nécessaire de commencer par mener un état de l’art pour comprendre les principes de consommation de ressources banalisées prêtes à l’usage et de segmentation des ressources, les différences avec les précédentes approches (ASP pour le SaaS, outsourcing pour le IaaS) mais aussi les spécificités, niveaux de maturité, bénéfices et complexités propres à chaque modèle.

Contrairement à ce que l’on pourrait penser, les complexités à adresser dans le cadre du cloud public ne se limitent pas à la dimension technologique et doivent être adressées en continu  :

• Complexités organisationnelles : le rôle de la DSI passe du pilotage de ressources à celui de pilotage de fournisseurs (c’est là la fin du mythe du super administrateur !) ;
•  Complexités réglementaires : réversibilité contractuelle, confidentialité, contraintes sectorielles ou légales sur le stockage des données ;
• Complexités technologiques : services d’intégration au SI, forte dépendance au réseau, etc.

2 –  Identifier  les opportunités d’externalisation de services

L’état de l’art permet d’identifier les cas d’usages aujourd’hui possibles dans l’entreprise :

• Le SaaS de par les fonctions génériques qu’il propose est envisagé pour des besoins non spécifiques au cœur de métier avec une faible intégration au SI ;
• Le PaaS public de par l’hétérogénéité des services offerts et le manque de standards est considéré pour les besoins « jetables »  surtout pour des organisations qui ont déjà investi sur leurs filières de développement basées sur des technologies traditionnelles ;
• Le IaaS privé s’inscrit en continuité de l’industrialisation des infrastructures en permettant plus d’agilité via le self-service ;
• Le IaaS public  ou hybride permet quant à lui d’adopter une position de « broker » d’infrastructure modulant le coût et la QoS en fonction des besoins métiers tout en étant capable de fournir une réponse agile à un besoin ponctuel de débordement de capacité.

Il est alors possible de s’appuyer sur un modèle comme SOI (méthodologie de catalogue de services) pour décliner les opportunités d’externalisation de services dans le cloud.

3 –  Affiner le périmètre éligible et définir la cible

Cette troisième étape commence par l’inventaire des critères d’éligibilité techniques et métiers (criticité des applications, environnements de développement, DMZ, étude des coûts …). Le business case est une étape clé et peut notamment révéler des coûts d’exploitation plus importants (par exemple dans le cadre du IaaS dès lors que l’utilisation des serveurs est intensive). L’application de ces critères permet alors de construire et de prioriser un portefeuille de projets. Une démarche usuelle mais avec des spécificités  propres au cloud s’impose :

• Commencer les déploiements par un périmètre pilote afin d’instruire plus facilement et à plus petite échelles les changements organisationnels ;
• Identifier des quick wins opportunistes et les adresser à l’issue du pilote sur des applications avec peu de contraintes technologiques ;
• Puis généraliser les déploiements et mener une politique du changement.

4 – Transformer le SI pour le cloud

Dès lors que les déploiements en mode cloud vont se généraliser, des applications de plus en plus en lien avec le cœur du SI vont partir vers le cloud. Se pose alors la problématique d’intégration aux services du SI. Les transformations à opérer sur le SI seront alors la prochaine étape dans l’odyssée vers le cloud …

Cet article 2012, l’odyssée du cloud : comment bien préparer votre voyage ? est apparu en premier sur RiskInsight.

L’importance croissante des canaux numériques dans les relations avec un client, la similarité des problématiques d’intégration au SI, quel que soit le média utilisé, et leur faible coût en font d’excellents candidats pour initier un parcours client multicanal.  Ils sont les premiers à bénéficier des synergies possibles pour :

• Développer des services de commodité (consultation de compte, support en ligne, etc.) et dégager des économies sur les canaux traditionnels.
• Valoriser l’audience et la connaissance fine des clients pour développer des revenus publicitaires (ciblage comportemental), développer des ventes incitatives / croisées.

Pour autant, nos retours d’expériences montrent qu’il est indispensable de favoriser des contacts avec un conseiller à des moments clés du parcours car il reste le meilleur moyen d’obtenir la satisfaction globale du client. La mise en place de parcours clients multicanaux doit donc se faire en pensant à la fois « apport de valeur » et « déport de contact ».

Comment déployer des moyens industriels qui apportent réactivité et souplesse au Métier ?

La mise en œuvre des parcours clients multicanaux nécessitent des moyens industriels qui assurent réactivité, souplesse au Métier. Ces moyens combinent des infrastructures de médiation, des infrastructures de téléphonie, des outils de workflow humain, des outils de CRM, des outils de gestion de campagnes, etc.  Leur déploiement peut être accéléré en achetant certains services à l’externe et profiter des avantages offerts par le cloud computing. Le choix du modèle d’hébergement entre celui proposé par l’éditeur (en mode Software as a Service), le  cloud privé  ou directement intégré au SI de l’entreprise dépend principalement des risques liés à la sécurité des données et des accès, de la dépendance au fournisseur, etc.

Quelle que soit la solution retenue, il faudra rester extrêmement vigilant sur l’intégration de ces services avec l’écosystème de l’entreprise et minimiser la conduite de changement des opérationnels pour ne pas réduire à néant les bénéfices escomptés.

Comment assurer une gouvernance multicanal dans la durée ?

La gouvernance d’un projet de transformation multicanal doit :

• Disposer d’un sponsor capable de porter et incarner le projet auprès de la Direction générale.
• Associer l’ensemble des Directions métier et informatique au pilotage opérationnel et stratégique.
• Privilégier une trajectoire d’évolution du SI qui passe par des paliers intermédiaires stables et produisant chacun des bénéfices pour les clients, les conseillers et l’entreprise.
• Impliquer au plus tôt les ressources internes de l’entreprise (architectes, exploitants, conseillers, etc.) pour limiter les freins aux changements et les aider à acquérir de nouveaux rôles et compétences.

Si les entreprises peuvent espérer optimiser leurs performances commerciales et financières en s’engageant dans une relation client multicanal, elles doivent réussir à concilier, d’une part, la qualité de services et la satisfaction globale du client, et d’autre part, la productivité du conseiller et la réduction des coûts opérationnels.

En suivant une stratégie d’intégration maîtrisée et progressive, les DSI peuvent contribuer activement à la réussite d’un projet de transformation de la relation client multicanal. Elles doivent pour cela passer d’un rôle de fabriquant et d’opérateur de solutions informatiques vers celui d’intégrateur de services en sachant externaliser à bon escient. L’externalisation agit, en effet, généralement comme un catalyseur, accélérant ainsi l’industrialisation interne et la montée en maturité des équipes internes.

Pour en savoir plus, consultez nos focus sur la thématique du multicanal

Cet article Multicanal, facteurs clés de succès pour les DSI est apparu en premier sur RiskInsight.

Il faut dire que le Cloud pourrait bien résoudre certains des casse-têtes récurrents des directions métiers et des DSI : réduction drastique des délais de mise en œuvre (la mise en ligne d’un serveur chez certains offreurs prend moins de dix minutes !), meilleure maîtrise des coûts du fait d’une facturation à la consommation, rationalisation du SI et renforcement des engagements entre les différentes fonctions du SI.

Au-delà des slogans, 2010 aura donc vu Le Cloud s’affirmer comme une tendance de fond qui risque de modifier profondément le paysage des SI dans les années à venir…. et l’architecture d’entreprise.

Une nouvelle dimension pour l’architecture

Aujourd’hui en charge d’opérer les différentes strates du SI, la DSI sera demain un agrégateur de services fournis par des tiers, lui permettant par ailleurs de se concentrer sur les applications cœur de métier demeurés hors du Cloud – pour des raisons de maîtrise du risque opérationnel.

Les architectes auront pour nouvelle mission de maîtriser tant sur le plan fonctionnel que technique l’éclatement et le morcellement du SI, tout en essayant de tirer le maximum de bénéfices du Cloud.

Nouveau modèle, nouvelles règles du jeu

Ce mouvement déclenché par le Cloud commence déjà à bousculer les rapports de force entre métiers et la DSI – mais également au sein de la DSI même. Ainsi, l’architecte aura –t-il demain pour mission de rendre les offres de services plus compétitives tout en garantissant la cohérence du SI quelles que soient les orientations retenues. Les architectes interviendront beaucoup plus en amont sur des phases clés, notamment lors de l’arbitrage entre internalisation et externalisation ou encore lors de la contractualisation avec des tiers pour imposer les contraintes d’intégration au SI.

La fonction Architecture va de fait progressivement passer d’une dimension projet à une dimension Entreprise renforçant ainsi sa contribution à la stratégie SI.

Un changement de rôle

Au-delà des aspects organisationnels, les architectes vont avoir la responsabilité de piloter l’évolution des services d’infrastructure existants pour préparer l’arrivée du Cloud.

En priorité, il s’agit d’ouvrir le SI pour faciliter l’intégration des offres Cloud sans compromettre pour autant la sécurité de l’entreprise et la performance du SI. Ensuite, ce sont les services d’infrastructure existants impliqués dans la chaîne de liaison avec le Cloud qui doivent être repensés et optimisés (plates-formes d’échange internes, briques de sécurité, etc.). Enfin, pour perdurer, les offres historiques de la DSI (comme la mise à disposition de serveurs) doivent évoluer pour offrir une réponse différenciée aux offres Cloud.

A la différence de précédentes évolutions du monde IT (la SOA par exemple), le tournant vers le Cloud peut réellement être amorcé sur des projets de petite taille et sans risque, le coût d’entrée étant relativement faible. Néanmoins, pour installer plus durablement le Cloud dans le paysage de l’Entreprise, il faudra viser des projets plus structurants de transformation du SI.

Une nécessité : adopter une vision transverse, de l’architecture fonctionnelle jusqu’à l’infrastructure technique

Au-delà du positionnement de la fonction architecture au cœur du triptyque Métier/Études/Production, l’architecte devra veiller à bâtir et promouvoir un socle IT sous forme d’offre de services qui répond aux exigences de performance et de sécurité demandées par le métier. Pour réussir dans cette mission, les architectes sont amenés à couvrir, de manière cohérente, un spectre allant des services fonctionnels jusqu’aux services d’infrastructure.

Avec le Cloud, cette mission sera demain à la fois plus complexe à réaliser mais également plus cruciale pour l’entreprise.

Pour en savoir plus sur le Cloud Computing, lire le dernier Focus Solucom :  » Cloud computing, comment en tirer parti » ?

Cet article L’affirmation du Cloud computing : un changement de dimension pour l’architecture en 2011 est apparu en premier sur RiskInsight.

Véritable transformation du SI, l’« informatique dans les nuages » s’accompagne de nouveaux besoins, nouvelles pratiques et d’un nouveau modèle économique. A l’ère des investissements lourds en Datacenter et infrastructures succèderont les services hébergés, facturés à l’usage.

Les offres Cloud du marché IT  couvrent l’ensemble des modèles de services Cloud : IaaS (Infrastructure as a Service), PaaS (Platform as a Service) et SaaS (Software as a Service).

Aussi, on retrouve sous la bannière du Cloud des acteurs allant de l’éditeur de logiciels à l’acteur issu du monde de l’e-business en passant par l’expert en solutions de virtualisation….ou l’opérateur de Télécoms.

Que font les opérateurs télécom dans les nuages ?

Pour déployer l’ensemble des services Cloud, la base est indispensable ; et cette base, c’est l’IaaS – les infrastructures…

Experts dans la conception, la production et l’exploitation de solutions de communications entreprises, les opérateurs ont donc une carte à jouer.

Certains opérateurs proposent déjà des offres Cloud, à base de solutions de virtualisation d’infrastructure et d’accès réseaux à la carte / à la demande. C’est le cas de Verizon Business avec CaaS (Computer as a Service)  et de l’offre Flexible Computing d’Orange business Service, déclinée en version premium depuis Décembre 2010. SFR a de son côté lancé en France une offre Infrastructure SI à la Demande le 30 juin dernier. L’opérateur s’est pour cela allié à HP qui fournit l’expertise Infrastructure manquant à l’opérateur.

Des atouts indéniables

Les opérateurs de télécoms bénéficient d’une notoriété et d’un capital confiance inégalés dans le monde des solutions et services informatiques. Par ailleurs, alors que sécurité et  dépendance au réseau sont évoqués comme des freins majeurs, ils y offrent des réponses concrètes.

– Sécurité : les opérateurs proposent des solutions d’interconnexion d’utilisateurs, de sites ou d’infrastructures sécurisés depuis plusieurs années.

– Dépendance au réseau : les opérateurs exploitent des solutions Très Haut Débit de moins en moins chères, avec une disponibilité bien souvent garantie à 100% et des engagements de niveaux de service associés.

Ils disposent en outre d’avantages concurrentiels établis sur ce marché (clientèle mixte entreprises et grand public, expertise en infrastructure et réseau, couverture globale et capacité d’intervention IT locale) et sont rodés au modèle économique de facturation à l’usage, caractéristique du Cloud.

Un positionnement appelé à évoluer

Le positionnement des principaux offreurs du marché se veut de plus en plus « généraliste ». Après avoir capitalisé sur leurs cœurs de métier respectifs (édition, gestion d’infrastructures, réseau) ils cherchent à élargir l’empreinte de leurs offres.

Pour les opérateurs notamment, cela passe par des alliances stratégiques avec les offreurs actifs sur les autres couches de la pyramide. Par exemple, Orange Business Services s’allie à Microsoft pour intégrer des solutions de messagerie et de collaboration de la plate-forme Microsoft Office 365, hébergée dans le Cloud. Dans ce cas, l’opérateur global qu’est France-Télécom Orange, met également à profit son savoir faire et ses ressources disponibles dans l’intégration de solutions informatiques.

Quelles perspectives ?

Le marché du Cloud n’en est vraisemblablement qu’à ses débuts, mais il dispose d’un potentiel de croissance fort que dénotent les investissements consentis sur le sujet et les premiers bilans économiques.

On ne compte plus les parallèles pour évoquer cette croissance attendue, par exemple avec la VoIP, un marché aujourd’hui mature et au cœur de la sratégie des opérateurs de télécoms.

Selon la plupart des acteurs du Cloud que j’ai pu rencontrer, ce marché représenterait 50% du marché total de l’IT dans le monde à horizon 5 ans. Ce palier de 50% demeurera la limite « physique » de développement du Cloud, tout l’IT n’ayant pas vocation à « basculer ».

Pour les analystes il devrait peser en 2015 dans le monde, entre 200 Mrd$ et 500 Mrd$. Le marché Français pourrait être estimé entre 10Mrd€ et 20Mrd€ cette même année (estimation Solucom).

Il y a fort à parier que Stéphane Richard, Directeur Général du groupe France Télécom, avait ces chiffres en tête en l’identifiant comme levier de croissance clé dans le cadre du plan stratégique « conquêtes 2015 ». Chiffres qui vont avec la certitude que les opérateurs disposent des atouts pour qu’une part importante du gâteau leur revienne d’ici 2015.

Cet article Les opérateurs, acteurs naturels du cloud computing est apparu en premier sur RiskInsight.