Cloud computing et Opportunités pour les DSI (africaines)

De nos jours la plupart des DSI sont confrontées à la problématique budgétaire. Les marges financières des entreprises ne permettent plus d'investir beaucoup dans l'informatique ni même de maintenir l'existant, et cela malgré la croissance des besoins dans le domaine.
Les informaticiens ne doivent plus se contenter de délivrer des résultats mais ils doivent le faire avec moins de moyens. Bref ils doivent être efficients !
Pour faire face à cette situation les DSI doivent de plus en plus faire appel au concept de cloud computing pour réduire de façon substantielle les dépenses IT.
En quoi consiste le cloud computing ? Quels sont ses différents modèles ? Quels avantages et quels inconvénients ? Quelle stratégie adopter ? Autant de questions auxquelles je vais essayer d'apporter des éléments de réponse dans ce billet.
Le Cloud computing ou Informatique en nuage consiste à utiliser à la demande des ressources informatiques mutualisées en libre service. Ces ressources peuvent être des serveurs d'application ou de bases de données, des applications, etc.
On distingue généralement trois modèles de cloud computing à savoir:

• Infrastructure as a Service (IaaS): Ce modèle consiste à utiliser à la demande les capacités de traitement et/ou de stockage d'une infrastructure hébergée en dehors de l'entreprise. Cela permet d'optimiser les ressources matérielles à acquérir ainsi que la consommation en énergie et en espace d'où une baisse importante des coûts liés à l'acquisition de serveurs (Capex) et ceux liés à leur exploitation (Opex). Ce modèle permet aussi d'améliorer considérablement le taux de disponibilité des équipements.
• Platform as a Service (PaaS): Ce modèle permet, en plus de l'infrastructure, d'utiliser de façon mutualisée à la demande et en libre service les frameworks de développement et autres middlewares comme les serveurs d'applications et de bases de données hébergées sur un site distant. Par exemple une entreprise qui dispose d'applications LAMP pourrait payer uniquement les frais d'accès à un éditeur PHP pour ses développeurs, un espace sur un serveur Apache et une base MySQL. Les informaticiens accèdent librement aux ressources leur permettant de développer leurs applications , les déployer et les exécuter. L'entreprise, en plus des avantages liés au modèle IaaS, économise sur les paiements de licences pour les middlewares et leurs coûts d'exploitation, réduit les interventions humaines et les délais de déploiement.
• Software as a Service (SaaS): En plus de l'infrastructure et des middelwares ce modèle permet d'utiliser une application distante et mutualisée à la demande et en libre service. Les utilisateurs accèdent aux applications et l'entreprise est facturée à l'usage. Par exemple une entreprise pourrait décider d'avoir son CRM en SaaS, ainsi elle paiera par exemple que pour le nombre de prospects, comptes et affaires créés. Il en ressort clairement une réduction importante des coûts fixes dans les budgets IT.

Le concept de cloud apporte certes des avantages énormes de scalabilité et d'optimisation de coûts mais il présente aussi quelques inconvénients qu'il faut prendre en considération. Il s'agit surtout de :

• La sécurité des données stockées dans le nuage.
• La localisation des données étant abstraite, cela pose quelques problèmes juridiques car certains pays interdisent le stockage à m'étranger des données liées à leurs citoyens.
• La qualité du service en cloud dépend beaucoup de la fiabilité du réseau (sécurité et bande passante). Ce qui est un frein important pour certains pays africains ayant une bande passante très limitée pour l'accès à Internet.

L'adoption du paradigme de cloud computing passe par le choix d'architectures standards. Il faut standardiser l'infrastructure à travers l'adoption des technologies de virtualisation. Il faut ensuite cartographier l'existant afin de déterminer les applications qui peuvent être "nuagisées" et celles qui ne pas l'être. Les critères pourraient être la consommation en ressource, l'architecture logicielle, la sécurité des données etc. Les applications les plus aptes à passer au cloud sont celles développées selon le modèle SOA.

Urbanisation du Système d'Information

L'urbanisation du Système d'information consiste à le faire évoluer pour l'aligner sur la stratégie et aux besoins métiers de l'entreprise suivant des règles d'architecture SI. Cette activité est aujourd'hui capitale pour disposer d'un SI créateur de valeur ajoutée et qui participe à l'exécution de la stratégie de l'entreprise. Globalement en quoi consiste le processus d'urbanisation ? Quels sont les outils qui le permettent ? Quels sont ses apports dans le management du SI ?
Voilà des questions aux quelles je vais essayer de répondre dans ce billet.

Le processus d'urbanisation passe par les étapes suivantes:

1. Modélisation de la stratégie et des besoins métiers de l'entreprise: A cette étape il faut répondre aux interrogations suivantes: Quels sont les besoins des métiers en matière de système d'information ? Quelle est la stratégie autour de la quelle l'entreprise cherche à développer son business ?
Ensuite il faut modéliser ces besoins et bien les spécifier.

