Un constat pour le moins mitigé

Malgré les évolutions technologiques, il reste toujours difficile d’insérer correctement une application métier dans le système d’information d’une entreprise. Cela est en partie dû au fait que les métiers souhaitent souvent aller au-delà de leur attribution en ne s’intéressant pas uniquement au « Quoi ? » mais aussi au « Comment ? ». Cet état de fait provient d’une sorte de « syndrome du métier roi », qui peut conduire à des extrêmes comme la mise en service d’applications sans que la DSI soit prévenue (le shadow IT). Cela peut notamment être le cas lorsque les règles et processus ne sont pas jugés pertinents ou trop lents par le métier.

En conséquence, de nombreuses spécificités apparaissent et ne sont pas toujours résorbées : non-respect des normes internes et réglementaires, non-utilisation des infrastructures et offres de services présentes, perpétuelle « réinvention de la roue » …

Ce phénomène implique des pertes de temps et des surcouts qui pourraient être évités. Il implique aussi des risques pour le bon fonctionnement et la sécurité du SI car la maitrise des applications est moindre.

Tout d’abord, cadrer

La mise en place d’un cadre clair et cohérent décrivant le SI est un prérequis fort de la bonne intégration des applications métiers dans le SI. Il doit être conçu pour s’appliquer également aux applications métiers basées sur des composants physiques industriels.

Ce cadre s’appuie sur la rédaction de politiques, que ce soit pour les infrastructures (positionnement des applications, gestion de la disponibilité, piles systèmes et logicielles préconisées …), pour le réseau (règles de raccordement, gestion du dimensionnement des échanges …) ou pour la sécurité (gestion de la confidentialité et de l’intégrité des données, gestion des authentifications et habilitations …), avec en particulier l’analyse des risques associés aux données et à leurs traitements. L’inclusion du cadre réglementaire et légal (réglementations informatiques et libertés, loi de programmation militaire …) est nécessaire.

De même, toutes les infrastructures et les services qu’elles rendent doivent être présentées sous forme d’offres de services, incluant les contraintes d’acceptation et dès que possible, les couts et délais associés à leurs utilisations, d’autant plus si le système s’oriente vers une approche micro-services et repose sur des API.

Tous ces éléments doivent être intégrés dans le schéma d’urbanisme du SI.

Une fois défini, le cadre est à dériver sous forme de toolkits permettant aux métiers d’identifier rapidement leurs besoins, afin d’intégrer les contraintes associées dans leurs pré-études et leurs appels d’offres.

Puis, fonctionner en mode processus

Le cadre mis en place doit s’accompagner d’un ensemble de processus facilitant la conception et la mise en place des applications métiers.

Les processus accompagnant la conception applicative sont, de loin, les plus importants, puisqu’ils amènent aux architectures applicatives à déployer. Ils doivent intégrer, dès les premières phases, l’exploitant ainsi que les équipes gérant le réseau et la sécurité du SI, qui sont amenés à faire partie de l’instance de validation des architectures applicatives.

Dans un cycle projet traditionnel, il est préférable de découper l’étude et la validation de l’architecture des applications en deux parties.

La première partie, doit traiter l’architecture fonctionnelle uniquement. Celle-ci commence par la fourniture des besoins par le métier : population cible, données utilisées et traitements associés. Une étude de ces besoins vis-à-vis du cadre défini permet alors de déterminer les contraintes imposées à l’architecture et les offres de services pouvant répondre au besoin métier. Cette étude passée, l’architecture fonctionnelle peut être définie par le métier et validée par l’instance de validation des architectures applicatives.

La seconde partie, qui s’intéresse à l’architecture technique, favorise l’utilisation des offres identifiées précédemment. L’architecture proposée peut enfin être validée en impliquant dans cette décision les responsables des offres de services retenues.

Et le plus important… faire appliquer !

La mise en application du cadre et des processus associés est à faire étape par étape.

