Pourquoi une stratégie de conception de données structurées est importante : Un exemple

Arrière-plan

Dans deux articles précédents, nous nous sommes concentrés sur les considérations relatives à la conception axée sur les données ; et plus particulièrement sur la manière dont les données commerciales représentent une valeur commerciale latente. Le message clé est qu’une architecture de données structurée est la base technique qui permet d’extraire cette valeur inhérente. Cependant, ces articles se concentraient sur l’introduction des sujets pertinents au niveau conceptuel. Aujourd’hui, j’aimerais démontrer les concepts dans le contexte d’un exemple plus tangible et plus pertinent ; une histoire sur la façon dont on pourrait réfléchir à l’architecture d’une application cohérente avec un état d’esprit privilégiant les données.

Mais d’abord, pourquoi devrais-je m’en soucier ?

Mais avant de passer directement au sujet principal, récapitulons pourquoi les données sont plus importantes aujourd’hui qu’elles ne l’ont été par le passé.  La collecte et le stockage de données ont toujours été effectués par de nombreuses entreprises, principalement pour leur propre bénéfice, pour des raisons de gouvernance, telles que l'audit et la conformité. En tant que telle, la collecte et le stockage des données ont toujours été considérés comme une sorte de « taxe » sur les opérations commerciales, avec peu de valeur opérationnelle directe perçue.

Ce qui a changé aujourd’hui, c’est la prise de conscience accrue que les données collectées peuvent être exploitées pour optimiser les processus commerciaux et améliorer l’expérience client. Par exemple, selon une enquête récente menée auprès d’entreprises de vente au détail numériques, ces deux objectifs – la mise à niveau des processus commerciaux et l’expérience client – étaient les principaux moteurs de la transformation numérique pour 57 % des personnes interrogées. entreprises . L’observation critique, l’essence de « pourquoi c’est important », est que les flux de travail basés sur les données ont un impact sur l’entreprise à la fois dans les domaines externes (comme l’expérience client) et dans les domaines internes, pour les processus commerciaux de base. C’est pourquoi une stratégie de données réfléchie et délibérée est fondamentale pour permettre la qualité et la rentabilité des flux de travail les plus importants de l’entreprise. De plus, lorsque les flux de travail sont instrumentés pour transmettre leurs données observées à une infrastructure de collecte et d’analyse de données, les flux de travail eux-mêmes peuvent être continuellement analysés et améliorés, ce qui donne lieu à des flux de travail commerciaux constamment adaptatifs et optimisés.

En passant, la plus grande inquiétude de ces mêmes entreprises concernant la transformation numérique était d’assurer la cybersécurité de ces mêmes processus numériques – ce qui, en fin de compte, est un autre domaine dans lequel cette même approche de télémétrie et d’analyse des données a un rôle clé à jouer – même si je garderai cela pour un autre article. 

L'application : Commande et livraison au restaurant

Passant à notre expérience de pensée, j’ai choisi une histoire à laquelle beaucoup d’entre nous peuvent probablement s’identifier dans le mode de vie actuel adapté au coronavirus : une application qui fournit un service en ligne de commande et de livraison de nourriture au restaurant. Les repas sont commandés en ligne auprès d'un restaurant spécifié par le client, et l'utilisateur peut choisir que la commande soit récupérée directement par le client, ou que le service effectue également la livraison.

Dans cette histoire, nous jouerons le rôle du propriétaire de l’application. Dans ce rôle, nous devons répondre à de nombreuses préoccupations différentes, que nous diviserons en deux volets : premièrement, les activités opérationnelles requises et, deuxièmement, les préoccupations stratégiques tournées vers l’avenir.

Le premier ensemble — les activités opérationnelles requises — comprend des préoccupations telles que :

• Recherche et caractérisation des restaurants, y compris leur emplacement et leurs heures d'ouverture
• Collecte de données sur les éléments du menu et les prix
• Informer les restaurants des commandes
• Traitement des paiements
• Conserver des données sur la disponibilité des ressources humaines pour récupérer et livrer les commandes
• Suivi de l'état de préparation de la commande et de l'état de livraison

