Le Tao de l’architecture technologique – Partie 1

Introduction

Dans le domaine du conseil technologique et des systèmes d’information, il est universellement reconnu que l’architecture et la conception comptent parmi les ingrédients les plus cruciaux d’un environnement informatique bien fonctionnel et bien géré.  Cependant, chez Ferroque Systems, nous avons observé qu’il est aussi très courant que de nombreuses (la plupart?) organisations n’aient pas une architecture d’entreprise adéquate ou incomplète et/ou assez dépassée, ce qui contribue à de nombreux défis.

C’est regrettable, car une architecture bien définie offre des avantages essentiels, tels que :

• Elle facilite l’organisation des idées et une vision en une solution pratique valide, et sert de référence pratique pour apporter des améliorations avant de commencer le déploiement physique (« mesurer deux fois, couper une fois »).
• Il fournit une référence globale pour l’environnement informatique qui guide les décisions et mises en œuvre technologiques, afin de garantir que ces décisions et actions perpétuent une approche cohérente et partageant les mêmes idées dans tous les domaines technologiques.
• Il constitue une base pour définir les artefacts de conception technique pour chaque domaine technologique; De tels artefacts de conception offrent des avantages supplémentaires, tels que :
  • Des directives détaillées pour configurer les composants technologiques tels qu’ils existent dans le monde réel, et s’assurer que plusieurs composants seront configurés pour orchestrer et intégrer des fonctionnalités dans une solution cohérente.
  • Justification de la configuration d’un composant technologique donné de cette façon, qui peut être référencée en continu pour déterminer si/quand un changement est justifié selon de nouvelles exigences et/ou cas d’utilisation.

La plupart des organisations reconnaissent la nécessité d’une architecture d’entreprise appropriée, mais ne savent parfois pas nécessairement comment en définir une, le font de manière incomplète et/ou laissent cela tomber obsolète, devenant ainsi obsolète.

Compte tenu de l’importance de l’architecture et du design, et sur la base de notre expérience et de nos observations sur le terrain, nous, chez Ferroque Systems, avons estimé qu’il serait utile d’écrire cette série de blogues qui expose les concepts clés de l’architecture informatique, clarifie les distinctions entre architecture et design, et offre des conseils pratiques pour développer l’architecture informatique et les artefacts de conception. et met en lumière les pièges courants à éviter.

Cadres/modèles d’architecture

Commençons par passer en revue les cadres d’architecture d’entreprise; Il y en a trop pour les nommer ici, alors nous resterons sur les plus connus.  De nombreux frameworks d’architecture existent aujourd’hui, tels que TOGAF, Zachman Framework, NIST, SOA.  Un bref résumé de chaque cadre est présenté ci-dessous (il ne s’agit pas d’une définition exhaustive, juste d’un bref aperçu pour la sensibilisation et le contexte).

• TOGAF. Le cadre d’architecture d’entreprise le plus populaire; au fil du temps, TOGAF a évolué à travers plusieurs maturations et des éléments formels de formation et de certification se sont développés autour de lui.  TOGAF organise l’architecture d’entreprise en quatre piliers architecturaux (affaires, données, application, technique), et décrit un vocabulaire, des méthodes et des outils pour définir et (tout aussi important) maintenir l’architecture d’entreprise.
• Cadre Zachman. Son objectif principal est de fournir des conseils structurés sur la façon de passer des concepts abstraits aux implémentations réelles, principalement en tirant parti d’une matrice qui organise les décisions pour les éléments fondamentaux (qui, quoi, quand, où, etc.) sur tout le spectre, de l’abstrait à l’implémentation physique, où des outils/artefacts sont prescrits pour aider à l’intersection de chaque élément.  Utilisés collectivement, ces outils et artefacts constituent la base de l’architecture d’entreprise et peuvent être utilisés pour guider les décisions continues d’architecture et de conception.
• NIST. Davantage un modèle d’architecture d’entreprise qu’un cadre, le NIST décrit une architecture d’entreprise comme étant composée de cinq couches principales d’architecture (processus d’affaires, flux d’information, applications, descriptions de données, infrastructure technologique) toutes interconnectées.  Au fil du temps, le modèle NIST a été référencé par plusieurs organisations importantes pour développer un cadre basé sur le NIST (par exemple DOE, FDIC, NWS).
• SOA. Un modèle d’architecture orienté services dans lequel tous les composants et processus sont intégrés pour former et livrer de nombreux services.  Beaucoup de ces services sont des services de back-office (par exemple, des services de gestion d’identité) qui supportent les services des utilisateurs finaux (par exemple, soumettre une demande automatisée pour être provisionnée d’une application particulière).  L’infrastructure SOA est un catalogue de services qui inclut la désignation d’un propriétaire de service responsable de tous les éléments du service (c’est-à-dire l’intégration des personnes, processus et technologies qui composent le service).

