Approches architecturales

Bien que l’architecture d’un système puisse emprunter de nombreux chemins et impliquer différentes approches et méthodes, quelques principes clés communs permettent d’obtenir une architecture ArcGIS moderne et réussie. Cette section du Well-Architected Framework comprend plusieurs rubriques sur l’architecture plus traditionnelle relatives à la séparation des logiciels et du matériel, aux points à prendre en compte concernant le Cloud ou aux approches d’intégration. Cependant, l’étendue des rubriques supplémentaires illustre comment le rôle d’un architecte d’entreprise ou de système a changé. Les résultats des activités architecturales ont également évolué, ce qui implique de nouvelles connaissances, rubriques et considérations. Ces recommandations visent à fournir une bonne base d’approche, et non un ensemble spécifique d’étapes et de résultats.

Tout d’abord, il est essentiel d’adopter une approche axée sur l’entreprise. Qu’est-ce que cela signifie en pratique ? À la base, cela signifie que l’architecture doit être conçue principalement pour prendre en charge des processus, des fonctionnalités d’entreprise ou des résultats spécifiques que l’organisation doit réaliser. Au lieu de se concentrer individuellement sur des domaines tels que les performances, la disponibilité, la technologie de déploiement ou les extensions de produit, ces décisions doivent toutes être ancrées sur la demande de l’entreprise pour cette capacité ou cette fonctionnalité. Cette approche axée sur la demande conduit à des systèmes qui prennent en charge les principales fonctionnalités en premier, puis se développent efficacement pour accroître l’impact et l’adoption dans l’ensemble d’une organisation.

Deuxièmement, il est important de suivre une méthodologie de développement architectural (ADM). De nombreuses méthodologies différentes existent, et aucune option n’est meilleure que l’autre, mais dans la mesure du possible, vous devez aligner les projets d’architecture sur la méthode couramment utilisée au sein de votre organisation.L’utilisation d’approches conformes à la façon dont les autres systèmes sont architecturés facilitera la communication des exigences du système, l’intégration d’autres conseils architecturaux et, finalement, l’approbation ou le soutien d’autres parties de l’organisation. Cela s’étend à l’implication d’architectes informatiques et commerciaux d’autres parties de l’organisation dans la mesure du possible.

Troisièmement, concentrez-vous sur la flexibilité plutôt que sur une taille matérielle ou une définition physique parfaite. Alors que les dépenses d’investissement liées à l’acquisition de matériel ont déterminé le coût des projets pendant de nombreuses années (et c’est encore le cas dans certaines organisations), un accès élargi à la virtualisation et au Cloud computing a réduit l’importance d’engagements matériels précis lors de la phase architecturale. La modification du calcul, de la mémoire ou du stockage d’un système est désormais généralement plus simple et nettement plus rentable que dans les architectures plus traditionnelles, ce qui suggère que des profils matériels flexibles et librement définis sont suffisants pour la plupart des architectures. De nombreuses organisations chercheront toujours à obtenir une recommandation sur la taille initiale d’un système, et ces systèmes ou applications demeurent responsables des coûts récurrents de ces systèmes. En résumé, il est important pour un architecte de trouver un équilibre entre une estimation initiale raisonnable et les changements potentiels induits par l’évolution de l’utilisation, les nouvelles fonctionnalités ou les nouvelles communautés d’utilisateurs.

De nouveaux domaines d’exigences ont renforcé l’importance d’une approche architecturale structurée, tels que la sécurité, les intégrations d’entreprise, la souveraineté des données ou d’autres sujets qui n’étaient peut-être pas pertinents dans des cas plus traditionnels. Ces exigences peuvent avoir un impact sur la conception de la solution, les choix matériels et le principe de gestion globale d’un projet ou d’un système, et sont tout aussi importantes pour les exigences fonctionnelles ou basées sur les performances qui orientent traditionnellement les choix d’architecture.

Voici d’autres bonnes pratiques pour l’architecture des systèmes ArcGIS :

• Faire preuve d’agilité : en tenant compte des dynamiques qui fluctuent, des changements dans les exigences pendant et après la phase de conception, et des revirements dans l’orientation de la stratégie informatique de votre organisation.
• Faire preuve de réactivité : passez régulièrement en revue les réussites (et les défis) d’une architecture avec les parties prenantes et suggérez des changements qui répondent à leurs demandes, qu’il s’agisse de fonctionnalités nouvelles et améliorées ou de modifications apportées à des fonctionnalités indésirables.
• Faire preuve d’intentionnalité : lorsque des changements sont nécessaires, soyez précis sur l’impact, le calendrier et les effets sur les utilisateurs. Une coordination minutieuse des modifications architecturales réduit la confusion, améliore la confiance des utilisateurs dans le système et augmente les chances de réussite.

