Qu'est-ce que l'architecture des données ?
Quatre éléments de l'architecture des données
- Besoins en données
- Principaux types de données
- Principales sources de données
- Ressources de gestion des données
Types de modèles d'architecture de données
- Naviguer dans les types de modèles
- Modèle de sujet
- Modèle de domaine d'étude
- Modèle de données logiques
- Modèle de document logique
Qu'est-ce que l'architecture des données ?
L'architecture des données explique et permet la besoins en données de l'entreprise. Il est décrit à travers quatre éléments—besoins en données, principales sources de données, principaux types de données, et le requis ressources de gestion des données.
Nous utilisons quatre modèles d'architecture d'entreprise pour décrire votre architecture de données - le modèle de sujet, modèle de domaine d'étude, modèle de données logique, et modèle de document logique.
L'architecture des données est la partie principale de la architecture des systèmes d'informationL'architecture des systèmes d'information est un système unique domaine de l'architecture qui s'aligne fonctionnalité, données, et gestion des donnéesEn pratique, cela signifie s’assurer que les applications fournissent le flux de données et la gestion des données requis, et pas seulement des fonctionnalités.
La pratique courante relègue l'architecture des données au second plan. Nous sommes obsédés par les fonctionnalités et parlons des applications : de leur fonctionnement, de leur conception ou de leur intégration à d'autres systèmes.
Les applications servent à traiter et à gérer les données. Sans une compréhension et une conception solides de l'architecture des données, les applications deviennent des îlots déconnectés. En fournissant des fonctionnalités, elles génèrent une dette technique. Elles complexifient les flux et la gestion des données. La complexité des flux et de la gestion des données accroît la dette technique et complexifie la gouvernance des données.
Lorsque vous utilisez des données et que vous garantissez la architecture des applications se concentre sur la structure et interaction des applications qui ... gèrent les actifs de données, vous disposez d'une architecture de systèmes d'information.
Pas de succès transformation numérique Ils seront construits sur la fonctionnalité. Ils sont toujours construits sur les données.
Quatre éléments de l'architecture des données
Chaque architecture de données abordera :
- Besoins en données
- Principaux types de données
- Principales sources de données
- Ressources de gestion des données
À eux seuls, ces éléments nous aident à comprendre la structure des données.
Nous cherchons à comprendre le flux de données. Ce flux s'explique par ses sources, et les besoins en données en sont les piliers : leur provenance et leur destination.
Gardez à l'esprit qu'une fois que les données commencent à circuler, elles peuvent aller n'importe où. Le flux nécessite des contrôles et des ressources de gestion des données.
Nous savons que l’architecture des données est très performante l'architecture d'entreprise. Il ne peut être piloté que si vous connaissez le flux de données. Le flux de données requis impose la manière dont l'architecture de l'application] et architecture d'infrastructure activez votre architecture d'entreprise.
Besoins en données
Tout commence par le besoins en données de l'entreprise.
Les besoins en données se répartissent en trois catégories :
- Données nécessaire créer des produits et des services:Informations dont dépendent vos produits et services.
- Données nécessaire exploiter l'entreprise:Données transactionnelles, opérationnelles et de processus qui assurent le bon déroulement des activités quotidiennes.
- Données nécessaire tenir des registres:** Informations contractuelles et réglementaires définies nécessaires à la conformité.
Ne vous méprenez pas besoins en données — vous devez séparer impitoyablement ce qui est agréable à avoir de quoi nnécessaire.
Nécessaire Ne nécessite pas de modificateurs comme absolument ou important. « Needle » signifie simplement « nécessaire ».
Principales sources de données
Où les données sont créées, collectées et transformées. Elles proviennent de processus manuels, d'applications, d'appareils et de partenaires externes. La compréhension du système source est essentielle à la qualité, à la traçabilité et à la gouvernance des données.
Principaux types de données
Identifier les catégories de données clés pertinentes pour votre entreprise : clients, produits, finances, opérations, etc. Cette classification permet de cibler les efforts d'architecture et de gouvernance.
Habituellement, les principaux types de données sont définis dans le Modèle de sujet
Ressources de gestion des données
Des outils et des systèmes permettant de fournir les données nécessaires où, quand et comment, avec la qualité, la fiabilité et la sécurité requises. En pratique, il s'agit d'un large éventail d'exigences visant les architectures d'applications et d'infrastructures.
Types de modèles d'architecture de données
Naviguer dans les types de modèles d'architecture de données
Naviguer Nous proposons une architecture d'entreprise de bout en bout. C'est une façon concrète de dire que nous travaillons à une architecture de modèle de bout en bout.
Nous développons le paysage EA en suivant la meilleure pratique consistant à l'étendre progressivement, un projet d'architecture à la fois.
Nous gérons le modèle d'entreprise à l'aide de types de modèles distincts. Un type de modèle peut prendre en charge une analyse spécifique ou se concentrer sur un aspect distinct du modèle de bout en bout. En termes simples, un type de modèle fait référence aux conventions d'un type de modélisation spécifique.
Chaque type de modèle est optimisé pour nous dire quelque chose sur l'architecture.
Différents types de modèles seront explorés :
- motivation et stratégie
- parties d'un domaine d'architecture
L'utilisation de types de modèles favorise la cohérence et la réutilisabilité, ce qui améliore la productivité et la cohérence au sein d'une équipe EA.
Naviguer Type de modèle Description
Chaque type de modèle est défini par :
- But:Pourquoi ce type de modèle existe et à quelles questions il est censé répondre.
- Portée: Décrire les limites de ce qui est inclus et exclu dans le type de modèle.
- Contenu et structure: Les composants, les relations et les propriétés qui doivent être utilisés lors de la création d'instances d'un type de modèle.
- Approche de modélisation: Des conseils sur la manière dont ce qui est inclus ou exclu permet de se concentrer sur des aspects spécifiques pertinents pour les objectifs.
- (Facultatif) Relation avec d'autres types de modèles:Décrit le but du lien et la relation utilisée pour relier les deux modèles.
Notes sur le modèle de données d'entreprise
Les types de modèles de données de Navigate sont issus du modèle de données d'entreprise de DAMA. Ce modèle est composé des éléments suivants : Modèle de sujet, Modèle de domaine thématique (SAM), et Modèle logique de données (MLD)Le SAM et le LDM sont tous deux construits à partir des sujets. Ils servent des objectifs distincts, mais interconnectés.
le Modèle de sujet Décrit le paysage de données de l'organisation. Chaque sujet est pertinent pour ce paysage.
le Modèle de domaine d'étude est centré sur l'entreprise Vue. Il s'agit de comprendre en détail un domaine métier spécifique, un « sujet ». Le SAM définit le sujet de manière à ce qu'il soit facilement compréhensible par les parties prenantes de l'entreprise. Il s'agit d'un récit des données, centré sur ce qu'elles représentent. moyens.
le Modèle de données logiques, est un orienté vers la techniqueIl s'appuie sur le SAM, passant des concepts commerciaux du SAM à des détails suffisants pour guider la mise en œuvre.
Ensemble, le SAM et le LDM s'adressent à deux publics distincts. Le SAM reflète la compréhension métier de la signification des données. Le LDM sert de guide et de contrainte pour la mise en œuvre. Ce cadre est souvent documenté dans un Master Data Blueprint.
Le SAM et le LDM reflètent le même sujet, s'adressant à des publics différents.
Modèle de sujet
Portée du modèle de sujet
Le modèle de sujet identifie pertinent pour les affaires zones d'information
Chaque sujet identifie les informations nécessaires dans un domaine d'activité ou un aspect distinct des opérations
Fournir un compréhension partagée du paysage des données
Habitué
- Encadrer les discussions sur le paysage des données
- Mettre en évidence les zones de complexité des données
- Modélisation directe ultérieure
Guide du modèle de sujet
À l'échelle de l'entreprise
- 12 à 20 matières
Projet d'architecture à l'échelle du département
- Prévoyez 3 à 5 sujets
Initiative de transformation
- Prévoyez 5 à 10 sujets
Modèle de domaine d'étude
Le modèle de domaine thématique (SAM) représente les informations d'un même sujet. Il permet de garantir une compréhension commune du paysage des données.
L’objectif est clair : développer une compréhension du paysage des données.
DAMA nous invite à réfléchir aux entités et aux attributs qui définissent les informations d'un sujet. Les entités entretiennent des relations avec d'autres entités, avec le sujet et entre les sujets.
Guide du modèle de domaine d'étude
Le modèle de domaine utilise 8 à 15 termes métier (entités) pour définir le sujet. Attendez-vous à un ou deux termes métier provenant d'un autre sujet pour compléter la compréhension du sujet.
Visez un nombre idéal d'environ 13 termes commerciaux. Le modèle doit être gérable.
À mesure que vous approchez des 12 termes commerciaux, demandez-vous si vous avez plus d'un sujet
Moins de 8 termes commerciaux suggèrent que ce n'est peut-être pas un sujet profond ou important.
Modèle de données logiques
Le modèle logique de données (MLD) représente les informations d'un sujet unique afin de guider et de contraindre la mise en œuvre. Il est utilisé pour garantir une gestion technique cohérente du paysage des données.
L'objectif est clair : guider la mise en œuvre pour garantir que le paysage des données permet à l'entreprise de besoins en données.
Guide du modèle de données logiques
Le modèle logique de données utilise 12 à 20 composants de données logiques (entités). Attendez-vous à 3 à 5 composants de données logiques pour une autre matière.
Le LDM devoir inclure les relations cardinales, les propriétés et les spécifications d'architecture d'accès et de gestion des données
Propriétés des données logiques
Accès aux données
-
- Cette entité a-t-elle des contraintes d'accès spécifiques
Classification des données
-
- De quelle classe de données s'agit-il ? (Maître, Référence, Transactionnelle)
Conservation des données
-
- Existe-t-il des exigences particulières en matière de conservation ? D'où viennent ces exigences ?
Type de données
-
- De quel type de données s'agit-il ? (Nombre, texte, booléen, calculé)
Propriété de protection des données (facultatif)
-
- Les données ont-elles des exigences de protection inattendues ?
Modèle de document logique
Le type de modèle de document logique existe pour représenter des artefacts (tels que des formulaires, des lettres ou des rapports) pertinents pour une activité commerciale spécifique (par exemple, un devis, un bon de commande, une facture, un connaissement, une demande d'emploi).
Il fournit un contexte aux données, facilitant ainsi la compréhension de leur sécurité, de leur conservation, de leur flux et de leur gouvernance. Par exemple, des entités de données telles que prix ne transmettent pas d'exigences de conservation ou de sécurité, alors que des documents comme le Citation, Commande client, et Facture fournir ce contexte.
Les documents logiques couvrent trois types de documents :
- Enregistrer:Documents exigés par la loi ou un contrat, avec un contenu défini en externe et des exigences de conservation.
- Document commercial:Documents définis en interne pour soutenir les processus métier, régis par des politiques organisationnelles de cohérence et d'auditabilité.
- Document transitoire:Documents informels créés et utilisés par des individus ou des équipes, dont la conservation est gérée par des politiques internes et alignée sur les besoins du créateur.
Guide du modèle de document logique
Le modèle de document logique est plus simple à utiliser lorsqu'un processus métier de bout en bout est envisagé. Un processus de bout en bout utilise de 3 à 10 documents logiques.
Visez un nombre idéal d'environ 6 documents logiques. Vous recherchez une liste complète de Enregistrements, et une liste utile de Documents commerciaux et Documents transitoires pour capturer la rétention, la sécurité et la qualité.
Chaque document logique contiendra 5 à 10 termes commerciaux ou composants de données logiques.
Propriétés du document logique
Type de document
-
- Enregistrement, document commercial, transitoire
Propriété d'accès aux données
-
- Données nationales uniquement, données organisationnelles uniquement, données départementales uniquement, données de processus uniquement ou données de conservation
Propriété de conservation des données (facultatif)
-
- Ad hoc, départemental, d'entreprise, contractuel, réglementé ou interdit
Propriété de protection des données (facultatif)
-
- - Détendu, Standard, Amélioré
Tout tourne autour des besoins en données
Clarifions les choses besoins en données— vous devez séparer impitoyablement ce qui est agréable à avoir de ce qui est nécessaire.
Données nécessaires Ne nécessite pas de modificateurs tels que « absolument nécessaire » ou « données importantes ». « Nécessaire » signifie simplement « nécessaire ».
La distinction claire entre nécessaire et tout le reste constitue la base des exigences d’application efficaces.
Une fois que vous savez qu’une activité commerciale a besoin de certaines données, tout le reste émerge :
- source
- couler
Les données nécessaires définissent où le flux doit arriver. - qualité
Les données nécessaires définissent la qualité. - sécurité
La sécurité ne définit pas où les données peuvent être stockées. Les données nécessaires vont là où elles sont nécessaires. Les données nécessaires définissent où les données sont stockées. devoir être livré en toute sécurité et là où il doit être sécurisé. - gestion des données
Besoin + qualité + flux + sécurité définissent les ressources de gestion des données requises
La source est un défi, en particulier lorsque le fournisseur et le consommateur appartiennent à des organisations ou à des autorité ou domaines de gouvernanceOn imagine souvent que ce sont les consommateurs de données qui définissent la qualité. Ce n'est pas le cas. Ce sont les producteurs de données qui définissent la qualité.
Les consommateurs peuvent exiger une qualité supérieure, mais ils peuvent être confrontés à trois choix :
- payer plus
- se passer de
- améliorer eux-mêmes la qualité
Ce n’est pas différent de toute autre relation producteur/consommateur.
Souviens-toi:
Les besoins en données tracent un chemin à travers des paysages de données fragmentés.
Les besoins en matière de données doivent briser les silos.
Les besoins en données déterminent les définitions réelles des données
Les besoins en données permettent une gouvernance des données.
Conclusion de Qu'est-ce que l'architecture des données ?
Responsables de l'architecture des données architecture des systèmes d'informationL'architecture des systèmes d'information est la domaine de l'architecture qui s'aligne données, gestion des données, et fonctionnalité.
L'architecture des données explique et permet la besoins en données de l'entreprise à travers quatre éléments—besoins en données, principales sources de données, principaux types de données, et le requis ressources de gestion des données.
Quatre modèles d'architecture d'entreprise décrivez votre architecture de données : la modèle de sujet, modèle de domaine d'étude, modèle de données logique, et modèle de document logique.
La pratique courante relègue l’architecture des données au second plan et met l’accent sur les applications : ce qu’elles font, comment elles sont construites ou comment elles s’intègrent à d’autres systèmes.
Les meilleures pratiques sont basées sur les données et garantissent architecture des applications se concentre sur la structure et interaction des applications qui ... gèrent les actifs de données.
Pas de succès transformation numérique Ils seront construits sur la fonctionnalité. Ils sont toujours construits sur les données.