La plupart des entreprises auxquelles je parle partagent un objectif similaire : adopter les meilleures pratiques et tirer parti des solutions disponibles pour libérer des ressources et se concentrer sur de véritables domaines de différenciation ou d’innovation. Mon travail, bien sûr, consiste à leur expliquer comment y parvenir. Bien que mes conseils à chaque client soient uniques – reflétant l’évolution historique de leur entreprise et de leur TI –, il existe certaines “indispensables à réussir” lorsqu’on tente de mettre en œuvre une architecture cible.

J’ai rassemblé ces impératifs dans ce blogue afin de vous présenter comment cela peut être réalisé en tenant compte à la fois du point de départ architectural actuel et en restant pragmatique quant à l’atteinte d’une architecture cible dans un contexte apparemment perpétuel de changements d’affaires et technologiques.

D’abord, qu’est-ce qu’une architecture transformationnelle ?

Pour répondre à une gamme sans cesse croissante de besoins d’affaires et de TI, les entreprises nécessitent une transformation de l’architecture capable de tirer parti des solutions disponibles et, lorsque nécessaire, de livrer des solutions plus personnalisées. Cela exigera souvent une réévaluation fondamentale de la façon dont les solutions sont supportées par une architecture d’entreprise plus ouverte et adaptable.

Combiner le remodelage et la refonte en des capacités « transformationnelles » au sein de l’architecture d’une entreprise est une façon de garantir une prestation efficace des fonctions et des services à l’entreprise.

Pour cela, je recommande de mettre l’accent sur la livraison d’une “architecture transformationnelle”. Ce que j’entends par là, c’est une architecture capable de répondre aux deux grands objectifs suivants :

• Remodeler l’architecture existante : Soutenir, développer et remanier l’architecture existante afin de favoriser une préparation graduelle et une transition vers tout état futur d’architecture d’entreprise, ce qui vous donne le temps nécessaire pour commencer à supporter de nouvelles options de prestation.
• Refondre pour une architecture future : Viser la réalisation d’une nouvelle architecture à la fois pour un modèle opérationnel cible, ainsi qu’un modèle qui permet une prestation beaucoup plus ouverte et flexible grâce à des changements continus dans les pratiques de conception et de prestation. Cette “refonte” peut inclure (et impliquer) un changement plus fondamental au niveau de l’architecture sous-jacente et ainsi signaler une évolution beaucoup plus importante dans les approches et pratiques.

Combiner le remodelage et la refonte en des capacités « transformationnelles » au sein de l’architecture d’une entreprise est une façon de garantir une prestation efficace des fonctions et des services à l’entreprise.

Pour appuyer ce résultat, l’architecture d’entreprise (et les solutions d’affaires et de TI sous-jacentes) doit subir des changements initiaux permettant de débloquer de nouvelles capacités. Après ce changement initial, vous serez mieux en mesure de soutenir des transformations de plus grande ampleur et des changements fondamentaux dans la prestation (de sorte que de petites et grandes phases de changement puissent survenir). Enfin, rappelez-vous qu’il ne s’agit pas d’un processus ponctuel, et il doit y avoir une tâche continue de révision et de mise à jour de l’architecture d’entreprise afin qu’elle puisse continuer à réagir aux changements et assurer l’amélioration et l’évolution continues.

Comprendre le(s) défi(s) architectural(aux)

Beaucoup d’entreprises possèdent de grandes applications d’entreprise qui constituent des piliers essentiels de leur architecture. Se lancer dans des projets de transformation numérique fondamentale (souvent conjugués à un virage vers l’infonuagique) peut donc être intimidant – surtout si l’on considère que l’architecture interne réelle de ces applications d’entreprise a elle aussi fondamentalement changé.

Mon expérience touche à la fois SAP (l’une de ces grandes applications d’entreprise) et les solutions d’infrastructure stratégiques telles que les couches d’intégration et les solutions de gestion de données. Plus récemment, j’y ai ajouté le développement infonuagique ouvert « côte à côte » pour aider mes clients à minimiser les changements dans leurs applications centrales « meilleures pratiques ». Pourquoi est-ce important ? Parce que je considère le défi du changement sous les deux facettes et je sais à quel point il est essentiel de posséder une expérience variée dans ces domaines lors de la modernisation de l’architecture d’entreprise.

Alors, comment est-ce que j’aborde la livraison d’une architecture transformationnelle ?

En résumé, travailler avec les gens déjà en place dans l’entreprise et les aider à adopter de nouvelles pratiques et approches peut favoriser la transformation architecturale. Fondamentalement, il s’agit d’admettre à quel point il est crucial d’avoir une architecture technique globale et d’en appliquer les principes et la conception, et de la mettre à jour non seulement dans le cadre d’un programme de transformation numérique mais aussi pour assurer un usage continu dans le soutien de besoins d’affaires élargis.

Applications d’entreprise – mais pas comme vous les connaissez