Le deuxième ensemble de préoccupations est moins opérationnel au quotidien, mais n’en est pas moins important. Ces problèmes, s’ils sont réfléchis en amont, permettront à l’entreprise d’être agile, adaptable et de s’améliorer en permanence. Voici des exemples de ce type de préoccupations :

• Comment prévoir la demande ? Il pourrait s'agir simplement d'une demande globale par heure de la journée/semaine, ou bien d'une demande plus fine, par exemple par restaurant.
• Quels types d’outils, de processus ou de flux de travail fournissent des informations commerciales à mes fournisseurs (restaurants) ?
• Comment les prix, qu’il s’agisse de la nourriture ou de la livraison, peuvent-ils être ajustés de manière dynamique ?
• En supposant que mon application soit hébergée dans le cloud public, comment mes coûts d’infrastructure opérationnelle peuvent-ils être optimisés ?

Il s’agit bien sûr d’un sous-ensemble de la richesse complète des préoccupations que nous pourrions avoir, mais même cet ensemble plus restreint suffit à permettre une bonne discussion qui souligne l’importance de l’architecture de données structurée pour soutenir un pipeline de traitement de données extensible.

Architecture des données ou pipeline de données/L'œuf ou la poule

Dans notre rôle imaginé de propriétaire d’application, lorsque nous réfléchissons à notre stratégie globale en matière de données, nous pouvons commencer par énumérer nos flux de travail métier, en identifiant les besoins de traitement des données de chacun. Un exemple est le flux de travail qui localise les restaurants ouverts à proximité, puis présente les sélections de menu et les prix des articles pour chacun d'eux. Il faudrait filtrer les restaurants par emplacement et heures d'ouverture, puis rechercher les sélections de menu pour un restaurant spécifiquement sélectionné, peut-être également filtré par la disponibilité des livreurs. Et nous pourrions faire cela pour chaque flux de travail : traitement des paiements, mise en relation des chauffeurs avec les livraisons, etc.

Ou, tout aussi raisonnablement, nous pourrions plutôt commencer nos réflexions avec les « atomes » de données de base, c’est-à-dire les éléments de base des données qui sont nécessaires. Nous identifierons et énumérerons les atomes de données importants, en accordant une attention particulière à la représentation uniforme et à la sémantique cohérente de ces atomes de données ainsi qu'à tout vocabulaire de métadonnées nécessaire à la prise en charge de nos flux de travail commerciaux. Les exemples d'atomes de données dans notre exemple d'application incluraient : les données de localisation des restaurants, des clients et des chauffeurs ; les aliments nécessaires aux menus et aux factures ; le temps, utilisé pour filtrer et suivre la qualité de la livraison ; et les informations de paiement, associées aux flux de travail de paiement des clients et des chauffeurs.

Lequel de ces deux points de départ potentiels (le pipeline de traitement des données des workflows ou, alternativement, les « atomes » de données) utiliser pour notre stratégie de données est une question de type « poule ou œuf ». Les deux perspectives sont utiles et, plus important encore, sont interdépendantes. Nous ne pouvons pas raisonner sur le pipeline de traitement des données sans penser aux atomes de données sous-jacents, ni développer l’architecture des données sans prendre en compte les besoins du pipeline de traitement. Cela dit, en général, je recommanderais une approche dans laquelle on effectue un premier passage à travers les flux de travail pour énumérer les atomes de données, mais on aborde ensuite la conception structurée de l’architecture de données avant de procéder à la conception détaillée du pipeline de données. Cela est dû au fait que les flux de travail sont plus dynamiques ; ils sont ajoutés et modifiés à mesure que l’entreprise évolue, tandis que les données sous-jacentes ont plus d’historique et d’inertie. Par conséquent, l’architecture des données bénéficie davantage de la prévoyance.

Application d'une approche holistique d'architecture de données et de pipeline à des exemples concrets