Il convient, en premier lieu, d’identifier au moins un correspondant métier au sein de la DSI moteur et connaisseur de l’organisation, afin de tester et de rôder le cadre et les processus. Une fois ce premier test effectué, il peut être étendu au sein de la DSI, en commençant sur une base de volontariat, et ce, avec l’appui du DSI.

La dernière phase, l’extension du processus à l’ensemble des métiers, est plus complexe en ceci qu’elle nécessite un sponsor au sein de la direction générale permettant son application.

Cette mise en application peut être facilitée par une communication régulière aux différents interlocuteurs sur les gains en termes de cout et de délais associés à l’application du cadre et des processus et par la priorisation des projets les appliquant par rapport aux projets réticents (« politique de la carotte et du bâton »).

Enfin, tout au long de cette mise en place, il est nécessaire de prendre en compte très rapidement tout retour.

Les outils clés

Afin d’assurer la réussite du processus, celui-ci doit être accompagné d’un certain nombre d’éléments.

Les offres de services doivent donner la priorité au respect des standards et contraindre le sur-mesure à des études supplémentaires. Chaque « standard » d’une offre de service est à associer à un template de configuration permettant de limiter les couts et délais de préparation des environnements des applications, ainsi que les couts d’exploitation, mais aussi de limiter le risque d’incidents par la maitrise de la configuration. La mise à disposition de modèles types de supervision des services applicatifs est également un point à ne pas négliger.

Le processus de demande de mise en place d’une architecture validée doit être le plus simple possible pour le métier, le nombre d’informations, minimisé, et la complexité sous-jacente à la demande, masquée. Au besoin, cela passe par la mise en place d’une entité chargée de traduire rapidement une demande de mise en place ou d’évolution de l’existant issue du métier en un ensemble de demandes techniques ciblant les besoins (installation de serveurs, mise en place de machines virtuelles, configuration réseau, ouverture de flux, configuration des équipements de sécurité applicative …).

L’objectif est de rendre attractif le suivi de l’offre standard en le rendant plus simple, plus rapide et moins couteux.

Il ne faut par contre pas bloquer la spécificité si elle ne remet pas en cause le bon fonctionnement ou la sécurité du SI. Elle peut en revanche être plus longue et plus couteuse à insérer, cela se justifiant par les études permettant sa bonne intégration.

Cadrer l’historique pour poser les bases du futur

La bonne gestion de l’insertion d’une application dans un SI passe par un cadre clair et partagé de tous, des processus et outils simples et acceptés, un accompagnement de proximité, facilitant la vie des responsables d’applications jouant le jeu des normes propres SI et reportant le cout de toute complexité sur le métier responsable, sans bloquer les spécificités.

Et ce mode de fonctionnement, bien adapté à une gestion classique des développements applicatifs, peut être une base pour entamer des réflexions sur le mode agile où la définition d’un cadre et la priorisation de l’utilisation des standards restent de bonnes pratiques.

Cet article De la bonne insertion d’une application métier dans le SI 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.

 Familles d’écueils rencontrés

À cela, plusieurs raisons concomitantes.

Il n’existe en général pas un, mais plusieurs, référentiels d’architecture (les architectures applicatives et fonctionnelles dans un premier référentiel, l’architecture technique dans un second référentiel via une CMDB).

Par ailleurs, de trop nombreux acteurs sont impliqués dans la vie de ces référentiels : urbanistes, architectes SI, architectes de domaine, architectes projet, exploitants…, diluant de ce fait les responsabilités.

Enfin, les processus de mise à jour du référentiel ne font souvent pas partie du cycle de vie projet. Seul le bon vouloir des différents acteurs garantit le maintien d’une information à jour et de qualité.

 Usages d’un référentiel d’architecture d’entreprise

Cependant, disposer de référentiels à jour et exhaustifs contribue efficacement aux principaux projets SI.

Dans le cadre d’évolutions des postes de travail, connaître le parc des applications (application client léger, application client lourd, etc.) s’avère nécessaire pour définir la politique de migration.

