Cette semaine, nous délaissons donc les feuilles de route pour revenir au carburant numérique : Architecture des données.
Si vous vous souvenez de notre séries de données de l'automne dernier, J'avoue avoir toujours eu une relation difficile avec l'architecture des données. C'est fondamental. Rien de bien extraordinaire. architecture d'entreprise existe sans données et architecture de sécurité. Pourtant, les discussions habituelles, arides et obscures, perdent généralement de vue l'essentiel.
Nous nous appuyons fortement sur le modèle de données d'entreprise de DAMA car il est tout simplement efficace. Ces quelques pages du DMBOK sont une mine d'or. Trois modèles simples :Modèle de sujet, Modèle de domaine thématique (SAM), et Modèle logique de données (MLD) Nous vous fournissons un modèle de données d'entreprise complet. En 8 à 20 sujets et une vingtaine d'entités dans le SAM, vous disposez des bases nécessaires pour comprendre la gouvernance, les flux et les besoins en données, le tout en 160 à 400 mots. C'est tout.
Puis nous avons abordé le sujet des produits numériques.
Vous connaissez le service numérique proposé par votre entreprise. Parfois, toute l'entreprise est organisée autour de ce service, comme ServiceNow. Parfois, il est profondément intégré, comme chez Apple. Photos. Parfois, il se trouve à côté des services proposés par votre entreprise.
Lorsque nous appliquons le modèle DAMA classique, il peine à fonctionner, voire s'avère inefficace. Un sujet correspond à une activité commerciale. Commencez par les activités commerciales essentielles, comme… Vente, Expédition, Facturation, et Soutien. Génial. Voilà une gouvernance des données fondamentales parfaitement claire. Le responsable du transport maritime possède données d'expédition. Le patron de ventes Vous gérez les ventes. Vous planifiez, vous vendez, vous expédiez, vous facturez, vous assurez le support. Les données circulent de manière séquentielle, sans frontières organisationnelles clairement définies.
Bien sûr, la plupart des équipes butent sur des mots comme « client ». Parce qu'elles sont parties des données, et non du business. Quand on part du sujet (l'activité commerciale), on découvre que les mots sont… acheteur, récepteur, payeur et opérateur. Chacune de ces relations avec votre entreprise est différente ; définissez précisément la relation, et non un terme vague comme… client Et tout devient clair.
Voici un panorama des données d'entreprise. Magnifique. La gouvernance et les flux de données sont parfaitement clairs. Vous partagez un vocabulaire commun avec l'entreprise. Le " Produit " est simplement une entité qui s'intègre à vos Sujets et intègre des relations de données supplémentaires.
Vous obtenez alors un produit numérique. Votre client se connecte à votre logiciel et y exprime ses espoirs, ses craintes et ses rêves (réseaux sociaux). Ou bien il gère son écosystème informatique (ServiceNow). Ou encore, son téléphone prend des photos géolocalisées et datées, et les enregistre dans votre base de données.
Comment l'expression d'un espoir, l'adresse IP utilisée par le navigateur, l'adresse IP interne du CI du client et la localisation du téléphone du client un vendredi soir à 23h25 s'intègrent-elles dans votre modèle de données d'entreprise ?
Un enchevêtrement inextricable
La lutte avec les produits numériques
Un produit numérique est fondamentalement différent car le client est à l'intérieur la machine. Le produit est intégrée à l'activité. Le client réalise souvent cette activité sans nous.
Prenons l'exemple de ServiceNow, une plateforme courante de gestion des opérations informatiques. Le client l'utilise pour saisir ses éléments de configuration (CI) et son portefeuille d'applications. Si nous ne délimitons pas clairement le produit et que nous ne partons pas des sujets d'activité, nous nous retrouvons face à un cercle vicieux. De plus, nous ne pouvons pas appliquer nos sujets d'activité (activités métier) directement au sein du produit.
Les éléments de configuration (CI) étaient simples à gérer. On constate clairement que ServiceNow Corporation peut disposer d'un CI utilisé pour exploiter le produit, sans que cela n'ait aucun lien avec son contenu. La difficulté réside dans les données qui franchissent la frontière. Lorsque le client est impliqué dans notre processus métier – lorsqu'il crée un identifiant ServiceNow pour gérer les tickets et accéder au produit –, cet identifiant devient essentiel pour ServiceNow. Sujet de sécurité, Sujet de facturation, Sujet du service à la clientèle.
Nous franchissons l'horizon des événements lorsque nous utilisons des données pour nos opérations. Les choses deviennent très étranges lorsqu'on franchit cet horizon.
En clair, ne franchissez pas l'horizon des événements.
Il est essentiel de séparer clairement l'architecture des données produit de l'architecture des données d'entreprise. Dès que nous entamons cette démarche, nous nous heurtons à un problème majeur : Conditions d'utilisation des données.
Êtes-vous la Poste ou Facebook ?
La séparation des données produit et des données d'entreprise soulève une contrainte fondamentale : quelles sont les conditions d'utilisation de ces données ? Nous utilisons des conditions d'utilisation partout dans… Naviguer Car elle nous impose une contrainte architecturale fondamentale. À l'époque de l'architecture orientée services, j'utilisais le ' test du bus ' pour expliquer les conditions d'utilisation. Un bus est un service partagé, avec des conditions d'utilisation strictes. Un ticket donne accès à un seul passager. Un ticket à un arrêt de bus donne accès à un seul passager sur un trajet prédéfini. Ce ticket, ce trajet et cet arrêt ne sont valables qu'aux heures prévues.
Le chauffeur ne vous demandera ni votre destination, ni votre heure d'arrivée, ni si vous souhaitez qu'il vous ramène chez vous. Il n'acceptera pas non plus qu'un voleur utilise votre ticket. Conditions d'utilisation claires.
Nous utilisons une comparaison simple et frappante dans notre missions de conseil. Lorsque vous créez un produit numérique, Sommes-nous la Poste ou Facebook ?
La Poste fournit un service essentiel : l’acheminement des messages d’un expéditeur à un destinataire. Pour ce faire, elle a besoin de métadonnées très précises : l’adresse de destination, l’adresse de retour et le niveau de service choisi. Voici la contrainte absolue : Ils ne regardent jamais à l'intérieur de l'enveloppe. Leur architecture, leur gouvernance et leurs modèles de données reposent sur le principe que le contenu des courriers ne les regarde pas. Si un employé de la Poste ouvre votre courrier pour analyser vos lettres et vous vendre des publicités ciblées, ce n'est pas une stratégie de monétisation astucieuse. C'est un délit.
Maintenant, Facebook. Facebook est tout le contraire. Oui, tout comme la Poste, ils servent d'intermédiaires dans la communication. Ils conservent une trace des métadonnées pertinentes. exploiter le service. Mais le contenu de vos messages C'est le principal moteur de leur modèle économique. Ils ouvrent chaque message et l'analysent. Ils suivent les actions du destinataire. Ils comparent les destinataires, les expéditeurs, les sujets, absolument tout. Ils pourraient tout aussi bien fouiller dans nos tiroirs à chaussettes pour monétiser leur contenu, leur marque, leur type et leur état. Car les conditions d'utilisation les y autorisent.
N'importe quelle condition d'utilisation peut convenir. Certaines, comme celles de WhatsApp, sont conçues pour une confidentialité maximale. D'autres donnent accès à tout. N'oubliez pas que ce n'est pas de la confidentialité absolue — même Facebook ne l'est pas. publier Vos espoirs, vos rêves, vos obsessions. Mais ils les utilisent. Ils les utilisent parce que les conditions d'utilisation du produit le leur permettent. Lorsque vous enfreignez les conditions d'utilisation, vous commettez une grave erreur d'architecture. Vous n'avez pas su définir les limites.
Les conditions d'utilisation sont toujours définies par propriétaire. Responsable de service, responsable produit, responsable d'installation, responsable de secteur d'activité… Peu importe. Concrètement, nous nous tournons vers le Responsable Produit. Pas un simple membre d'une équipe agile, mais la personne responsable du produit proposé à nos clients. Celle qui sait concilier les conditions d'utilisation acceptables pour les clients et celles acceptables pour l'entreprise. N'oublions pas que de nombreux usagers des transports en commun souhaitent un chauffeur à temps plein, quelqu'un qui les attend patiemment pour les conduire à destination. Ce service existe, mais à un autre prix.
L'assemblée comme ultime force de coercition
Les conditions d'utilisation définissent un cadre précis. Toute frontière est source de tension. L'architecture excelle précisément dans la gestion de ces contraintes.
La fonctionnalité " Souvenirs " de l'application Photos d'Apple alimente les tensions. Apple propose un stockage et un partage communs sur sa plateforme, ce qui ressemble beaucoup à la médiation communautaire de Facebook. Cependant, la principale valeur ajoutée d'Apple réside dans la protection de la vie privée. L'entreprise défend farouchement ses conditions d'utilisation et va jusqu'à retirer des services du marché lorsqu'elle ne peut garantir que personne ne puisse accéder à vos données. tiroir à chaussettes Apple sans votre participation active.
En interne, ils ne dépensent pas un centime pour le traitement des données clients en vue de l'exécution d'un mandat. Parce que… ne peut pas regarder. Ils affirment devant le tribunal Il n'y a pas de porte dérobée..
Ils proposent ensuite un service qui examine et sélectionne vos photos pour vous — vos souvenirs. Leurs conditions d'utilisation garantissent une confidentialité absolue.
Ils surmontent ces contraintes majeures — Apple ne peut pas accéder à vos photos et elles sont sélectionnées — grâce à des solutions efficaces. architecture d'application. En termes de navigation, il s'agit simplement d'utiliser Modèle d'assemblage.
L'assemblage des fonctionnalités est une tâche essentielle pour un architecte d'applications. Cet assemblage détermine les limites d'intégration, le cycle de vie et les dépendances ; il représente le principal défi de l'architecture applicative. Nous savons que les fonctionnalités peuvent être placées n'importe où. Littéralement n'importe où. On peut les intégrer à une application d'entreprise, les exposer dans un microservice, ou même les câblées directement dans un ASIC.
Pour respecter les conditions d'utilisation des données, Apple choisit délibérément de déployer la fonctionnalité AI Worker directement sur l'appareil périphérique : votre iPhone. En combinant le traitement des données et leur traitement, Apple se dissocie physiquement de ces dernières. L'entreprise renonce ainsi sciemment à la monétisation potentielle auprès du client.
Ignorer ses déclarations, c'est s'exposer à des conséquences désastreuses. La responsabilité civile impose des mesures de protection a posteriori, complexifie les choses, alourdit la dette technique et les coûts, et laisse un lourd passif à dissimuler.
Lorsque votre produit numérique comporte des conditions d'utilisation, inspirez-vous d'Apple. Concevez une architecture applicative, technologique et de sécurité conforme aux exigences.
Conclusion : Couper le nœud
Si vous ne commencez pas par les données produit et que vous ne connaissez pas vos conditions d'utilisation (Facebook qui jette un coup d'œil pour gagner sa vie, la Poste qui jette un coup d'œil lorsqu'on le lui demande, ou Apple qui ne peut pas jeter un coup d'œil), votre architecture dérive inévitablement vers la responsabilité.
Vos défis les plus complexes résident dans l'amélioration de vos opérations commerciales grâce à l'utilisation des données produit. Un exemple simple consiste à utiliser les identités gérées par vos clients au sein de votre produit SaaS pour la gestion des accès ou l'autorisation.
Vous ne démêlerez jamais ce nœud en modifiant légèrement vos sujets " Ventes ", " Support " ou " Opérations informatiques ". C'est comme tirer plus fort sur la corde : cela ne fait que resserrer le nœud. C'est exactement la même chose que d'organiser une réunion supplémentaire à ce sujet. qui possède le client.
Mon défi cette semaine est d'examiner vos produits numériques. Les séparez-vous clairement et distinctement dans l'architecture de vos applications ? Qu'en est-il de votre architecture de données ? Ou bien mélangez-vous tout dans un enchevêtrement complexe de données à gérer ? ton support aux entreprises et aux applications ton Votre entreprise ? Commencez à aborder vos produits numériques comme sujets de discussion. Commencez à énoncer clairement les conditions d’utilisation. Commencez régir votre architecture en suivant les instructions qui vous ont été données.
La semaine prochaine, je vous montrerai précisément comment résoudre ce problème. Nous verrons comment définir l'architecture du périmètre et établir des contraintes claires. Nous commencerons simplement par étendre le modèle de données d'entreprise DAMA standard et traiterons chaque produit numérique comme un sujet DAMA.
Comme toujours, vos avis et commentaires sont les bienvenus.
Passe une bonne journée!
Salutations,
Dave Dave Hornford Conexiam
PS. Si la simplification de votre architecture de données est une priorité absolue, consultez notre Atelier sur les fondations de l'architecture des données. Nous vous aiderons à cartographier vos sujets, à définir vos contrats de données et à veiller à ce que vos conditions d'utilisation pilotent votre architecture au lieu de la perturber.