Comment une demande utilisateur déclenche une crise à la DSI ?

Lors de la pause café du CODIR, le DRH a présenté le nouvel outil qu’il souhaite déployer pour la gestion des notes de frais : depuis une application smartphone, le salarié prend en photo son ticket de caisse, la note de frais est ensuite automatiquement saisie et envoyée en validation. 
L’ensemble du CODIR a immédiatement adhéré (la réduction d’effectifs des assistantes de direction ne semble pas être étranger à la décision).
Il a été demandé au responsable informatique de mettre en place l’outil dans les plus brefs délais : la solution pourra être paramétrée par un prestataire pour répondre aux besoins de l’entreprise en moins d’une semaine. Pour tenir les délais, le CODIR demande à la DSI de faire fi des processus habituels et de s’appuyer sur le Cloud. Les délais de mise en oeuvre de technologies type serverless sont jugés beaucoup plus acceptables que les mois historiquement nécessaires pour acheter et configurer des nouveaux serveurs.
Idée géniale ! Tout content, le DSI repart avec ce projet voir ses équipes… Mais très rapidement la tâche paraît bien plus importante que prévue :

• L’application sera déployée dans le Cloud, une première pour cette entreprise, et cela nécessitera la mise en oeuvre d’une zone pouvant échanger avec le SI legacy.  Comment inclure ce nouveau “datacenter virtuel” de manière sécurisée au sein du SI ? 
• L’application doit s’interfacer avec la RH et la paie. Ces systèmes étaient traditionnellement hébergés sur un réseau dédié, isolé d’internet. Le serveur hébergeant ces applications n’a pas été mis à jour depuis plusieurs années. La mise à jour de ce serveur impliquerait la mise à jour du SIRH. Si ce dernier devait être réinstallé, cela induirait un projet long et coûteux. Comment exposer et récupérer les données indispensables au bon fonctionnement du service, sans mettre en péril les données personnelles des salariés ? Outre la question de l’obsolescence, se pose la question des échanges sécurisés.
• Les accès internet de l’entreprise ne sont pas dimensionnés pour que les employés travaillent sur des serveurs hébergés en dehors de celle-ci. Les accès internet ne sont pas non plus dimensionnés pour permettre l’échange sécurisé d’informations  avec des partenaires tiers hébergés sur internet. Au delà de la taille des tuyaux, les problématiques d’échanges de données avec les applications partenaires doivent être adressées.

Les impacts si majeurs conséquents à cette demande du métier

Derrière une réponse en apparence simple d’un point de vue de l’utilisateur, (i.e. installer une application de gestion des notes de frais), se cache une transformation profonde du SI. Pour devenir Cloud Ready, la DSI doit ainsi adresser 4 chantiers majeurs :

La mise en place d’un cloud public

• Quels sont les services qui devront être instanciés dans le Cloud ?
• Comment mettre à disposition les services de la DSI dans le Cloud ? 
• Comment résoudre l’équation du respect des bonnes pratiques de sécurité avec le respect du budget de la DSI ? 
• Comment garantir l’exploitabilité des applications qui seront déployées dans le Cloud ?
• Comment mettre une politique FinOps qui permette d’aligner les coûts relatifs au Cloud avec les gains métiers attendus ?
• Comment permettre l’accès des utilisateurs depuis n’importe où aux applications déployées dans le Cloud ?

La gestion de l’obsolescence de la dette technique

• Comment optimiser les coûts de possession des applications ? 
• Comment garantir leur compatibilité avec les technologies Cloud ?

La gestion des échanges de données

• Quelle stratégie à mettre en oeuvre pour les échanges de données entre les applications du SI et celles dans le Cloud ? 
• Avec les applications des partenaires externes ? 
• Est-ce qu’une politique d’API doit être poussée ? 
• Comment gérer les échanges avec les applications historiques du SI ? 
• Est-ce que l’évolution de l’ESB ou de l’ETL est suffisante ou est-ce que la mise en place d’un iPaaS doit être envisagée ?

La sécurité “by design” du SI

• Quels sont les services de sécurité à mettre en service pour permettre une sécurisation de bout en bout ? 
• Quels sont les composants à instancier afin de garantir l’accès sécurisé aux applications ?
• Quelles sont les règles à imposer aux applications afin de garantir la sécurité du SI ?
• Est-ce que l’entreprise doit envisager la mise en place d’un SIEM (Security Information and Event Management) afin de détecter les éventuelles attaques ?

Dans certains cas, ces quatre chantiers seront suffisants. Dans d’autres cas, il faudra compléter avec : 

