Larchitecture informatique est importante. Laissez-moi vous dire pourquoi

Nous aimons dessiner !!

(Miguel Angel Coll) (2 juillet 2020)

Jai investi les 5 dernières années dans ma carrière en travaillant autour de la fonction darchitecture informatique. Toutes ces années, jai dû justifier la simple existence de la fonction darchitecture même à moi-même. Parfois aussi limpression que nous étions des intrus entourés par les gens qui font vraiment le travail (développeurs et sys-ops).

Après 5 ans, je suis toujours convaincu que larchitecture compte, laissez-moi vous donner quelques arguments pour le prouver.

Meilleur rapport qualité / prix

Si je dois choisir une seule mission pour larchitecture informatique, je choisirai celle-ci. Les services et plates-formes informatiques ne font généralement que croître. Certains dentre eux parce que lentreprise grandit, dautres parce que lentreprise est en pleine transformation numérique. Dans tous les cas, le résultat est le même, année après année, vous avez plus de systèmes, plus déquipes, plus de complexité.

Jaime hyper-simplifier une plate-forme informatique comme suit:

La fonction principale de larchitecture est de conserver la relation avec le Le coût de la plate-forme informatique et la valeur quelle offre dans un bon état.

Il y a quelque temps, jai travaillé dans une entreprise de voyages avec un modèle commercial basé sur la distribution de produits en ligne via des API. Ces API étaient étroitement associées à un énorme système monolithique basé sur Oracle Exadata. Cela signifie quà chaque fois que nous augmentons le trafic de lAPI (et que le trafic augmentait plus que le taux de conversion), nous devons faire évoluer verticalement notre base de données.

Larchitecture est le moteur de lefficacité de la plate-forme informatique

La proposition darchitecture à lépoque consistait à découpler les services API en créant une nouvelle couche de micro-services sur le cloud pour gérer tout le trafic avec des coûts moindres tout en conservant linfrastructure de base de données uniquement pour la réservation et les opérations (qui malheureusement ne croissent pas de manière exponentielle). Résultat, aucune nouvelle infrastructure nest nécessaire pour la base de données les années suivantes et une meilleure relation entre le trafic et les coûts informatiques.

Utilisez le même langage

Ne vous inquiétez pas, je suis ne parle pas de langages de programmation (java, python, etc.). En tant quarchitecte, je suis plus que ouvert à la diversité avec un certain contrôle (pas le chaos). Je fais référence ici à Intégrité conceptuelle , terme que jai lu pour la première fois sur Mois de lhomme mythique et autres essais sur le génie logiciel de Frederick P . Brooks Jr.

Dans le livre, Fred Brooks explique comment les équipes informatiques se développent et comment cet impact croissant sur leur productivité. Pour Fred, lun des plus gros problèmes à résoudre lorsque vous essayez de faire évoluer une équipe informatique est la communication entre les équipes. Afin de paralléliser les tâches, les équipes doivent être aussi indépendantes que possible. Mais, dès que toutes les équipes travaillent sur une plateforme interconnectée, nous avons besoin dune certaine communication entre les équipes. Est dans ces scénarios où avoir un langage commun est la clé du succès.

Je me souviens encore des conversations interminables avec mes anciens coéquipiers discutant de ce quest un système, un composant technologique, une interface ou un élément constitutif. Si vous travaillez dans un grand service informatique, vous savez probablement à quel point il est frustrant que les choses soient nommées différemment par les équipes. Parfois, cest même pire quand ils utilisent le même nom pour différentes choses.

Un exemple courant de ce dernier, est de nommer une application monolithique avec un seul nom. Même si cela a du sens (car il sagit dun monolithe), lorsque vous souhaitez briser ce monolithe, vous aurez besoin de plus de détails. Lintroduction de différents noms pour la base de données, le frontend, le modèle de données, etc. vous aidera dans le processus.

Même si vous êtes dans un petit service informatique ou un plus grand, cest toujours le bon moment pour commencer avec une convention de dénomination, un catalogue de services / systèmes / solutions, etc. Vous ne savez jamais quelle sera votre taille à lavenir.

À propos de lintégrité conceptuelle, nu avec moi, le plus tôt sera le mieux.

Forcer les conversations de conception

Dans mon esprit, toute solution à un problème commence toujours par un analyse de la situation et conception de la solution avant sa mise en œuvre. La réalité pour une équipe de développement est que chaque semaine, nous avons de nouveaux problèmes à résoudre. Après quelques mois de routines Business as Usual, les équipes commencent à fonctionner en pilote automatique et trouvent simplement des solutions aux problèmes sans trop réfléchir aux implications à moyen et long terme.

