IT Strat #2 - Définir une stratégie IT qui répond aux enjeux de l'Entreprise

Nous avons vu dans notre premier article d’introduction sur la stratégie IT l’importance d’une approche modernisée pour répondre aux différents enjeux (métier, technologiques, SI, opérationnels, sociétaux et environnementaux) dans un contexte de plus en plus mouvant.

Nous allons maintenant voir ensemble dans quelles sont les étapes et outils d’une stratégie IT, informée, actionnable et qui permet d’aligner au plus proche les exigences et besoins des stakeholders.
En commençant dans cet épisode par regarder de plus près les méthodes et outils que nous utilisons chez OCTO Technology pour intégrer à la fois les enjeux métier et technologiques, ou dit autrement comment participer à la stratégie métier en y apportant les bonnes réponses technologiques.

Nous pourrons ensuite aborder dans les prochains volets comment maîtriser l’évolution du SI, poser une feuille de route et la piloter, redéfinir le rôle des architectes et revoir le modèle opérationnel de l’IT dans cette approche modernisée.

Cette série d’articles s’adresse à tous les responsables IT au sens large et à ceux et celles qui les aident à anticiper et prévoir les évolutions à mener sur leur périmètre : DSI, CTO, architectes, responsables de domaine…
A noter aussi que dans cette série d’articles nous utiliserons souvent le mot entreprise qui est à prendre dans sa définition la plus large, au sens unité organisationnelle qui peut être privée ou publique (organisation institutionnelle).

Partenariat Business & IT

La définition et l'exécution d’une stratégie IT moderne est un processus méthodologique qui vise un alignement des capacités techniques, des plannings de réalisation et des jalons de livraison avec les contraintes légales et les ambitions/objectifs business à l’échelle de l’entreprise, tout en prenant en compte les opportunités technologiques.

A la recherche de l’alignement des différentes perspectives de l’entreprise

La transformation continue de l’entreprise se traduit souvent par différents points de vue qui ne sont pas toujours cohérents entre eux. Le schéma ci-dessous est inspiré par les travaux Open Agile Architecture de l’Open Group (1) et montre les différentes perspectives d’une entreprise (en gris) : Expérience utilisateurs, Opérations métier, Produit et Systèmes techniques. Dans chaque perspective, des vues ou méthodes (en bleu) peuvent être pratiquées pour comprendre l’existant et définir les évolutions de l’entreprise.

Les différentes perspectives de l’entreprise (en gris), les différentes vues ou méthodes (en bleu) et la recherche d’alignement nécessaire

Malheureusement les perspectives Expérience utilisateurs, Opérations métier et Produit sont trop souvent pensées de manière décorrélée de l’IT (les systèmes techniques). Cela entraîne des difficultés dans la définition d’une vision cible puis dans la manière de mener les projets et dans leurs résultats, avec des insatisfactions de toutes les parties prenantes.
Une stratégie IT efficiente doit reposer sur une vision globale du fonctionnement de l’entreprise et apporter une cohérence d’ensemble. Pour cela, l’IT ne doit pas être uniquement positionnée en aval, mais idéalement être impliquée et participer en amont pour apporter du lien entre les différentes perspectives de l’entreprise de manière continue et décliner les ambitions métier dans la transformation digitale et la stratégie IT :

• Stratégie d’entreprise : une participation de l’IT à cette vision globale est nécessaire pour bien comprendre les besoins, les enjeux et définir ensemble les ambitions et critères de succès à travers des canevas et des ateliers participatifs. Ces ateliers vont faciliter l’identification des capacités nécessaires pour l’entreprise et sont aussi souvent l’occasion d’apporter d’autres perspectives au métier en proposant des opportunités technologiques (boucle de feedback).
• Expérience utilisateur (“User experience”) : une meilleure prise en compte des outils de type “Experience design” ou “Journey map” qui donne le point de vue utilisateurs aide à mieux cerner les nouvelles capacités digitales à développer et peut être complémentaire de la vision interne des opérations métier.
• Opérations métier (“Business operations”) : la modélisation des activités et des flux de valeur de l’entreprise (value stream mapping) va permettre de définir les capacités IT nécessaires (nous y reviendrons dans le chapitre suivant)
• Produit et Systèmes techniques : l’utilisation d’outils comme le DDD (Domain Driven Design) n’est pas obligatoire mais elle est souvent pratiquée par nos consultants OCTO pour co-construire la cible avec le métier et donner de la cohérence entre les visions métier / produit et technique.
  Le DDD est un ensemble de pratiques visant à définir des systèmes techniques et qui participent à la conception du produit. Souvent utilisés dans la conception de nouvelles applications, les travaux de DDD peuvent aussi être positionnés en amont de manière stratégique pour prendre en compte la vision métier et les flux de valeur (value streams). Le tout de manière itérative comme illustré dans le schéma plus haut.