SAP et de nombreux autres fournisseurs offrent désormais des solutions beaucoup plus ouvertes, et comprendre comment ces solutions sont réalisées dans un paysage hybride (multi-fournisseurs et à conception flexible) est essentiel. En s’attardant spécifiquement aux grandes applications telles que SAP, leur propre architecture interne est conçue pour soutenir des principes clés pour faciliter la prestation dans le domaine SAP des solutions. Avec SAP, en particulier, il existe maintenant un modèle de données commun, des processus fonctionnels exemplaires, des solutions configurables et des services ainsi que des fonctionnalités « ouvertes » pour l’intégration ou la réutilisation. Ceux-ci faisaient historiquement partie de la plateforme SAP ou, tout au plus, étaient « ouverts » d’une manière « opinionnée ». Or, à mesure que SAP se tourne vers une prestation davantage axée sur les domaines (avec une combinaison de solutions infonuagiques ou même sur site), incluant des extensions ou options d’innovation, l’architecture SAP évolue également.

L’architecture de SAP a subi un changement fondamental. Fiori 3.0 permet maintenant une expérience utilisateur cohérente dans tous les produits SAP, le modèle de données unifié est aussi aligné à travers les domaines SAP et, à l’avenir, les intégrations passeront par des API communes, peu importe l’application en cours de mise à jour, comme le démontre le Graph (disponible à partir de 2022). Cela signifie que même si la prestation applicative, par exemple via les solutions SAP, comportera encore ses considérations propres, l’architecture d’entreprise globale doit également posséder des principes sous-jacents, un cadre et des objectifs architecturaux plus larges. De plus, les objectifs architecturaux élargis d’une société ne peuvent pas rester statiques. C’est pourquoi une architecture transformationnelle est requise pour permettre l’amélioration et l’évolution continues.

Souvent, les architectes d’entreprise se tournent naturellement vers les stratégies et tendances architecturales récentes axées sur l’ouverture et l’infonuagique pour nourrir leur vision et la conception de l’architecture cible. Cependant, je soutiens que les grandes applications et solutions ou services livrés, avec leurs propres cadres architecturaux, jouent encore un rôle majeur dans toute solution. Ceci inclut des domaines complets de solutions, par exemple un PGI comme SAP, ou la manière dont des éléments fonctionnels ou de service d’une entreprise peuvent être réutilisés ou intégrés à d’autres solutions de façon composable.

Livrer une architecture transformationnelle

La plupart des entreprises veulent encore que l’essentiel de leurs processus d’affaires standards soit fourni par des éditeurs comme SAP. Qu’il s’agisse d’un processus exemplaire de bout en bout ou de parties de processus, une grande part des fonctionnalités standard sera utilisée. La question centrale lors de la livraison d’une architecture transformationnelle est : comment ces processus, services et fonctions standards seront-ils combinés en une seule expérience utilisateur, avec une intégration transparente et une approche commune pour des éléments tels que les données, la sécurité, la veille et l’analytique ?

Obtenir des solutions d’affaires pour un domaine d’expertise tel que le traitement PGI, la gestion du capital humain ou l’entreposage peut potentiellement simplifier certains de ces enjeux. Et ces solutions possèdent leur propre architecture préconfigurée, souvent repensée pour le nuage et la livraison ouverte. Cependant, ces solutions de ligne d’affaires (LoB) et domaines doivent encore interagir entre elles et (idéalement) avec des services communs de soutien pour l’observation, l’exploitation et le développement.

Pour appuyer ceci, vous devrez considérer certains sujets clés lors de la réévaluation de l’architecture technique stratégique :

