Pattern d’architecture TOA… et cela vous concerne.

Aujourd’hui je voudrais vous parler et vous présenter un nouveau pas-encore-documenté pattern d’architecture : TOA. C’est un pattern-compagnon de TOT, mais avant de parler de ces patterns, j’ai quelques questions à vous poser …

Un jour, en pleine discussion avec le responsable BI d’une grande société, celui-ci m’indique utiliser Informatica PowerCenter avec son équipe. Celle-ci « souffrait » à cause de l’absence de certaines fonctionnalités de base comme « annuler la dernière action »; possibilité de créer plusieurs niveaux de séquencement des flux; possibilité de faire des boucles au niveau du séquencement (vendeur propose d’utiliser le shell!); incapacité de paralléliser les flux (option supplémentaire) ou encore impossibilité de tester les flux rapidement, etc.
Quand j’ai posé la question : « Pourquoi ? » – sa réponse m’a choqué: « Parce que au niveau du suivi, nous pouvons voir un diagramme de Gantt d’exécution ». Il était sérieux.
Quelle est la raison de ce comportement, selon vous ?

Une autre société implémentait un MDM de consolidation en se basant sur EBX, sauf que … EBX était utilisé juste pour le stockage des données car il lui manque justement des capacités de « consolidation ».
Pourquoi n’ont-ils pas simplement utilisé « une base de données » ? Parce que « pour créer un offre dans la société il te faut un outil et pas juste une approche » et « EBX était déjà choisi sur d’autres critères ».

L’une de plus grandes banques de France possède une équipe nombreuse de « Data Scientists ». En fait, ils sont tellement intelligents qu’ils n’ont pas utilisé ce terme, mais ce sont les personnes qui peuvent « venir et résoudre le problème en se basant sur les données ».
Vous savez quoi ? Ils n’ont pas le droit d’utiliser les outils ETL ni vraiment gérer leur environnement. En gros ils sont limités par Python et encore quelques outils de base.
Vous savez pourquoi ? « Ce sont les outils pour une autre offre. »
Est-ce normal, à votre avis ?

« Nous migrons dans le cloud ! De toute façon, tout sera dans le cloud dans 5 ans. Nous avons juste un problème : un certain nombre de filiales ne possède pas de connexion fiable. »

Je vais m’arrêter ici avec mes questions et mes allusions. Vous avez déjà du voir le trend, mais si nécessaire j’ai encore quelques exemples en stock …

Maintenant, je vous propose d’introduire ma vision des choses …

Je pense que ce que nous observons ici c’est TOT, Tool Oriented Thinking (Raisonnement Orienté Outil) – le comportement des personnes responsables des décisions techniques caractérisé par une prise de décisions basée sur des habitudes, autres décisions redoutables, la mode et les relations plutôt que centrée sur le besoin métier, la compréhension des conditions et le calcul des conséquences.

La conséquence de TOT est TOA, Tool Oriented Architecture (Architecture Orientée Outil). C’est une architecture baroque (parfois rococo) qui se caractérise par l’absence des modules vitaux, la multiplication d’outils à la mode, l’incompréhension des résultats attendus et une vision très orientée « utilisation d’outils ».

Vous n’êtes pas comme ça !

1. Vous ne choisissez pas un outil en n’ayant pas la moindre idée des spécifications et des conditions.
2. Vous ne jugez pas les outils par ses fonctionnalités « sympa », mais vous priorisez le besoin.
3. Vous choisissez les outils les plus simples possibles afin d’accomplir la tâche en question.
4. Vous vérifiez toujours que les outils ne se feront pas concurrence entre eux.
5. Vous écoutez votre équipe et ses besoins.
6. Vous n’avez pas d’excuses « politiques ».
7. Vous laissez le buzz passer pour évaluer les points positifs et négatifs de nouvelles approches.
8. Vous n’avez pas de projets-zombies qui sont « déjà trop chers pour les arrêter ».
9. Vous avez la pleine compréhension des processus à l’oeuvre derrière vos outils (oups, il ne me semble pas avoir entendu de définition pour cela, que diriez vous de la « gouvernance de connaissances »?).
10. Vous vérifiez que tout ce que vous faites est dans l’intérêt de vos « clients internes ».

Je vous laisse proposer la suite ou la correction de cette liste.

Conclusion

Finalement, nous sommes tous et toutes des humains. Nous avons nos faiblesses et il sera toujours séduisant d’appliquer soit ce que nous connaissons déjà soit ce qui est à la mode. Cela, par contre, n’aide pas le métier. Ne vous étonnez plus si un jour l’IT voit son son métier fatigué aller chercher des outils « self service », « cloud, sans installation », « no-code/low-code ». TOA c’est l’ennemi de l’IT de tout business à long terme.

Je vais finir cet article par une citation de la loi de Conway :

Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.

M. E. Conway

Vous savez par quoi commencer ?

Bonne santé à vous et à votre architecture.