Vision métier à travers les flux de valeur

La stratégie IT doit participer à la construction d’une vision métier formalisée. Cette représentation du métier de l’entreprise sous différentes formes comprises par tous servira de base à l__’analyse des écarts__ et de la transformation nécessaire.
Nous ferons un focus dans cet article sur la modélisation des Value streams, ou flux de valeur, qui sont la déclinaison de la chaîne de valeur de l’entreprise en séquences d’activités (produits et services). Cette technique appelée Value stream mapping (2) aide le métier à mieux visualiser les macro-processus, les étapes qui les composent et l’enchaînement des capacités nécessaires pour réaliser ces séquences d’activités.

Exemple (simplifié) d’une value stream map avec les différentes étapes et les capacités associées

Les value streams apportent un côté concret, ciblé et dynamique à la cartographie métier, et servent en général de base au découpage en domaines et produits. Les value streams donnent du sens aux fonctions et solutions IT qui vont contribuer à réaliser ces activités, mais sans rentrer dans les détails des processus opérationnels.

Cartographie des capacités de l’entreprise

Les capacités identifiées dans le Value stream mapping sont en général regroupées dans des “Capability maps” qui donnent une vision d’ensemble sur laquelle nous pouvons pointer les écarts à la cible et travailler sur les principaux investissements requis :

• les “Business capabilities” pour avoir un paysage des activités de l’entreprise supportées par l’IT, structuré par domaines, et arriver à une vision commune sur laquelle s’appuiera la discussion autour des enjeux, priorités et des capacités IT à mettre en oeuvre (Tech, Process, People). C’est quelque part le pourquoi de l’IT, qui doit être revue fréquemment pour coller aux évolutions et ambitions de l’entreprise.
  La “Business Capability map” est en général découpée par domaines métier. Par rapport à une cartographie fonctionnelle traditionnelle, elle apporte un côté moins figé et plus en phase avec les évolutions du métier de l’entreprise.
  Dans l’exemple ci-dessus on peut y voir un domaine fonctionnel standard assez large (“Ventes”), mais il peut être intéressant de découper plus finement cette carte en sous-domaines en phase avec les “Value streams” de l’entreprise.

• les “Technical capabilities”, ou “Enablers”, ce sont les services techniques qui vont permettre de répondre aux besoins métier (directement ou de manière transverse). On est plus ici dans la représentation du comment de l’IT.
  L'identification puis la gestion de ces communs est un enjeu majeur chez la plupart de nos clients. Construire cette vue constitue un point d’entrée intéressant de la stratégie technologique, on pourra ensuite y mapper les solutions techniques actuelles ou nécessaires et s’en servir de base pour construire un catalogue de services en lien avec l’organisation.

Illustration de business et technical capabilities (enablers) avec dans cet exemple la mise en relief d’enjeux à adresser dans la stratégie IT (en jaune)

Analyse d’écarts et scénarios métier

Ces méthodes de représentation ne sont pas une fin en soi, mais un moyen de renforcer le partenariat Business & IT qui est le titre de ce chapitre et auquel nous sommes particulièrement attachés chez OCTO Technology. Construire cette vision partagée permet ensuite de mieux analyser les écarts par rapport aux ambitions, aux exigences réglementaires ou à l’état de l’art du marché.
L’analyse d’écart permet ensuite de travailler ensemble avec les responsables métier sur les différents scénarios possibles pour l’évolution de l’entreprise et sur les impacts IT associés. Les scénarios métier vont influencer la stratégie IT qui va devoir identifier :

• Les transformations à mener dans les value streams pour y répondre : activités et capacités à créer pour apporter de la valeur, ou à améliorer pour optimiser l'efficience de l’entreprise ou la rendre plus éco-responsable par exemple,
• Les impacts IT qui en résultent : systèmes à rénover, enablers / communs à mettre en œuvre, nouvelles technologies à appréhender, changements de modèle opérationnel…