De même, les projets d’évolution de l’infrastructure doivent forcément s’accompagner de l’étude de l’impact sur le parc applicatif.

L’utilisation de référentiels facilite également la phase d’analyse de l’existant préalable à toute étude dans le cadre d’évolutions métiers.

Il est aussi indispensable de connaitre l’impact applicatif et fonctionnel et de le présenter aux métiers concernés dans le cas de l’externalisation d’un domaine technique.

Enfin, pour garantir l’industrialisation des solutions et donc la réduction des coûts, la mise en place de standards architecturaux est un impératif.

 Un contenu bien ciblé

En termes de contenu, plusieurs éléments sont à prévoir :

• L’ensemble des cartographies du SI : fonctions SI, applications, services applicatifs, éléments techniques (tels que les services techniques, les infrastructures…). Les cartographies de l’existant constitueront une première étape, qu’il conviendra d’enrichir avec une vision plus prospective.
• Le catalogue des solutions applicatives et techniques référencées : ensemble des composants validés et recommandés par la DSI pour constituer les réponses SI aux besoins métiers ou techniques.
• Les différents patterns d’architecture : typologies d’architecture à mettre en place afin de répondre aux besoins SI.

 Facteurs clés pour une implémentation réussie

Grande question que celle du niveau de granularité des informations contenues dans ces référentiels d’architecture d’entreprise. Se noyer dans un niveau trop important de détail est préjudiciable à la pertinence du référentiel et augmente ses chances de ne pas être à jour. A contrario, un manque d’informations peut nuire aux besoins notamment des projets SI et de ce fait n’avoir plus d’utilité.

Quelques recommandations pour profiter au mieux de ces outils au service des projets SI :

Première condition, accepter d’avoir un outillage multiple… mais mettre en place des processus qui garantissent les corrélations et les mises à jour des informations.

Seconde condition, lancer les premiers chantiers sur un sous-ensemble cohérent (architectures applicative et technique ou architectures fonctionnelle et applicative).

Enfin, dernière condition de succès, travailler à l’insertion du process de définition de l’architecture dans le cycle projet (a minima prévoir les points de contrôle).

A l’heure où les DSI se targuent d’être industrielles, innovantes,… bref, à l’état de l’art, il est temps de mettre en place et faire vivre ces référentiels d’architecture d’entreprise !

Cet article Référentiel d’architecture d’entreprise : vous ne pouvez plus faire l’impasse ! est apparu en premier sur RiskInsight.

En quoi investir dans la fonction architecture est aujourd’hui clé ?

La tendance des entreprises à s’appuyer et dépendre toujours plus des outils informatiques entraîne une complexité et une criticité croissantes du SI. Il est devenu indispensable pour la DSI d’en assurer une maîtrise globale, pour en garantir l’efficacité et l’agilité. Dans ce cadre,  la fonction Architecture a  un rôle central à jouer pour garantir cette maîtrise : elle a pour ambition d’améliorer la cohérence du SI et son alignement avec la stratégie de l’entreprise. Rôle clé qui se traduit notamment par une optimisation des processus métiers, une amélioration de la qualité des données, une meilleure maîtrise du SI par la DSI et une meilleure appropriation du SI par les métiers.

Concrètement, quelles sont les armes de l’architecture pour répondre à cet enjeu de maîtrise du SI ?

En premier lieu, je dirais que la fonction architecture a pour ambition de rendre agile le SI. En contribuant à la mise en place de composants réutilisables (techniques ou fonctionnels) et au développement de services d’infrastructure urbanisés, l’architecte  permet le développement rapide de nouvelles fonctionnalités dans le SI. Le SI peut ainsi s’adapter plus rapidement aux changements stratégiques et organisationnels, et la DSI devient  davantage proactive vis-à-vis des métiers.

Parallèlement, l’architecte œuvre à la rationalisation des composants du SI. Il est en effet  essentiel autant que possible de standardiser le  patrimoine applicatif et les flux d’échanges, de mutualiser les applications et les infrastructures et enfin d’augmenter le taux de réutilisation des composants du SI…

