https://wordpress.org/

Architecture : joindre l'utile à ... l'agile

Publié le 28/09/2017
Partager sur :

Dans la tête de beaucoup, agilité et architecture ne vont pas forcément ensemble. Il appartient aux architectes de construire le système d’information à 3 ans ou 5 ans et celui-ci se doit d’être agile. Pour ce faire, les architectes se réunissent en nombre, ils échangent pendant des semaines ou des mois, ils font intervenir une société prestigieuse de conseil pour enfin parvenir à publier LE schéma directeur, celui qui devra révolutionner l’entreprise. Au moment de le mettre en œuvre à l’aide de projets, ces mêmes architectes sont à nouveau sollicités et c’est là que le bât blesse. Pas assez pragmatiques, avec des concepts théoriques inapplicables, l’adéquation entre alignement avec l’architecture cible et agilité est délicate. De l’IT à l’orga, voici quelques éléments pour rendre compatibles architecture et agilité.

Cycle en V vs mode agile… Et l’architecture dans tout ça ?

Comme le système d’information, l’architecte se doit d’être « bimodal », c’est-à-dire être capable de basculer d’un projet géré en cycle en V  à un projet géré en mode agile. Ces deux types de méthodes amènent des différences importantes dans la réflexion de l’architecture. Le cycle en V va permettre aux architectes, au cours d’une phase clairement identifiée, d’étudier et de définir une cible d’architecture sur la base d’une projection des usages métier et applicatif. Tandis que le mode agile doit conduire à définir, en début de projet, une vision très haut niveau de l’architecture cible qui s’affinera au fur et à mesure des sprints. Pour limiter l’effet tunnel, les métiers sont de plus en plus demandeurs de projets gérés en méthode agile. Cela ne sonne pour autant pas la fin du cycle en V car il est adapté à la mise en place des fondations IT. Ces fondations servent à leur tour les projets agiles par l’apport du socle technologique sur lequel vont s’appuyer ces projets agiles. Ce socle se doit aujourd’hui d’être souple, réactif et scalable.

Quelles fondations pour simplifier l’architecture dans les projets métier ?

Il va de soi que la réponse dépend de la maturité IT de chaque entreprise. On constate que la transformation digitale et l’exposition du SI aux partenaires sont au cœur des réflexions métier et IT mais il ne faut pas pour autant en oublier l’essentiel. La plupart des systèmes d’information sont basés sur des systèmes historiques dits legacy. Ces legacy ont bien souvent été construits pour fonctionner au sein du SI (et non en dehors) et au fil des années, ils se sont parfois transformés en monolithes regroupant un grand nombre de fonctionnalités. Or, ce modèle ne correspond pas à l’approche associée aux nouveaux usages liés au digital. On constate que l’utilisateur souhaite davantage de la simplicité et de la facilité pour pouvoir traiter 80 pourcents de ses besoins métier quand par le passé on souhaitait couvrir l’exhaustivité de ses besoins par des outils hautement configurables et donc relativement complexes et chronophages. L’approche à retenir n’est donc pas celle visant à créer des surcouches aux legacy existants mais plutôt à exposer des services conçus pour et à les exposer à l’aide d’API (pour un SI partenaire) ou d’un portail (pour les utilisateurs du SI). En fonction de la maturité et du besoin en réactivité (nombre de livraison par jour), on s’attachera donc à une approche SOA (via un ESB) ou à des µservices (et des containers). A cela doit s’adosser une solution d’IAM pour la sécurisation des services. Il appartient aux architectes de définir les normes et standards d’utilisation de ces technologies pour permettre aux projets de les utiliser.

Quelle organisation pour l’architecture ?

L’architecte joue deux rôles dans une organisation, un premier régalien et un second d’accompagnement des projets. En phase de transformation de l’entreprise, il est nécessaire que les architectes soient regroupés et non disséminés dans les équipes. Leur positionnement dans l’organisation est même un facteur clé de succès pour la transformation de l’entreprise. Plus une cellule d’architecture est positionnée proche de la direction générale, plus son poids dans la transformation sera important et donc moins les choix seront remis en cause. En effet, on constate souvent que les recommandations ou les non conformités émises par l’architecture sont souvent mises de côté par l’absence de budget ou par des délais incompatibles. Si cela restera parfois vrai demain, il est primordial d’ajuster dès à présent la gouvernance projet pour permettre de pérenniser l’alignement des projets non conformes avec la cible d’architecture. Enfin, les architectes doivent être impliqués au plus tôt lors des projets, qu’importe l’organisation retenue (classique ou en product team), l’architecte est le garant de la réutilisabilité et responsable de la vision transverse du SI, il serait dommage de s’en priver ! Vous l’aurez compris, un architecte agile est un architecte formé aux méthodes agiles quand un architecte utile est rattaché au plus près de la direction générale et intervient au plus tôt dans les projets. Une architecture agile repose sur des fondations IT adaptées quand une architecture utile nécessite une légitimité dans les méthodes projets. Alors autant joindre l’utile à … l’agile !
Veuillez saisir votre adresse email pour vous abonner. Envoyer