Pour revenir à notre exemple, supposons qu’en tant que propriétaire d’application, nous ayons une vision assez développée des principaux flux de travail critiques pour l’entreprise et des atomes de données nécessaires pour les prendre en charge. Plus tôt dans cette discussion, nous avions identifié quelques-uns des éléments de données fondamentaux nécessaires à nos flux de travail : l’emplacement, l’heure, les aliments et les informations de paiement. Et, pour récapituler les articles précédents, l’architecture des données doit permettre trois objectifs clés : l’uniformité de la syntaxe, la cohérence de la sémantique et un vocabulaire de métadonnées pour raisonner et gouverner les données. Nous pouvons maintenant appliquer ces principes pour discuter des considérations relatives à l’architecture des données pour les atomes de données spécifiques énumérés dans l’exemple d’aujourd’hui.

En zoomant sur l’atome de données de localisation , considérez chacun des 3 objectifs clés de l’architecture des données.

• Tout d’abord, quelle est la syntaxe de représentation uniforme des données ?
  Une première idée pourrait être de représenter l'emplacement par l'adresse postale, car c'est ainsi que les restaurants et les clients représentent généralement leur emplacement. Cependant, tenez compte des besoins de localisation pour le suivi des chauffeurs effectuant des livraisons : ils sont souvent en mouvement, peut-être sur une autoroute principale ou à un endroit qui n’est pas bien décrit par une adresse postale. Au lieu de cela, une spécification de latitude et de longitude peut être un meilleur moyen de représenter l'emplacement pour ce flux de travail, et ce format fonctionnerait toujours pour les emplacements des restaurants et des clients. Mais comme les conducteurs doivent généralement se rendre dans un restaurant ou chez un client, il doit toujours y avoir un moyen de relier l'emplacement (lat/lon) d'un conducteur à l'emplacement (adresse postale) d'un client. Par conséquent, un choix plus réfléchi pourrait être de normaliser toutes les données de localisation en latitude et longitude (la représentation « canonique » requise), mais avec la possibilité de convertir les adresses postales en latitude/longitude lorsque l'adresse postale est fournie pour la première fois (un flux de travail « d'ingestion »).
• La deuxième considération est celle de la sémantique cohérente . 
  En supposant que l’emplacement soit normalisé en latitude/longitude, cela est relativement simple, car il s’agit d’une norme bien établie avec une interprétation sans ambiguïté. Cependant, un autre aspect de la sémantique cohérente concerne la précision, c’est-à-dire l’exactitude implicite des données. Étant donné que les données GPS et cartographiques auront une précision implicitement limitée, nous pouvons choisir de spécifier l'emplacement avec une précision constante (par exemple, à la seconde d'arc la plus proche, environ 100 pieds) ou avec une précision variable, selon la qualité de la source de données. Si nous choisissons cette dernière option pour plus de flexibilité, nous devons annoter – à l’aide de métadonnées, décrites ci-après – la précision de chaque instance de données de localisation.
• Le troisième objectif de l’architecture des données est d’avoir la capacité d’ annoter et d’enrichir les éléments de données collectés.
  Dans le cas de la localisation, cela peut inclure la précision des données, comme mentionné précédemment. En outre, nous pouvons également souhaiter annoter l'emplacement avec une adresse postale pour des raisons de convivialité, et surtout pour que les données d'adresse ingérées puissent être conservées. Ceci est particulièrement important dans les cas où plusieurs adresses de rue peuvent correspondre à la même latitude/longitude, comme dans le cas d'un complexe d'appartements. Un autre enrichissement peut être un horodatage indiquant le moment où le champ de données de localisation a été collecté, ce qui peut être pertinent pour un conducteur en mouvement où les données de localisation deviennent rapidement obsolètes.

Nous avons seulement parlé des exigences en matière de localisation et pouvons maintenant effectuer un exercice similaire pour chacun des autres champs de données. Cependant, plutôt que d’énumérer tous les domaines de préoccupation pour chacun des atomes de données, je soulignerai plutôt quelques observations notables :