Enfin, la fonction architecture permet à l’entreprise d’avoir une vision d’ensemble et prospective du SI, propice à la fois à engendrer des économies substantielles dans les projets (diminution de la complexité des projets, réduction des délais conception/réalisation, réduction des coûts d’exploitation…) mais également indispensable pour réduire les risques (obsolescence des composants par exemple).

Est-ce facile de mesurer les apports de l’architecture ?

Non, et c’est là le souci. La maturité des entreprises est relativement faible en matière de pilotage des apports de la fonction architecture. En moyenne, les entreprises ne mesurent que 3 ou 4 indicateurs.

Déterminer les indicateurs adaptés aux enjeux et au contexte de l’entreprise n’est d’ailleurs pas forcément évident. Quelques règles s’appliquent néanmoins systématiquement :

• Les indicateurs doivent évoluer en fonction de la maturité de la fonction architecture : inutile de mesurer « tous » les indicateurs imaginables !
• Les différentes parties prenantes (DSI et métiers) doivent s’accorder sur les modalités de mise en place et le sens des indicateurs.
• Plus un indicateur est simple, meilleure sera son appropriation. Un indicateur trop compliqué à calculer ne sera pas suivi dans le temps.
• La représentation graphique facilite la communication et donc la prise de décision : n’hésitez pas à utiliser des graphiques facilement compréhensibles.
• La mesure des indicateurs doit faire partie d’un processus d’amélioration. Ce qui importe n’est pas tant la valorisation de l’indicateur mais son évolution dans le temps.

L’architecture, comme de nombreuses fonctions transverses de l’entreprise, est contrainte de légitimer son action pour être pertinente. La communication d’indicateurs appropriés constitue un levier indéniable.

Cet article L’architecture : l’urgence de mesurer son apport ! est apparu en premier sur RiskInsight.

La virtualisation de serveurs a apporté un premier niveau de réponse à ces besoins de flexibilité au sein du datacenter. Plus récemment, le cloud computing est arrivé avec son lot de promesses d’optimisations et de souplesse supplémentaire.

Au-delà des buzz générés successivement autour de ces solutions, dans quelle continuité s’inscrivent-elles et quelles différences y a-t-il entre deux concepts souvent confondus ?

Retour sur les évolutions apportées par la virtualisation 

La virtualisation système consiste à faire fonctionner sur un même serveur physique plusieurs systèmes d’exploitation en parallèle. Ceci est réalisé au travers d’un hyperviseur assurant aussi bien la virtualisation du serveur physique que celle de ses interfaces (réseau, stockage…). La virtualisation s’inscrit ainsi dans le modèle SOI comme un moyen d’implémenter une couche « ressource ».

La virtualisation permet :

• De réduire le nombre de serveurs physiques en les consolidant,
• De normaliser le socle d’hébergement des OS sous forme de VM,
• D’améliorer l’agilité en réduisant le temps de provisioning,
• De renforcer la disponibilité et la reprise d’activité en offrant des mécanismes de migration et de redémarrage automatique intégrés.

La virtualisation apporte ainsi de nombreux bénéfices qu’il reste à bien mettre en balance face à ses contraintes. En effet, il faut  noter qu’elle a tendance à augmenter la complexité de l’architecture et de son exploitation et que la facilité de création des machines virtuelles peut provoquer une prolifération des instances de serveurs. Par ailleurs, la virtualisation génère de nouvelles problématiques de sécurité  et peut être source de contentions entre les services. Enfin, mêmes virtualisées, le temps de déploiement des ressources reste conséquent.

 Le cloud computing : au-delà du buzz, un mode de consommation

Depuis 2008, parallèlement à l’évolution interne des SI est apparu le cloud computing publique, promettant un niveau supplémentaire d’agilité avec une mise à disposition très rapide de ressources élastiques et une facturation adaptée à la consommation réelle.

