20-01-2024 17:49:12
Il n'est pas inutile de rappeler le schéma général, la Big Picture des Transformations Digitales.
Rappel : Colonne vertébrale digitale
2 contraintes, 2 objectifs, 5 piliers, 1 système nerveux
Pour rappel, 2 contraintes fortes agissent sur l'entreprise :
- L'élimination des frictions (tendance à la simplification, à la flexibilité, à l'adaptabilité, …)
- Le AAA (Anything — Anywhere — Anytime) : pouvoir tout faire, n'importe où, n'importe quand
Pour pouvoir rencontrer et s'adapter à ces contraintes, on positionne 2 objectifs majeurs :
- Une orientation client véritable et sincère qui dépasse les discours convenus
- Une force de travail engagée parce qu'heureuse qui peut exercer et développer son expertise, qui bénéficie d'autonomie et qui puisse donner du sens à son travail (MAP — Mastery, Autonomy, Purpose).
Les zones de contact (là où le combat va s'engager) sont dénommées les piliers qui sont au nombre de 5 :
- Les produits et services
- Les canaux de distribution
- Les canaux de communication
- Les méthodes de travail, l'organisation interne, les processus, …
- L'accélération des cycles
La colonne vertébrale est cette étoile qui apparaît et qui relie les organes internes de l'entreprise ainsi qu'elle la connecte à son monde extérieur selon les 5 zones de contact présentées ci-dessus. C'est un système nerveux, parcouru d'impulsions. Que vous voyiez cette colonne vertébrale digitale comme un ESB ― Enterprise Service Bus n'est qu'une forme de matérialisation.
Après ce rappel, replantons le décor : nous parlons ici de la colonne vertébrale digitale et nous nous apprêtons à aborder le sujet des Enterprise Patterns dont la définition courte est d'être des solutions communes à des problèmes récurrents. Cela m'amènera à parler de schémas, d'ESB, de SOA, … tout dans le même mouvement.
Introduction
Dans mon expérience du développement, à divers postes, j'ai vu de nombreuses équipes consacrer beaucoup d'énergie à développer des systèmes qui se trouvent avoir été mis au point, de manière assez semblable, ailleurs, dans d'autres entreprises, en exposant souvent les mêmes contraintes et objectifs, ou disons, à peu près les mêmes.
Toutes ces équipes font face aux mêmes défis, encore et encore. Les mêmes solutions — ou grosso modo les mêmes — sont développées, encore et encore. Les mêmes écueils attendent les néophytes, encore et encore. Les mêmes expériences, encore et encore. Les mêmes douleurs, encore et encore. Les mêmes découragements et — heureusement — les mêmes sourires, encore et encore.
À chaque fois, il y a un déjà vu obsédant. Comme une sorte de répétition agassante. Une anaphore informatique. Ma couturière dirait … un motif , un patron! Et en fait, oui, il y a bien un patron, un pattern.
Si les besoins sont toujours les mêmes, légèrement différents, ils se réduisent le plus souvent aux mêmes solutions génériques pour ceux qui sont capables d'universaliser la réflexion, de généraliser le sujet. C'est là que je voulais vous amener : les patterns sont des solutions communes à des problèmes récurrents.
Les Enterprise Patterns sont des solutions communes à des problèmes récurrents.
Je voudrais donc aborder un cas personnel où, j'ai vu la nécessité évidente d'utiliser un patron [1] : envoyer des PDFs aux clients, les remplir et les renvoyer.
C'est l'exemple très concret qui servira de fil rouge pour découvrir ensemble une quantité de motifs que je devrai couvrir de manière succincte mais précise.
It Is the Story of a Chick Who Wanted to …
… envoyer deux PDFs à environ 20000 clients. Le premier PDF n'avait qu'une seule page alors que le second en avait deux. Les originaux étaient des formulaires légaux, non conçus par la société de la dame. Les clients devaient recevoir les PDFs, les remplir avec leurs coordonnées et leurs données, les signer et les renvoyer. Pour faire bonne mesure, un message explicatif devait être ajouté afin que le client sache ce que les PDFs représentaient.
Je suis totalement sûr que le même genre d'histoire ne vous est jamais arrivé ! Je me trompe ? Ah, bon ! Vraiment ?
Alors, notre poule s'est dit : Je veux une solution moderne ! Je veux
que nous envoyions les PDFs à une boîte de réception digitale propre au client
qui les téléchargera, les remplira, les signera et les renverra via sa boîte de
réception. Ensuite, les PDFs seront acheminés au bureau régional du client pour
traitement.
Pour traiter de ce problème n'ai pas pu résister à l'envie de voir ce qu'avait schema.org, alors je TEXTE INCOMPLET L(i)VID - Babel API Service - 20201107.png
To be continued
Je n'ai pas pu résister à l'envie de voir ce qu'avait schema.org, alors je suis allé sur le site maintenu conjointement par Google, Microsoft, Yahoo et Yandex pour voir s'ils ne proposaient pas une définition de ce qu'est un PDF. avec la description suivante : Un fichier ou un document électronique. Un DigitalDocument est un type de données - je dirais une classe - qui hérite d'une multitude de propriétés d'une classe parente, CreativeWork, ayant elle-même une classe parente à son tour : Chose. Ayant ces classes toutes prêtes sous forme de code PHP depuis que je les ai générées automatiquement sur la base de définitions XML, je suis heureux d'avoir progressé dans mon projet sans faire grand chose. Encouragé par ce premier succès facile, je suis enthousiaste et décide de donner sa chance à Wikidata. Je le fais par le biais de mon propre service : https://www.trql.fm/api/wikidata-search/PDF?xml.
Les %EP% au service de la Transformation Digitale
Les Transformation Digitale ont tout intérêt à puiser dans l'énorme arsenal des %EP% pour y dénicher les solutions qui lui sont utiles pour accélérer la construction de ce qui est à réaliser mais également pour se faciliter, ultérieurement, la maintenance évolutive.
To be continued