Le concept clé ici est que chacun de ces cadres ou modèles favorise une perspective différente sur l’architecture d’entreprise, et il n’y a pas de réponse « correcte » unique.  En pratique, un architecte d’entreprise (EA) bénéficie souvent de l’intégration des éléments les plus utiles/utiles de chaque cadre ou modèle en fonction des besoins particuliers de l’EA pour l’organisation.

Concernant les cadres d’architecture, un autre point important est que de nombreux fournisseurs promeuvent un modèle d’architecture natif pour illustrer comment les composants du fournisseur s’intègrent dans le paysage technique informatique global.  Ces modèles natifs sont généralement spécifiques au fournisseur et ne correspondent donc souvent pas aux cadres ou modèles d’architecture « standard » décrits ci-dessus.  Par exemple, Citrix adhère à un modèle d’architecture qui s’organise en sept couches : Accès, Affaires, Calcul, Contrôle, Opérations, Ressources et Utilisateurs (les couches Affaires et Opérations sont considérées comme des couches fondamentales englobant les cinq autres couches).  Encore une fois, de tels modèles natifs ne sont ni « juste » ni « mauvais »; ils offrent plutôt à un architecte d’entreprise (EA) une autre méthode de structuration de l’architecture selon les besoins particuliers.  Nous aborderons davantage ce sujet dans cette série de blogues.

Principes fondamentaux de l’architecture

Comme mentionné plus haut, il n’existe pas un seul « bon » cadre ou modèle d’architecture; L’architecture d’entreprise d’une organisation donnée est basée sur les besoins de l’organisation, les technologies existantes, les compétences internes, la maturité des processus, l’appétit pour le risque et le budget.  Équilibrer tous ces éléments pour définir une architecture pertinente est un défi, mais il existe des principes fondamentaux d’une architecture bien définie qui fournissent des conseils pratiques :