Malgré les promesses du cloud public, les entreprises restent aujourd’hui frileuses dans son adoption. Les freins majeurs étant  les risques de sécurité perçus (utilisation d’internet, confidentialité des données et soumission à des lois locales à l’opérateur) ainsi que la dépendance aux fournisseurs engendrée par le manque de standards.

Une notion intermédiaire est donc apparue, le cloud privé. Il a pour vocation d’amener la flexibilité du cloud public dans le SI des entreprises tout en répondant aux réticences des DSI sur la sécurité et la fiabilité des services fournis.

 De la virtualisation au cloud privé

La mise en place d’un cloud privé peut être vue comme un empilement de blocs fonctionnels mettant à disposition des utilisateurs les ressources du SI en self-service, de manière automatisée, tout en offrant un niveau de qualité de service et de sécurité calibré.

Pour obtenir une plate-forme de cloud privé interne IaaS*, les principales fonctionnalités agrégées autour d’un socle de virtualisation système  sont les suivantes :

• L’automatisation du provisioning : supprimer les actions manuelles des processus de mise à disposition de ressources ;
• L’orchestration : mettre en musique les actions sur les différents composants de la plate-forme ;
• La supervision : contrôler le bon fonctionnement et collecter les métriques d’usage ;
• L’authentification et le contrôle d’accès : gérer finement les droits d’accès aux ressources et à leur administration ;
• Le portail self-service : permettre à l’utilisateur de réaliser ses demandes de création, modifications, et éventuellement suppression de ressources ainsi qu’en consulter les informations (inventaire, facturation, utilisation…) ;
• La refacturation à l’usage : traduire les métriques d’utilisation des ressources en termes budgétaires et les basculer dans les systèmes de gestion internes ;
• Le catalogue de service : être le référentiel des caractéristiques de ce qui peut être déployé.

La majorité de ces blocs existent déjà dans les SI et sont alors adaptés à l’occasion du passage au cloud privé. Ce passage s’inscrit dans une démarche d’évolution à la suite des travaux de normalisation et standardisation, de catalogues de services, d’automatisation et mise en place de stratégies self-service dans les DSI. C’est un mouvement précurseur des grandes tendances d’automatisation globale du SI.

[Article rédigé en collaboration avec Julien Contal et Aurélien Delcros]

Pour en savoir plus sur la virtualisation et le cloud computing, consulter la synthèse Solucom : Virtualisation et cloud computing : jusqu’où aller ? 

* : Le marché du cloud privé est structuré de la même facon que le cloud publique entre SaaS, PaaS et IaaS. Ce billet traite principalement du cloud privé interne IaaS. La structuration de ce marché est décrite dans la synthèse Virtualisation et cloud computing : jusqu’où aller ? 

Cet article Cloud privé, à la recherche du Graal est apparu en premier sur RiskInsight.

LGA (Lise Gasnier) : Le Big Data a une dimension “métier” évidente : pour les entreprises, le défi est d’identifier les opportunités de business offertes par leurs gisements de données. Déjà, des “business cases” montrent la faisabilité et l’intérêt d’exploiter des données jusqu’alors “non valorisées”. Il devient possible d’en extraire une information utile pour mieux connaître sa clientèle, optimiser son marketing, détecter et prévenir des fraudes, analyser son image sur les réseaux sociaux et la valoriser, optimiser ses processus…

En s’inspirant des initiatives innovantes de leurs secteurs, les entreprises pourraient initier la réflexion “Big Data” autour de 2 questions basiques :

• De quelles informations avons-nous besoin pour accroître notre efficacité et innover ?
• Quelles sont les données sous ou inexploitées à notre disposition?

Le Big data invite les métiers à plus de liberté, plus d’audace dans leurs réponses.

Dans ce domaine comme dans les autres, répondre à la première question et exprimer des besoins précis prend du temps. C’est, de plus, une question à poser en continu. D’évidence, les objectifs métiers exigeront de produire sans cesse de nouvelles analyses, sur des données déjà traitées (donc les “ré-analyser”) ou non, avec des sources et formats inédits.

