L’architecture IT … de quoi parle t-on exactement ?

Récemment, j’ai eu une discussion avec un client qui me demandait : “c’est quoi exactement le métier d’architecte technique ?” … vaste sujet. S’en est suivie une discussion sur les métiers d’architecte : Architecte d’entreprise, Architecte Data, Architecte logiciel, Architecte Cloud, Architecte solutions, Urbaniste etc.

Dans ce post, nous allons donc exposer notre vision de l’architecture technique et du rôle de l’architecte IT au sein de l’entreprise.

Nota Bene : certains architectes auront une vision différente ou verront plusieurs postes d’architectes en un etc. Ce post n’engage que celui qui l’a écrit à savoir moi-même ! 🙂


architecture generaliteL’architecture IT … quelques généralités …

 

L’architecture IT est un métier dit de “build”, on va donc se situer dans le domaine de la conception. Ensuite, si on devait énoncer un principe commun à l’ensemble des métiers de l’architecture IT, une synthèse pourrait être : “l’architecte IT traduit des besoins métiers ou fonctionnels en solutions techniques (infrastructure) ou logicielles”, ceci pouvant se réaliser ex-nihilo ou en intégration à un existant. On peut faire l’analogie avec l’architecte en bâtiment : en tant que client, vous souhaitez vous faire construire une (grosse) maison de 4 étages sur 1 hectare, mais vous n’avez aucune idée de ce qu’il faut utiliser en termes de béton, de fondations, de dalle etc pour faire tenir la maison de ce type surtout si le terrain est marécageux. L’architecte saura alors vous concevoir la maison de vos rêves pour éviter qu’elle ne s’enfonce dans le terrain dans quelques mois, il pourra même vous conseiller de changer de terrain si cela s’avère perdu d’avance.

Ensuite, il faut considérer deux grandes branches que sont l’architecture technique qui va concevoir les infrastructures et les plateformes, et l’architecture logicielle qui va concevoir les applications en utilisant des patterns de développement, éventuellement les processus de CI/CD etc.

Dans notre cas, nous allons nous focaliser sur les métiers de l’architecture technique dans lesquels nous allons pouvoir trouver des spécialisations telles que l’architecture réseau, l’architecture data, l’architecture cloud et son pendant on premises appelé architecture d’infrastructure etc.

Du point de vue des compétences, un de mes anciens employeurs disait : “Architecte, c’est plusieurs experts sous la même tête, un expert ayant environ 10 années d’expériences dans un domaine particulier. Il dispose donc d’une expérience pratique d’au moins 3 ou 4 éléments d’infrastructure …/… Cette expérience technique doit être accompagnée d’une réflexion pertinente sur l’efficacité des techniques.”, enfin il concluait par cette formule ô combien réaliste : “Ne pas oublier : l’architecte doit conduire et contrôler la construction. Il fournit les bottes pour la gadoue…”. Au quotidien, il conçoit les grandes parties du système d’information de l’entreprise en produisant schémas et documents d’architecture, mais comme indiqué plus haut, il s’assure également du contrôle du bon déploiement de ses conceptions. Ce contrôle peut également se réaliser au niveau de l’intégration dans le  respect des règles de l’entreprise. Enfin, un des aspects du métier réside dans l’évolution des conceptions, il peut donc être amené à apporter des modifications à tout ou partie des différentes phases de conception et règles associées auxquelles il a participé.

Un architecte a donc généralement une à deux expertises et une culture technique éprouvée sur d’autres aspects techniques. Il est donc normal d’avoir des spécialités dans l’architecture technique (ces spécialités pouvant avoir des zones de recouvrement), que nous allons présenter dans les prochaines parties.

Enfin, notons que la phase d’architecture n’est pas à négliger au regard des contraintes de planning etc… En effet, le meilleur moyen de faire échouer un projet est de négliger cette phase qui est structurante et permet de stabiliser un système d’information quelquefois pour des années durant.


Specialiste ITLes spécialisations de l’architecture IT

 

 

 

 

 

 

L’architecte réseau

Comme son nom l’indique, l’architecte réseau va s’occuper de concevoir tout ou partie du schéma réseau, qu’il soit déployé on premises et/ou dans le cloud. Il va donc être responsable du design général du réseau (Bus, Hub & Spoke, Mesh partiel ou complet etc.), de l’interconnexion de ces réseaux qu’elle soit réalisée avec d’autres partenaires à l’entreprise ou avec un Clouder. Il sera également chargé de la conception des règles de routage et de filtrage, de la sécurité, du positionnement et du choix des équipements sur le réseau (Firewall, routeurs, NVA, Proxies, Gateway etc.).

Il produit généralement de nombreux schémas réseau, et conseille d’autres architectes notamment Cloud et d’infrastructures qui vont utiliser les éléments de réseau conçus par l’architecte réseau.

 

IT infrastructureL’architecte d’infrastructures

