Tels des escadrons de cavaliers des temps modernes, les cellules PMO assistent les Dirigeants et directeurs comme le faisait en son temps les aides de camp de Napoléon et de ses maréchaux. Le contexte et les conditions ont évolué mais les exigences de visibilité et de coordination entre objectifs, ressources et contingences restent d’actualité.
De longue date, nous savons que les directions œuvrent à la transformation de l’entreprise en anticipant plus qu’en réagissant aux menaces et opportunités qu’elles rencontrent. Pour ce faire, elles gèrent leurs activités d’exploitation et d’investissement pour créer de la valeur. Les attentes sont distribuées dans toutes l’organisation (à la fois verticalement et horizontalement). Historiquement les directeurs de programmes dans les directions SI et plus récemment les directions métiers, ont mis en œuvre et développé les techniques et pratiques de Gestion de Portefeuille Projets. Chacun, à son niveau, y recherche des moyens d’optimiser ses ressources avec le souci d’obtenir la valeur et plus classiquement de satisfaire les intérêts de l’entreprise.
Un rôle déterminant pour les organisations
Plus aucun secteur d’activité économique n’est exempté de devoir gérer et maîtriser finement ses finances et l’utilisation de ses ressources. L’optimisation de l’allocation des investissements implique une attention toute particulière sur l’alignement stratégique du portefeuille de projets. Issue de ces investissements, le portefeuille de projets exige à son tour un pilotage pour évaluer son contenu. Ici, il n’est plus question de contraindre les chefs de projets à se conformer à un travail administratif, mais de leur fournir les outils à même de les aider à concrétiser la valeur du travail de leurs équipes et en apporter la visibilité à leurs responsables.
La responsabilité de la cellule PMO est à la fois d’analyser et de surveiller la matérialisation de la valeur des engagements pris par les projets. Il importe pour l’entreprise de la pérenniser en formalisant et en aidant la direction à décider à partir d’éléments factuels et qualitatifs via le pilotage dans le temps de la valeur du portefeuille des projets.
Quel que soit le niveau de rattachement de la cellule PMO, elle agit au cœur d’un réseau de relations humaines. Elle est à la croisée des préoccupations des différents responsables de l’entreprise. Son influence dans les relations est à la fois directive et collaborative, toujours dans le souci de servir la stratégie de l’entreprise. Chaque cellule occupe un positionnement transverse qui lui permet d’assurer une fonction qui cumule des responsabilités d’analyse, de gouvernance, et d’administration des données du portefeuille avec ou sans outils.
Elles ont pour rôle de planifier, créer, évaluer, soumettre à arbitrage les projets/programmes dans le portefeuille et de communiquer sur les priorités du portefeuille et les informations d’état des investissements en cours. Ce positionnement vise à l’obtention de la valeur des projets. Essentiellement active dans les instances et travaux de consolidation, elles font face à des exercices d’influence qui peuvent s’apparenter à du lobbying pour maximiser les affectations des directions et ce parfois au détriment des objectifs stratégiques.
Un dispositif garantissant la bonne conduite des projets
La conduite des activités PMO comprenant la planification, le contrôle et le pilotage du portefeuille implique du responsable qu’il définisse le dispositif d’évaluation en continu de son portefeuille. Elle inclue d’Accompagner les managers et les opérationnels des projets de transformation dont ces derniers ont la responsabilité. Ces activités visent à développer les capacités de l’organisation à garantir la maîtrise des projets tout au long de leur déroulement. Ces capacités sont essentielles pour porter une vision consolidée et ordonnée du portefeuille qui permet à la fois à la direction d’agir et réagir de façon approprié, mais aussi d’atteindre un meilleur alignement stratégique avec les métiers et fonctions transverses de l’entreprise.
La cellule PMO porte également une responsabilité de performance du portefeuille face à la complexité des projets à conduire. En effet, les besoins, les contraintes, contingences et dépendances émergent de toutes parts touchant tout autant le patrimoine organisationnel que le portefeuille IT. Pour cela, il lui incombe de produire une représentation de la performance du dispositif, toujours dans la perspective de concrétiser la valeur attendue des projets. Ce travail de formalisation des pratiques à mettre en œuvre et des données à analyser participe à la rationalisation des prises de décision.
Enfin dans certaines circonstances, le dispositif peut inclure la coordination Fonctionnelle/Technique des adhérences et des dépendances qui apparaissent entre les projets.
En complément, face à la multiplication des sources de données et de leur traitement en masse, la cellule PMO dispose d’un référentiel de données stratégiques pour l’entreprise. Les solutions PPM sur le marché répondent toutes à deux enjeux que sont l’amélioration de l’efficience opérationnelle recherchée (allègement du coût d’exploitation des applications et aide à la prise de décision documentée) et l’amélioration de l’efficacité organisationnelle (partage de l’information entre les entités et directions). L’apport initial de ces solutions reste l’industrialisation des activités de gestion de projet essentiel à l’amélioration de l’engagement des projets à mener. Ces solutions ouvertes sont à même de couvrir les exigences de complétude, de qualité, de cohérence et de disponibilité des données quel que soit le modèle organisationnel mis en œuvre.
Un maillon majeur pour gérer incertitude et complexité
Dernière prérogative de la cellule PMO, œuvrer à réduire le niveau d’incertitude attaché aux projets qui compose le portefeuille. Pour cela, son positionnement transverse dans l’organisation en fait le relais idéal du développement d’une culture de la gestion des risques. Toutes les activités évoquées dans le champ de la Gestion Portefeuille Projets visent à appréhender les différentes formes d’incertitude et de complexité auxquelles les programmes et directions peuvent se trouver confrontées. Réduire l’incertitude implique à tous les acteurs de poser et d’accepter de reprendre les hypothèses pour les adapter aux circonstances rencontrées.
De son côté la complexité croissante des enjeux à servir est source de contradictions au sein de l’entreprise. Elle impose à la cellule PMO de rompre les silos organisationnels et de faire preuve d’empathie envers ses parties prenantes pour parvenir à tisser des liens entre acteurs, entités, et disciplines. C’est à elle qu’il revient de multiplier les points de vue à même de relier les idées nécessaires aux décideurs.
Après plusieurs années d’accompagnement sur ces sujets, nous avons forgé des convictions fortes dans ce domaine d’intervention :
Qu’elle rende la Gestion de Portefeuille de Projet, levier de création de valeur au service de la stratégie des entreprises.
Qu’elle soit reconnue comme un relais d’information au sein du réseau d’acteurs des directions métiers et fonctions supports de l’entreprise.
Qu’elle tienne un rôle d’acteur catalyseur des capacités de l’organisation à mener à bien ses projets et activités récurrentes dans un cadre de travail connu de tous.
Qu’elle devienne le référent de l’expérience des projets métiers et technique en ce qui concerne la masse de données issues de sources multiples à traiter pour piloter les projets.
Enfin, qu’elle est un agent responsabilisant les acteurs de l’organisation dans la gestion des risques à même de réduire l’incertitude intrinsèque à toutes activités entrepreneuriales et de transformation.
Son crédo en somme : « Bien faire le travail pour faire du bon travail ».
Les transformations de l’entreprise impliquent rapidement un nombre importants de directions, une multitude de collaborateurs, internes ou externes. Les dépendances entre tous ses acteurs vont croissant et sont changeantes. Comme du temps des épopées Napoléoniennes, lorsque les aides de camp sur le champ de bataille avaient un rôle déterminant dans la victoire, la GPP, est aujourd’hui une activité essentielle pour toute direction moderne.
Dans ce troisième et dernier volet de notre parcours 360° de l’IoT, nous vous proposons de porter notre regard sur les promesses de l’IoT et de nous intéresser par la même occasion aux grandes problématiques techniques et organisationnelles à adresser lors, notamment, du passage à l’industrialisation de vos expérimentations IoT.
Les promesses de L’IoT
Nous l’avons vu lors des deux précédents volets de nos publications, l’IoT est rendu accessible à tous, dans tous les secteurs d’activités et pour des cas d’usages très variés. Cependant, que puis-je en attendre? Voici quelques éléments de réponse.
Moi, entreprise
Développer des services innovants pour fidéliser mes clients et en capter de nouveaux
Générer de nouvelles sources de revenus
Me démarquer de la concurrence
Utiliser les données pour tendre vers le service sur mesure et anticiper le besoin client
Optimiser ma productivité et mes processus
Réduire mes coûts à tous les niveaux
Moi, employé
Faciliter mon travail au quotidien
Augmenter la sécurité et diminuer la pénibilité
M’aider à avoir des insights opérationnels précis
Et ainsi m’aider à me focaliser sur les activités à valeur
Réaliser du prévisionnel pour anticiper les défaillances
Me faciliter les prises de décisions
Moi, utilisateur final
Disposer d’un environnement de vie conforme à mes habitudes
Sécuriser mes biens personnels et mon mode de vie
Réaliser des économies en fonction de mes propres usages
…Et ses démons !
Un potentiel énorme, de nombreuses promesses mais des problématiques tout aussi nombreuses à prendre en considération sur l’ensemble de la chaîne de valeur IoT.
Parcourons ensemble cinq éléments clés pour la bonne réussite des transformations IoT :
L’interopérabilité au centre des enjeux
Multiplicité des acteurs et des technologies sur l’ensemble des maillons de la chaîne IoT,
Complexité liée au contexte mouvant du marché de l’IoT et le manque certain de standardisation.
Ainsi, les choix technologiques et techniques (applicatifs et infrastructures) doivent être fait avec la vision d’un écosystème global, interconnecté et interopérable.
La sécurité, une problématique globale à maîtriser
Une multitude d’objets éparpillés sur le terrain et accessibles.
De nouvelles briques techniques et autant de portes d’entrée vers le SI.
Le sujet de la sécurité est prédominant dans les problématiques IoT actuelles du fait de l’industrialisation des projets. Il convient d’aborder le spectre de la sécurité sur toutes les phases de construction (approche Security By Design) de la chaîne de valeur IoT.
La protection des données personnelles
Les nouvelles législations autour de la GDPR, des projets de lois de protection des données de Santé, etc. sont autant de freins à la valorisation de l’IoT qui a pour but premier de collecter facilement et massivement des données du terrain.
Les modèles de traitement, d’analyse, de stockage et d’exposition des données doivent tenir compte des évolutions réglementaires et être adaptés en conséquence.
Le traitement des données
L’IoT doit être considéré comme une source de données du Big Data. La flotte d’objets (hétérogènes) génère au fil de l’eau un important volume de données, à grande vitesse et avec des formats variés.
Pour donner une valeur business forte à ces données, il est nécessaire de réaliser des corrélations avec le reste du patrimoine data de l’Entreprise.
Cette dernière doit donc avoir entamée une transformation autour de la Gouvernance Data et adoptée un SI Data Centric.
La gouvernance IoT, un réel facteur clé de succès
L’IoT transforme en profondeur les métiers et les offres traditionnelles. Les changements à effectuer sont complexes et transverses nécessitant une proximité forte entre des équipes métiers et DSI, après tout, l’IoT a avant tout une finalité business !
Il convient donc à chaque entreprise, pour réussir sa transformation IoT, de définir et mettre en place une gouvernance associée qui portera les messages, réalisera la mise en oeuvre et assurera que les métiers sont formés et outillés pour exploiter ces nouveaux gisements de valeur.
Comment la définir ? quels sont ses missions concrètes ? Quels sont les bonnes pratiques ? Comment et quand intégrer le métier ? Comment…
Tous ces différents points seront étudiés, illustrés dans un article dédié à la #Gouvernance IoT.
Sur cette belle lancée, restez avec-nous 🙂
Dans quelques jours, nous vous présenterons notre approche et les clefs pour répondre rapidement et efficacement aux initiatives IoT de vos métiers.
Et vous quelles problématiques IoT rencontrez-vous ?
Nous vous donnons rendez-vous très vite pour la suite de nos articles #IoT.
Si la mise en place de la DSP2 semble prendre l’apparence d’une querelle entre anciens et modernes – les banques contre les fintech – la réalité s’avère plus complexe…
Ouvrir à des tiers l’accès aux données et à l’initiation de paiement pour stimuler la concurrence tout en consolidant la sécurité des paiements. C’est l’ambition de la DSP2 (directive européenne sur les services de paiement) entrée en vigueur en janvier 2018 et dont la mise en œuvre est jalonnée par de grandes étapes définies dans les normes techniques et réglementaires (aussi appelées RTS), notamment sur les interfaces d’accès (API) et l’authentification forte.
Une première échéance est tombée le 14 mars 2019, date à laquelle les banques devaient avoir déployé un portail d’API afin de mettre à disposition la documentation et un bac à sable permettant aux TPP (Tiers Prestataires de Paiement) de les éprouver. Une autre suivra le 14 septembre 2019 avec l’ouverture officielle des APIs de production. Dans le contexte de tension entre fournisseurs d’API (teneurs de comptes) et consommateurs (nouveaux acteurs), cette échéance a relancé le débat sur la capacité des banques à respecter le calendrier…
La DSP2, une transformation lourde à marche forcée
Dans ces débats, un même coupable est souvent pointé du doigt : les banques. Qui complexifieraient la sécurité ou encore publieraient des API bien trop partielles pour être exploitables. La réalité est un peu plus… complexe. Et les enjeux ne peuvent se résumer à une querelle entre les anciens (les banques installées) et les modernes (les acteurs de la fintech). Rappelons que la DSP2 est un sujet plutôt nouveau, qui concerne « juste » la sécurité des paiements et la protection des données du client. Et comme pour toute transformation lourde, les acteurs impliqués découvrent en marchant les clarifications qui doivent encore être apportées.
Oui, les différents textes, de la directive aux RTS, ont bien posé des fondamentaux. Trois catégories ont été définies pour les fameux TPP (Tiers Prestataires de Paiement), des agrégateurs de comptes aux initiateurs de paiement en passant par les émetteurs de moyens de paiement.
Des obligations pour les tpp et les banques
Pour entrer dans le jeu, ces TPP doivent remplir des conditions : obtenir un agrément auprès d’une autorité nationale, un certificat (dit « eIDAS ») auprès d’une autre autorité ou encore renoncer (quand des API sont disponibles) au webscraping. Pour rappel, cette technique consiste à collecter les données à partir des sites de banque en ligne, en utilisant les identifiants et mots de passe des clients. Les banques pour leur part doivent respecter le calendrier de déploiement et mettre à disposition les API de production pour les trois catégories de TPP le 14 septembre prochain après avoir mis en ligne, en mars dernier, bac à sable (sandbox) et documentation.
Si les règles du jeu et le calendrier sont là, que manque-t-il ? Nous pourrions résumer en disant « des délais plus cohérents et des modalités plus précises ». À défaut, pour les TPP comme pour les banques, la route manque de lisibilité.
Quelques exemples pour comprendre :
Globalement, le planning de l’autorité de régulation (ACPR, Autorité de Contrôle Prudentiel et de Résolution) a été publié fin décembre pour des actions à lancer mi-janvier et des mises en production mi-avril. Un planning plus que tendu.
Sans surprise, dans ces délais les progiciels bancaires ne sont pas prêts pour intégrer les spécificités de la DSP2.
Selon les prestataires impliqués, les certificats eIDAS ne pourraient entrer en production qu’au 3e trimestre. Compliqué dans ce contexte d’être prêt pour le 14 septembre.
Pas simple non plus pour les TPP de suivre le rythme pour revoir leur mode d’accès aux données (passer du webscraping aux API) ou encore obtenir les certificats adéquats.
Le Fallback et son exemption cristallisent aussi les critiques. Le « Fallback » désigne un mécanisme de secours en cas d’indisponibilité ou de mauvais fonctionnement des API. Les banques peuvent demander une dérogation à ce sujet. Mais le planning n’a pas été aligné en cohérence avec l’échéance 14 mars 2019 et le dossier à fournir demeure complexe. Le mécanisme de Fallback lui-même souffre d’imprécisions.
Comment recueillir le consentement des clients ? Selon quel parcours ? En imposant une redirection vers l’établissement teneur de compte ? Évidemment, ce n’est pas du goût des TPP. Pour l’heure, même à l’échelle française, aucun consensus n’émerge vraiment sur le sujet.
Le renouvellement de l’authentification ? Les RTS prévoient actuellement d’obliger les utilisateurs à se réauthentifier tous les 90 jours auprès de leurs banques. Les TPP estiment le mécanisme incompatible avec une expérience utilisateur digne de ce nom.
Gageons justement que cette expérience client, un peu perdue de vue au fil des textes réglementaires, devrait s’imposer comme l’alpha et l’oméga des discussions à venir. Et comme un objectif commun à l’ensemble des acteurs. Parce que chacun a autant à perdre qu’à gagner. Parce que, aussi, cette expérience dépend de business modèles à caler de part et d’autre.
Une certitude : la DSP2, sujet restructurant à l’échelle bancaire, appelle des investissements lourds dans des délais serrés. Et seule la coopération permettra à chacun d’y trouver des bénéfices – et pas seulement financiers –, en apportant au client final, les nouveaux services fluidifiant le paiement dans son parcours utilisateur.
Une révolution est en cours dans nos cités. Les utilisateurs délaissent les moyens mis à leurs dispositions par les conseils régionaux et les mairies pour des solutions écologiques, innovantes, souples, facturées à l’usage et dont le bénéfice est immédiat.
Toutefois, bien que pratique, cette nouvelle mode urbaine génère du stress également, comment s’adapter à ces nouveaux usages ? Certaines municipalité ont tenté de les interdire, d’autres se posent la question de la réglementation, quel est le risque pour l’usager et pour les autres usagers, doit on permettre à ces utilisateurs de consommer ces services alors que nous ne l’avions pas prévu ?
Les infrastructures actuelles ne sont pas compatibles avec ces nouveaux usages, la pression des utilisateurs est telle qu’il faut trouver des solutions palliatives pour leur permettre de les utiliser en toute sécurité.
Ces précurseurs bousculent l’ordre établi qui se voit devancé sur les problématiques de développement durable et de transport.
Quel cadre proposer pour que tout le monde y trouve son compte sans pour autant bloquer ceux qui suivent le modèle historique mais que l’on aimerait réussir à convertir aux nouveaux usages ?
Ces réflexions sont en cours à Lyon, à Bordeaux, à Paris, ainsi que dans la majorité des métropoles régionales, et les villes rurales réfléchissent à offrir ces services même si la pression et l’impact sont moins importants.
Ces questions autour des vélos et des trottinettes en libre service ont peu de rapport avec l’IT ou avec nos DSI mais elles rappellent un sujet qui revient depuis plusieurs années : le Shadow IT.
Les utilisateurs consomment des services informatiques sans en informer leur DSI, les contraintes de sécurité sont ignorées, les fournisseurs multiples, la même solution peut être consommée plusieurs fois sans qu’il n’y ait d’optimisation des coûts.
Faut-il l’interdire ? Est-ce que l’entreprise acceptera de retarder son plan de transformation, la sortie d’un nouveau produit ou pire de dégrader la satisfaction client pour respecter les exigences de l’IT ?
Les problématiques se ressemblent, les solutions sont tout aussi éclectiques et dépendent à chaque fois de l’environnement, du cadre et des besoins. L’entreprise doit aujourd’hui permettre à ses utilisateurs, à ses clients internes d’utiliser des solutions compétitives au time-to-market imbattable et correspondant à leurs besoins. Mais l’entreprise doit aussi garantir la sécurité de son SI, de ses données et de son activité.
Ces nouvelles solutions ont généralement des attributs communs, elles sont hébergées dans le cloud, ne nécessite pas d’installation et la configuration est à la portée de tous.
L’enjeu pour les sociétés, quelle que soit leur taille, est de permettre la consommation de ces nouveaux services, de faciliter leur usage dans le respect des normes de sécurité en gardant la maîtrise des coûts qu’ils induisent.
L’entreprise se voit donc imposer une transformation vers le cloud par ses clients internes, ses employés, qui se demandent pourquoi les outils qu’ils utilisent au travail sont moins performants et conviviaux que ceux qu’ils utilisent à la maison.
Quels sont les bénéfices que l’entreprise tirera de cette transformation ?
Quelles sont les étapes à respecter ?
Ce sont les thèmes que nous développerons dans nos prochains articles.
#Batch, #ETL, #EAI, #ESB, #API… d’année en année depuis plus de 20 ans les professionnels de l’intégration ont développé et fait évoluer leurs produits pour accompagner les nouveaux modèles d’architectures.
A l’ère du #Cloud, un nouveau produit tisse progressivement sa toile : l’iPaaS.
Faciliter l’intégration des applications dans un écosystème hybride (Cloud to Cloud, Cloud to OnPrem) est la promesse phare de ces integration-Platform-as-a-Service.
Quels sont les acteurs de ce nouveau segment ? Quelle est la philosophie de leur produit ? Quels patterns d’intégration supportent-ils ? Ont-ils vocation à remplacer les solutions historiques OnPrem ? autant de questions que nous pouvons nous poser.
Ces quelques minutes de lecture vous donneront à la fois une vision théorique et concrète du marché et des concepts issus d’une démarche d’Appel d’Offre et de Proof-Of-Concept.
[Le marché] Se réinventer pour survivre
IBM, Informatica, TIBCO, Talend, Axway sont des grands noms de l’intégration parmi tant d’autres dans cet écosystème foisonnant.
Chacun propose une ou plusieurs solutions (IBM Datastage PX, IBM WebSphere TX, Informatica PowerCenter, TIBCO Business Works, TIBCO Mashery, Axway Amplify, …) pour couvrir tous les besoins d’intégration applicative des grandes entreprises.
Ces besoins ayant émergé successivement d’année en année, les DSIs ont lancé des programmes IT dont la résultante est un millefeuille de progiciels d’intégration différents, avec des recoupements fonctionnels et une multiplicité d’interfaces de conception / management / supervision / monitoring.
Autant dire que la simplicité et l’agilité ne sont pas au rendez-vous.
Ces solutions s’appuyaient sur une palette de connecteurs out-of-the-box mais surtout sur de grands bus d’entreprise monolithiques qui ont fait couler beaucoup d’encre (et sûrement de larme et de sueur). Cette architecture pouvait satisfaire les intégrations Ground to Ground au sein d’un même SI mais elle se confronte désormais :
A la recherche de modularité,
A l’ouverture du SI (Cloud, partenaire, …),
A l’augmentation prévisible ou non de la charge d’intégration (scalabilité) (OpenData, IoT, …),
A l’agilité introduit avec les démarches DevOps et l’outillage CI/CD,
Au shadow IT pratiqué par les métiers qui souhaitent aller vite sur des cas d’intégration simple,
…
La société Boomi, spécialisée initialement dans les échanges EDI, est l’instigatrice de ce nouveau mouvement iPaaS lancé en 2007. Rachetée par Dell en 2010, Dell Boomi truste la place de leader du marché.
Pour répondre à cette concurrence, les éditeurs historiques ont créé à leur tour des offres iPaaS sur la base de leurs solutions existantes. Simple rebranding ou véritable nouvelle offre ?
En parallèle de ces éditeurs bien ancrés, des acteurs born to be Cloud (à l’instar de Moskitos) apparaissent désormais dans le Magic Quadrant Gartner.
[Le concept] Une boîte à outils survitaminée
Bien malin celui qui pourra vous donner une définition unanime d’un iPaaS. Nous pouvons cependant la qualifier de plateforme d’intégration unifiée administrée dans le Cloud pour répondre simplement et facilement à tous les besoins d’intégration* : ETL, EAI/ESB, EDI, API, MOM, MFT.
Certaines offres affichent également des capacités autour du Master Data Management, du Workflow Management et du développement d’applications Web.
Un véritable couteau suisse de l’intégration en somme qui théoriquement pourra :
Etre mis en production en moins de temps qu’il n’en faut pour l’écrire,
Faciliter la création des flux d’intégration grâce à une approche LOW CODE avec du glissé-déposé. Vous rêviez de créer un flux moyen (transformation / composition) en moins de 2 jours, ils l’ont fait,
Rationaliser très fortement vos outils d’intégration actuels,
Simplifier la gouvernance et l’exploitation de la plateforme et de vos flux grâce à une plateforme centrale unifiée,
S’intégrer dans votre démarche DevOps et vos outillages CI/CD grâce à leur approche API Led / API First.
* Les éditeurs ne se cachent pas derrière ces grandes lignes et assument pleinement de ne pas offrir la même couverture fonctionnelle et le niveau de performance des solutions spécialisées (exemple : Dell Boomi MoM versus le bus SOLACE). Ce point n’est pas bloquant et sera totalement compensé par l’adoption d’une stratégie Hybrid Integration Platform (HIP) que nous détaillerons dans un second article.
[Architecture] Une architecture au goût du jour
En quête de simplicité de mise en oeuvre et d’agilité, les offres iPaaS trouvent leur essence dans les capacités offertes par le Cloud.
Cependant deux degrés de Cloudification s’opposent :
Le Cloud ou rien (Moskitos) : chaque flux d’intégration est orchestré dans le Cloud. Des agents techniques assurant la connectivité et les transformations sont déployés au plus près des applications sources et cibles. Ces agents techniques sont orchestrés par la plateforme centrale qui exécute les flux. Aussi chaque donnée métier, sensible ou pas, transite par votre plateforme iPaaS dans le Cloud. Cette architecture est pertinente pour les échanges Cloud-to-Cloud ou Cloud-to-On Premise. En revanche elle est peu pertinente par la latence induite, la dépendance à la connectivité internet et les enjeux de sécurité pour les échanges On Premise-to-On Premise.
L’hybridation avec un modèle distribué (Mulesoft, Dell Boomi) : les flux s’exécutent en toute autonomie sur les agents techniques (microservices) distribués au coeur du SI (On Premise, partenaire, Cloud). Ces agents techniques remontent des métadonnées vers la plateforme centrale disponible en SaaS qui permet de les manager.
La plateforme SaaS est :
Soit autosuffisance (Dell Boomi) pour créer des processus d’intégration simple/moyen/complexe et les déployer en un clic sur l’agent technique de votre choix pour sa future exécution. Le concept de Low Code est poussé à son paroxysme. En cas de besoin de transformation exotique, la plateforme SaaS dispose d’un éditeur de code en ligne (Python, Groovy) pour développer la fonction adéquate (qui pourra être réutilisée sur étagère dans vos autres processus d’intégration).
Soit plus limitée (Mulesoft, Moskitos, …) et il vous sera nécessaire d’utiliser un environnement local développeur (IDE, Éclipse ou autre) pour développer vos processus (avec une moins bonne gestion du Low Code) et finalement les sauvegarder sur le Cloud (Moskitos) soit les exporter en .jar (Mulesoft) en fonction de l’architecture de la plateforme.
[Licensing] J’aurais bien besoin d’un FinOps
Le modèle de souscription annuelle “as-a-service” de ces plateformes offre bien des avantages mais également des difficultés lorsque vient la comparaison des différentes offres du marché.
Effectivement chacune s’appuie sur des métriques de licensing fines qui lui sont propres :
Facturation au nombre de User Développeur / User Métier,
Facturation au nombre de connexions techniques unitaires,
Facturation au nombre de partenaires EDI,
Facturation au nombre de transaction par seconde,
…
Quand d’autre facture pour la mise à disposition d’une typologie de plateforme (small, medium, large) peu importe le nombre d’applications connectées, peu importe le nombre d’utilisateurs développeurs/métiers et peu importe le nombre de flux processés. La métrique la plus restrictive est ici la volumétrie des données qui transitent par la plateforme Cloud.
Il saute aux yeux que le premier modèle sera difficilement prédictif :
Combien de clients ont suffisamment de métriques sur leur existant : nombre de connexions, nombre de flux, nombre de specialist integrator / citizen integrator, …
Combien de clients ont une vision claire et arrêtée sur leur démarche de transition, sur l’accostage des nouveaux projets pour projeter le ramp up de la plateforme et ses coûts.
Cette connaissance est néanmoins primordiale pour deux raisons :
L’effet de volume induit un levier de négociation possible avec l’éditeur,
Une vision claire de ces métriques peut mettre en exergue un modèle de facturation éditeur qui n’est pas du tout adapté à votre contexte (qui voudrait payer 20M€ pour s’intégrer avec ses 4000 partenaires en EDI ?). Un nouveau modèle doit alors être pensé.
Certains produits du marché sont une véritable révolution soit par leur approche, soit par leur maturité et simplicité d’utilisation. Un véritable atelier de génie logiciel vous permet au travers d’une plateforme centrale unifiée de réduire grandement la complexité de conception, de documentation, de déploiement, d’exécution et de monitoring de vos flux.
Un iPaaS pour les gouverner tous…
Un iPaaS pour tout concevoir…
Un iPaaS pour tous les traitements…
… Rien n’est moins sûr.
Le suspens reste entier jusqu’au prochain article qui présentera la vision stratégique du moment : l’Hybrid Integration Platform (HIP).
Souvent, on oppose la vision métier à la vision IT. Cependant, itérer des refontes de processus dans une optique d’optimisation, sans regard pour leur implémentation, revient à vouloir placer Lewis Hamilton dans une 4L : l’idée est bonne, mais il y a peut-être plus efficace.
Le premier impact de la dette technique, c’est la difficulté à faire évoluer les fonctionnalités de son système d’information.
Souvent, on prend des raccourcis en phase de cadrage pour des raisons budgétaires, de planning, ou tout simplement parce que l’on se dit que l’on fera mieux les choses plus tard… sans jamais le faire.
Cela entraine un manque de capacité à répondre aux besoins ultérieurs, notamment à tous ces nouveaux enjeux qui apparaissent régulièrement (par exemple, construire une vision 360 est compliqué sans une démarche référentiel maitrisée). Le SI devient une sorte de boulet au pieds du métier, qui l’empêche de s’adapter aux évolutions du marché. Certains chantiers sans valeur ajoutée métier, mais structurant pour les évolutions futures, ne peuvent pas être repoussé : c’est la notion de chantier « enablers ». Ce point peut devenir particulièrement préoccupant dans le cadre de projet règlementaires (les différents chantiers issus de Bâle 2, ou les sujets LAB LAT sont de bons exemples, du fait des exigences en termes de qualité des données), ou dans des contextes ou l’agilité est vitale (le secteur du Retail, par exemple, où le déploiement d’une nouvelle fonctionnalité devient rapidement un enjeux critique vis-à-vis de la concurrence).
Le deuxième impact de la dette technique est l’image que l’on renvoie aux différentes parties prenantes externes à l’entreprise, mais aussi aux internes.
Une interruption de service due à un plantage nécessitant de redémarrer les environnements de production entraine une image très négative pour le client, qui peut entrainer un désengagement en cas de fréquence trop élevée (pensez à la dernière fois où votre connexion internet personnelle ne fonctionnait plus, et au stoïcisme dont vous avez su faire preuve à ce moment). En interne, cela entraine un désengagement progressif des équipes, du fait de tâches répétitives à très faible valeur ajoutée, du sentiment de faire systématiquement des solutions dégradées, ou à la survenue fréquente d’incidents de production. Ces points génèrent de la frustration, dans le sens où ils donnent le sentiment que la qualité n’est pas le souci de l’entreprise (surtout lorsqu’on leur demande de prioriser un sujet, pour au final dénaturer le résultat de l’étude). Si cela entraine un turn over dans vos équipes, le sujet est préoccupant. Si vous êtes en difficulté de recrutement, cela peut devenir critique, d’autant que les premières victimes du turn over sont les hauts potentiels, qui souhaitent être pilotés par la qualité et la richesse des sujets.
Le dernier impact de la dette technique que j’évoquerai dans cet article est budgétaire.
En effet, toute dette doit se rembourser un jour, et entraîne des coûts récurrents d’ici là. Cela va générer des coûts projets plus importants lors des évolutions, ou des actions humaines pour corriger des erreurs issues de ces dettes (par exemple, le rapprochement des chiffres comptabilité / gestion réalisé manuellement, faute de chaîne de traitement fiable). N’oublions pas aussi ces applications dont le décommissionnement est acté, mais jamais terminé (ce qui entraîne de nombreux coûts, mais une augmentation significative de la complexité du SI du fait de la parallélisation des chaines).
Au final, cela se traduit par des coups de canif dans votre budget projet, sous forme de coûts de runs importants, ou de chiffrages projets plus importants que prévu (matérialisés par le classique « La DSI coûte trop cher »).
Il y a bien entendu beaucoup d’autres raisons qui devraient nous pousser à ne pas négliger la dette, cependant, ces 3 points sont des enjeux que l’on retrouve dans toutes les DSI : Agilité, Expérience utilisateur / qualité de service, et maîtrise budgétaire.
Dans un prochain article, nous allons parler de la gestion de la dette dans le cadre des projets Agile.