Pour répondre à la seconde question, les métiers doivent connaître les sources de données à leur disposition et savoir interpréter les données brutes, pour en saisir la pertinence et en extraire l’information utile. Sur ce terrain technique, il est évidemment souhaitable que la DSI les accompagne. Elle doit par conséquent démontrer sa maîtrise des données du SI, au-delà de la “zone de confiance” des données gérées dans les systèmes de base de données traditionnels de l’entreprise.

MMI (Mathieu Millet) : Pour la DSI, tout l’enjeu va donc être de pouvoir traiter la volumétrie et l’hétérogénéité des données pour ouvrir le champ des possibles aux métiers. Pour anticiper des besoins que les métiers ne savent pas exprimer aujourd’hui, elle doit se doter d’une architecture permettant d’emblée de collecter, stocker et analyser “plus” et “plus varié”. C’est bien d’une architecture agile que les métiers ont besoin.

Une approche initiale serait d’imaginer ce que serait son système Big Data en proposant quelques cas d’usage sur un « échantillon » représentatif de données, à la fois structurées (comme celle que l’on trouve dans les entrepôts de données) et semi-/non-structurées (logs d’applications, messages sur les réseaux sociaux, documents bureautiques, utilisation des données issues de l’Open Data…). Cette “promotion” du service permettrait ainsi à la DSI de présenter aux métiers la valeur ajoutée de ces données et d’anticiper un changement profond de son infrastructure. Nous l’avons vu : les technologies sous-jacentes sont innovantes et pointues. La DSI a tout intérêt à emprunter la pente douce de sa montée en compétence sur le “Big Data” ; surtout que les compétences sur le marché sont peu nombreuses et qu’aujourd’hui, une prise en main technologique est nécessaire.

L’autre axe de travail serait d’initier un dialogue avec les métiers pour mettre en commun leurs données, historiquement réparties et cloisonnées, dont la duplication entre différentes applications sera de facto très difficilement réalisable.

LGA : Quelle que soit l’hypothèse de travail, il sera évidemment nécessaire d’établir un dialogue constructif entre les métiers et la DSI afin d’assurer la réussite d’un tel projet d’envergure.

Lire aussi les articles :

Qu’est-ce que le Big Data

Quel est le paysage technologique du Big Data

Cet article Comment faire face à l’émergence du phénomène Big Data ? est apparu en premier sur RiskInsight.

Pourquoi organiser un Symposium de l’Architecture ?

L’architecture et Solucom, c’est une longue histoire, qui remonte aux toutes premières années de Solucom. Aujourd’hui, la practice Architecture SI représente la première force du cabinet par ses effectifs, avec près de 250 consultants qui traitent de sujets aussi divers que les architectures multi canal, les usages des nouveaux terminaux en entreprise, et la consolidation de datacenters.

C’est la deuxième année que nous organisons le Symposium de l’Architecture. Comme l’an dernier, nous avons voulu cet évènement avant tout comme un moment de partage pour confronter toutes ces thématiques qui font la richesse de l’architecture. Pendant toute une journée, des ateliers, conférences, tables rondes, réunissent des consultants de Solucom, des partenaires et quelques clients, et permettent ainsi à cette communauté d’échanger sur ce qui fait l’actualité de l’architecture.

À terme, notre ambition est de faire du symposium un point de rencontre majeur pour le marché, qui contribuera à renforcer le leadership du cabinet en matière d’architecture des SI.

Quelles est l’actualité de l’architecture aujourd’hui ?

L’architecture doit relever aujourd’hui deux défis. Le premier défi est celui de l’innovation. Internet mobile, cloud computing, green IT, smartphones, consumérisation, nouveaux modes d’achats… : qu’elle soit technologique ou non, l’innovation, qui était il y a quelques années encore une affaire de spécialistes, est maintenant un sujet qui touche le grand public. Et du simple collaborateur au responsable métier, chacun, en entreprise, a ses propres attentes sur ce que peut apporter l’innovation dans le SI. C’est à l’architecture de s’assurer que cette quête permanente de nouveaux usages et d’accroissement de valeur par l’innovation se fait sans compromettre la cohérence globale ni la stabilité du SI.

