With the Building Safety Act requiring a new level of oversight, it’s a good time to sort out the information you hold on your housing portfolio.
You know – all those resident surveys, health and safety documents, energy guidelines and construction checklists. There has to be a better way than siloed spreadsheets with multiple duplicate entries and searches that only work if you’ve got the spelling exactly right. Just think of the working environment that could be yours – and the reflected glory you get from creating it. Projects running smoothly, information for a presentation deck that reveals itself immediately and people not pulling their hair out trying to find something that’s as good as lost.
The new safety requirements for housing provides a good excuse to finally kill off some half-built databases. And we recommend talking to your colleagues. Everyone has a concept about what should be included in a set of data. Every organisation has a set of processes and departments, people and information. It’s about agreeing on which of these are relevant for the upcoming task and doing it so the right people are involved. A workshop is a perfect first step.
Follow your framework
As data experts, we adopt an approach based on the challenges facing us. That means not attempting to shoehorn business processes into a particular model. In a recent case, we built a hierarchy of business areas, taxonomy of terminology, ontology of fire and safety entities, and an audit of processes, documents and datasets. We modelled all the entities – people, places, buildings, organisations, tools and systems.
Some people would have called it an example of a Conceptual Data Model. We didn’t because we prefer to spend time working out how different parts of a business relate to each other and not getting caught up in naming. Superimposing a particular model could put limits on that approach. From time to time we’d refer to it as a ‘Concept Model’ to show to other data experts that we weren’t using another, named design.
Plus there’s so much jargon and hazy terminology around at the moment. Don’t be afraid to ask a supplier what they mean by their use of the words ‘architecture’, ‘model’, ‘framework’ and ‘schema’. These are spoken about in so many different ways and things can get pretty blurred. You should even look out for the word ‘modelling’ being bandied about. A website can be modelled, with lists of products, services, contact details and a site map. But many exercises called ‘modelling’ are just a list or a summary of a process.
Even if you don’t start off your project with modelling, the ‘Zachman Framework’ can be useful. This kicks off with questions such as: ‘Why? How? What? Who? Where? When?’. You could have the ‘what’ as data, ‘how’ the function, ‘where’ as the network, ‘who’ as the relevant people, ‘when’ being the time and ‘why’ the overall motivation – in a recent case we were working on, this referred to the need to comply with building safety regulations.
To source information to answer these, use datasets, websites, papers, technical models, lists of people and organisations, buildings and assets, safety and hazards. If you’re in the housing sector a crucial requirement is providing a response for the Building Regulator. Look at data from residents and tenancy data, construction, repairs and maintenance, planning, building control and health and safety.
Box clever with your approach
If you’re rapidly put all this together to complete a Building Safety Case, then don’t stress the detail. Even though plenty of data might be part of the Case, it doesn’t all have to be sent to the Regulator. Extra information can be extracted later if your supplier has built the system right. This is especially necessary if – as often happens – it’s hard to define what goes where.
In a recent project, we found that there were no clear criteria for classifying some data as entirely health and safety-related, and some data as completely unrelated to health and safety. So whilst we were waiting for answer, we developed a list of Building Safety Case Reports with links to each other, plus other documents – but not datasets. It didn’t include every single piece of fire and structural safety data as requested by the building safety regulator.
Once you’ve done this make sure it’s shared – so it can be negotiated, amended and developed. That’s the bit when you can tweak according to the needs of the people you work with. Bonus points for a collaborative approach – you get to look like the right kind of project leader.
The output will serve to link databases across different business areas. Once you have a set of tables – financial, orders, HR, product, location, contact – the tables can be made into data models – the conceptual bit. From there your team can develop a physical model – a graphical representation of business requirements, and then physical data models – how the data will actually flow in your system. And that leads to the eventual database.
Thanks for reading our quick summary of data and building safety. Do feel free to get in touch if you’d like to discuss anything we’ve covered here – we’d be happy to chat it through.
You can reach out to our founder: ed.mcculloch@atendco.com
Some key definitions
You might want to know about…
Concept Modelling – a general term used to describe turning real world elements into concepts. It has been taken on by the data world to describe the visualisation and representation of data elements.
Data Architecture – how information flows, and how it is controlled. The aim is to translate business needs into data and system requirements.
Database – a collection of information that is structured and usually stored electronically in a computer system, enabling it to be easily accessed, managed and updated. Some examples are: MySQL, PostgreSQL, Microsoft SQL Server, MongoDB, Oracle Database, and Redis.
Data Capture – collecting information and converting it into data that is physically or digitally available.
Logical Data Model – establishes the structure of data elements and the relationships among them, independent of the physical database.
Physical Data Model – introduces database-specific context missing in conceptual and logical data models. So representing tables, columns – how it’s going to look, or the framework behind how it looks.
Taxonomy – a classifying of information. Comes from the classification of plants and animals that the Greeks and Victorians were so fond of. Hence its similarity to taxidermy – although we don’t suggest you start stuffing animals any time soon.
Unstructured Data – sets of data that don’t have a data model to structure and arrange them.
Zachman Framework – a way of organising data that takes into account what purpose the data is being used for, and what issue the use of the data is addressing. Named after John Zachman, who developed the concept at IBM in the 1980s.