• Concernant l'atome de données Time : La représentation d’une valeur temporelle est notoirement délicate. Cela peut varier, à la fois syntaxiquement (par exemple, format 24 heures par rapport à 12 heures plus AM/PM) et sémantiquement (par exemple, le concept de fuseaux horaires et la variation selon l'observation de l'heure d'été). Par conséquent, la représentation du temps devra probablement être canonique (par exemple en normalisant en GMT ou en secondes « depuis l’époque » pour les utilisateurs d’Unix/Linux).
• Les instances de données sur les aliments peuvent être très variées, avec des besoins uniques. Étant donné que les atomes de données sont souvent de forme libre, un vocabulaire de métadonnées canonique est plus utile que de tenter une syntaxe uniforme. Certains champs de métadonnées seraient destinés aux propriétés statiques par article, telles que « doit rester froid » ou « contient des noix », mais d’autres champs de métadonnées seraient requis pour les informations sur les aliments par instance (par commande), telles que « le niveau de piquant » ou « les condiments préférés ». Dans les deux cas, l’objectif de conception nécessite une syntaxe uniforme et une sémantique cohérente pour les champs de métadonnées, afin qu’ils puissent être partagés dans l’ensemble de l’inventaire des éléments de menu.
• D’autres considérations clés sont la conformité et la gouvernance des données. L’un des aspects est la politique de conservation des données, où certains champs, tels que l’adresse IP d’un client ou l’historique de localisation d’un chauffeur, ne peuvent être conservés que pendant une courte période. Une autre considération courante est que certains champs peuvent avoir des contraintes de sécurité ou de confidentialité ; les informations de paiement en sont un exemple. L’augmentation des métadonnées est une solution pour les deux cas. Les métadonnées doivent être utilisées pour annoter une adresse IP ou une valeur de localisation avec un délai d'expiration des données pour la conservation des données. Dans le cas des informations de paiement, les métadonnées peuvent être utilisées pour transmettre des exigences de sécurité, telles que la nécessité de chiffrer les données au repos ou pour spécifier les contraintes de géolocalisation du magasin de données persistant.

Bien que cet exemple n’ait été qu’un aperçu superficiel, il a mis en lumière de nombreuses préoccupations associées à des scénarios réels. Dans le monde réel, cependant, le processus de réflexion sur la stratégie de données ne s’arrêterait pas là mais serait itératif et continu. À mesure que les éléments de données sont introduits dans les pipelines de traitement de données qui incarnent les flux de travail de l'entreprise, des ajustements et des améliorations itératifs seront apportés à l'architecture des données. À mesure que les flux de travail existants sont améliorés et que de nouveaux flux de travail sont ajoutés, nous découvrirons des exigences d’architecture de données supplémentaires pour les atomes de données existants ainsi que pour les nouveaux atomes de données.

Réflexions finales

Bien que cet exemple ait été simplifié pour plus de concision, il démontre néanmoins les principes clés autour du mappage des flux de travail à leurs implications en matière d'architecture de données. Le processus commence toujours par prendre en compte les besoins de l’entreprise : l’expérience client et les processus commerciaux requis pour répondre à ces besoins. Les processus métier définissent à leur tour les éléments d’un vocabulaire métier. Au niveau de spécificité suivant, les processus sont mappés sur un pipeline de données, qui exploite un vocabulaire de données. 

Le principe clé est que l’architecture de données robuste, qui définit la syntaxe, la sémantique et les annotations, constitue une base qui permet d’améliorer efficacement le pipeline de données et d’ajouter facilement de nouveaux flux de travail. Au niveau de l'abstraction de la couche métier, cela signifie que les processus métier existants peuvent être facilement modifiés et que les processus métier nouveaux ou émergents peuvent être rapidement mis en ligne. À l’inverse, l’incapacité à prendre des décisions réfléchies dans l’un de ces domaines (vocabulaire des données, cadre d’architecture des données ou lien entre ces éléments et les besoins de l’entreprise) conduira à terme à un système fragile et cassant, qui ne sera pas agile face aux nouvelles exigences de l’entreprise.