ASSESSMENT

Data Architecture Maturity Assessment

24 questions · ~12 minutes

Evaluate how future-proof your data architecture is across six dimensions: business alignment, design methodology, metadata and lineage, automation, governance, and adaptability. Based on leading practice guidance from WhereScape.

Progress0 of 24 answered

Save your progress

Foundation & Structure

1How is your analytical data layer primarily structured?

Our tables mirror source system structures with minimal transformationA mix of source-aligned copies and some business-modelled entitiesMostly business entities, but some areas still follow source system designAll layers are modelled around stable business concepts, independent of source systems

2When two teams ask about the same concept (e.g. 'active customer'), what typically happens?

Each team uses their own version — definitions differ across reportsThere is usually debate about which version is correctWe have a shared definition but not all reports apply it consistentlyA single governed definition exists and is applied consistently across the organisation

3How are business rules (e.g. how revenue is calculated, how customers are counted) captured and stored?

Embedded in SQL views and reports — largely undocumentedIn a separate document or wiki, but often outdatedReasonably documented and linked to specific modelsVersion-controlled, always current, and traceable to the data that uses them

4When a source system changes its structure (e.g. a column is renamed or split), what is the typical impact on your platform?

It breaks multiple downstream models and takes significant time to fixIt requires updates in several places with moderate effortThe impact is generally contained to the ingestion layer with minor downstream effectsSource changes are absorbed at the integration layer with no downstream disruption

Integration & Design Patterns

5How would you describe your data warehouse or lakehouse design methodology?

No formal methodology — designs are created on a case-by-case basisAn informal approach that varies between developers and projectsA defined methodology exists but is applied inconsistentlyA consistent, documented methodology is applied across all projects

6How many different design patterns exist for similar work types (e.g. loading a daily transaction feed)?

Almost every developer has a different approach — no standard existsSeveral patterns — there is overlap but no single standardTwo or three approaches — consolidation is underwayOne standard pattern — all similar work follows the same design

7How well does your architecture handle integrating multiple source systems describing the same concept (e.g. customer from CRM, ERP, and web)?

We struggle — each integration is solved differently and creates duplicationWe manage it but with significant manual effort and some inconsistencyWe have a reasonably structured approach but it doesn't scale effortlesslyOur architecture is designed for multi-source integration with clear entity resolution patterns

8How well does your architecture support applying new business rules to historical data?

It can't — historical data is overwritten and cannot be reprocessedPartial reprocessing is possible but it's complex and riskyKey datasets can be reprocessed but it requires significant effortHistorical reinterpretation is a designed capability — raw history is always preserved and re-runnable

Metadata & Documentation

9How is metadata (table descriptions, column definitions, data ownership) managed?

Mostly undocumented — it lives in people's headsDocumented informally in spreadsheets or wikis, rarely kept up to dateCaptured in a data catalogue or tool but not fully adoptedActively maintained in a metadata platform integrated with development workflows

10How confident are you in the completeness of your data lineage (how data flows from source system to report)?

Not confident — we have no lineage documentationPartial confidence — lineage is documented for some critical areas onlyReasonably confident — lineage is mostly captured but has gapsVery confident — end-to-end lineage is captured and kept current

11Before making a change to your data platform, how do you assess what will be affected?

We don't reliably — testing reveals the impact after the factWe ask around and manually trace code to estimate impactWe have partial impact analysis capability for key areasWe can perform confident impact analysis before making any change

12How current and accurate is your data documentation?

Severely out of date — it describes how things used to workPartially current — some areas are well-documented, others are notMostly current — updated during delivery but not always consistentlyAlways current — documentation is a mandatory, automated part of every delivery

Automation & Operational Efficiency

13How are repetitive development patterns (e.g. loading a standard dimension or fact table) handled?

Everything is written from scratch — no templates or generators existSome templates exist but are not widely used or standardisedTemplates are in use but still require significant manual customisationAutomation or code generation handles the mechanical parts — developers focus on logic and exceptions

14How much of your team's time is spent on repetitive, low-value tasks (e.g. reformatting, renaming, moving data) versus higher-value design and analysis work?

The majority — automation is minimalA significant portion — some automation exists but it is limitedLess than half — automation covers the most common patternsA small fraction — most mechanics are automated, freeing capacity for strategic work

15When a new source system needs to be integrated, how long does it typically take from first access to the first usable model?

Months — every onboarding is effectively a standalone projectWeeks — some structure exists but it still takes considerable effortAbout a week — we have a reasonably efficient, structured processDays — standardised patterns and automation make onboarding rapid

16How are platform and infrastructure costs tracked and attributed?

Limited visibility — costs are rising but the drivers are unclearWe track total costs but struggle to attribute them to specific workloadsReasonable attribution for major workloadsDetailed cost visibility, workload-level attribution, and active optimisation

Governance & Standards

17How are data architecture design standards enforced?

They aren't — there are no formal standardsStandards exist on paper but compliance depends on individual disciplineStandards are reviewed during code review but not automatically enforcedStandards are embedded in tooling, templates, and automated checks

18How is new development reviewed and approved before it reaches production?

There is no formal review — changes are pushed when readyInformal peer review happens but is inconsistentA defined review process exists and is mostly followedA structured review and approval process is consistently applied to all changes

19How would you describe the culture around data quality and architectural discipline in your team?

It varies significantly — quality depends on who is doing the workThere is awareness but delivery pressure often overrides qualityQuality is valued and usually maintained — occasional pragmatic compromises are madeArchitectural discipline is a shared value — quality is non-negotiable and built into the process

20When a pipeline or data load fails, how is the root cause captured and used to improve the architecture?

It gets fixed and we move on — no formal process existsPost-mortems happen for major incidents but not consistentlyIncidents are usually documented and learnings are sharedAll incidents are documented, patterns are analysed, and the architecture is updated to prevent recurrence

Adaptability & Future Readiness

21If your organisation acquired a new company and needed to integrate their data, how prepared is your architecture?

It would be a major challenge — our architecture isn't designed for thisWe could do it but it would be a large, disruptive projectWe have integration patterns that would help, but it would still take significant effortOur architecture is specifically designed to absorb new sources without disrupting existing consumers

22How tied is your architecture to your current data platform or technology vendor?

Very tied — moving platforms would require a near-complete rebuildSignificantly tied — there is meaningful vendor-specific logic throughoutModerately tied — the core logic could be migrated with moderate effortLoosely coupled — the architecture is largely platform-agnostic and portable

23How does the time to deliver changes today compare to when your platform was first built?

Much longer — every change feels harder than the lastSomewhat longer — complexity is growing but still manageableAbout the same — the platform has scaled reasonably wellFaster — investment in patterns and automation means delivery accelerates over time

24How quickly can a new data consumer (a team, a product, or a BI tool) be onboarded to your data layer?

Slowly — there is no standard access layer and every new consumer requires custom workWeeks — discovery and access require significant hand-holdingA few days — there are standard interfaces and reasonable documentationQuickly — a governed, discoverable data layer with standard access patterns makes self-service realistic

Overall comments

Add any overall notes or context about your responses.

You can submit with unanswered questions - they will be counted as gaps.