Introduction
Dans notre article précédent, nous avons exposé 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 de l’architecture d’entreprise vers la conception détaillée.
La première partie de cette série a préparé la table en exposant les concepts et avantages importants de l’architecture et du design; Dans cet article, nous allons explorer des détails pratiques tels que la définition des principes et normes de l’architecture, ainsi que les méthodes pour définir et utiliser une architecture.
Principes et normes d’architecture
Dans la première partie de cette série, nous avons mentionné que Ferroque Systems ne voit pas souvent une architecture d’entreprise complète et pertinente; nous avons observé qu’environ la moitié de nos clients disposent d’une architecture complète et pertinente qui décrit leur environnement Citrix et/ou niveau d’accès; encore moins ont un design moderne; Presque aucun n’a documenté des principes ou des normes architecturales.
Les principes et normes architecturaux sont la colonne vertébrale d’une prise de décision technologique cohérente. Nous avons observé que pour la plupart des administrateurs TI, les principes et les normes ont tendance à être regroupés afin d’être considérés comme une seule et même chose; cependant, il y a une distinction claire. Les principes sont indépendants de la technologie et s’appliquent donc à tous les domaines techniques, et représentent le sommet de la cascade à partir duquel les normes sont définies. Les normes sont définies de manière à respecter les principes et sont généralement spécifiques à une technologie et donc spécifiques à un domaine technologique (c’est-à-dire un ensemble de normes pour chaque domaine technologique).
Étant basé aux États-Unis, j’aime faire une analogie avec les artefacts juridiques et le système qui existent aux États-Unis. La Constitution américaine (et ses 27 amendements) est la colonne vertébrale de toutes les lois et du système juridique aux États-Unis. L’autorité de la Constitution s’applique à tous les 50 États des États-Unis, ainsi qu’à tous les comtés, villes, etc. qui existent dans chaque État individuel. De cette façon, la Constitution établit les principes juridiques pour l’ensemble des États-Unis. Toutes les lois qui ont été et/ou seront créées doivent être conformes à la Constitution (les lois perçues comme contraires à la Constitution sont généralement contestées et peuvent être annulées). Il existe des lois fédérales qui s’appliquent universellement partout aux États-Unis, des lois spécifiques à chaque État, ainsi que des lois propres à chaque comté, ville, etc. De cette façon, les lois d’un État, d’un comté, d’une ville, etc., établissent les normes légales auxquelles chacun de ses citoyens est censé se conformer (de peur qu’une personne ne se retrouve en difficulté juridique). Mais peu importe leur juridiction (ou « domaine »), chacune de ces lois doit être conforme à la Constitution américaine.
Maintenant que la distinction entre les principes et les normes d’architecture a été clarifiée, nous fournirons des conseils pratiques pour définir ces principes et normes. La première étape consiste à définir les principes architecturaux. Naturellement, plusieurs méthodes peuvent être utilisées; une méthode que je préfère est ce que j’aime appeler les « -ilités », où un architecte liste ses 10 principaux attributs environnementaux – tels que l’agilité, la disponibilité, l’extensibilité, l’interopérabilité, la gérabilité, la fiabilité, l’évolutivité, la stabilité, l’utilisabilité, la visibilité et la sécurité – et attribue une définition à chaque attribut (pour assurer une compréhension commune). L’architecte définit ensuite les principes d’architecture pour chaque attribut – par exemple, l’un des principes d'« extensibilité » peut être « L’architecture d’entreprise et toutes les architectures de domaine adopteront une conception faiblement couplée où chaque couche a un but/fonction défini »; l’un des principes de « scalabilité » pourrait être « La mise en œuvre de nouveaux systèmes soutiendra la capacité pour le plan de croissance sur 2 ans du système »; l’un des principes de « visibilité » peut être « Toutes les solutions technologiques dans l’environnement de production doivent être surveillées et mesurées par la solution de surveillance d’entreprise »; etc. Ces exemples illustrent que les principes doivent être définis à un niveau de détail suffisamment large pour être applicable à tous les domaines technologiques, mais suffisamment spécifiques pour être mesurables (conformité facile à reconnaître) et exploitable.
En allant plus loin, un architecte peut alors prioriser ses 10 principales caractéristiques architecturales afin de fournir une compréhension commune des attributs les plus (et les moins importants). Une méthode efficace consiste à effectuer une comparaison par paires des « -ilités », où chaque attribut est comparé à tous les autres attributs pour noter la priorité relative, ce qui donne une liste ordonnée (priorisée) d’attributs. Le tableau ci-dessous illustre un exemple de cette comparaison.
Le tableau ci-dessus illustre un exemple de comparaison par paires complétée qui donne une liste prioritaire de principes architecturaux (le graphique complété est un exemple; il n’est destiné à aucun niveau d’influence concernant les principes priorisés). Cet exemple a été créé via Microsoft Excel; Pour guider la création d’un tel tableau, des indicateurs de lignes et de colonnes (aussi appelés étiquettes ou en-têtes) ont été inclus dans le graphique, et ci-dessous sont les formules des lignes #13 et #14 (« Total des votes » et « Classement ») :
- Total des votes (ligne #13) : COUNTIF($C$2 :$M$12,C1) *cette formule existe dans les cellules C13-M13; seule la lettre rouge (colonne) change dans la formule de chaque cellule, selon la colonne.
- Classement (ligne #14) : RANK(C13,$C$13 :$M$13,0) *cette formule existe dans les cellules C14-M14; seule la lettre rouge (colonne) change dans la formule de chaque cellule, selon la colonne.
Définir les principes de l’architecture de cette manière fournit un cadre qui peut faciliter la gouvernance architecturale et aider à la prise de décision technologique continue. Par exemple, supposons qu’Acme Rocket Co. ait priorisé ses principes d’architecture selon le tableau ci-dessus et mette en œuvre de nouveaux logiciels applicatifs. Ce faisant, Acme Rocket Co. souhaite améliorer la sécurité en exigeant la MFA (authentification multifacteur), mais l’équipe informatique sait que les étapes supplémentaires requises pour la MFA frustreront la communauté des utilisateurs. Dans ce cas, l’équipe TI fait référence à ses principes prioritaires et note que la « Sécurité » est prioritaire avant « l’Ergonomie », donc l’équipe TI configure la MFA. L’équipe TI adoptera la même approche pour prendre de futures décisions de ce type, favorisant ainsi une prise de décision cohérente et un alignement avec les principes architecturaux. C’est un exemple simplifié, mais il illustre clairement le concept.
Une fois les principes d’architecture définis, les normes d’architecture peuvent alors être définies. Naturellement, plusieurs méthodes peuvent être utilisées; Puisque les normes d’architecture sont spécifiques aux domaines technologiques, les normes techniques sont souvent catégorisées par domaine technologique – telles que la livraison d’applications, les services d’annuaire, les points de terminaison, le matériel, l’hyperviseur, le réseau, le stockage, etc. Les PME de chaque domaine technologique définiront les normes techniques pour leur(s) domaine(s) respectif(s); par exemple, l’une des normes de « livraison d’applications » peut être « Tout l’accès externe aux composants et ressources résidant sur le réseau interne se fera via Citrix Virtual Apps & Desktops »; l’une des normes de « sécurité » peut être « Toutes les solutions d’accès à distance doivent utiliser une authentification multifacteur via SAML 2.0 »; etc. Avec les principes architecturaux, définir des normes techniques de cette manière facilite une méthode pratique de prise de décision technique cohérente et une méthode fiable de gouvernance technique.
Utilisation pratique
Dans notre billet précédent, nous avons examiné une analogie d’il y a longtemps; Ici, voyons une analogie plus moderne pour illustrer l’utilisation pratique.
Comme c’est la période des Fêtes, ma femme et moi faisions récemment du shopping pour des cadeaux dans un magasin qui ne m’intéressait pas, alors j’ai trouvé une chaise à l’écart. En attendant (avec impatience, pour être honnête), j’ai remarqué que tous les vendeurs avaient des tablettes et effectuaient des transactions au point de vente (mobile) avec les clients sur le plancher, au lieu d’exiger que les clients fassent la queue pour payer à la caisse. En observant, mon esprit a vagabondé en pensant à la façon dont quelqu’un avait pris la décision de mettre en place cette nouvelle capacité mobile de vente/transaction et avait probablement mis au défi l’équipe TI de trouver comment y parvenir. Ce faisant, j’aimerais penser que l’équipe TI a consulté son architecture d’entreprise pour déterminer s’il était possible de tirer parti des capacités existantes, a identifié les lacunes pour de nouvelles capacités, et a travaillé avec un gestionnaire de relations d’affaires (BRM) pour comprendre si des processus d’affaires devaient être mis à jour. À ce niveau initial (conceptuel), les équipes étaient davantage concentrées sur les capacités et processus (par exemple, la capacité à répondre aux exigences de données PCI pour les transactions mobiles) que sur des technologies et composants spécifiques.
Une fois les capacités et processus déterminés, d’un point de vue TI, l’attention s’est portée sur la possibilité d’exploiter les technologies existantes ou si une ou plusieurs nouvelles technologies étaient nécessaires. Les principes et normes d’architecture ont probablement été référencés lors des séances de remue-méninges qui ont probablement eu lieu, afin d’aider à évaluer et prioriser les idées proposées. Pendant cette période, plusieurs idées étaient probablement schématisées sur un tableau blanc, et ces diagrammes étaient probablement encadrés dans le contexte d’une architecture logique pour un ou plusieurs systèmes informatiques existants et développés pour illustrer les composants nécessaires et le flux de données. Aussi, rappelez-vous que l’architecture concerne les personnes, les processus et la technologie, donc les diagrammes de processus ont probablement aussi été utilisés pour illustrer le flux de travail des processus parmi les rôles inclus (les personnes). Une fois qu’une idée « gagnante » a été identifiée – mais avant qu’elle ne soit finalisée – les détails de la mise en œuvre de cette idée ont probablement été discutés entre les équipes informatiques concernées afin de vérifier que la solution proposée serait alignée avec les principes et normes existants et s’intégrerait « proprement » aux systèmes existants.
Une fois l’architecture logique et les flux de travail déterminés, du point de vue informatique, l’accent s’est déplacé vers les composants physiques. À ce stade, les avantages et inconvénients de composants spécifiques ont probablement été discutés – comme le type spécifique de terminaison mobile (par exemple iPad, Surface, Chromebook, etc.) et les options pour capturer les transactions de paiement sur le point de terminaison (par exemple Square Card Reader pour magstripe ou puce, lecteur de carte de crédit portable, etc.) – et évalués et priorisés selon l’adéquation globale à l’usage et les coûts.
Ce processus global a été présenté ici de façon simplifiée et rationalisée afin d’illustrer le concept de la façon dont les artefacts de l’architecture d’entreprise, des principes et des normes sont souvent utilisés en pratique. Comme nous pouvons le voir, de tels artefacts sont essentiels pour fournir un cadre permettant à plusieurs équipes de collaborer afin de définir la solution optimale pour une nouvelle initiative d’affaires. Oui, ces activités pourraient certainement être réalisées sans de tels artefacts, mais comme on peut le voir dans cet exemple, il y a des moments clés où la présence de tels artefacts aide à accélérer une compréhension et une prise de décision communes, et ce, de façon cohérente et reproductible. Autrement dit, dans l’économie moderne où le temps presse toujours, de tels artefacts facilitent une prise de décision plus rapide et intelligente, accélérant le délai de mise sur le marché (TTM) des initiatives d’affaires et générant moins de dette technique.
À suivre...
Dans cet article, nous avons exposé les principales distinctions entre les principes et normes architecturales, présenté une méthode pratique pour définir ces principes et normes, et examiné un exemple concret de la façon dont ces artefacts sont utilisés dans le monde réel.
Le premier billet de blogue a préparé le terrain pour la conversation globale, celui-ci explore des détails pratiques sur la façon de définir et d’utiliser les principes et normes architecturales, et notre dernier article de la série passera en revue les pièges courants que nous avons constatés dans de nombreuses organisations lorsqu’ils tentent de définir et/ou d’utiliser les principes et normes architecturaux. Restez à l’écoute; Il y a bien plus à venir dans notre prochain article!
