Schémas

C'est l'outil de travail principal
- pour vous afin d'être certain d'avoir compris une solution technique
- si c'est flou, c'est qu'il y a un loup : pour clarifier.
- pour la médiation avec les différents acteurs du projet
- pour capitaliser les informations
- pour, si vous êtes outillés, générer les informations de vos dossiers d'architecture.
- en cas de crise, pour faciliter les décisions
les schémas doivent être uniques, par exemple l'intégrateur n'a pas à refaire des schémas "à sa sauce". Si des besoins surviennent, veillez à ce qu'il soit intégré dans vos schémas ou des schémas dérivés mais qui respectent toujours les règles édictées.

A minima 3 schémas sont nécessaires

fonctionnel : acteurs, macrofonctions de l'application, applications amont/aval, flux des objets métiers
applicative : briques applicatives, infrastructures utilisées, flux applicatifs
technique : hébergement, zones réseaux, ressources consommées, terminaux utilisateurs, WAN, LAN, VLAN

Pour les solutions simples, notamment lorsque vous êtes clients d'une solution SaaS, les 2 derniers peuvent être fusionnés sur un seul schéma.
Inversement vous pouvez faire d'autres schémas si cela vous semble pertinent. Par exemple, une solution très complexe peut être décomposée en un schéma applicatif global la représentant en tant que boite noire avec ses interfaces, tandis qu'un second schéma applicatif détaillera les entrailles de cette boite noire cette fois sans les interfaces.

Demander la réalisation de schémas, impose d'en définir le formalisme attendu. Au-delà du choix du langage (ici Archimate), il convient de détailler la façon de modéliser au sein de l'entreprise. Je vous recommande fortement de limiter les libertés : sans cela, chaque architecte va modéliser selon son propre regard et ce qui est une application pour l'un, va devenir une brique technique pour l'autre, et un service réseau pour le troisième.

Les règles doivent être vivantes, inutile de vouloir couvrir tous les cas dans la version initiale, vous les ferez évoluer à chaque nouvelle problématique rencontrée. Ne les figez donc pas dans un beau document Word signé par 15 niveaux hiérarchiques mais gardez-les à la main de tous les architectes qui les affineront au fur et à mesure.

A titre d'exemple, elles faisaient X pages dans ma dernière expérience et évoluaient toujours un peu 3 ans après leur rédaction.
Pour un formalisme comme Archimate, qui laisse beaucoup de marges de manoeuvres sur l'usage de tel ou tel concept, vous y détaillerez comment vous voulez :

représenter vos applications est-ce le même formalisme que celui des applications externes de votre SI
eprésenter vos serveurs et les propriétés à préciser (faut-il indiquer l'OS, le type VM ou physique, les logiciels, la RAM, etc)
les relations que vous voulez voir utiliser (Archimate propose beaucoup de types de relations différentes toutes ne sont pas forcément indispensables et surtout vous risques de perdre le elcteur peu au fait de ce formalisme, ne perdez pas de vue que votre schéma est un outil de communication, sa compréhension doit rester accessible au plus grand nombre)

Bien sûr tout cela sera grandement facilité si tous les architectes partagent un référentiel commun dans leur outil de modélisation. Puisqu'ils réutiliseront la plupart des concepts déjà existants, il n'y aura nul besoin de se poser la question de leur représentation à chaque utilisation.

Les schémas sont des outils de communication mais il peut aussi qu'on souhaite, tout comme le reste de la documentation architecture, en restreindre l'accès.