1. Remodeler – Utiliser et étendre l’architecture existante
   1. Confirmer l’architecture existante et établir un registre central des systèmes, applications, services et intégrations. Ceci doit comprendre un portrait du paysage système actuel, un aperçu des intégrations et de l’architecture technique pour confirmer l’utilisation et la vue d’ensemble de l’architecture existante. En outre, le modèle opérationnel doit être couvert, de la gestion des évolutions ou changements jusqu’à la façon dont l’exploitation, l’observabilité, l’alerte ou la surveillance sont traitées.
   2. Évaluer les opportunités et l’orientation des applications et services – Disposer d’une méthodologie comme HCLTech’ FENIX 2.0 aide ce type d’évaluation, ce qui doit confirmer le niveau d’investissement applicable par application et sa feuille de route potentielle en fonction de l’usage et de la valeur d’entreprise.
   3. Détailler et regrouper les principales influences sur l’architecture d’entreprise – Ces influences découlent d’anciens ou actuels besoins d’affaires et/ou préférences et schémas de conception TI, jusqu’à la manière dont le paysage actuel a été construit (tels que les systèmes principaux utilisés, l’évolution de composants ou les acquisitions ou cessions de l’entreprise). De plus, il faut rassembler et comprendre les principes ou politiques architecturales sous-jacents auxquels il faut adhérer ainsi que les cibles et objectifs architecturaux attendus.
   4. Comprendre l’approche sécurité et résilience – La manière dont la sécurité et la résilience sont traitées peut avoir un impact important sur le paysage (tout comme la reprise après sinistre et la haute disponibilité). Il s’agit souvent de points d’attention prioritaires, mais comprendre l’état actuel peut influencer les changements ou améliorations requis.
   5. Définir la stratégie de données – La donnée est un actif de l’entreprise et le modèle de données, la gouvernance et la qualité sont essentiels à toute réévaluation. L’architecture cible doit comprendre les grandes lignes de la modélisation, la gestion, la gouvernance et la prestation uniforme de la donnée à l’échelle de l’entreprise tant pour les besoins transactionnels qu’analytique.
   6. Confirmer les cadres d’architecture adoptés : Les cadres architecturaux actuels, ainsi que les principes dont ils dépendent, devraient être documentés. Il peut s’agir d’éléments issus des architectes d’entreprise ou d’éléments indirects (par exemple, intégrés aux applications fondamentales ou solutions déjà utilisées en entreprise). En plus de ce qui a déjà été adopté, il existe généralement des éléments en évolution pouvant être supportés (au moins en partie) dans l’architecture actuelle, comme la consommation d’API et l’encapsulation de services pour les exposer de façon ouverte ou le passage vers une livraison plus native au nuage (automatisation, DevOps, AIOps, etc.). Ces éléments supplémentaires doivent être pris en compte pour confirmer les options d’architecture existantes et potentiellement disponibles.
   7. Détailler le statut de l’organisation – Les connaissances, les compétences et l’organisation actuelle influenceront également les options de fourniture existantes ou futures. Cela peut donc nécessiter non seulement de la documentation, mais aussi possiblement une évaluation formelle comme avec la méthode Dreyfus d’évaluation des compétences.
2. Refondre – Appliquer de nouvelles méthodes et solutions architecturales
   1. Regrouper les initiatives et programmes actuels ou attendus : En regroupant ces détails, les besoins futurs peuvent être compris et intégrés dans toute refonte envisagée. Cela pourrait inclure des transformations numériques, l’infonuagique, l’automatisation, l’IdO, la livraison d’entreprise intelligente et les initiatives Big Data/analytiques pour fournir de nouvelles solutions, améliorer les efficacités ou réduire les coûts.
   2. Comprendre les impacts d’un environnement hybride – Il est probable que des solutions et services proviennent de multiples fournisseurs, mais aussi de solutions sur mesure de l’entreprise tant dans la prestation directe que dans le développement ou l’exploitation. Ainsi, l’architecture cible devra supporter un environnement hybride avec coordination et intégration, mais aussi des vues d’ensemble et des approches communes. Toute architecture mise à jour doit définir comment elle sera réalisée et exploitée dans un paysage hybride.
   3. Attentes de modernisation sur les principes, motifs de conception et architectures mis à jour – Cette modernisation peut être la refactorisation pour le nuage, le support aux solutions composables, ou la découplage d’applications au moyen de solutions axées sur la conception et un accent produit avec livraison agile et DevOps, tout en évitant l’enfermement propriétaire et la dette technique. Les principes et la stratégie architecturaux cibles doivent alors être actualisés pour tenir compte des zones de modernisation attendues, ce qui pourrait avoir un impact plus vaste que le simple remodelage de l’architecture existante. Cela peut ensuite mener à de nouvelles approches, méthodes et outils, avec des répercussions organisationnelles plus importantes.
   4. Amélioration et développement continus – L’architecture cible, les exigences et la solution ne seront pas statiques et l’approche doit porter sur la manière dont l’évolution sera soutenue par des améliorations ou des développements au fil du temps. Un certain niveau de changement doit aussi être intégré à toute prestation pour éviter des obstacles futurs à l’adoption de nouvelles pratiques ou solutions. Cela permet à la livraison de produit ou de programme de respecter les préférences architecturales, tout en gardant la capacité d’approuver des dérogations et permettre l’identification et la réalisation de nouvelles capacités sans imposer un fardeau ou une centralisation excessive aux équipes d’affaires ou techniques.

Je recommande aux entreprises de réfléchir à ces facteurs et d’accorder l’attention nécessaire à la création d’une architecture transformationnelle véritablement transversale à l’entreprise. Globalement, l’architecture doit soutenir un niveau de remodelage du paysage actuel de façon pragmatique, tout en identifiant la voie vers une architecture repensée plus large, apte à soutenir les solutions d’affaires et la prestation technique en continu, à un rythme plus rapide et plus flexible.

Pour compléter une vue d’ensemble architecturale, des éléments tels que les principales exigences d’affaires, les feuilles de route, les plans de changement et les aspects organisationnels devront aussi être discutés et compris. Un partenaire comme HCLTech peut réaliser ces étapes en début de projet ou sous forme de services dédiés de stratégie ou d’évaluation préalables à l’engagement.

HCLTech souhaite échanger avec des entreprises qui possèdent de vastes environnements axés sur SAP afin de les aider à comprendre comment elles peuvent transformer leur prestation, leur architecture d’entreprise SAP et leurs capacités.