2. Modélisation de l'existant SI: Ici il faut cartographier les 4 niveaux de l'architecture SI tels que préconisés à savoir
- L'architecture métier qui décrit les processus métiers de l'entreprise
- L'architecture fonctionnelle qui décrit les fonctions qui supportent les processus métiers décrits dans l'architecture métier
- L'architecture applicative qui donne les applications qui supportent les fonctions décrites précédemment
- Et enfin l'architecture technique qui décrit les infrastructures techniques qui supportent les applications.

Une fois muni de ces deux modélisations (Existant SI, enjeux et stratégie business) le vrai travail de l'urbaniste SI commence et cela consiste à:

3. Étudier la cible SI qui permettra de répondre aux enjeux business recueillis et modélisés tout en respectant les règles de l'état de l'art.
En partant de l'existant SI il faut définir la trajectoire à suivre (un ensemble de scénarii) pour arriver à la cible et évaluer les moyens humains et financiers permettant d'atteindre cette cible. Cette étape est sans doute la plus difficile mais aussi la plus passionnante car c'est à ce niveau que l'urbaniste exprime son génie et sa capacité à définir, planifier et évaluer un SI aligné sur les besoins métier.

Il faut noter que pour un besoin de cohérence du processus global il est important de valider à chaque étape les livrables. En effet il faut s'assurer de bien modéliser la stratégie de l'entreprise en la validant avec les métiers et s'assurer aussi de bien cartographier le SI existant en validant sa cartographie avec les experts informatiques.

Aussi pour mener à bien un projet d'urbanisation il est important de s'assurer que l'instance dirigeante de l'entreprise est convaincue de la nécessité d'un tel projet et des apports qu'il peut apporter à son SI. Il faut aussi avoir l'adhésion des équipes et leur forte implication dans le projet.
Sans ces pré requis un projet d'urbanisation court non seulement les risques de partir sur de mauvaises modélisations de la stratégie business et de l'existant SI mais aussi de proposer un plan d'urbanisation qui sera inapproprié et non partagé.

Dans cette ère nouvelle où l'alignement stratégique du Système d'information est indispensable à l'entreprise pour atteindre ses objectifs métiers l'urbanisation de ce dernier se présente comme un passage privilégié pour ne pas dire obligé.

Gouvernance des SI

Je préfère vous le dire tout de suite: Ce billet n'est pas un cours de gouvernance des systèmes d'information et n'a pas la prétention de l'être. Il s'agit plutôt d'idées amassées ici et là et mises en pratique pour certaines dans des contextes assez intéressants. Le management des systèmes d'information est une science vaste sur la quelle vous trouverez beaucoup de documentation car la recherche dans ce domaine est très active, ce qui démontre bien de l'importance du sujet.
La gouvernance est une composante très importante du management des systèmes d'information et a pour objectif principal de permettre au SI de créer de la valeur et dépasser la vieille conception du SI comme simple centre de coûts. On y retrouve généralement les thèmes suivants:
- L'alignement stratégique du SI avec les métiers
- L'organisation et la planification du SI
- L'évaluation des performances du SI
Je vais donner quelques commentaires sur les thèmes précédents.

** L'alignement stratégique du SI consiste à inscrire ce dernier dans une dynamique de déclinaison des objectifs de l'entreprise en objectifs informatiques. Le modèle d'Henderson et de Venkatraman décrit les différents types d'alignement qu'on peut trouver. Ce modèle décrit quatre stratégies qui décrivent le SI comme une exécution de la stratégie de l'entreprise, un potentiel technologique, un potentiel concurrentiel ou un centre de services. On peut aussi trouver dans une même organisation une combinaisons de ces stratégies. Par exemple chez un opérateur télécom on doit avoir les entités en charge de l'innovation comme un potentiel technologique et concurrentiel et les entités en charge des applications métiers seront vues comme une exécution de la stratégie de l'entreprise ou centre de services selon leur maturité.
** L'organisation et la planification du SI a trait aux différents outils permettant de pérenniser l'existant et de garantir l'évolutivité. Pour pérenniser l'existant il est important d'aborder une démarche d'urbanisation qui s'appuie sur une cartographie claire des différentes fonctions ainsi que les couloirs de passage (interfaces) entre ces fonctions. Planifier le SI consiste à avoir une vision de la direction à suivre à travers l'élaboration d'une roadmap c'est à dire un schéma directeur SI.
** Le pilotage du SI passe par la mesure des performances de celui-ci, performances qui se mesurent à travers des indicateurs clés. Le IT Scorecard est un outil de pilotage SI qui décrit cinq volets à savoir la contribution du SI au business, la maîtrise des coûts du SI, la performance des processus SI, la gestion des compétences pour une prise en compte du futur et l'orientation utilisateurs.