L’architecte d’infrastructures a en responsabilité de concevoir des infrastructures techniques essentiellement on premises. Il a donc une pleine connaissance des éléments de stockage (DAS, NAS, SAN etc.), de réseau, pour lesquels il peut prendre conseil auprès de l’architecte réseau, de bases de données, de systèmes (OS, Cluster, Load Balancer etc.) et de middleware (Serveurs Applicatifs et Web, moniteur transactionnel). Il conçoit donc les infrastructures qui vont devoir répondre à des objectifs de disponibilités et SLA, de robustesse, de performance etc. Il pourra également prendre en charge la définition des architectures de Cloud privé et d’intégration de solutions externalisées.

Il produit généralement de nombreux schémas et des documents d’architecture technique générale ou détaillée.

 

CloudL’architecte Cloud et architecte Solutions

L’architecte Cloud est le pendant de l’architecte d’infrastructures en charge de définir la stratégie d’adoption et de déploiement du Cloud computing au sein de l’entreprise. Il est donc à ce titre agnostique d’un quelconque Clouder (même s’il dispose des connaissances des diverses solutions Cloud). Dans le cadre de la présence de plusieurs Clouders au sein de l’entreprise, il sera chargé, via les standards qu’il aura définis, de définir ou positionner tout ou partie d’une infrastructure Cloud.

L’architecte d’infrastructures dont le périmètre est celui d’un ou plusieurs Clouder(s) sera l’architecte solutions Cloud (On parlera alors d’architecte solutions Azure ou AWS). Il va donc œuvrer dans la conception d’infrastructures répondant à des objectifs de disponibilités, SLA, robustesse, performance etc. mais dans le périmètre des solutions offertes par le Clouder. Par exemple, si l’architecte solutions œuvre sur Azure, il aura la pleine connaissance des possibilités de réplication et de performance pour un stockage objet, il saura également conseiller une base Azure SQL pour stocker les données relationnelles en fonction du besoin exprimé par le métier, ou encore privilégier une solution de conteneurs Kubernetes sous AKS. Évidemment, s’il œuvre sur AWS, il sera en mesure de conseiller la bonne configuration S3 pour son stockage objet et la base de données RDS répondant au mieux au métier et à ses contraintes.

Chose importante à noter, rappelons qu’un architecte est un poste expérimenté voire multi-expérimenté. Les plateformes Cloud étant relativement “jeunes” au regard de l’ère informatique mais néanmoins très fournies en services et en perpétuelle évolution, un architecte solutions aura généralement une plateforme de prédilection, plus rarement deux. Un architecte solutions se vantant d’œuvrer sur Azure, AWS, GCP, et OVH-Cloud devra susciter de la méfiance quant à ses compétences et expertises.

dataL’architecte Data

L’architecte Data va avoir à sa charge toute la conception des plateformes et le choix de solutions hébergeant des données de l’entreprise. On y inclut par exemple les architectes bases de données qui seront consultés pour choisir un SGBD dans une configuration donnée en fonction de divers paramètres en entrée (features de la solution, habitudes d’utilisation et de codage, réplication synchrone ou asynchrone, cluster, configuration et sécurité etc.). Il s’occupera également de proposer des solutions de sauvegarde et de leur éventuelle externalisation afin d’assurer les SLA, RTO et RPO demandés par le métier. Enfin, il aura à sa charge le dimensionnement de bases de données en fonction des objectifs de temps de réponse et, toujours, des besoins du métier.

Si l’architecte data est plus spécialisé sur du Big Data, il sera à même de proposer les meilleures architectures en fonction des objectifs d’ingestion et de traitement des données (temps réel et/ou batch). Il proposera donc des architectures plus horizontales dites en lambda, kappa, ou datalake et au niveau desquelles il proposera et concevra des solutions de stockage adéquates avec les objectifs de SLA, RTO et RPO. Il s’occupera également de proposer et concevoir les plateformes de traitement de ces données en prenant en compte le format des données, la volumétrie etc. en relation avec les équipes de data-engineers voire de data-scientists, et également les solutions en bout de chaîne de présentation de la données (dashboarding et reporting, API etc.). En complément de cela, il est bien au fait du RGPD, de la classification, gouvernance, cycle de vie, chiffrement et catalogage de ces données.

Ce poste est un véritable couteau suisse de la donnée dans l’entreprise, il est capable d’évoluer aussi bien on-premises que dans un environnement de Clouder. Sur ces aspects, comme sur les aspects réseau, il aura la possibilité de s’appuyer sur les architectes réseau, Cloud ou infrastructures.

SLA : Service Level Agreement ou Niveau de service attendu. Généralement, il est exprimé avec plusieurs indicateurs que sont : le taux de disponibilité, RTO, RPO.

RTO : Recovery Time Objective. Il représente le temps accordé pour restaurer le service d’un système après incident

RPO : Recovery Point Objective. Il représente la perte de données acceptable après incident exprimée en temps d’exploitation.

 

L’architecte d’entreprise

