How the organisation's data models, schemas, integration standards, and storage placements conform to defined architecture standards and support interoperability.
ARC-CON-01
Platform availability and performance
How reliably do the data platforms, reporting tools and systems you depend on perform when you need them — in terms of availability, speed and capacity at peak business times?
Maturity level descriptions
Platform performance and availability are unmanaged from the Data Consumer’s perspective; outages and slow performance are frequent, unexplained and unpredictable. The Data Consumer routinely cannot complete work because a report will not load or a system is down, with no explanation and no expectation of improvement.
Problems are addressed reactively once business users complain; there is no stated expectation of availability or performance. The Data Consumer reports a slow or unavailable system and it is eventually fixed, but nothing anticipates the problem or sets a service expectation.
Defined availability and performance expectations exist for business-facing platforms, are communicated to users, and outages are communicated through a defined channel. The Data Consumer knows what service level to expect and is notified through a defined channel when a platform is unavailable or degraded.
Availability and performance are measured against the stated expectations, reported, and capacity is planned against actual business demand including peaks. The Data Consumer experiences consistent performance at known peak periods because capacity is planned for them, and performance against expectation is reported.
Capacity and performance are managed proactively and elastically, scaled ahead of anticipated business demand, with degradation detected and addressed before users notice. The Data Consumer is rarely the first to know about a problem, and periods of unusual business demand are absorbed without perceptible degradation.
ARC-CON-02
Consolidated access to data
To what extent can you reach the data you need through a small number of consistent, integrated entry points, as opposed to navigating many disconnected systems, extracts and local copies?
Maturity level descriptions
Data is fragmented across disconnected systems and local copies; the Data Consumer must know which individual system or spreadsheet holds each piece of data. Work requires assembling information manually from several systems and personal files, with no integrated view available.
Some consolidation exists for a few high-profile areas, but most data still requires system-by-system access and manual assembly. The Data Consumer has one or two combined reports, but most questions still require going to individual source systems or asking for extracts.
A defined analytical or reporting environment consolidates the organisation’s priority data, and business users are directed to it as the standard route. The Data Consumer obtains most of their regular data needs from a defined central environment rather than from individual source systems.
Consolidated access covers the substantial majority of business data needs, is measured for coverage and adoption, and proliferation of local copies is actively managed down. The Data Consumer rarely needs a one-off extract, and the organisation tracks how much business data consumption flows through the consolidated environment.
Data is accessed through a governed, self-describing layer that integrates sources transparently, with new sources added without changing how business users work. The Data Consumer accesses new data through the same interface as existing data, with integration handled beneath the surface and no new tool to learn.
ARC-CON-03
Visibility of data origin
When you use a dataset or report, how easily can you establish where the underlying data actually comes from, how current it is, and what has been done to it along the way?
Maturity level descriptions
No origin information is available to business users; the Data Consumer cannot tell what source a number came from or when it was last refreshed. The Data Consumer uses figures with no way of establishing their source or currency, even by asking.
Origin can sometimes be established by asking a specific individual, but nothing is documented or discoverable independently. The Data Consumer relies on a knowledgeable analyst to explain where a figure came from, and that explanation exists nowhere in writing.
Source and refresh information is documented and accessible for priority data assets, in a location business users are shown how to use. The Data Consumer can look up the source system and last refresh time for the reports and datasets they regularly use.
End-to-end lineage is documented and maintained for business-facing assets, showing transformations between source and report, with currency displayed at the point of use. The Data Consumer can trace a figure in a report back through its transformations to the source system, and sees a refresh timestamp on the report itself.
Lineage is captured automatically from the platform and surfaced in context, remaining accurate without manual maintenance as pipelines change. The Data Consumer sees automatically generated, current lineage alongside the asset, reflecting pipeline changes without anyone updating documentation.
ARC-CON-04
Data extraction and onward use in business tools
How well supported are you in getting data out of corporate platforms and into the tools you actually work in — spreadsheets, planning tools, models or documents — in a controlled and repeatable way?
Maturity level descriptions
No supported route exists; the Data Consumer relies on manual copying, screen scraping or asking someone to send a file. Data reaches the Data Consumer’s working tools by manual copy-paste or ad hoc emailed files, re-created from scratch each time.
Ad hoc extracts are provided on request, but each is bespoke, unrepeatable and dependent on a specific person’s availability. The Data Consumer requests an extract each time it is needed and waits for someone to produce it manually.
Defined self-service export and connection options exist, are documented, and business users are trained to use them. The Data Consumer can export or connect to approved datasets themselves through a documented, supported method.
Extraction routes are governed and monitored — controlled by access rights, logged, and subject to defined rules on retention and onward handling of extracted data. The Data Consumer’s exports are permitted by role, logged, and subject to stated rules on how long extracted data may be retained.
Live, governed connections largely replace extraction — business tools consume data directly under central control, minimising uncontrolled local copies. The Data Consumer’s working tools connect to governed data live, so figures update automatically and static local copies are rarely needed.
ARC-CON-05
Feedback loop on platform friction
When the tools and platforms you use create friction — something is too slow, an integration is missing, an interface is unusable — how effectively does that experience reach the people planning the data architecture?
Maturity level descriptions
No mechanism exists for business users’ platform friction to reach architecture or technology planning; the Data Consumer simply works around it. The Data Consumer builds a manual workaround and the underlying constraint is never recorded or reported.
Friction is raised informally through service desks or personal contacts, treated as individual incidents rather than as architectural input. The Data Consumer logs a ticket that is closed once their immediate problem is worked around, with no pattern analysis.
A defined channel exists for business users to raise platform and tooling constraints as improvement input, and it is communicated to them. The Data Consumer knows how to raise a platform constraint as an improvement request rather than only as an incident, and has done so.
Business-user friction is systematically collected and analysed for patterns, feeding a tracked technology improvement backlog with outcomes reported back. The Data Consumer receives an outcome on raised constraints, and recurring friction is visible in a tracked improvement backlog.
Business-user experience is a standing input to architecture roadmap decisions, proactively sought and demonstrably reflected in platform investment. The Data Consumer is consulted during platform planning, and can identify a platform change made as a result of business-user experience.