• La refonte de l’environnement de travail et les problématiques du BYOD (Bring Your Own Device), les problématiques liées à la conformité du poste de travail, la sécurisation des accès à privilèges.
• La mise à disposition des services de la DSI via un portail de service.
• La mise en place d’une chaîne DevOps permettant d’industrialiser le déploiement des applicatifs dans le Cloud (ou On-Premise).
• L’étude de mise en oeuvre de plateforme (Blockchain, BigData ou IOT) pouvant accueillir des applications métiers afin d’anticiper leurs impacts sur le SI historique.

(Re-)mise en perspective d’une transformation vers le cloud

Beaucoup d’entreprises initient ces transformations en ayant uniquement un objectif économique. Il est important de noter que dans la plupart des organisations, les économies espérées ne seront pas générées par la transformation technologique, mais par la transformation des processus qui les consomment. Un service technologique sera rentable dans le Cloud à condition qu’il soit dimensionné et disponible en fonction de la demande des métiers. Par exemple, les serveurs de développements peuvent être éteints la nuit, et certains services de Production re-dimensionnés la nuit lorsqu’il y a peu d’utilisateurs.
La transformation vers le Cloud permettra à la DSI et aux métiers d’être plus réactifs dans la mise à disposition de nouveaux produits et services. Les investissements pourront être limités car proportionnels aux revenus ou économies générés par leur consommation.
Pour approfondir le sujet, nous vous conseillons de consulter les 5 mythes associés à une stratégie cloud first :

• La réduction systématique des coûts
• Toutes les applications sont éligibles au cloud
• Il ne faut conserver qu’un seul fournisseur
• La migration vers le cloud rendra mon application résiliente
• Une fois dans le cloud je n’aurais plus besoin d’architecte

En conclusion

L’utilisation du Cloud ne s’improvise pas, la transformation doit être planifiée afin de respecter les exigences métiers. Il faut aussi veiller à ce que les métiers s’approprient les nouveaux services au fil de l’eau.
Les organisations qui sont parvenues à se transformer ont pris le contrôle de leur transformation en formant massivement leurs acteurs aux technologies Cloud, et en se faisant accompagner par des sociétés expertes sur les différentes problématiques.
Il n’existe pas de recette préformatée permettant de répondre à ces problématiques. Même si de bonnes pratiques ont été éprouvées sur des projets majeurs, la feuille de route devra être adaptée au contexte de l’entreprise et à sa maturité. Le succès de la transformation du SI sera atteint à condition de replacer les enjeux métiers au centre de la transformation.

Vous pouvez approfondir le sujet avec cette article : Ten Commandments for Cloud Decision-Makers.

Les APIs sont omniprésentes. Les métiers en demandent car elles promettent les plus belles perspectives commerciales, des effets boules de neige et de la démultiplication de valeur. Les consultants ne jurent que par cette solution. Pas un schéma d’architecture sans que l’API Gateway ne règne en maitresse, ayant comblé le moindre interstice entre les applications et s‘érigeant en barrière impérieuse entre les deux mondes du Legacy et des frontaux Web, chantre et cœur de l’IT bi-modal.

Obnubilé par les promesses de l’API management, la réflexion sur le bien-fondé de l’utilisation d’un échange synchrone est morte née.

Votre direction a donc investi (cher) et la cellule d’architecture applique une stratégie d’API par défaut.

Mais obnubilé par les promesses bien connues de l’API Management, la réflexion sur le bien-fondé de l’utilisation d’un échange synchrone est passée au second plan. Tout comme la SOA avait imposé ses Web-Services pour des raisons de vitesse de propagation, l’API Management assoit sa domination sur sa supériorité technologique pour l’exposition à l’ensemble des partenaires.

Les échanges synchrones n’offrent aucun mécanisme efficient de reprise des erreurs.

On en oublie une caractéristique et une limite intrinsèque à ce type de flux. Les échanges synchrones ne se justifient en effet que quand une réponse (et donc un aller-retour) est nécessaire, et ils imposent en contrepartie un couplage fort entre l’appelant et l’appelé, l’échange ne pouvant pas aboutir si l’appelé n’est pas disponible au moment précis de l’appel. Les échanges synchrones n’offrent ainsi aucun mécanisme efficient de reprise des erreurs techniques (des retry toutes les 5 secondes ? Pendant 1 heure par exemple ? avec de plus en plus de services qui ne répondent plus… ? Autant sortir les arva® et attendre le Saint Bernard).

On tombe ainsi dans des cas où le rejeu devient très gênant et où la responsabilité de ce rejeu est déporté vers l’appelant alors que son message était correctement émis, correctement formaté et qu’il ne tire aucun bénéfice de l’acquittement HTTP qui lui reviendra. On rencontrera particulièrement ce cas sur des appels visant à créer ou modifier des données. Qui est responsable du rejeu d’une fonction POST ou PUT tombée en erreur ? Pour peu que le partenaire appelant soit une application SaaS, un logiciel propriétaire voire pire un partenaire B2B, on se retrouve dans une impasse.