Co-construction de la cible avec les équipes

L’approche capacitaire et value streams décrite plus haut permet d’avoir une vision macro partagée avec les responsables métier, mais elle peut parfois être ressentie comme étant trop “top-down” quand elle est pratiquée en comité restreint. On veillera donc à inclure un maximum de participants métier et IT pertinents dans la réflexion, et faire converger cette vision intentionnelle avec la vision émergente qui vient des équipes (cf le principe de boucle de feedback expliqué dans notre premier article).

Des outils plus participatifs issus de l’approche DDD (Domain-Driven Design) sont intéressants pour réaliser cette convergence avec une approche bottom-up qui va permettre d’aller plus dans le détail de la chaîne de valeur métier et des impacts IT, et de faire émerger de nouvelles idées pour le futur : on citera en particulier l’Event Storming qui peut être utilisé de manière stratégique pour mieux comprendre le métier et ses besoins, découper les domaines métier à gérer dans le SI (Big Picture), leur donner une substance fonctionnelle concrète en utilisant le même langage entre métier et IT. Nous reviendrons plus en détails dans un prochain article sur cette approche DDD stratégique.
L’Event Storming joue aussi un rôle charnière avec l’IT en permettant de se projeter sur l’espace de la solution, en commençant à détourer des sous-domaines plus précis (appelés Bounded Contexts) pour répondre aux problématiques. Ce travail, qui peut être fait de manière globale ou sur des parties ciblées de l’entreprise, est à faire le plus possible en continu pour alimenter la stratégie technologique qui s’intéresse aux solutions.

Mise en oeuvre d’une stratégie technologique

Priorisation des investissements

D’autres outils DDD comme la Wardley Map ou le Core domain chart vont eux aider à prioriser les investissements et à définir une stratégie technologique en lien avec le métier.

La Wardley Map était un des sujets de la Duck Conf 2024 (3) et le Core domain chart a été abordé en 2022 (4) mais plus dans un objectif de priorisation des ressources humaines.
Nous allons faire un focus ici sur le Core domain chart utilisé comme un outil d’aide à la décision qui permet d’éclairer la question Make or Buy en évaluant les domaines / sous-domaines sur deux axes : la différenciation business, mais aussi la complexité métier du domaine / sous-domaine concerné et de la solution à implémenter. Ce qui permet d’arriver à une classification sur 3 niveaux :

• les domaines différenciants (les “core domains”). Ce sont les domaines au cœur de la stratégie, ceux où il est pertinent d’investir sur des solutions “sur-mesure” (Make) là où le spécifique est nécessaire pour apporter un avantage compétitif, ou simplement pour répondre aux besoins des clients ou des entités internes.
• les domaines intermédiaires (“supporting”) : un domaine peut être important pour l’entreprise, mais adressable par une solution sur étagère ou développée en interne mais avec un investissement limité (le choix Make or Buy est à traiter au cas par cas).
• les autres domaines dits “génériques” peuvent en général être adressés par des solutions sur étagère car communes à toutes les entreprises du secteur (Buy).