• Axé sur la solution. Dans un paysage moderne des TI, rien n’existe dans le vide, et tous les éléments du paysage doivent s’assembler pour offrir les solutions nécessaires.  Ainsi, une architecture bien définie définit la portée d’une solution complète plutôt que de se concentrer sur des composants individuels.  Par exemple, une solution alimentée par Citrix comprend bien plus de technologies que de simples composants Citrix, donc une architecture logique Citrix bien définie inclut des technologies auxiliaires (comme l’hyperviseur, la base de données, les points de terminaison, le stockage et Active Directory, pour n’en nommer que quelques-unes) pour illustrer les différentes technologies qui doivent s’assembler pour livrer une solution Citrix.
• Indépendant de la technologie. Un puriste de l’architecture d’entreprise insistera généralement sur le fait que l’architecture d’entreprise ne devrait pas mentionner les technologies; c’est-à-dire qu’elle est indépendante de la technologie.  Ainsi, en règle générale, toute définition architecturale basée sur une technologie spécifique dépasse intrinsèquement la portée (définition) d’une véritable architecture d’entreprise.  En pratique, ce niveau d’architecture entre rarement en jeu une fois qu’une architecture de base a été définie; Au contraire, cette approche est plus pertinente pour définir une nouvelle architecture (plutôt que pour maintenir une architecture existante) et peut aider à initier des définitions d’architecture pour permettre de nouvelles initiatives d’affaires.  Dans ces moments, il est très utile de référencer une architecture d’entreprise qui illustre toutes les capacités TI existantes, afin de déterminer si une nouvelle capacité est nécessaire pour permettre de nouveaux objectifs d’affaires, ou s’il est possible de tirer parti d’une capacité existante.
• Accent sur les capacités. Étant donné que l’architecture d’entreprise est destinée à un usage technique, la règle de base « indépendante de la technologie » peut sembler très restrictive.  C’est parce que l’objectif de ce concept est de concentrer ses énergies initiales sur les capacités nécessaires pour répondre aux exigences et aux cas d’utilisation.  Dans ce contexte, une technologie donnée est une solution proposée à une ou plusieurs exigences, d’où l’accent mis sur les capacités.  Par exemple, un diagramme d’architecture pour un nouveau cas d’utilisation du télétravail peut simplement illustrer que la capacité d’authentification multifacteur (MFA) est requise, mais ne précisera pas si la solution MFA sera RADIUS, Azure AD, DUO, etc.  C’est intentionnel et cela concentre la prise de décision sur toutes les parties concernées qui décident si la MFA est requise ou non pour les utilisateurs externes.  Une décision concernant la solution spécifique de MFA est une décision en aval et devrait (du moins en partie) être basée sur les principes d’architecture de l’organisation (abordés plus loin dans ce blogue).  Il est important de noter que certaines capacités peuvent avoir une solution basée sur les processus plutôt que sur la technologie; Par exemple, de nombreuses organisations de santé effectuent encore des dossiers en temps réel des patients via un clipboard traditionnel ou du papier et du crayon (et ce n’est que plus tard que ces informations sont saisies dans une demande de DME).
• Complète. Une architecture d’entreprise, ainsi qu’une architecture pour n’importe quel domaine du paysage informatique, doit représenter tous les éléments nécessaires pour répondre aux exigences attendues de la solution en cours d’architecture; c’est-à-dire qu’il doit être complet.  Être complet est une des raisons pour lesquelles un principe fondamental est de se concentrer sur les capacités, car cela permet aux dirigeants d’entreprise (qui ne possèdent généralement pas de connaissances techniques approfondies) de participer au processus initial d’examen de l’architecture afin de déterminer si l’intégration proposée des capacités permettra d’atteindre les objectifs d’affaires de la manière (utilisation) de ces objectifs envisagés par les dirigeants d’entreprise.  Ainsi, se concentrer sur les capacités aide une architecture à atteindre un niveau plus élevé de complétude et facilite la livraison d’une solution qui correspond à ce que l’entreprise a imaginé.
• Déterminé par les exigences. L’importance de rassembler les exigences n’est pas surprenante, mais il est très surprenant de constater combien de projets ne documentent pas correctement les exigences.  Les exigences doivent être organisées en exigences fonctionnelles (capacités requises par l’entreprise pour que les utilisateurs finaux puissent faire leur travail), exigences techniques (éléments nécessaires au bon fonctionnement des systèmes qui composent la solution), utilisation (les scénarios dans lesquels la solution sera utilisée) et cas d’utilisation (exemples qui précisent qui, quand et où la solution doit pouvoir être utilisée).  Le lit d’une personne est le canapé-lit d’une autre, donc les exigences devraient inclure une description de la façon dont les utilisateurs finaux utiliseront la solution en pratique (c’est-à-dire utilisation et cas d’usage) pour s’assurer que ce qui sera livré correspond à ce que l’entreprise envisage; d’autres processus, comme le SDLC, peuvent être adoptés pour aider à cette capacité.

Distinguer l’architecture du design

Jusqu’à présent, nous avons présenté les principaux avantages du maintien d’une architecture et d’une conception pertinentes, résumé brièvement certains des cadres d’architecture d’entreprise les plus populaires, et défini les principes fondamentaux.  Comme pour la plupart des blogues Ferroque Systems, notre objectif est de fournir des conseils pratiques, et ici nous allons aborder un sujet populaire : distinguer l’architecture du design.

