Aujourd’hui, le Cloud, ainsi que la mise en place de pratiques DevOps figurent au premier rang des technologies clés de la Transformation Digitale.
Mais comment adapter une approche d’Architecture d’Entreprise à la problématique actuelle d’une adoption contrôlée du modèle Cloud ? Comment un patrimoine d’Architecture d’Entreprise peut être enrichi et utilisé pour mieux répondre à des enjeux de Transformation Digitale ?
Lisez notre article ci-dessous
Tout au long de nos publications de ces derniers mois, nous avons partagé avec vous nos convictions relatives au nouvel enjeu que représente la Transformation Digitale pour l’Architecture d’Entreprise.
Nous avons relevé les nouveaux défis d’une pratique agile et collaborative de l’Architecture d’Entreprise pour piloter l’alignement dual sur les évolutions changeantes et non prédictibles des modèles d’affaires et du métier d’une part, les innovations ou meilleures pratiques technologiques d’autre part, engendrées par la Transformation Digitale.
Au premier rang des technologies clés de la Transformation Digitale aujourd’hui, se retrouve le Cloud, ainsi que la mise en place de pratiques DevOps, ayant pour objectifs la sélection sur le marché de services « clé en main » (« off the shelf ») répondant fonctionnellement au besoin, la fluidité et la rapidité de mise à disposition des différents services (IaaS, PaaS, SaaS), un déploiement rapide et automatisé des applications sur ces briques, et une capacité à adapter « à la demande » le dimensionnement et plus généralement le niveau de service attendu.
Cette évolution technologique et ce changement de pratiques s’appuient en particulier aujourd’hui sur la fourniture et le déploiement des briques d’infrastructure sous la forme de services « managés » (« managed services ») offerts par les principaux fournisseurs du marché du Cloud, Google, Amazon (AWS), Azure ou encore IBM.
Ce type de solution a lors de son émergence suscité un grand intérêt et une forte attente de gains en termes d’optimisation de ressources, dimensionnement, coût et « timing » adaptés à la demande. Cette vue sans doute idéale à l’instant de la découverte de ces nouvelles solutions se confronte aujourd’hui à la réalité du terrain, et à un premier retour d’expérience opéré par les utilisateurs. L’approche purement réactive s’avère insuffisante à l’échelle du management du SI et il est nécessaire aujourd’hui de la cadrer et de pouvoir anticiper sur une évaluation à plus long terme du dimensionnement et donc du coût associé.
En projetant le Cloud dans un modèle de maturité d’un produit, qu’il soit inspiré du « Hype Cycle » de Gartner ou du cycle de vie d’un modèle d’affaires selon J. Appelo, un enjeu stratégique du Cloud est aujourd’hui d’accélérer son adoption et son passage à maturité.
Et ainsi éviter une phase de « désillusion » et atteindre plus vite le plateau de productivité. Autrement dit, passer rapidement d’une étape à un stade encore stratégique (« formation ») aux phases pleinement opérationnelles et financièrement viables et gagnantes (« cristallisation » et « expansion »).
C’est ici qu’un modèle d’Architecture d’Entreprise agile, piloté par les enjeux du Cloud, tels que nous les avons exposés ci-dessus, prend tout son sens et sa valeur.
Au cours des dernières publications, nous avons déjà communiqué sur la capacité d’un modèle d’Architecture d’Entreprise à représenter à la fois les vues stratégique et métier, applicative et technologique, projet et réalisation, ainsi qu’à mettre en exergue les impacts relatifs à une caractérisation de ces éléments, à un scénario ou à une feuille de route. C’est typiquement ce qui peut être réalisé vis-à-vis d’une solution Cloud pour anticiper d’une part sur son dimensionnement, d’autre part sur son coût, à moyen ou long terme.
Pour illustrer notre propos, nous nous inspirons d’un projet en cours que nous menons auprès d’un client fournisseur de services dans le monde du transport, visant à déployer un « data hub » dont la finalité est de pouvoir fournir toute information métier requise à un écosystème de clients et partenaires, et unifier les différentes sources de données gérées au sein des multiples applications métier. Ingestion et transformation des différentes informations depuis les sources vers le « data hub », synchronisations et intégration inter applications, consultations via API depuis un portail, supervision métier de l’ensemble des interactions sont opérées via un socle d’intégration Cloud IBM, composé d’une passerelle API, d’un bus d’intégration et de gisements de données opérationnels et analytiques.
Premier artefact produit, l’aide au dimensionnement. Dans notre contexte, l’ensemble des services qui nourrissent les gisements de données et assurent l’intégration entre applications, sont déployés sur un bus d’intégration, initialement prévu dans le Cloud. Les premiers développements et déploiements ayant montré des empreintes significatives en termes de ressources, une projection de l’ensemble des composants sur la plateforme au sein d’un modèle d’Architecture d’Entreprise a permis de simuler des situations de saturation vis-à-vis du dimensionnement initial.
La modélisation des services d’intégration et de leur projection sur les briques d’infrastructure, permet de visualiser simplement l’atteinte ou non d’un niveau de criticité selon le nombre de composants déployés et leur empreinte.
Second artefact, l’aide au contrôle de coût. A ce stade, et au vu de la première simulation, nous enrichissons le modèle d’Architecture d’Entreprise avec les données de coûts annuels des licences selon deux options de déploiement pour le bus d’intégration, la première dans le Cloud, la seconde « on premise », pour en obtenir une projection à moyen terme. Le coût sur cet horizon de temps restant le critère majeur pour la prise de décision, d’autres classes de critères sont aussi évaluées telles que la complexité de déploiement ou encore l’impact stratégique.
Le modèle des coûts de licences et de leurs relations aux deux options du bus d’intégration permet de visualiser la comparaison des coûts annuels et leur évolution au fil du temps selon l’option retenue, et offre ainsi un support à la prise de décision et l’anticipation.
Le modèle d’Architecture d’Entreprise facilite aussi l’extraction d’indicateurs clé et leur visualisation dans des tableaux de bord.
Ces quelques exemples, volontairement simplifiés et s’appuyant sur des données fictives et non significatives, nous ont permis d’illustrer une approche d’Architecture d’Entreprise adaptée à la problématique actuelle d’une adoption contrôlée du modèle Cloud.
A travers les deux types d’artefacts proposés ici, nous avons aussi souhaité démontrer par des exemples simples comment un patrimoine d’Architecture d’Entreprise peut être enrichi et utilisé pour mieux répondre à des enjeux de Transformation Digitale.