Évidemment d'autres thèmes existent sur le sujet de la gouvernance qui est un domaine très évolutif et j'espère que j'aurais le temps matériel d'aborder ces thèmes dans de futurs billets.

Le fossé technique-fonctionnel

Force est de constater qu'aujourd'hui de plus en plus de projets informatiques sur la production logicielle débouchent sur un chaos total caractérisé particulièrement par la non-satisfaction des utilisateurs finaux et des délais de réalisation sans cesse prolongés, Et ce en dépit d'une forte croissance des technologies de développement logiciel. Les frameworks de développement pullulent partout et il est même difficile de faire un choix. Il y a quelques années nos ainés utilisaient des outils/langages basiques comme basic, cobol, vb etc. mais produisaient des logiciels de grande qualité, c'est ce qui explique d'ailleurs l'entêtement de certaines entreprises à ne pas se débarrasser de leurs vieux logiciels sur écran console malgré la pauvreté des IHM. Elles se disent satisfaites de ces logiciels qu'elles trouvent bien adaptés à leurs besoins fonctionnels. Il faut dire que nos ainés étaient beaucoup plus préoccupés des aspects fonctionnels que nous. Ils passaient beaucoup de temps sur les sujets de réccueil de besoins, de spécifications et de modélisation que sur le développement. Aujourd'hui la tendance des équipes de production logicielle est plutôt vers la maîtrise des technologies plutôt que la maîtrises des méthodes de récceuil de besoins ou de modélisation. Les informaticiens d'aujourd'hui se sentent plus fiers de connaître les plateformes JEE, .Net ou PHP5 que de connaître les méthodes RUP, 2TUP. A mon humble avis c'est là où le bat blèsse, les équipes de production logicielle sont plus techniques que fonctionnelles et développent des logiciels à la pointe des technologies mais fonctionnellement inadaptés aux besoins des utilisateurs finaux. Le fossé technique-fonctionnel s'agrandit de plus en plus en faveur de la technique et ce au grand désarroi des consommateurs de logiciels.

SOA et BPM: Un couple presque parfait!

Une bonne gestion des processus métier contribue beaucoup dans l'accroissement des performances de l'entreprise en ce sens qu'elle permet de réduire énormément les pertes de temps et d'augmenter l'efficacité opérationnelle à travers l'élimination des tâches n'ayant aucune valeur ajoutée. Mieux encore, lorsque les processus sont bien cartographiés, automatisés et pilotés cela donne une visibilité claire sur les performances de l'entreprise et les points à améliorer. Pour ce faire la gestion des processus métier gagne à s'appuyer sur des outils et méthodes éprouvés. C'est ce qui explique l'orientation des éditeurs d'outils BPM vers l'adoption de langages standards de modélisation de procédures basés sur XML et l'utilisation des web services comme moyen d'interfaçage avec les système d'information d'entreprise. Les processus métiers utilisent de plus en plus les architectures orientées services (SOA).
En effet SOA est devenu la pierre angulaire de l'urbanisation des systèmes d'information au vu de son apport dans l'interopérabilité et l'intégration applicative; depuis que les web services XML connaissent un essor tel qu'ils s'imposent comme les fondamentaux d'une architecture pérenne. L'utilisation de ces architectures dans la gestion des processus métier apporte aux entreprises une grande souplesse dans l'interaction entre ceux-ci et le système d'information.
Par exemple un processus automatisé de gestion de notes de frais est beaucoup plus efficace lorsqu'il communique directement avec le système de gestion de paie. Nous pouvons imaginer aussi un processus dont les différents nœuds de traitement interagissent avec les éléments du SI, il est évident que pour des raisons de souplesse et de réutilisabilité ce processus est plus facilement optimisable si ses interfaces avec le SI sont basées sur des web services. La cerise sur le gateau serait que ce même processus puisse être ré-utilisé dans un autre processus simplement comme un service, eh bien cela est rendu possible grâce au langage BPEL4WS. En effet l'orchestration des processus métier grâce à BPEL est l'autre trait de charme qui a facilité et facilite encore le rapprochement de SOA et BPM qui donnent l'air d'être un couple presque parfait.

Histoire d'un Lancement de SI chez un Opérateur Fixe/Mobile/Internet

Le 21 Avril 2008 j'arrive chez un opérateur FMI durant son lancement from scatch en tant que chef de projet SI. Lors de mon entretien avec le DSI les objectifs qui m'étaient assignés consistaient d'abord à suivre la mise en place du SI, en faire la recette et gérer les anomalies et évolutions en relation avec un intégrateur. C'était une activité difficile d'autant plus que le SI était composé de sous-systèmes qui n'avaient jamais été intégrés ensemble d'où de fréquents problèmes d'interfaces. Ce SI était composé d'un CRM, d'un système de provisionning et d'activation, de deux plateformes de médiation (Active et Passive), d'un système de valorisation et de Billing. Tout ceci est classique pour un SI d'opérateur Telecom, seulement l'intégration avait été difficile.