Autre défi pour l’architecture, dans une économie globale où les entreprises adaptent leur stratégie de manière extrêmement réactive, et où les métiers, pour garder un avantage concurrentiel, recherchent un « time to market » toujours plus réduit : comment concilier efficacement au niveau du SI vision long terme reflet de la stratégie d’entreprise, et besoin plus court terme de satisfaire chaque projet métier ? Les mots clés sont ici alignement Métiers – Études – Production, décloisonnement des filières architectures (fonctionnelle, applicative, technique) au sein de la DSI, et même « architecture d’entreprise » – un terme tombé un temps en désuétude, et en passe de s’offrir une deuxième jeunesse.

Quels thèmes avez-vous creusé pendant cette journée ? Quelles conclusions en avez-vous tirées ?

Le programme de la matinée a fait la part belle à l’innovation, avec deux ateliers animés par des consultants de la practice sur les nouvelles technologies réseaux dans les datacenters d’une part, et sur l’arrivée des smartphones et autres tablettes dans le SI et l’environnement de travail des collaborateurs d’autre part. Le cloud computing était aussi à l’honneur, avec deux ateliers animés par nos partenaires du jour, Microsoft et VCE.

L’après-midi fut un temps de réflexion sur la fonction architecture chez les grands comptes, avec deux temps forts : tout d’abord une conférence sur l’évolution du métier d’architecte en entreprise. Puis une table ronde sur l’apport des bureaux d’architectes, avec la participation de trois clients de Solucom chez qui nous animons des centres de service architecture.

Autant de pistes sérieuses pour permettre à notre practice Architecture SI, aujourd’hui dotée d’expertises et savoir-faire unitaires forts, d’enrichir sa proposition de valeur, et permettre ainsi aux clients de Solucom de relever avec succès ces nouveaux défis de l’architecture. Un chantier majeur qui s’ouvre pour la cabinet, dans le droit fil de notre stratégie Solucom 2015.

Cet article Retour sur le Symposium de l’Architecture de Solucom avec Guillaume Chassard est apparu en premier sur RiskInsight.

Le 12 octobre dernier, IBM a annoncé le rachat d’un acteur majeur du marché du grid computing : Platform Computing. A cette occasion, nous revenons sur les principes, apports et défis de ce type de technologies peu connu.

1.     Qu’est-ce que le grid computing ?

Le grid computing consiste à mettre en commun des ressources logicielles et matérielles distribuées (ensemble que l’on appelle la « grille ») afin de fournir une puissance de calcul importante. La charge de travail est divisée en sous-tâches qui sont traitées en parallèle par les ressources de la grille, les résultats étant ensuite agrégés dans un résultat global rendu à l’utilisateur.

En anglais, l’emprunt du mot « grid » à l’expression « electric power grid » qui désigne le réseau électrique, traduit bien les promesses du concept : l’utilisateur se branche à la grille qui pourvoit à son besoin. Peu lui importe la complexité du système, l’hétérogénéité ou la distribution des composants, masqués par l’interface d’accès.

Des projets emblématiques donnent le ton, en matière de gigantisme :

• SETI@HOME se présente comme « une expérience scientifique qui utilise des ordinateurs reliés à internet pour la recherche d’une intelligence extraterrestre (SETI) » ; elle tire sa puissance de son « ouverture » aux ordinateurs des internautes volontaires ;
• La grille du LHC, l’accélérateur de particules du CERN,  relie en mode « fermé », plusieurs dizaines de milliers de machines, situées sur trois continents, pour analyser des données.

La puissance des ordinateurs a beau croître, la « gourmandise » de tels projets scientifiques, atteint des niveaux qui justifient ce modèle d’architecture. Dans le sillage des initiatives académiques, l’industrie et le secteur bancaire s’en sont emparés pour résoudre leurs problèmes complexes : valorisation et analyse de risque pour la finance, détection de gisements pour le pétrole, simulation et analyse de crash pour l’automobile. Aujourd’hui, les grilles intéressent les médias, les jeux en ligne, les fournisseurs internet…

