How to assess alignment, choose a proportionate scope, and turn findings into action
This is the final article in a five-part series on implementing HACT’s UK Housing Data Standards.
The earlier articles considered why organisations need to understand their own data, what a useful data dictionary should contain, and what the work can expose about definitions, governance, hidden rules, and quality.
This final article considers what happens next.
Once an organisation has begun describing its data, it needs to assess how its current position relates to the standards, decide what type of change is required, and establish a scope that can deliver practical value.
The aim should not be to produce a perfect enterprise dictionary before implementation begins. Nor should the organisation attempt to map every field in every system at once.
A more realistic approach is to begin with a defined business objective, focus on the data that matters to that objective, and use the findings to create a controlled programme of improvement.
Standards alignment is not binary
It can be tempting to reduce standards mapping to two outcomes:
- Matched
- Not Matched
That may be simple to report, but it conceals much of the information required for implementation.
Two fields may describe the same concept but use different formats. Another field may contain only part of the standard concept. A similar-looking internal field may represent something materially different. A relevant concept may not be held at all, while another field may remain too poorly understood to assess safely.
Those outcomes should not lead to the same action.
A more useful assessment distinguishes six forms of alignment:
- Direct
- Transformable
- Partial
- Conflicting
- Missing
- Unknown
Direct alignment
Direct alignment exists where the internal data item and the standard describe materially the same concept at a compatible level of detail.
The names do not need to be identical. What matters is that the business meaning, intended use, structure, relationships, and permitted values are sufficiently consistent.
For example, an internal field and a standard attribute may both record the date on which a tenancy legally began. The internal system may use a different label, but the definition, source, data type, and purpose align.
Relatively little change may be required. The organisation may need only to document the relationship, confirm the quality of the existing data, and ensure that the mapping remains governed.
Even direct alignment should not be assumed from the field name. The source, derivation, code list, effective date, and quality of the values still need to be confirmed.
Transformable alignment
Transformable alignment exists where the internal and standard concepts correspond, but their technical representations differ.
The internal system may use another date format, identifier structure, code value, naming convention, or combination of fields.
For example, an internal repairs-priority field may use local values such as 1, 2, and 3, while the standard uses named categories. If the local meanings are clearly defined and map consistently, the difference can be managed through a controlled transformation.
This is primarily a technical implementation issue rather than a disagreement about meaning.
However, the transformation still needs to be documented and governed. The organisation should know which rules are applied, who approves them, how exceptions are managed, and what happens when either the internal code list or the standard changes.
A transformation that exists only inside an interface or SQL query may work today while remaining difficult to test, reuse, or maintain.
Partial alignment
Partial alignment exists where the internal data captures only part of the standard concept, or where one internal field combines several concepts that the standards represent separately.
The Property Type example used throughout this series illustrates the problem.
An internal field might reliably distinguish houses from flats but also include values relating to tenure, building use, construction history, or operational management.
Some values may align with a standard concept, while others belong elsewhere in the model. Treating the entire field as directly aligned would conceal those differences.
Partial alignment may also arise where the standards expect greater detail than the organisation currently records.
The response may involve improving the definition, separating concepts, introducing additional fields, or accepting that only part of the standard can currently be implemented.
Partial alignment should not be upgraded to a direct match simply to make the mapping appear complete.
Conflicting alignment
Conflicting alignment exists where an internal field appears similar to the standard concept but is defined or used differently.
An internal ownership classification may describe management responsibility, while the standard concept describes legal ownership.
A property hierarchy may group records for administration, while the standard relationship represents physical building structure.
An internal status may be a reporting category, while the standard describes an operational stage within a process.
These cases cannot be resolved through renaming or technical conversion alone. They require a business and governance decision.
The organisation may decide to retain the existing internal concept because it remains operationally necessary, but give it a clearer name. It may need to introduce a separate field for the standard concept or redesign the process through which the information is captured.
Conflicting alignment is particularly risky where the internal and standard terms use the same label. The apparent similarity can make an unsupported mapping look credible.
Missing internally
The standards may include a concept that the organisation does not currently record in a structured form.
That could indicate a genuine data gap, but the position should be investigated before assuming the information does not exist.
It may be held in narrative documents, a contractor’s system, a local spreadsheet, several unconnected fields, or the knowledge of an operational team.
The organisation must then decide whether the information is required for its implementation objective.
Not every standard attribute necessarily needs to be populated in every project. Where the data is required, the response may involve new data capture, document extraction, an improved contractor exchange, a system change, or a revised business process.
Missing data should therefore become a business decision rather than automatically being treated as a system defect.
Unknown
Unknown applies where the organisation cannot yet establish what an internal field means, how it is populated, or whether it is reliable enough to map.
This is a legitimate outcome.
Without an explicit unknown category, teams may feel pressured to select the closest-looking standard attribute and complete the mapping. That creates the appearance of progress while introducing uncertainty into later reporting, integration, and migration.
Unknown should lead to a defined investigation, not a permanent blank.
An unresolved mapping supported by a clear action is safer than a direct match that cannot be defended.
The mapping should explain the decision
Recording an alignment category is useful, but it is not enough. The dictionary should also explain why the category was selected and what evidence supports it.
For each important mapping, the organisation should be able to identify:
- The internal and standard definitions
- The systems and fields involved
- Any difference in meaning or granularity
- The internal and standard code lists
- The source or derivation of the internal value
- Known quality limitations
- The required transformation or remediation
- The person or group approving the decision
This becomes especially important where a mapping is reused across interfaces, reports, migrations, and transformation programmes.
A mapping should be treated as governed metadata, not as a temporary spreadsheet created for one project and then forgotten.
Start with a useful problem, not the whole organisation
A comprehensive enterprise dictionary may eventually contain thousands of items across housing, assets, repairs, finance, customer services, compliance, complaints, and supporting platforms.
Attempting to document and map all of them at once is unlikely to be an effective starting point.
The work can become so large that early value is difficult to demonstrate. Teams may spend months populating technical fields while important definitions remain unresolved. By the time the exercise is complete, systems and processes may already have changed.
Metadata-management guidance supports an enterprise perspective, but recommends incremental implementation connected to concrete business priorities. It also warns that metadata created for its own sake is unlikely to be funded or maintained effectively.
The same principle applies to the UK Housing Data Standards.
A useful initial scope might be shaped by:
- A standards module
- A system procurement or replacement
- A contractor interface
- A regulatory return
- A compliance requirement
- A known data-quality problem
- A service redesign
- A reporting inconsistency
- A data-platform development
- A new integration
The scope should be broad enough to include the relevant processes, systems, and relationships, but narrow enough to complete, govern, and use.
Prioritise critical data
Not every technical field requires the same level of attention.
A system may contain hundreds of configuration flags, audit fields, and locally used attributes. Documenting them may eventually be useful, but they should not distract from the data elements that drive material decisions and risks.
The first scope should focus on data that:
- Supports legal, regulatory, or safety obligations
- Affects resident services or outcomes
- Drives significant financial decisions
- Appears in important operational or regulatory reporting
- Moves between several systems
- Is exchanged with contractors or partners
- Identifies residents, properties, tenancies, repairs, or cases
- Has known quality or reconciliation problems
- Will be affected by a planned transformation
These critical data elements provide a practical starting point through which the organisation can establish its method, governance, templates, and experience.
A practical route from understanding to implementation
The exact route will vary by organisation and purpose, but the work can be structured into six connected stages.
A practical implementation route begins with a defined purpose, then connects processes, critical data, systems, profiling, standards alignment, action planning, and ongoing governance.
1. Define the business purpose and scope
A goal such as “implement the data standards” is too broad to guide practical decisions.
A more useful objective might be to improve repair information exchanged with contractors, define requirements for a new housing management system, strengthen property information used for compliance, or reduce differences between operational and regulatory reporting.
The purpose determines which standards material, systems, processes, and data items should be included.
It also provides a basis for deciding what does not need to be included at this stage.
2. Understand the process and identify critical data
Before concentrating on database fields, the organisation should understand the process in which the information is created and used.
Where does the data originate? Who records it? Which events cause it to change? Where does it move, and which services, decisions, interfaces, and reports depend upon it?
A process view helps reveal information that might otherwise be missed. A key value may begin outside the main system, be amended by a contractor, transformed through an interface, and grouped differently within a report.
Understanding that journey is essential when deciding which field is authoritative and whether the data can support its intended use.
3. Connect business meaning to technical implementation
The organisation can then document the relationship between business concepts and the systems in which they are represented.
This requires input from operational users, subject specialists, analysts, developers, data engineers, system administrators, and other relevant teams.
Technical metadata can often be harvested automatically, but business meaning, operational use, and governance responsibilities normally require discussion and agreement.
The resulting dictionary should connect the definition, system fields, code lists, source, derivation, processes, downstream uses, ownership, quality expectations, and relevant standards concept.
4. Profile the data and assess alignment
Definitions should be evaluated against the data itself.
Profiling may reveal values that do not fit the proposed definition, retired codes that remain in use, defaults masking missing information, unexpected duplicates, incomplete relationships, or patterns suggesting that the documented process is not being followed consistently.
The analysis should evaluate the current understanding rather than replace it.
Once the internal data has been described and profiled, its relationship with the standards can be classified as direct, transformable, partial, conflicting, missing, or unknown.
The reasoning and evidence should be recorded alongside the category.
5. Convert findings into an action plan
Findings should be separated according to the type of response required.
Some may need improved documentation. Others may require a definition to be approved, ownership to be assigned, or a code list to be rationalised.
There may also be data cleansing, process changes, new validation controls, system configuration, interface development, or new data capture.
This distinction matters because not every problem exposed by the dictionary is a cleansing problem.
For example:
- An undefined term requires a governance decision
- A valid local code differing from the standard may require transformation
- A mandatory default may require process and system change
- Historic duplicates may require cleansing
- A concept held only in documents may require extraction or new collection
- An undocumented reporting rule may require formal approval and lineage documentation
Treating every finding as cleansing would address symptoms while leaving many causes unchanged.
6. Approve, publish, and maintain
The dictionary and mappings should move through a proportionate approval process and be made accessible to the people who need them.
Users should be able to see which definitions are approved, which remain under review, who is responsible, and when the information was last updated.
Maintenance must then be integrated with normal change activity.
The dictionary should be reviewed when a system, process, code list, interface, report, dataset, ownership arrangement, or standards version changes.
It should not depend on someone returning to a spreadsheet once a year and attempting to reconstruct what happened.
The dictionary is also data
A dictionary can become incomplete, duplicated, inconsistent, and out of date just like the information it describes.
It therefore needs its own governance.
That may include:
- Defined ownership and stewardship
- Standard templates and mandatory fields
- Review and approval statuses
- Version control and effective dates
- Change history
- Retirement and replacement arrangements
- A route for users to report errors
- Periodic quality and coverage checks
Currency must be visible.
A user should be able to tell whether a definition is approved, when it was last reviewed, and whether a known system or process change has made it unreliable.
An outdated dictionary that appears authoritative can create greater risk than an honest record that clearly identifies areas still under review.
Measure success against the original purpose
The success of a dictionary and standards implementation should not be judged only by the number of fields documented or mapped.
A large repository may provide little practical value if definitions are vague, ownership is missing, users cannot find the information, and changes are not maintained.
Measures should relate to the purpose of the work.
For a repairs integration, success might include fewer bespoke transformations, more consistent status reporting, reduced interface failures, and faster onboarding of contractors.
For a housing management system procurement, the benefits may include clearer requirements, better visibility of legacy rules, stronger migration and testing criteria, and a reduced risk of recreating poor structures in the new platform.
For a compliance-related dataset, success might be reflected in clearer asset scope, stronger evidence requirements, more meaningful quality rules, and more reliable reporting.
The organisation may also track the proportion of critical data elements with approved definitions, confirmed owners, documented lineage, agreed quality rules, and assessed standards alignment.
Usage matters as well.
A technically complete dictionary that is not used when systems, processes, reports, and interfaces are designed is not fulfilling its purpose.
A common language still requires translation
The UK Housing Data Standards provide the sector with a common way to describe important data, relationships, processes, and exchanges.
That common language can support better integration, more consistent reporting, improved governance, and greater freedom to move between technologies.
However, an organisation cannot adopt a common language simply by changing the labels attached to its existing fields.
It first needs to understand what those fields represent, how their values are created, which processes depend upon them, who is accountable for them, and whether the information can be trusted.
Building an internal data dictionary helps create that understanding.
The completed dictionary is valuable, but so is the work required to produce it. That work exposes where definitions are missing, where teams interpret concepts differently, where business rules remain hidden, where ownership is unclear, and where quality cannot yet be assessed.
Those findings should not be treated as reasons to delay standards implementation.
They are the information needed to make implementation meaningful.
The standards provide the common reference point. The dictionary describes the organisation’s current position, identifies the distance between the two, and helps determine what needs to change.
The dictionary is therefore not merely preparation for implementation, it is part of implementation.
So perhaps the first question should not be:
How closely do our systems match the UK Housing Data Standards?
It should be:
Can we clearly describe the data we are trying to standardise?
About this series
- 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.