À un moment de re-priorisation des projets SI suite aux chamboulements amenés par la crise sanitaire, que ce soit l’urgence du développement de la relation client par internet, y compris son intégration en temps réel avec la logistique (voir la logistique au cœur de l’expérience client) ou le doublement des télétravailleurs, l’architecture du SI n’a jamais été si importante.
Mais le rôle de l’architecte des SI, défini par la cohérence interne et la gouvernance centralisée, trouve-t-il toujours sa place dans une réaction rapide à des évolutions externes pilotée par l’urgence et les métiers ?
La transformation digitale des modèles économiques de certaines entreprises, dans des industries en mutation, avait déjà posé un certain nombre de questions ces dernières années sur la place de l’architecture d’entreprise (EA). Quand les métiers évoluent dans un contexte routinier, « business as usual » comme disent les Américains, l’architecture d’entreprise se développe et rationalise le SI.
Mais quand le contexte business devient incertain, que la compétition franchie les barrières des industries de façon disruptive, l’approche traditionnelle de l’architecture d’entreprise devient parfois un frein, qui apporte plus de questions que de réponses. Le désordre est même toléré, pourvu qu’il fasse vendre. Les métiers pourraient alors être tentés de s’affranchir de l’EA, de se concentrer sur les applications qui vendent à court terme, et non sur l’harmonie du SI à moyen terme 😉
Le digital a-t-il besoin d’architectes d’entreprise ?
Le retour d’expérience des « digital factory« , ces équipes souvent dédiées et isolées du reste du SI, en charge des développements digitaux natifs dans le Cloud, est intéressant. Il montre que l’architecture ne peut pas être abandonnée car elle réapparaît spontanément dans ces usines à applications digitales. L’architecture y est prise en charge par les développeurs les plus expérimentés, qui dirigent les équipes en mode agile (Lead dev). Dans ces équipes la conception, la réalisation, et parfois l’exploitation (depuis DevOps) sont réalisées de façon intégrée, contrairement à la vision classique d’une DSI – confortée par des années de gouvernance CoBIT – qui sépare les études, du développement (organisé en projets) et les développement de l’exploitation.
Ces architectes ont cependant un horizon plus limité, à la fois dans le temps en s’autorisant du « re-factoring » régulièrement, et dans l’espace en se concentrant sur le système à développer, souvent la ligne de produits portée par le « product owner », et ses interfaces, et non l’ensemble du SI.
Le déplacement de l’architecture, dans l’action et là où se crée la valeur client, est donc une piste à explorer quand on fait le constat d’une architecture régalienne, éloignée des métiers. Surtout si la bascule que l’on observe, de « grands projets » à des « plateformes produits », devient une réalité dans l’entreprise, y compris pour les plateformes support (RH, ERP…) avec des utilisateurs internes et non des clients externes. La gestion de produits prend le pas sur la gestion de projets.
Une autre façon de voir cette émergence, est de considérer que le rôle de l’architecture est repris par le développeur car ce rôle est lié au fonctionnement de l’équipe agile multidisciplinaires (product owner, le designer, le graphiste, les développeurs et parfois le support) qui avance par étapes (sprints).
Pour voir loin, l’architecte a besoin d’interactions. Dans ces équipes intégrées, il peut plus facilement être immergée dans la vision de la roadmap, l’IHM et bien sûr les contraintes de réalisation, délais du sprint en cours et des prochains. L’architecture peut garder son indépendance, mais au sein de l’équipe qui produit, et casser sont image de tour d’ivoire.
Le profil de l’architecte recherché par les métiers évolue alors vers des personnes pragmatiques, communicantes qui peuvent influencer les développements dans l’action.
Mais comment maintenant éviter les écueils classiques des équipes autonomes : développer plusieurs fois la même chose, la complexité croissante de l’architecture qui duplique les efforts de gestion des composants, ou le manque de synergies entre lignes de produits pouvant aller jusqu’à une expérience client décousue ?
Personnellement, j’ai déjà été confronté au site d’une grande assurance pour gérer des produits d’épargne acquis personnellement (type PER), totalement différents du site utilisé pour des produits identiques, acquis pour moi, mais par mon entreprise. On se retrouve alors avec deux sites, deux authentifications, et une vision différente de produits identiques. On se doute vite que l’équipe B2C et l’équipe B2B étaient distinctes, et dans deux divisions différentes. Pourtant dans une logique patrimoniale centrée sur l’utilisateur (moi), la vision similaire à défaut d’être unifiée, de mes investissements dans ces produits, est juste une évidence.
C’est justement là que l’architecture d’entreprise doit reprendre la main.
Une approche rencontrée est, à partir d’une cellule intégrée multidisciplinaire centrée sur un produit, de confier aux architectes d’entreprise une responsabilité plus transverse, à plusieurs lignes de produits, en fixant dans leurs objectifs la gestion de la plateforme digitale comme socle accélérateur des projets.
C’est donc la poursuite d’une construction du bas vers le haut, en reprenant les composants produits par les équipes au plus près des besoins, et en les consolidant comme composants normalisés au niveau d’une plateforme digitale mise à disposition de tous. Cela demande bien sûr du « re-factoring » régulier, par rapport à la même approche du haut vers le bas, mais le gain est réalisé au niveau des délais et de la disponibilité des composants.
Ce fonctionnement est utilisé par l’open source qui arrive à fédérer des centaines de développeurs sur le développement de plateformes. C’est aussi un moyen de faire changer de posture l’architecture d’entreprise, depuis une position régalienne, vers une position de solutions, puisque les architectes partagent maintenant la responsabilité de cette plateforme socle et, vu des métiers, contribuent à accélérer les projets.
Les évolutions de versions de ces composants sont alors réalisées pour toutes les équipes, L’architecture d’entreprise à ce niveau prend un rôle très opérationnel, qui n’empêche pas le régalien mais qui en modifie profondément la posture.
L’architecture reste un rôle, mais se rapproche d’une mission de gestion de produit, la plateforme digitale socle, ce qui est facilité par le Cloud avec le PaaS – Plateforme as a service – et les avancées de la conteneurisation, et sans se substituer aux métiers, qui voient au contraire ce socle comme un accélérateur.
Voyez donc vos architectes d’entreprise comme des « product owners » de cette plateforme digitale socle, à laquelle vous pouvez même donner un nom. Ils sont alors en animation d’un réseau d’autres architectes, qui parfois n’en ont pas le nom, déployés au niveau des équipes agiles, au cœur de là où se passe la production de valeur et avec la capacité d’une réaction rapide en réponse à l’incertitude.
Cette organisation en réseau a clairement un impact sur les profils à recruter et les formations pour répondre au nouveau challenge d’une architecture d’entreprise distribuée. La capacité d’animation d’un réseau devient une compétence importante. Surtout quand ces plateformes rendent des services à d’autres SI à l’extérieur de l’entreprise par exemple avec des API en plus des applications portées. Il faut alors coordonner les aspects techniques avec les ré-utilisateurs de ces APIs, DSI de clients et partenaires, voir développeurs indépendants.
Et puis l’architecture digitale c’est de plus en plus la capacité à intégrer des objets connectés, avec éventuellement du stockage de données « Edge« , en local, quand les coûts ou les ressources pour les remonter dans le Cloud, seraient trop importants. C’est notamment vrai quand on a besoin de temps réel, avec peu de latence, ou que l’on manipule de la vidéo qu’il faut analyser au plus vite. On se retrouve alors avec trois niveaux d’architecture, l’infrastructure des objets connectés qui ont leur logiciel embarqué, les nœuds Edge et les services Cloud.
L’arrivée de la 5G, adaptée à ce type d’applications, devrait les multiplier.
Dans ce contexte, l’architecture régalienne, qui régit l’intérieur de l’entreprise, doit aussi se préoccuper de systèmes répartis et ouverts, avec des parties prenantes sur lesquels elle n’a aucune autorité régalienne. C’est un autre signe qui montre les limites de la vision d’une architecture d’entreprise totalement centralisée dans un monde digital.
Le rôle de l’architecture d’entreprise est donc progressivement en train de changer avec le développement du digital.
L’organisation et la gouvernance traditionnelle pour y répondre ne sont donc peut-être plus totalement adaptées. C’est le bon moment pour éliminer les missions d’architecture régaliennes les moins utiles, et utilisées, et de redéployer les ressources sur l’action, là où se joue la valeur ajoutée, au plus proche des produits. C’est peut-être également le bon moment de développer les compétences des architectes avec des compétences en gestion de produits numériques et en animation de communautés.