Commençons par une affirmation simple : l’architecture se concentre sur ce qui est et le design sur le comment.  En pratique, les disciplines architecturales servent à identifier les personnes, les processus et les technologies qui seront assemblés de manière à permettre la solution désirée; Dans ce contexte, l’architecture définit le cadre (c’est-à-dire le « quoi ») d’une solution.  Une fois ce cadre établi, il peut être défini davantage en fournissant des détails substantiels pour définir les rôles et responsabilités spécifiques, les processus, procédures et flux de travail, ainsi que la manière dont les différentes technologies seront intégrées; Dans ce contexte, la conception définit le « comment » d’une solution.  En pratique, ce n’est souvent pas un processus linéaire; Cela peut commencer naturellement de l’architecture à la conception, mais le fait de définir de nouveaux détails suscite souvent de nouvelles questions et/ou des besoins (exigences) auparavant inconnus qui nécessitent de « retourner à la planche à dessin » pour mettre à jour le cadre (par exemple, un nouveau rôle, un nouveau processus et/ou une nouvelle technologie devient nécessaire), avant de recommencer à définir des détails de conception supplémentaires.

Utilisons une analogie du monde réel.  En tant que fan de Star Wars, je m’intéresse aussi à des sujets réels similaires, comme le programme spatial américain qui est né à la fin des années 1950.  Vivant dans le monde de l’informatique, je trouve incroyable de penser à la façon dont les États-Unis ont fait atterrir un homme sur la lune avec une technologie désuète des années 1960.  Si on se remettait dans cette époque, il n’y aurait pas de NASA, pas de fusées, pas de combinaisons spatiales... Rien.  Aujourd’hui, nous utilisons souvent l’expression « architecte du système »; lorsque la course à l’espace a commencé à la fin des années 1950, quelqu’un devait concevoir le programme qui permettrait aux États-Unis de rivaliser : quelqu’un avait pour mission de définir et de rassembler tous les éléments nécessaires pour rendre possible le vol spatial habité.  En 1958, la NASA a été créée grâce à l’évolution de la NACA (axée sur l’aéronautique; La NASA a ajouté « et l’espace »), et devait définir tous les rôles et responsabilités (par exemple, directeur de vol, commandant de mission, ingénieurs systèmes, etc.), processus (ex. processus CAPCOM, procédures de lancement, procédures d’alunissage, etc.) et technologies (par exemple, trop nombreuses pour être nommées) nécessaires pour atteindre cet objectif.  L’ampleur de l’objectif nécessitait la définition d’un cadre approprié pour examiner tous les éléments qui devaient se réunir pour former une solution cohérente; Ce n’est qu’une fois qu’un cadre de haut niveau était défini que les différentes équipes pouvaient alors procéder à la définition de leurs détails spécifiques (c’est-à-dire la conception).  Dans le cas de la NASA et des programmes de vols spatiaux, en raison de leur taille impressionnante, des cadres existaient à différents niveaux; Par exemple, le diagramme ci-dessous illustre un cadre de haut niveau (architecture) de rôles et responsabilités clés, où chaque boîte engendre un cadre de niveau inférieur de rôles et responsabilités clés, et chaque cadre de niveau inférieur est extrapolé en des niveaux de détail plus granulaires qui définissent les rôles, processus et systèmes spécifiques, comment ils fonctionnent tous ensemble, ainsi que les entrées et sorties clés.  Ces détails granulaires de bas niveau sont analogues à la conception.

Dans l’analogie du programme spatial, la taille même permet de distinguer plus facilement l’architecture et la conception; dans le monde des TI, les initiatives sont bien plus petites, donc la distinction est généralement beaucoup plus subtile et souvent floue.  Mais comme nous le verrons dans ce billet, de telles distinctions existent toujours.

À ce stade, il vaut la peine de mentionner les différents types d’architecture technologique; pour des raisons pratiques, nous limiterons à ce que Ferroque Systems voit le plus souvent dans le domaine : les architectures conceptuelles, logiques et physiques.  Pour les besoins de ce blogue, nous allons définir ces types d’architecture comme suit :

