Les hasards des missions m’ont conduit récemment à discuter de structuration d’équipes d’architectures au sein de plusieurs DSI. Avec des constats communs : le bon architecte informatique est un oiseau rare et cher, et ce qu’on en attend n’est pas toujours clair pour tout le monde.

Des ressources clés.

Si une chose est communément partagée au sein des grandes DSI, c’est que les architectes sont des ressources stratégiques, qu’on aimerait les renforcer, les pérenniser et qu’on attend de grandes choses de leur part. Parce que le « logiciel dévore le monde », que les processus sont de plus en plus numérique. Parce que l’interaction entre les systèmes, les applications, les différents processus métiers est de plus en plus complexe à maîtriser. Parce qu’il qu’il y a beaucoup d’inconnues, et beaucoup de manières de se planter en construisant un système d’information. Comme dans le BTP, l’architecte devrait garantir que l’ouvrage va répondre au besoin sans s’effondrer, et à moindre coûts. Mais il y a toutes sortes d’architectes en informatique.

50 nuances d’architectes informatiques.

On trouve de nombreux intitulés de postes comprenant le mot architecte dans les DSI :

  • L’architecte d’entreprise qui pilote la construction d’ensemble du système d’information en anticipant les besoins métiers et en définissant les standards à appliquer
  • L’urbaniste ou architecte fonctionnel qui cartographie le SI, en réalise les plans et scénarios d’évolution et produit des études d’opportunité
  • L’architecte technique qui définit l’architecture technique, en établit la cartographie, et en définit les standards

Certains experts de grandes solutions progicielles peuvent également être appelés architectes solutions dans certains cas.

Ce panel large montre la difficulté d’amalgamer sur une seule tête à la fois la vision large et la vision micro, la vision métier, celle du partage des tâches entre les applications, et celle de implémentations techniques dans les couches basses. Et pourtant, c’est ce que l’on rêverait d’avoir.

Ce que l’on attend des équipes d’architecture :

  • Entretenir une vision globale systémique des interactions entre les métiers et les SI et définir les grands socles du système
  • Amener une vision prospective de l’apport des nouvelles technologies et sur l’évolution à apporter aux systèmes existants pour en bénéficier
  • Apporter un conseil aux métiers dans la définition de leur feuille de route et dans leur approche des projets, sans se substituer à eux pour les prises de décisions, mais en sachant les challenger
  • Donner dans un temps limité un cadrage de l’architecture des nouvelles solutions SI, et des guidelines pour les équipes projet
  • Définir quelles fonctions sont à porter par quel sous-système et donc quelles équipes de la DSI vont devoir travailler sur quoi
  • Appuyer les projets pour la mise en œuvre du cadre d’architecture ainsi défini, s’assurer de son respect

Le bon architecte et le mauvais architecte informatique.

On peut paraphraser le fameux sketch du chasseur des inconnus. Il y a le gars, il a un SI à faire évoluer, il pond une architecture, et c’est un mauvais architecte. Et puis il y a celui qui a un SI à faire évoluer, et il pond une architecture. Mais c’est un bon architecte.
Blague à part, notre portrait-robot idéal serait le suivant :

  • Il a un côté geek, sait comment fonctionne toute la chaîne informatique, du serveur au logiciel en passant par les bases de données ou les OS
  • Mais il conserve une vision systémique du SI, comprend les interactions métiers, et peut expliquer avec pédagogie à un DG quoi faire en matière de systèmes d’information, pourquoi et comment
  • Il sait ce que c’est que développer une application, il connaît les outils d’ingénierie logicielle les plus modernes… mais il sait que moins on développe aujourd’hui, mieux on se porte, car on peut réutiliser un maximum de composants ou de logiciels disponibles sur le marché
  • Il est à la pointe de la veille technologique, et dispose de ses antennes sur les bonnes sources d’information pour identifier de nouvelles solutions robustes aux problèmes IT
  • Il est branché en direct sur les travaux du W3C et de l’IETF parce qu’il sait qu’aujourd’hui les technologies de l’internet et du Cloud dominent le monde et qu’il faut en adopter au maximum les standards
  • Il pense performance technique autant que réponse aux besoins fonctionnels dès le début des projets
  • Il porte des exigences non fonctionnelles auxquels les métiers ne penseraient pas mais qui sont pourtant indispensable pour répondre vraiment à leur besoin
  • Il challenge les maîtres d’ouvrages pour chasser les spécifications trop complexes et viser la simplicité, l’adoption des meilleures pratiques plutôt que la reproduction de l’entropie existante. Mais il ne se fait pas maître d’ouvrage à leur place
  • Il sait challenger les informaticiens et les ramener dans le droit chemin lorsqu’ils sortent du cadre et créent de la dette technique
  • En cas de doute, il teste, il expérimente en permanence, plutôt que de rédiger un rapport de 30 pages. Et il retient et préconise ce qui fonctionne

De tels profils sont donc rarissimes, souvent hors des grilles salariales des organisations. Pour avoir quelqu’un qui coche ne serait-ce que la moitié de ces cases, il faut donc tordre les modèles RH, ou acheter des prestations externes. Avec dans tous les cas une difficulté à trouver les « bons » et à les garder. Car ces grands architectes informatiques sont souvent comme ceux qui apposent leur signature sur les bâtiments emblématiques : des stars, des divas, admettant souvent peu la contestation, compliqués à gérer.

Mais il faut quand même des visionnaires. Alors les DSI composent des cellules d’architectures pluridisciplinaires, et mettent parfois en place des « comités des sages ». Ce sont des comités avec des visionnaires extérieurs pour définir ou challenger les grandes orientations informatiques.

Quant aux PME, elles font de même à leur échelle. Avec un facteur qui peut être un avantage ou un inconvénient : elles ont des moyens limités, et doivent donc viser une informatique frugale. La simplicité de l’architecture, si difficile à obtenir dans un monde entropique, est donc clé. L’identification des bons partenaires également.

 

Sur le thème de l’architecture, vous pouvez lire ceci sur notre blog : 5 principes d’architecture pour un SI moderne ou les exigences générales pour un SI