Dans un monde de plus en plus digitalisé, chaque entreprise cherche à innover et à optimiser ses processus en continu. Mais comment vous assurer que cette transformation numérique s’aligne parfaitement avec vos objectifs business ? C’est là qu’intervient l’architecte de solutions.

L’allié de votre transformation digitale

Un architecte de solutions n’est pas qu’un simple professionnel en ingénierie. Il est le lien entre vos ambitions business et les solutions technologiques les plus adaptées pour les réaliser. Il s’assure que chaque investissement technologique réalisé ait du sens pour votre entreprise et participe à la création de valeur.

L’expertise technologique au service du business

Avec l’évolution effrénée des nouvelles technologies, vous avez besoin de vous entourer d’un spécialiste qui les maîtrise, connait leur réelle maturité et sait comment elles peuvent être mises en pratique dans votre contexte d’entreprise particulier afin de vous donner un avantage concurrentiel.

La fluidification de la communication entre les métiers et les « techniciens de l’informatique »

L’architecte de solutions facilite la communication entre les équipes techniques et les métiers. Il s’assure que chaque décision est prise en connaissance de cause et qu’elle répond précisément aux besoins exprimés, ce qui l’amène souvent à les reformuler pour qu’ils soient effectivement partagés par tous.

La maîtrise des risques

De la compliance règlementaire à la sécurisation, l’architecte de solutions identifie, évalue et anticipe les risques liés à toutes les initiatives technologiques ou introduction de nouvelles technologies au sein de votre écosystème IT.

Le bon choix technologique

Que vous souhaitiez migrer vers le cloud, intégrer de nouvelles applications ou renforcer votre cybersécurité, l’architecte de solutions s’assure que la pile technologique choisie est la meilleure pour vous en fonction de votre existant mais aussi de vos ressources disponibles. Il vous propose également la bonne stratégie et la trajectoire de transformation technologique.

Le profil type d’un architecte solution

En raison des multiples dimensions de son poste et la diversité de ses missions au quotidien, il a à la fois des compétences techniques solide, une véritable vision stratégique et des qualités interpersonnelles indispensables.

1. Expériences : C’est un professionnel expérimenté qui a souvent commencé sa carrière comme développeur ou ingénieur système suivi d’une expérience en conseil. Il a généralement plusieurs certifications dont AWS Certified Solution Architect et/ou Azure Solutions Architect Expert.
2. Connaissances techniques : il maîtrise bien entendu toutes les dernières tendances en architectures data modernes (data fabric, data mesh, lakekouse, etc.), le cloud, l’intelligence artificielle, etc. Il a de l’expérience dans l’intégration de différentes plateformes et de technologies pour être en capacité d’être force de recommandations pour réconcilier des systèmes disparates. Il connait tous les principes de sécurité pour assurer la protection des données et la sécurisation des systèmes.
3. Compétences en gestion de projet : Gestion et coordination d’équipe sont ses points forts ! Il est le garant du budget (suivi des dépenses et ROI projet) et de la gestion des risques afin d’identifier précocement les éventuels problèmes (anticipation).
4. Vision stratégique : il est en capacité de traduire des besoins métiers ou des attentes métiers en solutions technologiques. Il sait également anticiper et proposer des solutions évolutives dans la durée.
5. Qualités : C’est un communiquant qui sait expliquer des concepts complexes à des interlocuteurs souvent néophytes. C’est un négociateur qui sait trouver des compromis entre des partie prenantes qui ont souvent des intérêts divergents. Et il s’épanouit dans le travail en équipe !

Un architecte de solutions a un rôle pivot dans toute entreprise qui souhaite mener à bien sa transformation numérique. Sa capacité à jongler entre des compétences techniques pointues, une vision stratégique claire et une communication efficace en fait un atout inestimable pour toute organisation.

Besoin de renfort dans vos projets, challengez-nous !

Dans un monde moderne qui produit sans cesse des données qui nourrissent en continu ses économies, faire le bon choix en terme d’architecture est essentiel pour capter, gérer, analyser et exploiter les données. Les architectures de données ont beaucoup évolué pour répondre à ces nouveaux besoins sur des volumétries jamais atteintes jusqu’alors et des systèmes qui demandent de plus en plus de traitement temps réel. Voici un selon nous les architectures data les plus modernes en 2024.

Data Warehouse Appliances

Les appliances de data warehouse, tels que Teradata, Netezza, Neoview, Parallel Data Warehouse et SAP HANA, ont été conçues pour gérer les charges de travail analytiques qui ne sont pas efficacement traitées par des systèmes de gestion de bases de données traditionnels. Grâce à une architecture parallèle massive et un traitement en mémoire, ces appliances offrent des performances améliorées.

