petits-outils-Architecture-dEntreprise-grands-benefices

Petits outils d’Architecture d’Entreprise, grands bénéfices !

Petits outils d’Architecture d'Entreprise, grands bénéfices !

10 septembre 2020

– 5 min de lecture

Architecture

Marie Gazal

Il y a quelques temps, nous avons démarré une saga sur deux sujets qui nous semblaient décorrélés : outils d’Architecture d’Entreprise et Agilité. La question sous-jacente est bien de savoir comment l’outil d’Architecture d’Entreprise peut apporter de la valeur aux équipes opérationnelles, sans perdre pour autant sa simplicité d’utilisation et ses cas d’usage principaux.

De nouveaux acteurs dans le secteur des outils d’Architecture d’Entreprise ont axé leurs efforts sur la facilité de prise en main et la qualité des restitutions à la volée. Un outil facilitant ce travail de manière récurrente peut permettre d’embarquer des utilisateurs « non-architectes », dont l’activité quotidienne est déjà consacrée à 100% à des tâches opérationnelles.

Mais ces nouveaux outils signent-ils pour autant la fin des leaders historiques du marché ? Et surtout, cela signifie-t-il qu’ils doivent être utilisés à des fins plus opérationnelles par les équipes ?

La fin des dinosaures ?

dinosaure

Les outils historiques du marché de l’Architecture d’Entreprise ont été conçus par des experts pour des experts. Et qui en est pleinement satisfait aujourd’hui ? Étant donné leur inertie et la lourdeur de leur configuration, ces outils peuvent exclure les projets et les équipes agiles.

On reproche aux EAMS (Enterprise Architecture Modeling System) d’être des logiciels difficiles d’utilisation, obscurs pour les utilisateurs occasionnels et nécessitant une phase de formation non-négligeable avant utilisation. Trop souvent l’architecte d’entreprise est arrivé avec l’artillerie lourde pour imposer outils et process : c’est tout sauf agile !

Par ailleurs, l’intérêt de l’Agilité est d’apporter rapidement de la valeur au métier, grâce à aux interactions au sein d’équipes mixtes métier/IT. Formés à plusieurs domaines, les développeurs polyvalents sont capables de comprendre les besoins et d’interagir avec les experts pour prendre les meilleures décisions possibles. Cette interaction entre plusieurs disciplines favorise la montée en compétence et enrichit les échanges. De la même façon, des outils déployés par les architectes pour les architectes apportera moins de valeur que s’ils sont ouverts à d’autres domaines d’expertise et améliorés en fonction des enjeux de chacun.

Alors, architectes, puisons notre inspiration des opérationnels et de leurs outils !

Jeune outil deviendra grand

jeune outil AE

Face aux mastodontes historiques, de nouveaux acteurs ont émergé ces dernières années, jusqu’à devenir de sérieux concurrents. Serait-ce la réponse à l’incompatibilité apparente entre besoins de l’Architecture d’Entreprise et des équipes opérationnelles ?

Certains outils sont de simples modelers. Sans prérequis particuliers de prise en main, ils répondent directement aux besoins de modélisation des projets. Encore faut-il trouver le bon compromis entre la gestion centralisée d’un référentiel d’assets IT et de l’architecture mouvante des projets agiles.

D’autres outils, à peine plus complexes en apparence, gèrent même un référentiel : le principe est d’alimenter l’outil via l’import de données pour générer automatiquement des rapports. Interfacer un outil d’Architecture d’Entreprise et un outil de modélisation est même possible nativement chez certains éditeurs. Ou bien, sous réserve d’avoir quelques « techos » disponibles, une interface « maison » entre l’EAMS et l’outil de modélisation projet (tel Archi, ou autre) permet de dissocier la partie référentielle du projet et de ses changements. Tout cela pour un contenu toujours plus riche, mais structuré !

Nous pensons également aux éditeurs qui intègrent de manière « out-of-the-box » des outils utilisés par les projets, comme la suite Atlassian. En quelques clics sur Confluence, par exemple, il devient possible de partager au sein de l’équipe des diagrammes et roadmaps modélisés dans le logiciel d’AE, de manière dynamique et embarquée. La démarche se veut collaborative : cette interconnexion ferait-elle le pont entre les deux mondes pour finalement mettre tout le monde d’accord ?

Grâce à ces logiciels, il devient possible de centraliser toutes les informations importantes pour les projets et l’entreprise dans une vue unique et partagée. Si le but est de communiquer des informations clés, c’est suffisant. Architectes d’entreprise et équipes agiles échangent leurs connaissances (opérationnelles ou stratégiques, détaillées ou macroscopiques, délimitées ou transverses) pour mener les projets de transformation de l’entreprise au mieux.

L’outil d’AE, l’ouvrir aux opérationnels ou pas ?

ouvrir outil AE aux opérationnels

Pour garantir la mise à jour régulière du référentiel d’architecture, l’implication des équipes opérationnelles (exploitation, projet, développement, intégration) est indispensable. Car ce sont eux, les « sachants » ! 

Or, si les équipes opérationnelles ont besoin de connaître l’historique des incidents et évolutions de l’application, ses certificats associés et ses contrats de support, les architectes souhaitent principalement visualiser l’existant et bénéficier d’analyse d’impacts exhaustives sur un périmètre précis.

Pour autant, faut-il que l’outil d’AE se plie aux besoins des équipes opérationnelles pour garantir sa mise à jour effective ?

La réponse à cette question réside dans le fait que pour faire fonctionner un logiciel d’architecture, il faut se focaliser d’abord sur un ou deux cas d’usage majeurs, avant d’en élargir l’utilisation au gré des opportunités et des besoins. Que ce soit un outil flexible succinct ou un imposant dino, il faut revoir à la baisse les attentes vis-à-vis d’un outil d’Architecture d’Entreprise.

L’enjeu est donc de bien cadrer le scope. Votre outil d’Architecture d’Entreprise peut très bien se contenter de renseigner les grands jalons et dates d’atterrissage, afin de donner de la visibilité au métier et à la Direction informatique sur les applications et projets qui vont impacter le Système d’Information.

Dans tous les cas, le niveau de granularité des informations à renseigner reste l’élément le plus structurant pour un tel outil. Savoir quoi renseigner, par qui, jusqu’à quelle maille et surtout à quel moment demeure la clé pour garantir un référentiel cohérent et mis à jour régulièrement.

L’Architecture d’Entreprise en libre-service

N’essayons pas de faire monter les projets sur nos vastes outils d’Architecture d’Entreprise. Soyons clairs, ils ne sont pas adaptés à la capacité et à la philosophie des équipes projets. 

Avec un EAMS aussi simple qu’une appli de smartphone (à la navigation fluide, sans formation nécessaire et au contenu aisément partageable), les développeurs membres d’une équipe agile bénéficieraient des apports de l’AE et de sa connaissance du métier, de l’IT comme de l’entreprise dans son ensemble, sans alourdir leur charge.

Peut-être le secret réside-t-il dans la conception à deux entrées de l’outil d’AE : un grain précis et spécialisé pour les équipes opérationnelles et un grain macroscopique pour les responsables de pôle, les architectes et les directeurs (opérations, architecture, études, métier…), gérant les roadmaps et permettant l’alignement du SI sur les besoins du métier.

Architectes et équipes projets, qu’en pensez-vous ?



Sources images :

Les autres articles qui peuvent vous intéresser