• Une architecture conceptuelle possède essentiellement les mêmes attributs que les principes fondamentaux décrits ci-dessus; C’est-à-dire qu’elle se concentre sur les capacités et est indépendante de la technologie, et présente une solution complète qui regroupe toutes les capacités administratives et administratives nécessaires au fonctionnement de la solution comme il faut.
• Une architecture logique indique des technologies spécifiques et illustre comment ces technologies fonctionneront ensemble pour fournir des résultats attendus qui répondent aux exigences. Selon la solution représentée, elle peut aussi indiquer les flux de trafic et indiquer les zones où des solutions non techniques (par exemple, les processus) jouent un rôle clé.  Une architecture logique fait souvent le lien entre architecture et conception et c’est ce que Ferroque Systems observe le plus souvent sur le terrain.
• Une architecture physique indique des composants spécifiques et illustre comment ces composants sont physiquement connectés; par exemple, il représente souvent du matériel spécifique, des spécifications et dimensions, des ports et configurations de commutateurs, des diagrammes de câblage, des configurations de rack, des régions cloud, la topologie réseau, les adresses IP et les noms DNS, etc. Comme le dit le proverbe, « Une image vaut 1000 mots », donc cela accompagne le plus souvent un document de conception pour illustrer graphiquement (plutôt que simplement décrire verbalement) comment tous les composants vont fonctionner ensemble pour fournir une solution.

Concernant les principaux avantages décrits au début de ce blogue, ces types d’architecture s’alignent comme suit :

• Facilite l’organisation des idées et une vision en une solution pratique valide, et sert de référence pratique pour apporter des améliorations avant le début du déploiement physique (« mesurer deux fois, couper une fois »). >> Architecture conceptuelle
• Fournit une référence globale pour l’environnement TI qui guide les décisions et mises en œuvre technologiques, afin de garantir que ces décisions et actions perpétuent une approche cohérente et partageant les mêmes idées dans tous les domaines technologiques. >> Architectures conceptuelles et logiques
• Fondation pour définir les artefacts de conception technique pour chaque domaine technologique; De tels artefacts de conception offrent des avantages supplémentaires. >> Architecture logique
  • Des directives détaillées pour configurer les composants technologiques tels qu’ils existent dans le monde réel, et s’assurer que plusieurs composants seront configurés pour orchestrer et intégrer des fonctionnalités dans une solution cohérente. >> Architecture physique
  • Justification de la configuration d’un composant technologique donné de cette façon, qui peut être référencée en continu pour déterminer si/quand un changement est justifié selon de nouvelles exigences et/ou cas d’utilisation. >> document de conception (contenant divers diagrammes d’architecture)

Il y a généralement un flux ou une progression naturelle dans la définition de solutions axées sur la technologie, qui commence lorsque les dirigeants d’entreprise énoncent les objectifs principaux de l’organisation, suivis des dirigeants de groupes d’affaires qui énoncent les initiatives et exigences de leurs groupes pour atteindre ces objectifs.  Peu après, les équipes TI de l’organisation s’impliqueront pour déterminer comment tirer parti des investissements technologiques de l’organisation afin d’atteindre ces objectifs et exigences.  C’est à ce stade qu’une architecture d’entreprise devrait être référencée, afin d’aider à identifier les domaines qui devraient jouer un rôle dans la satisfaction des exigences (par exemple, en identifiant les capacités requises et si toutes ces capacités existent déjà); c’est-à-dire que l’architecture d’entreprise est le sommet de la cascade qui suscite le flux des discussions techniques nécessaires en aval.  Être au sommet de la cascade souligne l’importance de la complétude de l’architecture d’entreprise.

Comme suggéré plus haut, la distinction clé entre architecture et design réside dans la portée globale et le niveau de détail (et donc l’utilisation prévue) : une architecture d’entreprise est une architecture conceptuelle qui représente l’ensemble de l’écosystème technique, une architecture conceptuelle existe souvent pour chaque système clé de l’entreprise, les architectures conceptuelles au niveau des systèmes sont souvent développées en architectures logiques pour illustrer des détails supplémentaires, et de telles architectures logiques peuvent être étendues davantage en architectures physiques et documents de conception pour justifier des décisions de conception détaillées.  En pratique, ce flux naturel de l’architecture au design se manifeste le plus souvent comme suit :

