Les outils

Les outils

Outre une solution vous permettant de créer/gérer vos 99-archives/05-Projet livre architecture/content/Schémas , la boite à outils idéale d'un architecte se compose

  • d'une solution permettant de gérer et partager un référentiel de règles d'architecture,
  • d'une solution pour référencer et partager les logiciels, matériels de votre cadre d'architecture.
  • d'une solution pour gérer la documentation afférente à vos dossiers

l'outil pour les schémas

Même si vous êtes le seul et unique architecte de l'entreprise, vous aurez tout interét à mettre en place un outil un peu plus évolué que, au hasard, Powerpoint.

L'outil doit vous permettre de passer le moins de temps possible à réaliser un schéma. A titre indicatif, les 3 schémas relatifs à une application qui suivrait à la lettre un de vos patterns standards ne devraient jamais nécessiter plus de 20 minutes de votre temps.
Pour cela l'outil doit bien sûr permettre de respecter le formalisme que vous aurez préalablement choisi mais aussi

  • d'enrichir et maintenir au fur et à mesure un modèle dont les constituants seront facilement réutilisables pour les projets ultérieurs
  • de partager avec les autres architectes ce modèle
  • d'exporter dans un format ouvert et standard la totalité des données qui y auront été créées afin de pouvoir quand le besoin se fera sentir, changer de solution. Cet outil contient tout un patrimoine vital pour le SI, ne le laissez pas dans une solution fermée.

A titre personnel, je déconseille FORTEMENT les outils ne proposant qu'une interface en client léger, voire aussi ceux qui ne permettent de pas de travailler tranquillement en mode déconnecté. SI les solution en navigateur font des progrès, la réactivité des interfaces n'est clairement pas à la hauteur lorsque qu'on doit établir rapidement des schémas avec 112 relations entre 48 concepts. Vous ne pouvez pas vous permettre de perdre du temps du fait de ce type d'outils.

L'outil n'a pas besoin d'être une usine de gaz (je te vois EA !), il devrait même pouvoir se faire oublier. SI vous êtes obligés de prendre une ou des ressource(s) à plein temps pour administrer un outil dédié aux architectes, ce n'est, de mon expérience, pas un bon signe. Idem si vous avez besoin de 3 mois de formation avant d'être productif dessus.

En bonus, il vous permettra d'automatiser les tâches fastidieuses

  • synchronisation du modèle avec d'autres référentiels de l'entreprise (par exemple un annaire des applications déjà existantes)
  • vérifier la cohérence des schémas par rapport aux règles établies par vos soins,
  • identifier les éventuels doublons,

Sans faire de publicité si vous choisissez le formalisme Archimate, Archi est un outil simple qui "fait le job" intelligement et efficacement, à tel point qu'il peut être confié sans sourciller à des chefs de projets (auxquels vous allez pouvoir déléguer une partie de votre travail, tout le bénéfice est pour vous).
Bien sûr, il vous faudra parfois mettre les mains dans le cambouis GIT ou dans du javascript mais le jeu en vaut le chandelle.

Concernant Enterprise Architect, j'ai déjà diit que la solution était complexe avec une courbe d'apprentissage raide. Si à un moment ou à un autre de vos interventions vous ne prévoyez pas de l'utiliser pour faire de l'UML, je vous conseille de passer à autre chose.

Le réferentiel de règles

Ce référentiel est une liste vivante, évoluant sans cesse, des règles du jeu pour définir une architecture.
Il contient des énoncés, assortis d'un caractère obligatoire ou facultatif, de tags pour les filtrer, d'un identifiant unique, et de toute autre chose que vous jugerez utile comme des cas d'exceptions.

Le nerf de la guerre est la formulation des énoncés : il doit être concis, compréhensible par des non-architectes et dépourvu d'ambiguités. Il doit pouvoir être lu par des personnes extérieures à votre entreprise (par exemple lors d'un appel d'offres) et doit donc évacuer ou expliciter toute terminologie interne.

Exemple de règles :

  • Lors du choix d'une solution on privilégiera les solutions en Saas sur les solutions on-premise
  • Tous les flux, y compris ceux internes à nos datacenters sont obligatoirement chiffrés.

D'un point de vue technique, un tableur est largement suffisant mais vous pouvez aller plus loin si vous cherchez à implémenter un cycle de vie ou du versionning règle par règle.,
Dans tous les cas prévoyez de pouvoir les exporter afin d'adjoindre tout ou partie de ces règles à vos appels d'offres.

le référentiel logiciel, matériel

Sur le même modèle, vous devez documenter l'ensemble des solutions et équipements que vous acceptez de voir dans votre SI, sur vos serveurs, vos postes de travail.
Il peut s'agit de solutions pour lesquelles vous avez des compétences internes, vous avez approvisionné des licences, etc...
Ce réferentiel doit prévoir pour chaque entrée, le nom de la solution, la version concernée, un rapide descriptif, les informations de licence, les contacts des personnes compétentes, une notion de cycle de vie (est-ce une solution cible, ou plutôt une solution à résorber)

Ce référentiel sera très utilement annexé à vos appels d'offres afin d'orienter les réponses sur les choix techniques. Bien sûr, il est vivant, on peut toujours ajouter de nouvelles solutions mais si vous avez déjà 3 moteurs de base de données relationnelles dans votre parc, pensez-vous qu'il soit s'y pertinent d'en ajouter un 4ème parce que tel éditeur le privilégie dans sa réponse ?

Ce référentiel va aussi vous permettre de mener un exercice, annuel et tout simplement passionnant, de gestion de l'obsolescence. C'est pourquoi je vous conseille de stocker pour chaque entrée 3 dates :

  • la date d'entrée
  • la date à laquelle cette version de la solution sera à résorber
  • la date à laquelle on ne souhaite plus que cette solution soit présente dans le parc.

Nous reviendrons sur cet exercice dans Gérer l'obsolescence

Gestion de la documentation

Cette solution peut être une GED, dédiée ou non, l'important est d'avoir un point centralisé où elle est présente et accessible à qui de droit.