L’architecte d’entreprise est l’architecte qui va se positionner entre le management de l’entreprise qui définit la stratégie globale et l’ensemble des architectes qui implémentent les souhaits du métier. Il a donc un rôle de transcription de cette vision en moyens techniques et tactiques. Il s’assure ainsi que les contraintes stratégiques soient bien appliquées au niveau de la conception. Une analogie serait de le comparer à un chef d’orchestre qui connaît les tâches des uns et des autres et qui coordonne globalement l’ensemble des équipes notamment d’architectes.

Typiquement, si les données de deux Business Units ne doivent pas cohabiter au sein de la même base de données pour des contraintes légales, il devra donner cette information à ses architectes data et s’assurer que les dossiers de choix intègrent cette contrainte.

Par conséquent, il y a donc dans ses fonctions une part importante de contrôle, en complément il devra également avoir une fibre d’urbaniste développée. 

L’urbanisme est la discipline visant à structurer le système d’informations. 

L’architecte d’entreprise aura parmi ses attributions celle de mettre en place des règles et des méthodes de développement d’architectures au sein de l’entreprise et de son système d’information, la plus connue étant l’ADM (Méthode de Développement d’une Architecture)

Il devra également être responsable de la mise en place de patterns d’architectures, d’un référentiel d’architecture (composants, matrices de choix, schémas, briques de base etc.) et de livrables. La mise en place de ces éléments au sein de l’entreprise est primordiale car il permet de gagner un temps fou dans la conception des projets de l’entreprise. On produit les briques pour construire des murs solides et standards.

Note : Les matrices de choix représentent un élément clé dans les phases de conception et de définition de standards, car elles représentent un moyen de se préserver des “caprices” de certains architectes. (Merci à Yann pour la remarque!)

La finalité sera donc d’avoir des standards, et l’outillage nécessaire pour construire des architectures standardisées au sein de l’entreprise.

Il aura également un rôle de contrôle auprès des équipes d’architectes pour s’assurer que les livraisons réalisées obéissent aux règles de l’entreprise. Il pourra également faire évoluer ces règles au besoin.


La production documentaire d’un architecte

Comme nous l’avons vu, un architecte, la plus grande partie de son temps, propose et conçoit des infrastructures techniques et leurs règles de conception en vue de répondre à des besoins métiers. Il s’assure également du contrôle et de l’évolution de celles-ci.

 

 

 

Cette conception se matérialise par un ensemble de documents et de livrables parmi lesquels on pourra trouver (liste non exhaustive) :

  • Des diagrammes de haut niveau, généralistes, appelés HLD (High Level Design) et des diagrammes de bas niveau, plus détaillés, appelés LLD (Low Level Design). L’ensemble de ces diagrammes pourra être décliné selon la portée technique, par exemple, diagramme de flux, de processus, réseau, stockage etc.
  • On peut également trouver des catalogues de solutions et leurs matrices de choix.
  • Des patterns d’architectures qui représentent des modèles d’architectures en briques prêts à l’emploi pour les projets.
  • Des livrables qui sont des documents contractuellement spécifiés et qualifiés par les parties prenantes. Ce sont les résultats de projets, dont la part de documentation est destinée à entrer dans le référentiel d’architecture. On y trouve généralement deux documents centraux :
    • Le dossier d’étude d’architecture globale (DEAG) ou dossier de choix. Il s’agit d’un livrable essentiel dès lors qu’on propose plusieurs architectures techniques pour la réalisation d’un projet. Il permet généralement d’avoir une vue d’assez haut niveau et de donner une orientation globale avec avantages et inconvénients de chaque solution. On peut y ajouter une estimation budgétaire, voire un macro-planning (même si cela revêt des attributions du chef de projet). Il permet ainsi au client de décider où il souhaite aller sans en donner tous les détails d’implémentation. Typiquement, on pourra y trouver un HLD réseau sans pour autant donner les détails d’un plan d’adressage IP.
      Généralement, à l’issue de l’étude de ce dossier par le client, un choix est fait et le dossier retourne dans la main de l’architecte pour détailler la solution.
      A noter que ce livrable n’est pas systématique et, dans le cas où il n’y aurait qu’une solution, la partie générale est présentée dans le dossier d’architecture technique détaillée.
    • Le dossier d’architecture technique (DAT) qui va préciser l’architecture générale choisie. C’est dans ce dossier qu’on va exposer les détails d’implémentation de l’architecture : choix des solutions, type de réplication utilisée, plan d’adressage IP, diagrammes de flux précis etc.
      Un dossier d’architecture technique terminé peut ainsi, après contrôle de la conformité architecturale, passer dans les mains des opérationnels et chefs de projets qui vont procéder à la planification de son déploiement et à son implémentation.

Enfin pour conclure, l’architecte participe à de très règulières réunions car il est généralement au milieu de plusieurs métiers : nous avons vu plus haut que chaque architecte échange avec d’autres spécialités d’architectures, mais il est généralement au contact de nombreux métiers de l’IT (Data Engineers, Chefs de projets, DevOps/Cloud Ops etc.) et du management. Il est donc un peu “la colle” entre l’ensemble de ces entités.


Pour terminer ce billet, je tenais à remercier Alexandre et Yann pour leurs relectures et leurs précieux conseils !