Was ist Datenarchitektur?
Data architecture is explains and enables the data needs of the enterprise. It is described through four elements—data needs, major sources of data, major types of data, and the required data management resources.
We use four Modelle der Unternehmensarchitektur to describe your data architecture - the subject model, subject area model, logical data model, und logical document model.
Data architecture is the leading part of the Architektur von Informationssystemen. The Information Systems Architecture is a unique Architekturbereich that aligns functionality, data, und data management. In practice, this means ensuring that applications are delivering the required data flow and data management, not just delivering features.
Common practice pushes data architecture to the background. We obsess about features and talk about applications — what they do, how they’re built, or how they integrate with other systems.
Applications exist to process and manage data. Without a solid understanding and design of Data Architecture, applications become disconnected islands. As they deliver features, they deliver technical debt. They create complexity in data flow and data management. Complex data flow and data management accelerate your technical debt, and add complexity to data governance.
When you lead with data , and ensure the Anwendungsarchitektur is focused on the structure and interaction of the applications that ... manage the data assets, you have an information systems architecture.
No successful digitale Transformation will be built on functionality. They are always built on data.
Laden Sie den KI-Leitfaden für Führungskräfte herunter
Laden Sie den Leitfaden für Führungskräfte zur künstlichen Intelligenz herunter. Organisationen, die innovative Technologie erfolgreich anwenden, haben einen Wettbewerbsvorteil. Innovative Technologie geht nicht mit etablierten Erfolgsmustern und Best Practices einher. Innovative Technologie ist neuartig und […]
Laden Sie die Einführung in den TOGAF-Standard, 10. Ausgabe, herunter
Herunterladen Einführung in den TOGAF®-Standard, 10. Ausgabe Der TOGAF-Standard, 10. Ausgabe, erleichtert die Einführung von Best Practices für Unternehmensarchitekturen. Es trennt die universellen Konzepte von bewährten Best Practices. Der Standard-Unterstrich wo […]
Laden Sie den Leitfaden zur fähigkeitsbasierten Planung herunter
Laden Sie den Leitfaden zur fähigkeitsbasierten Planung herunter. Streben Sie stets danach, Werte zu realisieren. Eine halbe Verbesserung ist 100% Verschwendung! Niemand bringt einem Adler das Krabbeln, Gehen oder Laufen bei. Adler fliegen! Laden Sie „Teach your Eagles to Fly: Capability-based Planning“ herunter […]
Laden Sie den Leitfaden zur Bewertung der Geschäftsarchitektur herunter
Leitfaden zur Bewertung der Geschäftsarchitektur herunterladen Laden Sie einen Leitfaden zur Bewertung der Geschäftsarchitektur herunter. Die fähigkeitsbasierte Planung ist eine der leistungsstärksten Techniken zur Verbesserung der Geschäftsarchitektur. Best Practice der fähigkeitsbasierten Planung nutzt Fähigkeit als Management […]
Laden Sie Beispiele für Prinzipien der Unternehmensarchitektur herunter
Beispielprinzipien für die Architektur herunterladen Laden Sie ein Beispiel für Prinzipien der Unternehmensarchitektur herunter. Die Prinzipien der Unternehmensarchitektur legen fest, wie man ein Problem oder eine Entscheidung angeht. Der Ansatz treibt Sie immer zu Ihren dauerhaften Prioritäten. Beispielprinzipien der Unternehmensarchitektur herunterladen […]
Laden Sie den Governance-Leitfaden für Unternehmensarchitekturen herunter
Leitfaden zur Unternehmensarchitektur-Governance herunterladen Laden Sie den Leitfaden zur Unternehmensarchitektur-Governance herunter, um Best Practices zur Lenkung und Kontrolle der Entwicklung von Architekturen und Änderungen zu verstehen, um die erwarteten Ergebnisse zu erzielen. Governance-Leitfaden für Unternehmensarchitektur herunterladen […]
Laden Sie die TOGAF- und SABSA-Integration herunter
TOGAF- und SABSA-Integration herunterladen Bringen Sie SABSA, das weltweit beste Sicherheitsarchitektur-Framework, und TOGAF, das Industriestandard-Unternehmensarchitektur-Framework, zusammen. TOGAF- und SABSA-Integration herunterladen TOGAF- und SABSA-Integration Beinhaltet SABSA verwendet ein […]
Laden Sie die Enterprise Architecture Capability Reference Architecture herunter
Laden Sie die Referenzarchitektur „Enterprise Architecture Capability“ herunter. Die Referenzarchitektur „Enterprise Architecture Capability“ beschleunigt den Aufbau und die Weiterentwicklung Ihres EA-Teams. Gestalten Sie Ihr Enterprise-Architecture-Team für den Erfolg. Identifizieren und verbessern Sie die Architektur Ihres Unternehmens […]
Laden Sie den Agile Enterprise Architecture Report herunter
Laden Sie den Agile Enterprise Architecture Report herunter Der Agile Enterprise Architecture Report deckt unsere Erfahrung ab – Agile Enterprise Architecture ist real, praktisch und wertvoll. Wir tun es jeden Tag. Erfahrungsberichte überbrücken die theoretischen Konzepte und […]
Fallstudie zur agilen Unternehmensarchitektur herunterladen
Laden Sie die Fallstudie „Agile Unternehmensarchitektur“ herunter Laden Sie die Fallstudie „Agile Unternehmensarchitektur“ herunter, um ein Beispiel für die gleichzeitige Entwicklung einer EA-Fähigkeit und einer nützlichen Architektur zu sehen. Wir decken alle sechs Anwendungsfälle ab […]
Four Elements of Data Architecture
Every data architecture will address:
By themselves these elements help us understand the structure of the data.
We are chasing an understanding of data flow. Data flow is explained by data sources and data needs are the bookends of data flow—where it comes from, and where it is needed.
Keep in mind that once data starts moving it can go anywhere. Flow requires controls; it requires data management resources.
We know that data architecture steers great Unternehmensstruktur. It can only steer if you know the data flow. Required data flow mandates how application architecture] and infrastructure architecture enable your Geschäftsarchitektur.
Data Needs
Everything starts with the data needs of the enterprise.
Data needs fall into three categories:
- Daten needed to create products and services: Information your products and services depend on.
- Daten needed to operate the business: Transactional, operational, and process data that keep day-to-day activities running smoothly.
- Daten needed to maintain records:** Contractual and regulatory defined information necessary for compliance.
Do not get confused about data needs — you must ruthlessly separate what’s nice to have from what’s needed.
Needed does not require modifiers like absolutely, or important. Needed is simply necessary.
Major Sources of Data
Where data is created, or collected, and where it is transformed. Data comes from manual processes, applications, devices, and external partners. Understanding the source system is central to data quality, lineage and governance.
Major Types of Data
Identifying key data categories relevant to your business—customer, product, financial, operational, and so forth. This classification helps focus architectural efforts and governance.
Usually the major types of data are defined in the Subjektmodell
Data Management Resources
Tools and systems that deliver the needed data where, when, how, with the right quality, confidence and security. In practice these are a broad set of requirements directed at the application and infrastructure architectures.
Enterprise Architecture Training und TOGAF Training
Avolution ABACUS-Schulungskurs
Avolution ABACUS Training Effektive Unternehmensarchitektur basiert auf formaler Modellierung und Analyse. Wir bieten Avolution ABACUS-Schulungen von praxisorientierten Unternehmensarchitekten an. Die Studierenden erwerben Fähigkeiten und Kenntnisse zur Erstellung integrierter Unternehmens- und Domänenarchitekturen in diesem […]
Kickstart für Enterprise-Architekten
Kickstart für Enterprise-Architekten Wir müssen unsere Fähigkeiten auf dem neuesten Stand halten. Jetzt mehr denn je. Nutzen Sie den Enterprise Architecture Kickstart, um Ihre Fähigkeit zu verbessern, transformative Unternehmensarchitektur bereitzustellen. Dieser 90-tägige Kickstart ist der Weg, den Conexiam Consulting […]
Schulungskurs für Unternehmensarchitektur
Business-Architektur-Schulung Effektive Unternehmensarchitektur basiert auf der Geschäftsarchitektur. Der Kurs vermittelt den Studierenden die Fähigkeiten und das Wissen, um eine Geschäftsarchitektur in einer Unternehmensarchitekturumgebung zu entwickeln. Bei der Geschäftsarchitektur geht es um die Beschreibung der Struktur des […]
Benutzerdefinierte Schulung für Unternehmensarchitektur
Maßgeschneiderte Schulungen zu Unternehmensarchitekturen Maßgeschneiderte Schulungen zu Unternehmensarchitekturen zielen auf die berufliche Weiterentwicklung ab, die Ihr EA-Team benötigt. Gute Unternehmensarchitekten verwenden ein breites Spektrum an Fähigkeiten und Methoden sowie spezialisiertes Domänenwissen, um Unternehmen zu entwickeln […]
TOGAF-Schulungskurs für Unternehmensarchitektur
Möchten Sie eine Schulung zur TOGAF-Zertifizierung? Demonstrieren Sie Ihr Wissen über Unternehmensarchitektur mit der TOGAF-Zertifizierung. TOGAF® Enterprise Architecture-Schulungskurs Machen Sie einen großen Schritt, um ein besserer Unternehmensarchitekt zu werden mit TOGAF Standard, 10. […]
Effektive Online-Bildung
Effektive Online-Bildung Effektive Online-Bildung funktioniert. Studenten haben Zugang zum besten verfügbaren Lehrer. Studenten bestimmen ihr Lerntempo. Lehrer können reichhaltiges Zusatzmaterial bereitstellen, ohne vom Hauptthema abzulenken. Effektive Distanz […]
Data Architecture Model Kinds
Navigate Data Architecture Model Kinds
Navigieren provides an end-to-end enterprise architecture landscape. This is a specific way of saying we work towards an end-to-end model architecture model.
We develop the EA Landscape following the best practice of incrementally extending it one architecture project at at time.
We manage the enterprise model through discrete _model kinds._ A model kind can support specific analysis, or focus on a separate aspect of the end-to-end model. In simple terms, a model kind refers to the conventions for a specific type of modelling.
Each model kind is optimized to tell us something about the architecture.
Different model kinds will explore:
- motivation and strategy
- parts of an architecture domain
Using model kinds drive consistency and re-usability driving productivity and consistency across an EA Team.
Navigate Model Kind Description
Each model kind is defined by:
- Purpose: Why this model kind exists and what questions it's intended to answer.
- Zielfernrohr: Outlining the boundaries of what’s included and excluded within the model kind.
- Content & Structure: The components, relationships, and properties that should be used when creating instances of a model kind.
- Modelling Approach: Guidance on how what is included or excluded to focus on specific aspects relevant to the objectives.
- (Optional) Relationship with other Model Kinds: Describes the purpose of the link and what relationship is used to bridge the two models.
Enterprise Data Model Notes
We draw Navigate's data model kinds from DAMA's The Enterprise Data Model. The Enterprise Data Model is comprised of the Subjektmodell, Subject Area Model (SAM), und Logical Data Model (LDM). Both the SAM and LDM are built from the Subjects. They serve distinct, but interconnected, purposes.
Der Subjektmodell describes the organization's data landscape. Every Subject is meaningful to the data landscape.
Der Themenbereichsmodell Ist business-centric view. It’s about understanding a specific business domain - a "Subject" - in detail. The SAM defines Subject in a way that’s readily understandable by business stakeholders. It’s a narrative of the data, focusing on what it means.
Der Logical Data Model, is a technically-oriented. It builds upon the SAM, transitioning from the SAM's business concepts into sufficient detail to guide implementation.
Together the SAM and the LDM speak to two distinct audiences. The SAM reflects the business understanding of the data's meaning. The LDM is guidance and constraint for the implementation. This frame is often documented in a Master Data Blueprint.
The SAM and LDM reflect the same Subject, speaking to different audiences.
Subjektmodell
Subject Model Scope
Subject model identifies business relevant information areas
Each Subject identifies the information needed in an area of activity or a distinct aspect of operations
Provide a shared understanding of the data landscape
Used to
- Frame discussions about the data landscape
- Highlight areas of data complexity
- Direct further modelling
Subject Model Guidance
Enterprise-wide
- 12-20 Subjects
Department-wide Architecture project
- Expect 3-5 Subjects
Transformation Initiative
- Expect 5-10 Subjects
Themenbereichsmodell
The Subject Area Model Kind (SAM) represents the information within a single Subject. The SAM is used to ensure a common understanding of the understanding of the data landscape.
The purpose is clear - develop an understanding of the data landscape.
DAMA tells us to think about the Entities and attributes hat define the information in a Subject. Entities have relationships with other Entities. Relationships with the Subject, and between Subjects.
Subject Area Model Guidance
The Subject Area Model uses 8-15 Business Terms (Entities) to define the Subject. Expect 1-2 Business Terms from from another subject, to complete the understanding of the Subject.
Aim for a sweet spot of ~13 Business Terms. You must keep the model manageable.
As you approach 12 Business Terms consider whether you have more than one subject
Less than 8 Business Terms suggest this might not be a deep, or important Subject.
Logical Data Model
The Logical Data Model Kind Kind (LDM) represents the information within a single Subject with the intention of guiding and constraining implementation. The LDM is used to ensure a consistent technical handling of the data landscape.
The purpose is clear - guiding implementation to ensure the data landscape enables the business' data needs.
Logical Data Model Guidance
The Logical Data Model uses 12-20 Logical Data Components (Entities). Expect 3-5 Logical Data Components from from another subject.
The LDM muss include cardinal relationships, properties, and data access and data management architecture specifications
Logical Data Properties
Data Access
-
- Does this Entity have specific access constraints
Data Classification
-
- What class of data is it? (Master, Reference, Transactional)
Data Retention
-
- Does it have special retention requirements? Where do these requirements come from?
Data Type
-
- What type of data is it? (Number, text, boolean, calculated)
Data Protection Property (Optional)
-
- Does the data have unexpected protection requirements?
Logical Document Model
The Logical Document Model Kind exists to represent artifacts—such as forms, letters, or reports—relevant to a specific business activity (e.g., Quotation, Sales Order, Invoice, Bill of Lading, Job Application).
It provides context for data, facilitating understanding of data security, retention, flow, and governance. For example, data entities such as price do not convey retention or security requirements, whereas documents like the Quotation, Sales Order, und Invoice provide that context.
Logical documents cover three document types:
- Record: Documents mandated by law or contract, with externally defined content and retention requirements.
- Business Document: Documents internally defined to support business processes, governed by organizational policies for consistency and auditability.
- Transitory Document: Informal documents created and used by individuals or teams, with retention managed by internal policies and aligned to creator needs.
Logical Document Model Guidance
The Logical Document Model is easiest when an end-to-end business process is considered. End-to-end processes will use 3-10 Logical Documents.
Aim for a sweet spot of ~6 Logical Documents. You are looking for a complete list of Records, and a useful list of Business Documents und Transitory Documents to capture retention, security and quality.
Each Logical Document will contain 5-10 Business Terms or Logical Data Components.
Logical Document Properties
Document Type
-
- Record, Business Document, Transitory
Data Access Property
-
- Country-only, Organization Only, Department Only, Process Only, or Custodial Data
Data Retention Property (Optional)
-
- Ad Hoc, Departmental, Enterprise, Contract, Regulated, or Prohibited
Data Protection Property (Optional)
-
- - Relaxed, Standard, Enhanced
Gehen Sie noch einen Schritt weiter mit Best Practice-Prozessen und -Methoden für die Unternehmensarchitektur
Beste Übung Unternehmensstruktur aus Conexiam navigieren
Entdecken Sie die Leistungsfähigkeit von Unternehmensarchitekturmustern
Entdecken Sie die Leistungsfähigkeit von Unternehmensarchitekturmustern: Ein umfassender Leitfaden Jedes Unternehmen möchte sich verbessern. Optimieren Sie ihre Abläufe. Verbessern Sie die Agilität Ihres Unternehmens. Stimmen Sie den Wandel auf Ihre Strategien ab. Erfolgreich bei der digitalen Transformation. Unternehmensarchitektur, eine Disziplin […]
Einrichten eines Prüfungsgremiums für moderne Architektur
Einrichten eines modernen Architekturprüfungsgremiums Um ein modernes Architekturprüfungsgremium einzurichten, ist die Schaffung eines dynamischen Governance-Prozesses und die Einrichtung eines Entscheidungsgremiums auf höchster Ebene erforderlich, das als Rückhalt fungiert. Ziel ist die Einrichtung einer effektiven Architektur-Governance ohne Bürokratie. […]
Erschließen Sie Ihr Geschäftspotenzial: So erstellen Sie eine effektive Fähigkeitskarte
Erschließen Sie Ihr Geschäftspotenzial: So erstellen Sie eine effektive Fähigkeitskarte. Fällt es Ihnen schwer, die Fähigkeiten zu identifizieren, die Sie benötigen, um Ihr Unternehmen auf die nächste Stufe zu bringen? Finden Sie es schwierig, Ressourcen aufeinander abzustimmen?
Arbeitsmanagement für die Unternehmensarchitektur
Enterprise Architecture Work Management Enterprise Architecture Work Management ist entscheidend für den täglichen Erfolg eines Enterprise Architecture-Teams. Architekten müssen nützliche Anleitungen liefern, bevor die Beteiligten fundierte Entscheidungen treffen. Enterprise-Architekten müssen die […]
Unternehmensarchitektur-Roadmap als Design
Enterprise Architecture Roadmap als Entwurf Eine Architecture Roadmap ist ein Planungstool, das den Entscheidungsträgern einer Organisation hilft. Eine dynamische Architecture Roadmap soll ihnen dabei helfen, den besten Weg nach vorne zu entwickeln und zu beschreiten. Sie […]
Entwicklung einer Architekturansicht
Die Entwicklung einer Architekturansicht Die Unternehmensarchitektur ist ein wesentlicher Kompass. Es hilft Unternehmen, die Komplexität von Technologie, Strategie und Betrieb zu bewältigen. Der Kern der Unternehmensarchitektur ist ein systematischer Ansatz. Ziel ist es sicherzustellen, dass […]
Szenarioanalyse für die Unternehmensarchitektur nutzen
Szenarioanalyse für die Unternehmensarchitektur verwenden Ein Szenario ist einfach eine plausible Zukunft. Die Szenarioanalyse untersucht, wie wir zu einer plausiblen Zukunft gelangen und wie sich unterschiedliche Szenarien auf unsere aktuellen Entscheidungen auswirken. Szenarien helfen Führungskräften […]
Alles, was Sie über die Verwendung von Architekturalternativen wissen müssen
Alles, was Sie über die Verwendung von Architekturalternativen wissen müssen Architekturalternativen sind für eine gute Entwicklung von Unternehmensarchitekturen erforderlich. Wenn Sie mit der Architekturentwicklung beginnen, weist Ihr Unternehmen Mängel auf. Es gibt Bereiche für Verbesserungen. Du musst […]
So definieren Sie Prinzipien der Unternehmensarchitektur
So definieren Sie Prinzipien der Unternehmensarchitektur Um Prinzipien der Unternehmensarchitektur zu definieren, müssen Sie zunächst verstehen, was ein Prinzip ist und wie man es anwendet. Dann können wir starke Architekturprinzipien entwickeln, die dazu beitragen, unsere Organisation zu verbessern. […]
Intelligentere Entscheidungen treffen: Warum Ihr Unternehmen architektonische Entscheidungen benötigt
Intelligentere Entscheidungen treffen: Warum Ihr Unternehmen architektonische Entscheidungen braucht Unternehmen stehen ständig vor der Herausforderung, wichtige Entscheidungen zu treffen. Jeden Tag haben Entscheidungen, einschließlich betrieblicher Praktiken und Technologieauswahl, erhebliche Auswirkungen auf ein […]
Everything Revolves Around Data Needs
Let's clarify about data needs— you must ruthlessly separate what’s nice to have from what’s needed.
Needed data does not require modifiers like absolutely needed, or important data. Needed is simply necessary.
The clear distinction between needed und everything else is the foundation for effective application requirements.
Once you know that a business activity needs some data everything else emerges:
- source
- flow
Needed data defines where the flow must get to. - quality
Needed data defines quality. - security
Security doesn't define where data can go. Needed data goes where it is needed. Needed data defines where the data muss be securely delivered, and where it must be secured. - data management
Need + quality + flow + security define the data management resources required
Source is a challenge— especially when the provider and consumer are in different organizations or authority, or governance domains. We often imagine that data consumers define quality. They don't. Data producers define quality.
Consumers can request higher quality, but they may be faced with three choices:
- pay more
- do without
- improve the quality themselves
This is no different than any other producer/consumer relationship.
Remember:
Data needs drive a path through fractured data landscapes.
Data needs break silos.
Data needs drive real data definitions
Data needs deliver data governance.
Workshop zur Fähigkeit zur Unternehmensarchitektur
Enterprise Architecture Capability Workshop Der Enterprise Architecture Capability Workshop beginnt mit Ihrem Enterprise Architecture-Anwendungsfall und entwickelt einen Verbesserungsfahrplan für Ihr EA-Team. Das Ergebnis des Enterprise Architecture Capability Workshops ist ein entworfener EA […]
Workshop zum Engagement von Interessengruppen
Stakeholder Engagement Workshop Stakeholder Engagement Workshops stellen Ihre Architekturentwicklung auf eine solide Basis. Verstehen Sie Ihre wichtigsten Stakeholder, ihre Anliegen, wie Sie sie einbinden und wie Sie kommunizieren. Holen Sie sich Hilfe, um noch heute mit dem Stakeholder Engagement Workshop zu beginnen […]
Initiative-Strategie-Workshop
Workshop zur Initiativenstrategie In Workshops zur Initiativenstrategie wird eine Strategie für eine Initiative entwickelt. Wird für neue Initiativen und Initiativen verwendet, die ins Stocken geraten sind. Verstehen Sie, welche Maßnahmen zur Erreichung des Ziels zur Verfügung stehen. Seien Sie in der Lage, die […]
Workshop zur Unternehmensarchitektur-Governance
Enterprise Architecture Governance Workshop Enterprise Architecture Governance Workshops stellen sicher, dass Ihr Architekturprojekt und Ihr Implementierungsprojekt über die Architektur-Governance verfügen, die Sie zum Erfolg brauchen. Sie haben keine Zeit für fehlgeschlagene Verbesserungsbemühungen. Enterprise Architecture Governance […]
Szenariobasierter Architektur-Roadmap-Workshop
Szenariobasierter Architektur-Roadmap-Workshop Szenariobasierte Architektur-Roadmap-Workshops entwickeln mögliche Architektur-Roadmaps mithilfe von Szenarioanalysen. Szenarioanalysen in Verbindung mit Architektur-Roadmaps sind leistungsstarke Tools, wenn sie früh in der Architekturentwicklung eingesetzt werden. Wenn Sie […]
Conclusion of What is Data Architecture?
Data architecture leads Architektur von Informationssystemen. Information Systems Architecture is the Architekturbereich that aligns data, data management, und functionality.
Data architecture is explains and enables the data needs of the enterprise through four elements—data needs, major sources of data, major types of data, and the required data management resources.
Four Modelle der Unternehmensarchitektur describe your data architecture: the subject model, subject area model, logical data model, und logical document model.
Common practice pushes data architecture to the background, and puts the spotlight on applications — what they do, how they’re built, or how they integrate with other systems.
Best practice leads with data, and ensures the Anwendungsarchitektur is focused on the structure and interaction of the applications that ... manage the data assets.
No successful digitale Transformation will be built on functionality. They are always built on data.
