Connecting business meaning, technical data, processes, governance, quality, and standards alignment
This is the second article in a five-part series on implementing HACT’s UK Housing Data Standards.
Part 1 considered why an organisation needs to understand its own data before reliable standards mapping can begin. It argued that an internal data dictionary provides the translation layer between the common sector model and the systems, processes, definitions, and information already in use.
This article considers what that dictionary should contain.
The exact structure will vary according to the organisation and the purpose of the work. A dictionary created to support repairs integration will not require the same scope as one supporting a housing management system replacement.
However, a useful dictionary must connect more than physical fields. It needs to explain what the data means, where it is held, how it is produced, how it moves, who is accountable for it, what quality should be expected, and how it relates to the standards.
A dictionary is more than a schema extract
At its simplest, a data dictionary may identify a system, database, schema, table, column, data type, length, key relationship, default value, and whether missing values are permitted.
Much of that information can be extracted automatically from databases, data models, integration tools, and system catalogues. That technical metadata is useful, but it is not sufficient.
A database can tell you that a field is a ten-character string. It cannot necessarily tell you what the organisation believes those ten characters represent, why the value is collected, which process changes it, or whether the field is still being used as originally intended.
DAMA-DMBOK treats metadata as broader than the familiar description of “data about data”. It includes business terminology, logical and physical structures, systems, processes, rules, constraints, relationships, lineage, security, ownership, and operational use. It also describes data dictionaries as resources that can connect physical structures to business terminology, security restrictions, and the processes in which data is applied.
A useful housing data dictionary should therefore connect five broad dimensions:
- Business meaning
- Technical implementation and reference data
- Process and lineage
- Governance and quality
- Standards alignment
A useful data dictionary connects a business term to the system field, permitted values, process, accountable owner, quality rules, and the corresponding standards concept. It provides one governed definition linking business meaning to technical imp
Business meaning
The starting point is a clear description of what the data is intended to represent.
A definition should do more than repeat the name of the field. Defining Property Status as “the current status of the property” adds almost no useful information. It does not explain which condition is being classified, how the status is determined, or which alternative meanings are excluded.
A stronger definition might state: The current operational availability of a residential property, based on whether it is let, available for letting, unavailable for letting, or closed from housing use.
Even that definition may require further decisions. Does the status describe whether a tenancy exists, whether the property can be let, or whether the asset remains in management? Are temporary accommodation and decant use represented separately? Can a property be closed while an occupancy relationship remains active?
Developing the definition forces those questions into the open.
The dictionary should also record the term’s purpose, related concepts, synonyms, common misunderstandings, permitted uses, exclusions, supporting evidence, owner, review status, and approval date.
This helps prevent one field from being used as a convenient answer to several different questions.
Technical implementation and reference data
The business concept must then be connected to its physical implementation.
That might include the application, system module, database, schema, table, file, column, physical data type, length, precision, key relationships, default value, source system, and target systems.
This should not be limited to the main housing management system.
Relevant data may also exist in:
- Asset management and compliance platforms
- Repairs and contractor systems
- Finance applications
- Customer relationship management tools
- Data warehouses and lakehouses
- GIS platforms
- Document-management systems
- Reporting models
- Locally maintained spreadsheets and databases
The dictionary should distinguish whether a value is directly entered, imported, copied, calculated, derived, inferred, overridden, or manually corrected.
That distinction matters because a value can be useful without being the authoritative source of the underlying business fact.
A reporting classification derived from several finance fields may be appropriate for financial reconciliation. It should not automatically be treated as evidence of legal ownership or the physical condition of an asset.
Code lists are part of the definition
Many housing fields rely on controlled codes, and the dictionary should connect each field to the code list through which it is implemented.
For each value, it may be useful to record:
- the code and display name
- a clear definition
- its current or retired status
- effective and retirement dates
- parent or related values
- permitted transitions
- the equivalent standard value
- any required transformation
- the owner and approval route
A code list is not governed simply because it exists within a system.
Values may overlap, remain selectable long after they have been retired, or act as catch-all categories whenever the correct answer is unknown. New values may have been added to meet a local reporting need without considering their effect on interfaces, existing reports, or the meaning of the wider field.
A well-defined field can still have a poorly governed code list. The reverse can also be true.
Process and lineage
A data item cannot be understood fully without the process that creates and maintains it.
The dictionary should explain where the value originates, who records it, which event triggers its creation, what causes it to change, and where it moves next.
This helps distinguish designed behaviour from operational reality.
A property status may be expected to change when a tenancy ends. Analysis may show that it is updated later through a void process, a manual task, or an overnight interface. That delay affects whether the field can be relied upon for real-time reporting.
Lineage is equally important.
A value displayed in a report may have passed through several stages. It might originate in a source application, be recoded through an interface, grouped in a data warehouse, and classified again within a reporting model.
Without documented lineage, the final label can easily be mistaken for a direct source value.
The dictionary should therefore connect the original field to its transformations, interfaces, downstream datasets, reports, and business uses.
It should also identify the refresh frequency, history retained, dependencies, reconciliation process, and known operational constraints.
Governance and quality
The dictionary should record how the data is governed and what acceptable quality looks like.
Governance information may include the business owner, data steward, technical custodian, system owner, approving body, security classification, retention requirement, legal or regulatory relevance, review cycle, and definition status.
Quality information might cover whether the field is mandatory, which values or formats are permitted, how quickly it should be updated, which relationships should hold, and what evidence can confirm the value.
For example, a dictionary could record expectations such as:
- An occupied dwelling should have an appropriate active occupancy relationship
- A void property should not have an active general-needs tenancy
- A postcode should be valid and correspond with the expected property
- A retired code should not be assigned to a new record
- A compliance certificate should relate to the correct asset and inspection period
Some rules can be checked technically. Others require business context, evidence, and agreed exceptions.
At this stage, the dictionary does not need to prove that every rule is being met. It should establish what the organisation expects, who is accountable for the expectation, and where the rule remains under review.
Standards alignment
Finally, the dictionary should record the relationship between the internal data and the UK Housing Data Standards.
That might include:
- The relevant standards module
- The standard entity and attribute
- The standard definition
- The expected data type
- The applicable code list
- Validation and relationship requirements
- The internal-to-standard mapping status
- Differences in meaning or granularity
- Any required transformation
- Missing internal information
- The mapping owner and approval status
- Planned remediation or target implementation
The result should not be a simple cross-reference based on similar names.
It should explain whether the concepts genuinely align, whether technical transformation is required, whether the internal data captures only part of the standard concept, and whether the information is dependable enough for the intended implementation.
Data dictionary, business glossary, or data catalogue?
There are useful distinctions between a data dictionary, business glossary, and data catalogue.
A data dictionary normally describes datasets, fields, structures, and their technical characteristics. A business glossary focuses on organisational terminology, definitions, and the relationships between business concepts. A data catalogue helps people locate systems, datasets, reports, and other information assets.
In a mature data environment, these may be managed through separate but connected resources. An organisation beginning the work, however, may initially bring several of these elements together.
The first version might be maintained in a controlled workbook, SharePoint list, collaborative database, or an existing governance system. The format matters less than whether the information is structured consistently, accessible to the people who need it, and subject to clear ownership, review, and change control.
The important question is not whether the organisation has selected the perfect name or specialist technology.
It is whether people can connect:
- Business terminology and definitions
- Systems, datasets, and fields
- Code lists and permitted values
- Processes and business rules
- Sources, transformations, and lineage
- Quality expectations and known limitations
- Owners, stewards, and approval status
- Relevant UK Housing Data Standards concepts
As the scope and maturity increase, the organisation may decide that more specialised technology is needed. That decision should follow the practical requirement rather than delay the initial work.
Technology can make metadata easier to search, connect, and maintain. It cannot decide what important data means, identify the correct evidence, or assign accountability on the organisation’s behalf.
Designing the dictionary is only the beginning
A well-designed dictionary establishes the information that should be known about each critical data item.
Populating it is where the organisation begins to discover how much of that knowledge is missing, disputed, outdated, or held only by particular people.
The dictionary may reveal that different teams use the same term differently, that a code list combines several concepts, that a report applies undocumented logic, or that no one has been made accountable for an important definition.
Those are not failures of the dictionary.
They are the reason the work matters.
Part 3 will consider what the dictionary-building process exposes about conflicting definitions, hidden business rules, ownership, and governance.
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.