Les échanges asynchrones et leur pattern publish-subscribe apportent par construction une extrême résilience à ce type d’incident en persistant les messages et en laissant les destinataires maitres de leur rythme de consommation. Ajouter à cela la grande facilité de paramétrage d’une nouvelle cible -là ou une plateforme d’API demandera une nouvelle règle de routage- et l’on retrouve pourquoi les solutions asynchrones sont des impératifs d’un SI bien structuré.

Il serait bien trop limitant de se passer d’un portail d’API et de l’accessibilité externe qu’il offre.

Favoriser l’asynchronisme est un bon principe de conception de flux.

Si l’échange est unidirectionnel, que la donnée peut être stockée chez le consommateur et que la fréquence de modification n’est pas trop importante, oubliez le synchronisme, rendez sa liberté au fournisseur d’information et appuyez-vous sur votre MOM ou EAI !

Pour autant il serait bien trop limitant de se passer d’un Portail d’API et de l’accessibilité externe qu’il offre. La facilité d’exposition offerte par ces solutions est sans pareil sur le marché actuel.

Appliquez-vous donc à construire un système hybride. Pensez l’API Gateway, et le package HTTP, REST et JSON comme un connecteur, une porte d’entrée sur votre SI, et débrayez immédiatement derrière sur une solution de bus de messages (MOM ou EAI) dès que cela est sensé.

En cassant la chaine du synchronisme on récupère la souplesse souhaitée, en maintenant la Gateway en frontal on conserve l’ouverture et la facilité d’utilisation.

La fonction Architecture évolue souvent de manière cyclique : animatrice des transformations de l’entreprise un jour, décriée et sans ressources le lendemain; tel le phœnix elle doit souvent renaître de ses cendres.  Ces cycles ne sont pas inéluctables, pour peu que l’architecte sache résoudre cette équation : se montrer indispensable et préserver son existence.

En matière de système d’information, le rôle de l’Architecte est régulièrement discuté, remis en cause et doit en permanence être justifié. Pourtant, dans le secteur du bâtiment, aucun promoteur sensé n’envisagerait de se passer d’un Architecte, garant à la fois de la bonne réponse de l’ouvrage à ses besoins, mais aussi de sa conformité et de son évolutivité.

Dans nombre d’entreprises, nous voyons naître une fonction d’Architecture soit à l’occasion d’un grand programme de transformation, soit parce que la complexité du SI ou simplement le déficit de connaissance de celui-ci rend son évolution difficile et coûteuse. Dès lors, l’Architecte est reconnu comme le messie qui va résoudre tous les problèmes et réaligner le SI avec les enjeux stratégiques de l’entreprise.

Pour autant, une fois ces tâches réalisées avec efficacité, son existence sera remise en cause et éventuellement sacrifiée sur l’autel des réductions budgétaires ou simplement de la volonté de réduire son influence.

Ainsi, selon un cycle plus ou moins long, les fonctions Architecture alternent des périodes de forte influence et d’autres de désintérêt. L’Architecte, comme nos amies les abeilles, doit composer avec ce paradoxe : être indispensable tout en luttant pour sa survie.

Certaines entreprises ont démontré que ces cycles ne sont pas inéluctables et la bonne nouvelle est que l’Architecte lui-même dispose des clés de son succès :

L’apport permanent de valeur ajoutée

Il en va en théorie de toute fonction de l’entreprise, mais c’est encore plus vrai de l’Architecte. Ses interventions doivent toujours apporter de la valeur aux projets ou à l’actualisation de la trajectoire au bénéfice de l’entreprise dans son entier. Pour cela, il faut choisir ses combats. Si l’Architecte doit tout voir de l’évolution du SI à un moment ou un autre, il ne doit en aucun cas apparaître comme un administratif qui appose son tampon sur tous les dossiers. Il doit savoir sélectionner les projets ou études sur lesquels il apportera de la valeur à l’entreprise, en regard des enjeux d’architecture qu’ils portent, eux-mêmes en lien avec les orientations stratégiques de l’entreprise.

Dans cette logique, la fonction Architecture ne pourra plus être vue comme un coût mais comme un investissement dont la rentabilité réside dans le rapport qualité/prix des solutions et les erreurs évitées.

L’ajustement du dispositif