Processus architectural

Lors de la conception de systèmes avec ArcGIS, de nombreuses organisations passent par des étapes similaires dans un processus structuré, généralement dépendant de la méthodologie de développement architectural (ADM) utilisée. Pour fournir du contexte supplémentaire, voici des exemples de phases d’architecture avec quelques détails spécifiques à ArcGIS.

1. L’établissement d’un cadre et de principes est une phase dans laquelle l’identification d’une méthodologie de développement architectural est importante, ainsi que les principes architecturaux principaux qui guideront la conception, tels que l’accent mis sur les contrats de niveau de service (SLA), la perspective d’approches de projet agiles ou en cascade, etc.
2. La définition d’une vision architecturale permet d’identifier les thèmes clés qui guideront le développement de l’architecture, tels qu’une initiative organisationnelle axée sur le Cloud, une migration vers un fournisseur de base de données ou un système d’exploitation différent, ou le désir d’implémenter rapidement de nouvelles fonctionnalités dans le système obtenu. Cette vision commence à préparer le terrain pour les décisions et les recommandations qui sont réalisées plus tard dans le processus.
3. La phase d’architecture d’entreprise se concentre sur « l’entreprise », un terme subjectif qui désigne généralement les opérations quotidiennes et les opérateurs d’une organisation, qu’il s’agisse d’une institution du secteur public ou privé. Cette phase se concentre sur les processus et les fonctionnalités existants et souhaités : quels sont les composants basés sur ArcGIS qui vous aideront à accomplir vos missions ? Cette phase comprend également les exigences non fonctionnelles qui sont importantes pour l’entreprise, telles que la convivialité, la sécurité ou les performances. Il est essentiel de séparer les exigences fonctionnelles de l’architecture d’entreprise (les processus et les fonctionnalités souhaités) des exigences non fonctionnelles et de l’architecture de la solution (la solution logique ou le logiciel et les composants de la solution) pour identifier les lacunes et les domaines potentiels où ces exigences peuvent entrer en conflit les unes avec les autres.
4. Une fois ces processus définis, une phase d’architecture des systèmes de données et d’information se concentre sur les structures qui prendront en charge les processus, à la fois les interfaces d’application (telles que les applications mobiles, Web ou de bureau) et les structures de données (structure, modèle de données, stockage) qui prendront en charge la persistance des données métier. Au cours de cette phase, des recommandations spécifiques concernant les applications, les fonctionnalités client ou les modèles de stockage à utiliser peuvent être élaborées.
5. Comme il existe de nombreuses façons de déployer ArcGIS, une phase d’architecture technologique se concentre sur les décisions et les distinctions qui conduisent à une spécification logicielle réelle ou à une acquisition. Au cours de cette phase, des décisions concernant le rôle d’ArcGIS Online et d’ArcGIS Enterprise peuvent être prises, ou des choix spécifiques seront faits en ce qui concerne le fournisseur de base de données, le fournisseur Cloud ou le système d’exploitation qui hébergera le logiciel.
6. Une fois cette image cible plus claire, une organisation peut commencer à planifier le déploiement, les opportunités et les solutions tout en se concentrant sur les étapes et les modifications qui doivent être réalisées pour rendre le nouveau système accessible aux utilisateurs. Il peut s’agir de changements organisationnels importants, d’acquisitions ou d’une amélioration du support du personnel technique, ou d’évaluations de technologies qui permettent de prendre une décision.
7. Lorsqu’un système existant est déjà utilisé pour certains processus métier, ce qui est souvent le cas, la planification de la migration permet de s’assurer que les utilisateurs migrent de façon rapide et efficace vers la nouvelle architecture. Cela peut impliquer une planification de la gestion des changements axée sur les personnes et les processus, mais aussi une planification technologique afin que les intégrations, les processus et même le contenu destiné au public soient migrés en douceur pour accéder à la nouvelle architecture et l’utiliser.
8. Une fois toute cette planification terminée, d’autres considérations de gouvernance sont souvent discutées. Ces considérations peuvent influencer la façon dont le nouveau système est utilisé, la façon dont les modifications apportées aux données ou aux applications sont examinées et contrôlées, et la façon dont le processus d’examen, de révision et d’implémentation se déroule, afin que l’architecture puisse rester pertinente, s’adapter aux nouvelles exigences et rester réactive face aux attentes des utilisateurs.

Grâce à une structure et à un processus architectural bien planifiés, les systèmes, grands et petits, peuvent être soigneusement conçus, implémentés et gérés efficacement au fil des années et des changements apportés aux utilisateurs et aux publics.