• En commençant par une architecture conceptuelle pour définir des limites de portée tangibles et fournir un cadre technique (squelette) pour orienter les discussions et décisions en cours. En supposant que l’architecture respecte les principes fondamentaux, il peut être approprié d’inclure les dirigeants d’entreprise dans certaines de ces discussions afin de s’assurer que les résultats s’alignent davantage sur les besoins de l’entreprise (notamment en ce qui concerne l’utilisation, car il existe souvent plusieurs options pour répondre à une exigence, donc inclure des dirigeants d’entreprise peut aider à identifier l’option qui correspond le mieux à la vision de l’entreprise sur l’utilisation des nouvelles exigences).
• Évoluer vers une architecture logique en approfondissant les domaines (capacités) qui seront utilisés pour répondre aux nouvelles exigences, dans le but d’ajouter plus de détails; par exemple, pour indiquer des technologies spécifiques et comment elles s’intégreront. Bien qu’elle ne soit pas spécifiée comme telle, souvent une architecture logique définit intrinsèquement un système logique (qui peut franchir les frontières technologiques) et indique les entrées et sorties nécessaires (par exemple, ensembles de données, jeton de sécurité, rapports, etc.), ainsi que les flux de trafic à l’intérieur du système (pour définir plus clairement le séquençage et les dépendances).
• Un détail supplémentaire en utilisant une architecture physique pour traduire une architecture logique en implémentation réelle. Cela inclut souvent des détails spécifiques nécessaires au fonctionnement de la solution réelle, tels que les hôtes physiques, les adresses IP, le stockage et les partages de dossiers, les noms DNS, les URL, etc.  Un document de conception sera souvent aussi créé pour documenter (capturer) les justifications des décisions de conception.  De telles architectures physiques et documents de conception servent généralement de plan pour configurer et intégrer les technologies/composants nécessaires à la mise en œuvre de la solution réelle.

Après avoir parcouru la progression naturelle et les distinctions clés, prenons un moment pour rappeler que nous avons mentionné plus haut que de nombreux fournisseurs (par exemple Citrix, VMware et d’autres) promeuvent un modèle d’architecture natif, qui dans ce contexte est généralement représenté graphiquement comme une architecture logique (puisqu’elle est spécifique à la technologie du fournisseur et à toute technologie auxiliaire).  Nous mentionnons cela ici parce que souvent de tels diagrammes d’architecture sont décrits comme une architecture conceptuelle, ce qui peut sembler un peu déroutant compte tenu du contenu de ce blogue.  En pratique, qu’on l’appelle une architecture conceptuelle ou logique n’est pas significatif – ce que certains appellent une architecture conceptuelle, d’autres peuvent considérer comme une architecture logique, et vice versa – ce qui compte, c’est que le diagramme d’architecture soit informatif, précis et utile pour guider la prise de décision continue.

Cela dit, au sein d’une organisation donnée, il est pratique de souscrire à une définition commune des architectures conceptuelles, logiques et physiques, afin que tout le monde ait les mêmes attentes lors de la création et de la révision de tels artefacts.  Comme mentionné plus haut, dans Ferroque Systems, nous travaillons le plus souvent au niveau de l’architecture logique, principalement parce que cela fait partie de la nature de la conception de solutions de livraison d’applications axées sur des technologies comme Citrix et diverses solutions cloud (comme Microsoft Azure et Amazon/AWS).  De plus, en pratique, ces efforts logiques prolongent souvent la conception pour inclure des détails physiques; Le niveau de considération physique de la conception dépend des besoins du client, de la pile de produits en cours de conception et du type de conception (par exemple, haut niveau vs. bas niveau).

Comme indiqué ci-dessus, il existe des distinctions clés entre architecture et design, et chacun de ces artefacts a un but, un cas d’usage et un public cible spécifiques; Fait correctement, chaque artefact facilite les discussions et décisions qui s’ensuivent.

À suivre...

Dans cet article, nous avons présenté les principaux avantages de l’architecture et du design, résumé brièvement certains des cadres d’architecture d’entreprise les plus populaires, exposé les principes fondamentaux de l’architecture, décrit les distinctions importantes entre architecture et design, et décrit le flux naturel et la progression de l’architecture d’entreprise vers la conception détaillée.

Ce premier billet de blogue vise à préparer le terrain pour nos prochains articles de cette série, où nous entrerons dans des détails pratiques tels que la définition des principes et normes architecturaux, les méthodes pour définir et utiliser une architecture, comment faire évoluer l’architecture vers le design, ainsi que les pièges courants à éviter lors de la définition de l’architecture et du design.  Restez à l’écoute; Il y a bien plus à venir dans notre prochain article!