Data Lakes

Les data lakes représentent une évolution majeure par rapport aux entrepôts de données et aux data marts. Ils peuvent gérer et analyser non seulement des données structurées, mais aussi des données semi-structurées et non structurées. Ils sont généralement mis en œuvre sur des infrastructures cloud comme AWS S3, Azure ADLS, ou GCS de Google, qui offrent plus flexibilité via une séparation entre les ressources de stockage et celles de calcul.

Data Mesh

L’architecture Data Mesh vise à résoudre les problèmes de scalabilité et de disponibilité associés aux architectures de données centralisées. Avec un Data Mesh, les données sont organisées en « produits de données » (Data a a product), chacun géré par l’équipe responsable de son domaine fonctionnel respectif. Cela facilite l’exploitation des données, car les propriétaires de produits de données sont au plus proches des applications métiers qui produisent et utilisent les données.

Data Fabric

L’architecture Data Fabric, comme le Data Mesh, vise à surmonter les défis traditionnels auxquels sont confrontées les architectures de données centralisées. Cependant, à la différence du Data Mesh, qui est une approche décentralisée basée sur le domaine, le Data Fabric est une approche centralisée axée sur la technologie, s’appuyant sur les métadonnées, les catalogues, les modèles de données logiques et les APIs.

Lakehouse Architecture

La Lakehouse est une architecture qui a pour objectif de mixer les avantages des data warehouses et des data lakes tout en surmontant leurs limites respectives. Elle offre une interface commune pour toutes les charges de travail d’analyse de données et prend en charge les propriétés ACID des applications transactionnelles.

Pour conclure, le choix de la bonne architecture de données dépend de vos besoins spécifiques. Que ce soit le Data Mesh, la Data Fabric ou le Lakehouse, chaque option a ses propres intérêts qui peuvent servir votre stratégie d’exploitation des données. Chez Smartpoint, nos architectes vous conseillent car être en capacités de comprendre les différentes architectures de données est primordial afin de concevoir et mettre en œuvre des systèmes data efficaces : traitement par lots, traitement en flux, architecture Lambda, entrepôt de données, le lac de données, microservices, (…)

Au-delà du concept et des principes d’architecture, est-ce que le Data Mesh est viable à l’épreuve de réalité des organisations et des SI data ? Est-ce que cette architecture décentralisée et orientée domaine fonctionnel, qui permet une exploitation des données en libre-service, est la hauteur des promesses ?

Voici les principaux écueils à anticiper.

En tant que pure-player de la Data, nous en avons connu chez Smartpoint des architectures de données … Et nous savons à quel point il est complexe de trouver, de concevoir, de mettre en œuvre la bonne solution et de briser enfin les silos. On sait aujourd’hui qu’environ 80% des projets de Data Warehouses ont échoué et il y a déjà presque 10 ans, Gartner prédisait que 90% des Data Lakes seraient finalement inutiles. Il est vrai aussi que l’on sait qu’une équipe Data centralisée est souvent débordée et manque d’expertises par domaines métiers, ce qui nuit invariablement à la découverte et à la création de valeur data.

Revenons sur les principes fondamentaux qui caractérisent le Data Mesh ou Maillage de données tel que promus par Zhamak Dehghani(ThoughtWorks) en alternative aux structures de données centralisées et monolithiques :

1. Domain-driven ownership of data : Les données sont considérées comme des actifs appartenant à des domaines spécifiques au sein de l’organisation. Chaque domaine est responsable de la production, de l’amélioration de la qualité des données et de la gestion. Cette approche permet de créer des équipes spécialisées, composées d’experts métier et techniques, qui travaillent en étroite collaboration pour définir les normes et les règles spécifiques à leur domaine. Leur objectif est de répondre aux besoins de leur domaine fonctionnel en terme d’exploitation des données, tout en favorisant la réutilisation et l’interopérabilité entre les différents domaines métiers.

2. Data as a product : Les données sont destinées à être consommées par les utilisateurs au sein de l’organisation. Les équipes data doivent se recentrer sur le client pour fournir des data sets de qualité, fiables et bien documentés. Elles créent des interfaces claires (API) et définissent des contrats pour la consommation des données. Ainsi, les utilisateurs peuvent découvrir, accéder et utiliser les données de manière autonome, comme un produit prêt à l’emploi. On est dans la même logique que les architectures microservices.

