En 2001, en travaillant dans un BICC (BI Competence Center), j’entamais une réflexion avec mon client sur la définition de l’offre de service que devait porter le BICC vis-à-vis des différents métiers demandeurs de solution décisionnelle. Ce travail nous avait alors permis, sur la base de l’identification et la classification des grands besoins de nos utilisateurs, de proposer une matrice de décision aiguillant les projets vers la solution la plus adéquate (2 architectures et 3 solutions logicielles différentes à l’époque). C’était intéressant et innovant à l’époque même si le champ des possibles était encore assez restreint.
Les choses ont bien évolué depuis sous l’impulsion de différentes rationalisations, de l’évolution des usages, des innovations technologiques et bien entendu de l’avènement du courant Big Data. En prenant un petit raccourci, on peut dire que ce qui caractérise aujourd’hui ces évolutions a été résumé par Leo Apotheker, pourtant ex-CEO de SAP et HP, en une 1 phrase à l’USI : « one size doesn’t fit all ».
Fort de cette affirmation et du bilan positif des travaux réalisés en 2001, ce travail me parait incontournable aujourd’hui à l’échelle d’une entreprise ou d’un domaine de celle-ci. Cependant, ce qui se limitait à l’époque à une réflexion autour des outils et des architectures se doit d’être étendu à une réflexion sur les méthodologies et les processus qui ne sont pas restés figés non plus. L’incidence du choix d’une architecture ou d’un logiciel est évidente mais il en va de même des méthodes et des processus comme l’illustrent ces interrogations :
Mon cycle en V est-il une bonne solution pour répondre à tous mes besoins ? Certains besoins ne méritent-ils pas une approche plus itérative, voire une mise en flux de la demande ?
Mon processus industriel est-il adapté à toutes les situations? Comment répondre à des demandes urgentes ? Comment adresser des besoins non industriels mais nécessitant une approche d’innovation ?
C’est bien joli tout ça mais pour quoi faire ?
Voici un petit extrait non exhaustif et non contextualisé des raisons qui m’amènent à faire cette recommandation en général :
Parce que les besoins métiers autour du décisionnel se sont diversifiés et que la politique de l’autruche n’a qu’un résultat : la mise en place de solution de contournement par les métiers
Parce que les technologies actuelles fournissent de nouvelles opportunités souvent ignorées par les BICC et par les métiers, et que c’est du devoir d’une DSI d’être force de proposition
Parce qu’entre une approche de rationalisation extrême et une approche « best of breed », il y a un juste milieu. Les SI décisionnels monolithiques utra-rationnalisés ont vécu.
Parce qu’une réponse à un besoin, ce n’est pas seulement une architecture et un software mais cela regroupe aussi des méthodes, des processus, voire une organisation
Et une petite pour la fin (ma préférée du moment) :
Parce que cela permet d’instruire une nouvelle demande du business rapidement, basée sur des critères univoques permettant d’éviter de rentrer dans des débats d’expert (cas du conflit classique entre une MOA technique et une MOE)
Bon et ça ressemble à quoi une offre de service ?
De façon schématique, ça pourrait ressembler à ça :
Pour être un peu plus explicite, voici quelques exemples d’offres de service classiques :
Offre de service « reporting de masse automatisé »
Usages : Reporting très industrialisé et automatisé pour une diffusion large de rapports paramétrables
Architecture : Datawarehouse et datamart
Exemple d’outils : BusinessObjects, Cognos sur un SGBDR si la volumétrie reste raisonnable (<15 To) sinon une Appliance est préférable
Méthode : cycle en V ou agile
Processus : industriel utilisant les processus standards de l’entreprise éventuellement aménagés au contexte décisionnel
Architecture : datawarehouse comprenant un espace de stockage personnel ou collaboratif permissif (écriture, import notamment). Un espace de type Hadoop pour certains traitements MapReduce ou pour le stockage de données complémentaires (volumétrie >100 To)
Exemple d’outils : stack Hadoop, SAS, SPSS, R studio
Méthode : cycle en V sur la fourniture des données
Processus : industriel sur le datawarehouse, innovation sur la partie relative au laboratoire
Offre de service « archivage en ligne » :
Usages : Stocker et conserver en ligne (càd disponible) des profondeurs d’historique habituellement purgées ou mises sur bandes
Exemple d’outils : Hadoop, Cassandra et outils de restitution compatibles (Tableau notamment)
Méthode : cycle en V
Processus : Industriel
Offre de service « prototypage » :
Usages : En phase amont d’un projet décisionnel pour qualifier par exemple la faisabilité, ou de manière indépendante pour tester un concept innovant
Architecture : environnement de type bac à sable quelle que soit l’architecture
Exemple d’outils : Outils de virtualisation (Composite Software par exemple), Amadea, Spotfire, SAS, MySql
Méthode : Agile
Processus : Innovation
Pour conclure
Si je reste plutôt convaincu par cette démarche, elle n’est malheureusement pas exempte de quelques pièges ou anti-pattern :
L’offre de service figée dans le marbre : du fait de l’entropie ou de l’arrivée de nouveaux concepts, une offre de service est bien entendu quelque chose qu’il faut faire évoluer régulièrement
L’offre de service exhaustive : ça c’est du stock au sens Lean ; d’abord la moitié des services proposés ne serviront jamais et en plus cela nuit à la lisibilité du modèle. Quelques offres bien sentis ont bien plus de valeur qu’un catalogue sans fin
L’offre de service IT : il faut répondre à des besoins métiers, alors les dernières bases NoSQL, c’est intéressant de les tester en essayant d’avoir des use cases en tête. De plus, l’offre de service doit être compréhensible par les métiers et, ça va mieux en le disant, construite avec lui
Enfin, dans une période d’investissement en baisse au sein des DSI, je me permettrai un denier conseil : un juste compromis entre rationalisation et profondeur de l’offre de service doit être trouvé.