L’activité des architectes varie en fonction des plans d’évolution du SI. Pourtant, les équipes d’architectes sont généralement très stables, ce qui se justifie souvent par la volonté de conserver les sachants qui seront précieux lors des futures sollicitations. Plutôt que de meubler les périodes de baisse d’activité par des travaux d’intérêts limités, le responsable de l’architecture doit construire un dispositif ajustable en fonction de la charge, par exemple avec un minimum de recours à la sous-traitance,  sans attendre qu’une directive budgétaire vienne s’en charger à sa place.

Le renouvellement des forces

La fonction Architecture doit faire preuve d’innovation, ou à minima de créativité afin de challenger en permanence la pertinence des choix et des règles établies. L’apport d’un regard neuf est indéniable et évite de reproduire par la routine les mêmes réflexes. Pour reprendre l’image du bâtiment, il n’est pas si fréquent de confier la réhabilitation d’un immeuble à l’Architecte qui l’a conçu. Ce renouvellement peut être obtenu grâce au pilotage de la mobilité des collaborateurs, ou encore par un apport régulier de conseil spécialisé pour les travaux les plus structurants. Pour permettre ce renouvellement dans la continuité, il faut bien entendu tenir à jour la documentation des plans du SI et de ses règles de construction.

L’influence plutôt que le pouvoir

Enfin, et c’est peut-être le point le plus essentiel, l’Architecte doit avoir pour rôle principal d’éclairer les décisions des décideurs de l’entreprise sans se substituer à eux. La tentation est grande pour l’architecte d’imposer ses points de vue, en particulier lors de grands plans de transformation. En effet, la vision globale et à long terme qu’il est souvent le seul à apporter peuvent le convaincre de posséder seul les solutions aux problèmes posés  et donc de les imposer aux différents acteurs sans que ceux-ci les comprennent vraiment.  Or, si l’Architecte se doit d’exercer une influence sur les décisions structurantes pour le SI de l’entreprise, il ne doit pas chercher à exercer un pouvoir sur celle-ci. A défaut, ceux qui possèdent réellement le pouvoir saurons le lui rappeler le moment venu, et ainsi réduire considérablement son potentiel voire son existence même.

Au final, il est bien normal que les architectes soient challengés en permanence et c’est aussi ce qui rend ce métier passionnant. L’application de ces quelques règles conduit à apporter la valeur, l’agilité, l’innovation et l’influence de nature à répondre à ce challenge.

Bien que tentante par sa concision et sa fluidité, cette formulation est une chausse-trape tant elle semble précise alors qu’elle est absolument vide de sens. Elle donne l’impression aux parties prenantes de s’être exprimées alors qu’elle masque complètement la réflexion qu’ils doivent mener.

« Faire du temps réel » n’est en effet pas un besoin. On voit tout juste pointer le bout du nez d’une information sur la vitesse de propagation mais c’est une exigence non fonctionnelle qu’il sera nécessaire d’arriver à quantifier, l’ubiquité de la donnée n’étant pas encore accessible.  Et ce sera d’ailleurs l’occasion de parler volumétrie, supervision, sécurité.

Et rappelons que le synchronisme n’a rien à voir là-dedans… De nos jours des API complexes vont mettre beaucoup plus de temps à répondre qu’une transmission asynchrone utilisant un outil correctement dimensionné.

Pour être sûr de ne plus faire l’erreur, reprenons les bases

L’important dans la conception d’un échange de données est de comprendre la relation entre le consommateur et le producteur. Et ça, c’est bien les sachants fonctionnels qui sont les mieux placés pour l’exprimer (un accompagnement par une personne exercée peut être utile) :

• Qui déclenche le flux ? Est-ce le besoin d’accéder à la donnée -et donc le consommateur- ou le fait d’avoir capté un événement (création, modification d’information) -et donc le créateur ?
• Est-on dans le cadre d’une communication bidirectionnelle -question-réponse-, ou unilatérale ?
• S’il y a réponse, doit-elle être liée à la question et à son contexte ou garde-t-elle tout son sens et sa pertinence quel que soit le timing de retour ?

Un petit exemple, car je sens que cette phrase absconse peut laisser pantois : Quand je lance un calcul d’itinéraire avec G**gle, la réponse est entièrement liée au contexte d’appel, i.e. ma position. L’information n’a plus de sens si elle arrive trop tard ou si j’ai depuis déclenché une nouvelle demande (si j’ai raté une intersection par exemple). En revanche si je demande le score de Lyon/Paris-Saint Germain d’hier, le contexte de ma demande n’influe pas, je veux la réponse dès que possible, et si cela arrive dans 2 minutes cela m’intéresse toujours !

Il est maintenant clair que ces trois questions dépassent largement la notion de « temps réel ». Délaissez donc cette formulation passe partout et cantonnez-la aux discussions dont le fond n’est pas réellement l’architecture des échanges (et heureusement elles sont nombreuses !).