2.     Quels bénéfices attendre du grid computing ?

Le grid computing peut apporter beaucoup aux secteurs tant privés que publics pour les projets qui requièrent une quantité importante de puissance de traitement dans une période de temps restreinte.

Les bénéfices attendus d’une grille sont :

• l’amélioration des performances tout en limitant les coûts,
• l’augmentation de la flexibilité d’une infrastructure pour absorber les augmentations d’échelle,
• la haute disponibilité de cette infrastructure faces aux pics de charge.

Les vertus « informatiques » du grid computing se transforment en atouts « métiers » : réduire les temps de calculs, c’est éviter les retards ou gagner du temps pour accroître la compétitivité et/ou pour améliorer ses processus.

Les middlewares « commerciaux » (citons pour l’exemple ceux de Platform Computing, Tibco Datasynapse, GridGain en open source) ont bien saisi ces enjeux. Développés à la suite des grilles académiques par transferts technologiques, ils tirent profit de ces besoins en proposant des solutions sur étagères et leur expertise.

Certes, ils évoluent sur un marché de niche, celui  constitué des clients historiques (banques, industries du pétrole, de l’automobile etc.). Mais avec la croissance exponentielle des volumes d’information, qu’il s’agisse d’événements (CEP) ou de données (Big Data), et la nécessité de les exploiter, le positionnement du grid computing pourrait bien se renforcer.

3.     Quels sont les défis à relever ?

Le concept de grid computing, ainsi que les produits du marché, sont arrivés à maturité au cours de la dernière décennie. Pourtant, il reste encore quelques barrières à franchir pour assister à une démocratisation de cette approche :

• L’expertise et le support des grilles informatiques ont un coût : il faut des techniciens qualifiés pour passer la barrière technologique des produits, ou développer/maintenir une grille « maison », mais aussi « gridifier », c’est-à-dire adapter ou développer des applications pour une exécution sur la grille. A ces coûts s’ajoutent ceux des problématiques connexes tels que le stockage ou le transfert des données.
• De plus, l’infrastructure peut nécessiter un investissement dédié.Chaque entreprise dispose généralement d’un ensemble conséquent d’ordinateurs connectés en réseau mais l’usage en grille de ces ressources existantes n’est pas évident :
  • La tendance à la virtualisation a progressivement optimisé l’usage des ressources serveurs qui sont moins sous-exploités qu’il y a une dizaine d’années.
  • Les préoccupations énergétiques interrogent sur l’intérêt, en entreprise, du modèle des grilles fondées sur des parcs d’ordinateurs peu puissants.

Pour autant, le grid computing n’est pas nécessairement l’apanage des grandes structures. Internet autorise le partage de ressources avec des partenaires extérieurs : des PME, des écoles ou des hôpitaux  peuvent se fédérer pour bâtir des grilles qui leur sont inaccessibles, seuls.

• Les grilles de calcul imposent un modèle d’architecture bien spécifique au sein du SI. De part leur caractère intrusif, elles exigent de trouver des solutions ou des compromis notamment en matière de sécurité mais également de dépasser les aprioris quant aux partages des ressources.

Pour autant, le plus gros des défis, pour les acteurs du marché, sera celui du marketing. Le grid computing doit aujourd’hui savoir se faire entendre face à des concepts phagocytaires car, quand il est question de « computing », le « cloud » vient brouiller les pistes.

Pour l’heure, si l’entrée sur le marché d’IBM ne résout pas ce problème d’image, il confirme en revanche l’intérêt du modèle de « grille » et préfigure une tendance, celle de l’intégration. L’avenir du grid computing est, sans doute, au cœur, mais, dans l’ombre du « cloud ».

Pour lire plus d’articles sur le secteur de l’énergie, cliquez ici.

Cet article Quel avenir pour le grid computing ? 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.