Core domain chart avec ses axes d’évaluation et des 3 niveaux de classification (cf https://github.com/ddd-crew/core-domain-charts)

La classification des domaines est aussi intéressante dans une vision dynamique pour montrer l’évolution souhaitée. Elle peut être matérialisée par des flèches dans le Core Domain Chart pour montrer la stratégie par sous-domaine.
Un domaine “supporting” peut devenir différenciant par ambition stratégique (flèche vers la droite), ou à l’inverse ne plus être considéré comme différenciant et ne plus justifier des développements custom importants (flèche vers le bas pour réduire la complexité).

Discernement dans les choix technologiques

Ces grandes directions Make or Buy vont devoir s’appuyer sur une stratégie technologique, c'est-à-dire comment utiliser au mieux les possibilités offertes par les solutions du marché (Buy) tout en sachant aussi répondre au besoin de fabrication de solutions sur-mesure (Make) :

• Technologies de développement front (web / mobile), back, API…
• Solutions de stockage et d’échange de données
• Solutions de déploiement et d’hébergement Cloud, conteneurisation, automatisation…

Poser un cadre directeur permet d’adresser plus facilement ces enjeux technologiques en définissant les patterns et solutions à privilégier, mais aussi en définissant comment opérer au bon moment les choix de solution, en éclairant les options et les critères de décision.
Les opportunités technologiques doivent donc être identifiées et revues fréquemment pour répondre aux enjeux de l’entreprise et aux enjeux opérationnels des équipes IT.
Des méthodes et des outils permettant de faire des choix éclairés dans le contexte de l’entreprise sont à mettre en place, on peut citer:

• les “Tech radars” qui synthétisent la veille technologique et apportent une classification des technologies du marché. Plutôt que de prescrire de manière directive une solution pour chaque besoin, un Tech radar offre un panel de possibilités à la disposition des équipes.
• les analyses d’écart pour mieux contextualiser la décision et évaluer la trajectoire

Tech Radar Thoughtworks, une illustration de la complexité des choix technologiques et du besoin d’appropriation et de simplification

Comme illustré ci-dessus avec le plus connu d’entre eux, les Tech radars que l’on peut trouver sur Internet offrent trop de possibilités pour pouvoir s’y retrouver, il faut les contextualiser en se focalisant sur l’essentiel des options technologiques et en tenant compte des capacités et de la maturité de son entreprise. Une technologie classée “Adopt” par Thoughtworks sera considérée comme “Trial” (à essayer) dans beaucoup d’entreprises.
Les vues de type radar sont d’ailleurs intégrées dans de plus en plus d’outils de type Architecture d’Entreprise comme LeanIX ou de type IDP (Internal Developer Platform) comme Backstage.

L’anticipation du futur doit aussi s’accompagner d’une bonne gestion du patrimoine technologique existant, de l’obsolescence associée et des risques induits sur les opérations, la conformité et la sécurité. Le prérequis est un inventaire précis et à jour, donc le plus automatisé possible, des composants techniques utilisés dans le SI et de leurs versions (différents outils de type CMDB ou Architecture d’Entreprise peuvent aider à cette tâche), et une organisation adéquate qui responsabilise les équipes locales tout en gardant une vision globale pour permettre des rationalisations et mutualiser les efforts.
La dette technique doit ensuite être caractérisée et traitée de manière continue et le cycle de vie des technologies géré dans son ensemble : de l’adoption au décommissionnement en passant par les mises à niveau et évolutions nécessaires.

Conclusion

L’importance et la finalité de la stratégie IT restent les mêmes qu’auparavant (discernement, alignement avec les enjeux de l’entreprise, maîtrise des coûts), mais les outils pour sa conception et mise en œuvre évoluent en intégrant le besoin d’avoir des résultats rapides pour gagner en agilité et permettre d’ajuster le plan en continu.
Nous avons vu dans cet article comment :

• Intégrer la stratégie métier, la formaliser sous différentes formes (vision métier, chaînes de valeur, cartographie des capabilities et des domaines métier) et y participer en travaillant sur des scénarios et en proposant des éléments à valeur ajoutée de l’IT
• Établir un lien cohérent avec la stratégie tech grâce à des outils comme le DDD, être en mesure de prioriser et de faire des choix (par exemple Make or Buy), avoir une bonne gouvernance de la dette et des opportunités technologiques

Des méthodes et des outils utiles à la stratégie IT vous ont été présentés, mais la façon de les mettre en œuvre et les étapes nécessaires sont spécifiques à chaque contexte et OCTO peut vous accompagner dans cette démarche.
Pour citer un CTO dans le domaine de la distribution : “ce travail d'éclairage et de priorisation de notre stratégie IT, en cohérence avec notre business plan, était indispensable et a permis de redonner du sens et de la visibilité à nos équipes digitales”.

Nous verrons dans notre prochain article comment traduire les visions métier et tech en stratégie de transformation du SI, comment maîtriser l’évolution du patrimoine applicatif et poser un cadre directeur pour décliner la stratégie IT.

Références :

1. Open Agile Architecture
2. TOGAF Value Streams Guide (opengroup.org)
3. Olivier Wulveryck, Duck Conf 2024 : Décider avec : Stratégie, Wardley, Orientation, et Territoire - OCTO Talks !
4. Romain Vailleux, Duck Conf 2022 : Core Domain Chart - Une pratique socio-technique à découvrir à travers un atelier et une étude de cas - OCTO Talks !