Les vrais problèmes avaient commencé après les installations et paramétrages c'est à dire après le lancement, sur la gestion des bugs car il y en avait beaucoup. Plusieurs fonctionnalités importantes ne marchaient pas. On ne pouvait pas par exemple faire les opérations de changement de SIM ou même de MSISDN. En plus, une fois qu'un client a choisi une offre il ne pourra plus la changer car les changements d'offre n'étaient pas possibles ni en montée ni en descente de gamme. Ce SI était vraiment une catastrophe informatique. Lorsqu'on lance une opération il faut croiser les doigts pour qu'elle arrive à terme.

Vous comprenez bien que j'étais dans une situation difficile en face d'utilisateurs loin d'être satisfaits et d'un intégrateur peu réactif. Chaque jour nous découvrions de nouvelles anomalies et je les reportais via notre process de gestion d'anomalies. Je m'assurais que toutes les anomalies étaient tracées et prises en compte. Je passais des heures au téléphone avec le chef de projet MOE à décrire les anomalies et à négocier des dates de livraison de correctifs et/ou évolutions.

Quand j'ai la chance d'avoir une nouvelle livraison la recette sortait d'autres nouvelles anomalies, des régressions. Je passais des journées très stressantes à contourner les anomalies surtout concernant les opérations quotidiennes sur le CRM, le Bus, la médiation, etc. Et quand arrive la fin du mois il faut veiller des nuits entières pour corriger les factures, passer des journées entières pour les imprimer. Chaque cycle de facturation était un calvaire. Pour couronner le tout le GPRS/EDGE n'était pas facturé parce que l'interface entre le GGSN et la plateforme de médiation active n'était pas fonctionnelle. J’avais réuni une grosse équipe d'experts et on passait plusieurs heures de conférence téléphonique pour tenter de résoudre le problème. Il faut dire qu'avec ce SI chaque semaine j'avais une nouvelle livraison soit pour corriger des anomalies soit pour apporter une évolution pour permettre une fonctionnalité prévue dans le document d'architecture fonctionnelle mais qui n'a jamais marché. De livraison en livraison on était arrivé la trentième version du CRM pou avoir un minimum de confort dans l’usage. Mes clients internes avaient commencé à desserrer les mines, ils avaient de plus en plus confiance à ce SI et nous avons même été retenus pour un prix SI du groupe. Aujourd’hui je regarde ces temps passés sur ce SI avec beaucoup de fierté et de réjouissance. Depuis, je suis passé à autre chose: L'automatisation des processus métier et la gestion des projets de services à valeur ajoutee.

Gestion du relationnel pour les responsables Informatiques

Lorsqu'on se trouve en tête d'une cellule informatique la gestion du relationnel est très importante car elle influence en grande partie l'atteinte des objectifs de la cellule. Le responsable informatique est souvent en relation avec trois catégories de personnes en l'occurrence les clients internes de l'entreprise, les fournisseurs et ses propres collaborateurs.
Les clients internes attendent du service informatique que celui-ci l'aide dans l'atteinte des objectifs de l'entreprise en leur mettant à disposition des moyens de communication adéquats, des matériels et logiciels fonctionellement adaptés à leurs besoins et surtout un support technique réactif.
Le client interne tout comme le client externe a aussi ses caprices qu'il faut savoir gérer à travers une communication sereine et rassurante, des procédures claires et compréhensibles d'accès aux services informatiques. C'est dans l'objectif de satisfaire ses clients internes que le responsable informatique fait appel à des fournisseurs externes pour la fourniture de matériels, logiciels et services. Face à ces fournisseurs le R(S)I exprime ses besoins et garantit les plannings de livraison en gardant toujours à l'esprit un rapport qualité/prix intéressant. Pour ce faire il doit donc avoir de bonnes capacités de négociation et un bon réseau professionnel pour l'aider dans le choix.
Pour atteindre ses objectifs le R(S)I doit surtout s'appuyer sur ses collaborateurs. Pour la réussite de cette relation, le R(S)I doit se conduire en bon manager. La motivation des collaborateurs, leur adhésion au projet, leur responsabilisation ainsi qu'un climat de confiance mutuelle permettent au R(S)I d'assurer une bonne relation avec ses collaborateurs.
Le R(S)I étant un acteur important dans la réalisation des objectifs communs à toute l'entreprise, il est important qu'il aie un relationnel facile qui s'inscrive dans ce sens.