Why understanding your existing data is the starting point for meaningful implementation
This is the first article in a five-part series exploring how housing organisations can move from an interest in HACT’s UK Housing Data Standards towards practical implementation.
This article focuses on the starting point: understanding the data an organisation already holds. Part 2 will consider what a useful housing data dictionary should contain. Parts 3 and 4 will examine what the dictionary-building process exposes about governance and data quality, before Part 5 considers how those findings can be translated into standards alignment and practical action.
The central argument is straightforward. A housing organisation cannot determine whether its data aligns with a common sector model until it understands what its own information represents, where it comes from, how it is used, and who is accountable for it.
That is where an internal data dictionary becomes important.
The standards are available. Implementation is where the work begins
HACT’s UK Housing Data Standards were developed with the sector to help housing organisations improve their data and overcome common challenges. HACT positions them as supporting stronger governance, improved performance, more streamlined regulatory reporting, and greater consistency in the way information and processes are structured. They can also inform transformation programmes, system integration, data sharing, and the design of new processes and interfaces.
There is clearly interest in that potential. At the time of writing, HACT states that the standards have been downloaded more than 2,000 times by social housing organisations.
Downloading the standards, reviewing the available modules, and recognising their value are important first steps. Implementation, however, requires an organisation to connect the common sector model to the systems, processes, definitions, relationships, and data it already uses.
That is not simply a technical exercise. Internal data structures have usually developed over many years through system constraints, local decisions, regulatory requirements, integrations, reporting needs, organisational change, and operational workarounds.
Nor does meaningful implementation require every provider to replace all its existing structures, redesign every system, and implement the entire model through one transformation programme. An organisation might begin with a particular dataset, interface, process, regulatory return, or system procurement and expand its use of the standards over time.
Useful starting points might include:
- Improving repairs information exchanged with contractors
- Making property and asset data more consistent
- Designing a new complaints process
- Integrating customer information across systems
- Strengthening regulatory or environmental reporting
- Defining requirements for a new housing management platform
- Reducing bespoke transformations between existing technologies
Starting with a defined problem gives the organisation a practical reason to understand the relevant data, compare it with the standards, and turn the findings into action.
The standards themselves are considerably broader than a list of suggested field names. The Version 3.5 materials include entities, attributes, code lists, data types, validation rules, relationships, use cases, process material, data models, and exchange structures across a range of housing subject areas.
This distinction matters. The standards are not simply proposing that housing organisations adopt the same labels. They provide a structured way of describing what information represents, how different concepts relate, which values are permitted, how information should be validated, and how it may move between systems and organisations.
They therefore provide a common reference model against which an organisation can assess its own data and processes.
That creates a central implementation question: How does the organisation’s current data relate to that model?
At first, this can appear to be a straightforward mapping exercise. An internal field is identified, a similar attribute is found in the standards, and a relationship between the two is recorded.
However, a mapping is only dependable when both sides are understood. The standards may provide a clear definition of the target concept, but the more difficult question is often whether the organisation can explain what its own internal field actually represents.
My connection to the standards
During my time at Data Futurists, the organisation was involved in supporting the continued development of the UK Housing Data Standards.
I was not one of the people directly leading or developing the standards. However, working around that activity gave me a close view of their structure and of the practical considerations involved in applying a sector model to existing housing systems, processes, and data.
Since then, one point has become increasingly clear through wider analysis, governance, and data-quality work: An external standard and an internal understanding of data are not competing approaches. Each makes the other more useful.
The standards provide a coherent model against which an organisation can challenge its current structures. An internal data dictionary provides the context needed to interpret those structures honestly.
Without an external reference model, an organisation may simply document existing inconsistency. Without a clear understanding of its internal data, standards implementation can become a superficial exercise in matching names. Used together, they can support meaningful change.
The uncomfortable first question: what does your own data mean?
Imagine an organisation has a field called Property Type.
The name appears clear enough. It seems reasonable to assume that a corresponding concept can be found in the standards and that the field can then be mapped against it.
Before doing so, the organisation needs to establish what the internal field actually describes.
It might record the physical form of a dwelling, the use of a building, whether an asset is residential or non-residential, its construction method, the type of accommodation being provided, its tenure, the operational service responsible for it, or a historical classification inherited from an earlier system.
It may also represent a mixture of several of those concepts.
The permitted values might include:
- House
- Flat
- Maisonette
- Hostel
- Garage
- Office
- Conversion
- Shared Ownership
- Temporary Accommodation
- Commercial
Each value may be meaningful in isolation, but together they do not describe one consistent characteristic.
House, Flat, and Maisonette may describe the physical form of a dwelling. Hostel may describe building use, accommodation arrangement, or service model. Garage and Office describe different forms of non-residential asset. Conversion may refer to the history or construction of the building. Shared Ownership is a tenure, while Temporary Accommodation may describe how a property is being used or managed rather than what it physically is.
The field could be technically complete. Every property might contain a value selected from an approved code list. It could still be conceptually inconsistent.
There may therefore be no single standard attribute to which the entire field can be mapped. Its values belong to several different concepts within the standard model.
The issue is not that the standards have failed to accommodate the organisation’s data. The issue is that the internal field may have accumulated several meanings over time.
What does ownership mean?
An internal field called Ownership Type might refer to registered legal title, management responsibility, repair obligations, financial treatment, whether a property is leased in or leased out, whether the organisation collects rent or service charges, or whether the asset forms part of a management agreement.
An organisation may legitimately need to record all these characteristics. They influence different services, reports, financial treatments, and legal responsibilities, but they are not interchangeable meanings of ownership.
A field created for finance reporting may not provide evidence of legal title. A management classification may not establish who owns the asset. Responsibility for repairs may be divided between several parties.
A mapping based only on the word Ownership could therefore appear convincing while connecting fundamentally different concepts.
What does occupied mean?
An Occupied status might mean that an active tenancy exists, that someone is physically living in the property, that a rent account remains open, or simply that the property has not been recorded as void.
It could also refer to a temporary accommodation placement, a licence, or another form of occupancy agreement.
Several of these conditions will normally occur together, which makes the differences easy to overlook. They can also diverge. A tenancy may remain active while the resident is temporarily absent. A rent account may remain open after physical occupation has ended. A property may be unavailable for letting without being occupied.
Before Occupied can be mapped, governed, or tested for quality, the organisation needs to define which condition the status is intended to represent.
How do you define a building?
A single building can be represented in several valid ways, including its physical structure, administrative hierarchy, compliance scope, and operational or financial grouping. Problems arise when one representation is assumed to serve every purpose.
A field or hierarchy that appears to represent a building may, in practice, describe several different things.
It might identify a single physical building. It might instead represent several connected buildings, a group of independent building sections, an administrative property hierarchy, a repairs reporting unit, a compliance assessment scope, or part of a wider estate structure.
Different teams may also need different views of the same asset. Finance may use one grouping for service charges. Housing operations may rely on an administrative hierarchy. Compliance teams may need a representation based on the physical building and its independent sections. Asset teams may need to understand the relationship between the wider building, its blocks, sub-blocks, cores, entrances, and the homes contained within them.
Each of these structures may be valid for its own purpose. The difficulty arises when one of them is assumed to represent all of them.
An internal field may be labelled Block, Building, or something similar, but the name alone does not establish what relationship it actually describes. It may reflect physical form, management structure, inspection scope, or reporting convenience. Those are not automatically the same thing.
Before the organisation can map the concept reliably to a common standard, it needs to establish what that field is intended to represent. Is it a physical building? Is it a collection of connected structures? Is it an administrative grouping? Or is it a practical operational unit created for a specific service?
Until that is understood, the organisation cannot safely assume that its existing Block or Building field provides a reliable representation of the built environment.
Familiar names can conceal different concepts
These examples demonstrate why field-name matching is not enough.
Two fields can share the same name while representing different business concepts. Two fields with different names can represent substantially the same concept. One internal field can combine several concepts that the standards represent separately.
The meaning of a field may also vary depending on the process, report, team, or system using it.
Before a reliable mapping can be created, the organisation needs to understand:
- What the data is intended to represent
- How the value is created or derived
- Which processes and decisions depend upon it
- Which evidence supports it
- Who is accountable for its definition
- Whether its current values can be trusted
Only then can it determine whether the data aligns directly, requires transformation, represents only part of the standard concept, or cannot yet be mapped with confidence.
Familiar field names can conceal several different business concepts. Before mapping data to a standard, the organisation must establish what each field is actually intended to represent.
The standard is the reference point, not the explanation of your existing data
The UK Housing Data Standards provide a common language through which organisations can describe data, relationships, processes, and exchanges more consistently.
However, an external standard cannot automatically explain why an internal code was created, how a legacy field is populated, or which interpretation an operational team currently applies.
There may be several internal versions of the same apparent concept. A core housing system might hold one property status, the finance system might derive another, and a reporting platform might apply separate logic to produce a third. Each version may have a valid purpose, but that does not make them interchangeable.
The organisation may also find that a concept is not recorded in a structured field at all. It might exist within a document, a contractor’s system, a local spreadsheet, or the knowledge of an experienced member of staff.
In other cases, a system limitation may have encouraged users to record information against the nearest available field, gradually changing what that field means in practice.
The standards can show what a more consistent sector representation looks like, but they cannot document the organisation’s current state on its behalf.
That understanding has to be developed from systems, data models, processes, reports, interfaces, business rules, analysis, and the people who create and use the information.
The dictionary as the translation layer
A useful internal data dictionary brings that knowledge together.
It does more than list databases, tables, columns, and data types. It connects business terminology to technical fields, code lists, processes, rules, ownership, lineage, quality expectations, and known limitations.
The standards provide the common sector model. The dictionary describes the organisation’s current reality.
Used together, they can show where information already aligns, where transformation is required, where an internal field combines several concepts, and where the organisation does not yet know enough to make a reliable decision.
The next question is therefore not only whether an organisation needs a data dictionary, but what that dictionary must contain to be useful.
About this series
Implementing HACT’s UK Housing Data Standards
- You Cannot Standardise What You Cannot Describe
- What Should a Housing Data Dictionary Actually Contain?
- What Your Data Dictionary Will Expose
- Valid Does Not Mean Accurate
- From Internal Data to Standards Implementation
About HACT
HACT is the charity of the social housing sector, supporting innovation, collaboration, and insight across housing. Since 2018, it has worked with OSCRE and organisations across the sector to develop the UK Housing Data Standards, which provide the common framework at the centre of this series. More recently, HACT has established UK HIVE to support sector-wide collaboration, research, development, and implementation.
I would like to acknowledge HACT, OSCRE, and the wider sector contributors whose work has made the standards possible. This series is an independent discussion of the practical questions that can arise when applying them to existing housing systems, processes, and data.