La fonction darchitecture intégrée dans les équipes de développement aide toujours sur laugmentation des conversations de conception pour trouver les meilleures solutions aux problèmes auxquels nous sommes confrontés.

Aussi, jaime remettre en question le processus de développement à lancienne où le design est considéré comme quelque chose à faire juste au début dun projet.Dans larticle Lascenseur darchitecte – Visite des étages supérieurs , Gregor Hohpe décrit parfaitement ma compréhension du rôle de larchitecture:

«… Au lieu de confier toutes les décisions cruciales à une seule personne, le risque du projet peut être réduit de minimisant le nombre de décisions irréversibles . »

Larchitecture doit être présente sur tout le processus de développement . En effet, si vous travaillez sur Agile, vous prendrez des décisions à chaque itération.

Discussions sur la stratégie

En tant quinformaticien, jadorerai faire partie du conseil dadministration de lentreprise ayant des et des discussions techniques détaillées. La réalité pour les moyennes et grandes entreprises est que les membres du conseil dadministration ne peuvent pas se permettre daller trop loin dans les détails. Mais, le conseil dadministration de lentreprise doit-il prendre des décisions sur la stratégie sans comprendre la situation informatique?

Dans le monde actuel, seules quelques entreprises peuvent dire que linformatique nest pas au centre de leur stratégie. Ensuite, qui est chargé de traduire la stratégie en informatique et vice versa? – vous connaissez déjà la réponse.

Lune de nos plus grandes contributions à léquipe darchitecture de TUI Destination Experiences a été de dessiner un modèle darchitecture cible. Le TAM permet aux non-informaticiens de comprendre nos principales solutions et systèmes et comment ils sont connectés aux flux de valeur de notre entreprise. Après avoir distribué le TAM, la plupart de nos conversations sur la stratégie ont commencé par examiner à quoi ressemble notre architecture et comment nous devons nous adapter à une nouvelle situation.

Mais attention, un modèle darchitecture cible nest pas censé être statique image de larchitecture «telle quelle» et «future». Essayer de faire ce genre dexercice aboutira à quelque chose déphémère qui convient parfaitement à un projet spécifique. À mon avis, il est préférable de se concentrer sur le dessin des principaux composants de votre architecture et sur la sélection des éléments que vous souhaitez conserver (car ils sont au cœur de votre activité) et sur les éléments que vous devrez changer ou évoluer.

Première diapositive de la présentation TAM

Souvenez-vous toujours de ce que Dee Hock, fondateur de Visa, a dit:

Un objectif et des principes simples et clairs donnent lieu à un comportement intelligent complexe. Des règles et réglementations complexes donnent lieu à de simples comportements stupides.

Vers linfini et au-delà

Lobsession de lagilité transforme parfois les équipes informatiques en décideurs à court terme . Comme nous lavons déjà mentionné, nous devons nous assurer que les décisions que nous prenons aujourdhui sont à lépreuve du temps. Parfois, cela signifie avoir une vision claire de la stratégie à long terme. Parfois, cela signifie faire attention à ne pas être enfermé dans une solution qui ne correspond pas à votre avenir. signifie la plupart du temps assurer un niveau de qualité par défaut et être capable de sadapter à tout ce qui est arrivé.

Comme nous lavons déjà commenté, larchitecture doit également travailler au niveau stratégique. Cela signifie que cela aura probablement de nouvelles informations sur les possibilités futures qui pourraient affecter la plate-forme informatique. Parfois, ces changements stratégiques sont même confidentiels. Être capable dinfluencer certaines décisions en essayant déviter les mouvements de regret est parfois une tâche difficile car des personnes non informées ne comprendront jamais la vraie raison derrière.

À un moment donné, nous étions au milieu de la discussion sur lamélioration de larchitecture de la plateforme B2C. Il est vraiment logique daméliorer beaucoup larchitecture. Mais, certains dentre nous savaient que nous étions en discussion pour acquérir une entreprise qui se substituera à notre plateforme B2C.

Croyez-moi, ce nest pas toujours facile dêtre architecte, mais il faut toujours réfléchir à ce quest le mieux pour lentreprise.

Et aussi…

… Nous aimons aussi dessiner et nous rendrons le bureau beaucoup plus cool.

Équipe de développement ayant des discussions à laide dun diagramme darchitecture

Jespère que ce message modeste contribuer à lavenir à comprendre un si beau travail.

Migue Coll, responsable du domaine technologique chez Tui Destination Experiences.