3. Self-service data platform : Les équipes data fournissent une plateforme de données en libre-service, qui facilite la découverte, l’accès et l’exploitation des données. Cette plateforme fournit des outils, des services et des interfaces qui permettent aux utilisateurs de trouver intuitivement et de consommer les données de manière autonome. Elle favorise l’automatisation et l’orchestration des flux de données, permettant ainsi aux équipes data de se concentrer sur la qualité et l’enrichissement des données plutôt que sur des tâches opérationnelles chronophages et à faible valeur ajoutée.

4. Federated computational governance : La gouvernance des données est décentralisée et répartie entre les différentes équipes. Chaque équipe a la responsabilité de définir et d’appliquer les règles et les normes spécifiques à son domaine. La gouvernance fédérée consiste à mettre en place des processus et des outils qui permettent de gérer et de contrôler les données de manière distribuée. Cela inclut la gouvernance des métadonnées, la sécurité, la conformité réglementaire, ainsi que la prise de décision collective et transparente sur les évolutions de l’architecture et des pratiques liées aux données.

Voici pourquoi une architecture data mesh pourrait se révéler être un échec dans certaines organisations où les notions de produit data ou de propriété de domaines sont difficilement applicables.

• Toutes les données n’ont pas forcément une valeur, c’est même le contraire. La plupart des données collectées sont inutiles et brouillent l’information car elles ne sont pas pertinentes. Dans les faits, c’est compliqué d’identifier dans la masse celles qui sont réellement précieuses et potentiellement génératrice de valeur. C’est un véritable chantier en soi, complexe et laborieux. Un travail de chercheur d’or !
• Produire des données est une charge supplémentaire ! Certes le concept de data product est séduisant et facile à appréhender mais dans la réalité du terrain, les ingénieurs data doivent déjà les créer … Et les transformer en plus par domaine nécessite d’élargir encore leurs compétences. Certes les avancées en IA, automatisation, et autres Low Code promettent de leur faciliter la tâche mais c’est encore une promesse qui reste à éprouver.
• On en vient naturellement à la troisième difficulté : le manque de compétences data disponibles. Le Data Engineering, c’est un métier de spécialiste de la gestion des données et nous savons qu’il est rare de trouver des professionnels qui en maîtrise toute la palette ! Déléguer la responsabilité à des équipes par domaine, sans compétences spécialisées en data, peut générer des problèmes sans aucun doute.
• La gouvernance fédérée est aussi une évidence sur le papier. Dans les faits, ce n’est pas applicable sans de fortes contraintes avec un véritable régime central très autoritaire qui encadre les comportements et contrôle régulièrement les usages. En effet, si la gouvernance des données est détenue par une guilde fédérée composées de représentants de différents domaines, cela risque fortement d’être inefficace car chaque département a ses propres règles et priorités.
• Une plateforme centralisée en libre-service fait rêver mais dans les faits, mettre en place ce type de solution se révèle très complexe car on est confronté à une variété vertigineuse de formats de données, une pluralité de systèmes et d’applications différents, de différentes versions voire de générations. Certes, nous disposons aujourd’hui de nombreux outils pour ingérer massivement les données et de larges bibliothèques de connecteurs … mais on peut rapidement retomber dans les travers du data warehouse.

Pour conclure, une architecture Data Mesh est très intéressante, mais au là du concept, il faut en mesurer les risques, les écueils et ses limites.

Voici les principaux avantages qui méritent qu’on étudie sa faisabilité et sa mise en pratique dans votre SI Data :

1. Démocratisation de l’exploitation des données par un plus grand nombre (au delà des data scientist) via les applications en libre service
2. Réduction des coûts car cette architecture distribuée est davantage #Cloud native avec des pipeline de collecte des données en temps réel (paiement à la consommation en terme de stockage)
3. Interopérabilité car les données sont normalisées indépendamment du domaine et les consommateurs s’interfacent par APIs.
4. Renforcement de la sécurité et de la gouvernance des données car les normes sont appliquées au-delà du domaines ainsi que la gestion des droits et des accès (journalisation, observabilité).

Sources :

• L’échec des projets de datawarehouses : https://www.dbta.com/Editorial/Think-About-It/Why-a-Majority-of-Data-Warehouse-Projects-Fail-and-What-Businesses-Can-Do-145910.aspx
• Dès 2014, Gartner prévoyait qu’en 2018, 90% des data lakes déployés seraient inutiles car ils seront submergés d’informations capturées pour des cas d’utilisation incertains. Relire les prédictions de l’époque : https://blogs.gartner.com/merv-adrian/2014/12/30/prediction-is-hard-especially-about-the-future/
• 6 raisons pourquoi le Data Mesh va échouer : https://medium.com/@hannes.rollin/six-reasons-why-data-mesh-will-fail-195886c89bdd