How the organisation's data models, schemas, integration standards, and storage placements conform to defined architecture standards and support interoperability.
ARC-01
Adherence to enterprise data architecture standards and data modelling conventions
How consistently do the data models, schemas, and structures used in your domain conform to the organisation's defined data architecture standards and modelling conventions?
Maturity level descriptions
No enterprise data architecture standards exist, or if they exist, domain data structures are built with no reference to them. Data models and schemas in the domain are designed ad hoc, based on individual preference or immediate need, with no reference to any standard.
Standards exist but are inconsistently applied; some domain data structures loosely follow convention, others do not, with no mechanism to check conformance. Data Engineer is aware standards exist but cannot confirm which domain data structures actually conform, since no review has taken place.
Domain data structures are checked against defined architecture standards at the point of creation or major change, using a documented review step. Data Engineer participates in or requests a standards conformance check (e.g. schema review, naming convention check) when a new dataset or major structural change is introduced.
Conformance to architecture standards is tracked across all domain data structures, with non-conformance logged as remediation debt and progressed on a defined cycle. Data Engineer maintains or contributes to a tracked conformance register for the domain, with identified deviations assigned as remediation items with owners and timelines.
Conformance to architecture standards is enforced automatically (e.g. schema validation, automated linting against modelling conventions) at the point of data structure creation or deployment. Automated tooling checks new or changed data structures against architecture standards before they go live, blocking or flagging non-conformant structures without relying on manual review.
ARC-02
Integration and interoperability of domain data flows
How well do the data flows into and out of your domain's datasets (APIs, file transfers, event streams, integrations with other systems) conform to defined organisational integration standards and support interoperability with other domains?
Maturity level descriptions
Data flows into and out of the domain use whatever method was expedient at the time, with no reference to any integration standard; interoperability with other domains is accidental at best. Integrations are built point-to-point, ad hoc, using inconsistent formats and methods, with no consideration of how other domains might need to consume the same data.
Awareness exists that integration standards should be followed, but domain data flows are a mix of standard-conformant and legacy, non-conformant methods. Data Engineer is aware some data flows follow standard patterns (e.g. a defined API format) while older ones do not, with no plan to reconcile this.
New domain data flows are built to conform to defined integration standards (common formats, defined API patterns, agreed protocols), documented for each integration point. Data Engineer can point to documentation for the domain's data flows showing the standard, format, or protocol used for each integration point.
Domain data flows are systematically reviewed for interoperability, with integration standards conformance tracked and non-conformant legacy flows scheduled for remediation. Data Engineer's domain maintains an inventory of integration points with conformance status, and legacy non-conformant flows are tracked as planned remediation work.
Domain data flows are built on a shared, self-describing integration layer (e.g. managed API gateway, event bus with schema registry) that enforces interoperability by design, with real-time visibility into flow health and conformance. New integrations are built directly on managed, standards-enforcing infrastructure, with automated monitoring of flow health and conformance rather than manual documentation and review.
ARC-03
Documentation of data models, schemas, and lineage
How complete, accurate, and accessible is the documentation of your domain's data models, schemas, and data lineage (where data comes from, how it's transformed, and where it goes)?
Maturity level descriptions
No documentation exists for domain data models, schemas, or lineage; understanding of data structure and flow relies entirely on individual knowledge. Data models and lineage exist only in the heads of whoever built them, with nothing written down or discoverable by others.
Some documentation exists in scattered, informal locations (personal notes, old emails, outdated wikis), inconsistent and largely out of date. Data Engineer can locate fragments of documentation, but it is inconsistent, hard to find, and not reliably kept current.
Domain data models, schemas, and basic lineage are documented in a defined, centrally accessible location, covering at least priority datasets. Data Engineer maintains or has access to structured documentation (e.g. in a data catalogue) covering schema definitions and basic lineage for the domain's priority datasets.
Documentation covers all domain datasets (not just priority ones), including detailed lineage (transformations, source systems, Data Consumers), and is kept current through a defined maintenance process. Data Engineer follows a defined process (e.g. documentation updated as part of change management) ensuring full-domain coverage and detailed lineage remain accurate over time.
Data models, schemas, and lineage are captured and maintained automatically (e.g. via automated lineage tracking tools integrated with pipelines), with documentation always reflecting the current state without manual upkeep. Lineage and schema documentation update automatically as pipelines and structures change, with no reliance on Data Engineers remembering to update documentation manually.
ARC-04
Fit-for-purpose data storage and platform placement
How well does the placement of your domain's data (which storage platform, tier, or technology it resides in) match its actual usage patterns, performance needs, and cost/value profile?
Maturity level descriptions
Data is stored wherever it happened to land historically, with no assessment of whether the platform or tier is appropriate for its usage pattern, performance need, or value. Storage decisions were made once, long ago or by default, and have never been revisited against actual usage.
An informal sense exists that some data is "in the wrong place" (e.g. too expensive for how rarely it's used, or too slow for how often it's queried), but nothing has been evaluated or acted on. Data Engineer has an informal suspicion about poor-fit storage placement but has not requested or conducted a formal assessment.
A defined process exists for assessing whether domain data is placed appropriately (tiering criteria, cost/performance review), applied to at least priority datasets. Data Engineer has participated in or requested a storage placement review for priority datasets, using defined criteria (access frequency, performance requirements, cost).
Storage placement across the domain's full dataset inventory is systematically reviewed on a defined cycle, with mismatches tracked as migration/optimisation actions. Data Engineer's domain has a tracked register of storage placement reviews, with identified mismatches assigned as remediation actions with owners and timelines.
Data is automatically or near-automatically moved between storage tiers/platforms based on real usage patterns, with continuous monitoring ensuring placement stays fit-for-purpose without manual review. Automated tiering or lifecycle policies move domain data between storage options based on observed access patterns, with no reliance on manual periodic review to catch mismatches.
ARC-05
Feedback loop from domain to architecture evolution
When your domain encounters real-world architecture constraints, technical debt, or friction (e.g. a data model that doesn't fit actual business needs, a slow or brittle integration, a platform limitation), how effectively does that experience feed back into and shape the organisation's data architecture roadmap?
Maturity level descriptions
No mechanism exists for domain-level architecture issues to reach architecture owners; problems are worked around locally and never inform the broader architecture roadmap. Data Engineer or domain team members build informal workarounds for architecture limitations without reporting the underlying issue anywhere.
Issues are occasionally raised informally to an architect or technical contact, with no consistent process and no visibility into whether anything changes as a result. Data Engineer has, at least once, informally flagged an architecture constraint or friction point to someone involved in architecture decisions.
A defined channel exists (e.g. an architecture review forum, a technical debt backlog) that Data Engineers are expected to use to raise domain-level architecture issues. Data Engineer has used a specific, named mechanism to report a domain architecture issue or technical debt item.
Domain architecture issues are logged, tracked, and reviewed as part of a defined process, with outcomes reported back to the reporting Data Engineer and reflected in architecture planning. Data Engineer receives confirmation and status updates on reported architecture issues, and can see whether/how the issue influenced the architecture roadmap or backlog prioritisation.
Domain-level architecture experience is treated as a primary, proactively-sought input to architecture evolution, with structured mechanisms ensuring lessons are captured and applied continuously. Data Engineer is proactively consulted as part of architecture roadmap planning or retrospectives, and can see direct, documented evidence of domain experience shaping architecture decisions.
ARC-06
Architecture readiness for AI/GenAI data patterns
How well does your domain's data architecture support the structures and access patterns AI/GenAI initiatives actually need (e.g. vector embeddings, feature stores, unstructured/semi-structured data, retrieval-optimised storage), as opposed to only traditional relational/tabular patterns?
Maturity level descriptions
Domain architecture supports only traditional data patterns; no consideration has been given to AI-native structures such as vector stores, embeddings, or feature stores. Domain data exists only in traditional relational/tabular form, with no capability or plan to support AI-specific access patterns.
Awareness exists that AI initiatives will need different data patterns, but nothing has been built; any AI-specific structures that exist were created ad hoc, outside standard architecture. Data Engineer is aware AI projects have requested or built one-off AI-specific data structures (e.g. a project-level vector store) outside the domain's standard architecture.
Defined architecture patterns exist for at least one AI-specific data structure type (e.g. an approved vector store or feature store platform) and are used for new AI initiatives touching the domain. Data Engineer can point to a named, approved AI-native data structure or platform used when a new AI initiative needs domain data in that form.
AI-native data structures are systematically provisioned as part of standard architecture, with domain data made available in AI-ready form (embeddings, feature sets) as a managed, tracked capability. Data Engineer's domain has a tracked inventory of AI-ready data assets (e.g. which datasets have embeddings or feature-store representations maintained), reviewed and kept current.
AI-native data structures are generated and kept current automatically as source data changes (e.g. embeddings regenerated on data update, feature stores auto-refreshed), fully integrated into standard architecture rather than treated as a separate concern. Automated pipelines keep AI-ready representations of domain data (embeddings, features) synchronised with source data changes, with no manual regeneration required.
ARC-07
Integration and interoperability of domain data with AI/ML pipelines and platforms
How well do the connections between your domain's data and AI/ML pipelines, model-serving platforms, or GenAI tools (RAG systems, agent frameworks, model training pipelines) conform to defined integration standards?
Maturity level descriptions
Domain data reaches AI/ML pipelines and tools through whatever ad hoc method was convenient (manual exports, one-off scripts, direct database access), with no defined integration standard. Data is pulled into AI pipelines through informal, undocumented means, often bypassing standard integration layers entirely.
Some AI/ML integrations use standard methods, others use ad hoc workarounds, with no consistency and no plan to reconcile the two. Data Engineer is aware some AI pipeline connections follow standard integration patterns (e.g. a defined API) while others were built as one-off workarounds.
New connections between domain data and AI/ML pipelines are built to conform to defined integration standards (APIs, data contracts, agreed retrieval methods), documented per connection. Data Engineer can point to documentation for the domain's AI/ML integration points showing the standard, format, or protocol used.
AI/ML integration points are systematically tracked for conformance, performance, and reliability, with legacy or non-conformant connections scheduled for remediation. Data Engineer's domain maintains an inventory of AI/ML integration points with conformance and reliability status, with remediation tracked for problem connections.
Domain data is exposed to AI/ML pipelines through a managed, self-describing integration layer (e.g. a governed feature/retrieval API) that enforces standards by design, with real-time monitoring of integration health. AI/ML pipelines consume domain data exclusively through managed, standards-enforcing infrastructure, with automated health and conformance monitoring rather than manual tracking.
ARC-08
Lineage and documentation of data used in AI/GenAI initiatives
How completely and accurately can you trace which of your domain's datasets have fed into which AI/GenAI models, prompts, retrieval systems, or agents — and, conversely, trace a given AI output back to the domain data that informed it?
Maturity level descriptions
No lineage tracking exists connecting domain data to AI/GenAI usage; there is no way to determine which datasets have been used in which AI initiatives. Once data is used in an AI project, no record is kept of that usage, and there is no way to trace an AI output back to its data source.
Some informal knowledge exists about which datasets have been used in AI projects (e.g. from memory or informal conversation), but nothing is documented. Data Engineer can informally recall that a dataset was used in a particular AI project, but this exists only as personal knowledge, not a record.
AI/GenAI data usage is documented for at least priority datasets or major AI initiatives, recording which datasets fed which models, prompts, or systems. Data Engineer maintains or has access to a record showing, for at least the domain's priority AI-related data usage, which dataset fed which AI initiative.
AI/GenAI data lineage is tracked comprehensively across all domain datasets used in AI initiatives, including transformation steps (e.g. chunking, embedding, feature engineering), and is kept current through a defined process. Data Engineer's domain maintains comprehensive, current AI-specific lineage records covering all relevant datasets and the transformations applied before AI use.
AI/GenAI lineage is captured automatically end-to-end (from source dataset through transformation, embedding, and model/prompt use, to output), enabling real-time traceability of any AI output back to its underlying domain data without manual investigation. Automated lineage tooling captures the full chain from domain data through AI processing to output, allowing any AI-generated result to be traced back to source data on demand.