Credit: Polly, Tanja and Neil Tamplin.
As we transition toward making services more joined up and data informed, one of our initial tasks is to understand the types of data that we record and where that data is being held.
At a high level we understand what systems we have and what purpose they serve, but as conditions change over time, the types of things that people record in systems can morph and become more complex.
Where to start?
We knew that to begin with we needed to identify all the types of things (‘entities’) we hold data about as an organisation. In doing so, we could begin to map these to different systems and identify duplication and natural sources of truth.
Identifying entities
We started by trying to identify our initial set of entities. To begin with we weren’t sure we had the level of abstraction right, but as we pushed on we became more confident that we were being consistent and were working at a high enough level that we wouldn’t get bogged down in technicalities too soon.
Here’s an example of some of the entities we identified.
- Customer
- Household
- Property
- Blocks
- Components / elements
- Repair / Job
- Invoice / Order
- Contractor / Supplier
- Tenancy / Account
There was some debate about whether certain entities were sub-types or types in their own right. For example, the concept of Blocks can be used for grouping properties at different levels. So we decided to settle on Block as an entity and presume that it’s recursive. (Scheme, Blocks, Sub-Blocks etc.)
Adding systems
As this was the first iteration of this work, we didn’t want to try and be too exhaustive on the first pass. Instead we compiled a list of our main systems.
For example…
- Total repairs
- Castleton Housing
- Sharepoint
In retrospect, in future iterations of this I think it would be useful to add the purpose of the system as well as the system name to make it more readable for others who may be less familiar with the whole estate of IT systems in the organisation. For example, Document Management (Sharepoint).
Building the grid
Now that we had a list of systems and a list of entities, we needed to cross reference them in some way. That way turned out to be a grid.
Down the side we placed our systems, and along the top we placed our entities.
Next we worked our way along each row, placing a green Post-It where an entity existed in a system. In some instances this sparked a really useful discussion about whether entities were captured or not. For anything we couldn’t immediately resolve, we put a question mark on the Post-It to denote that it required further investigation
Early on we found we needed to make a distinction between a system having a view of an entity in another system versus actually holding the entity within the system.
In some cases there was automation in place to push/pull updates from system to system. In other cases we found that it was manual duplication or the same types of entities being recording in isolation.
In starting to identify the most important entities and systems that weren’t automatically linked in some way, we began to build a much better picture of where our immediate priorities are with regards to our work with data.
Toward the end of our session, we began to identify where there were common identifiers between entities and systems in order to gauge the effort required for integration.
Next steps
Our Post-It note grid currently resides in one of our meeting rooms away from where the team work, so we need to transfer it to a more portable and permanent digital format so that we can continue to iterate upon it.
Where we’ve got some question marks, we’re going to arrange demo sessions with key users so we can get a better understanding of the workflow that happens in those systems so we can improve our knowledge of the types of data entities that might be applicable.