Oh boy, non-technical readers, please keep reading. This one is certainly for you! Hang on in, please.
For people who are not fully submerged in data practices, it is often very difficult to understand data models. More often than not, the ‘business user’ does not recognise their own data in these complex structures and models.
That is not necessary!
There is a very simple and meaningful way to describe the data that organisations use in a language that we all understand and use. In the diagram below, I have put 12 aspects, that together can describe 99% of what any business or organisation does.
The aspects I have used are common, but following good data architecture practice, I want to define them:
- object – a physical object or abstract object (a database for example);
- party – a person, group or organisation;
- time – a point or period in time, either relative or absolute (for example a ‘week’ or WWII);
- event – an occurrence of something (for example an accident or a measurement);
- location – an absolute, relative, long/lat or a named location;
- geometry – the shape in 2D or 3D or as a network;
- requirement – a prerequisite of an object, party or activity;
- activity – an act or series of acts by a party or an object;
- function – the natural purpose of a part an object or activity, irrespective of the context (for example a pump has a function to pump water from A to B);
- purpose – the goal of an object or activity described in business terms;
- relation – the relation between 2 things (for example a person is an instance of a party and a person is the driver of a vehicle);
- state – the state of a thing (for example ‘profitable’ for a company, ‘retired’ for an object, ‘in progress’ for an activity, ‘decommissioned’ for an installation);
I think you can apply these aspects easily to your own situation. The good thing is that these aspects can be refined to describe much more detailed parts of your business. As you go along and there is a need, you can go more detailed.
The beauty is, that a universal model like this can also be very easily understood by computers. This kind of model is based on linked data principles and allows many organisations on the Internet to link their data with data from others in a meaningful way.
To refine these aspects further and make them specific for your business, you can refine them. These aspects will be refined in 2 ways: as decomposition and as taxonomy.
With decomposition, you describe all the parts that make the whole. For example, a party consists of a company, which consists of departments, which consists of teams, which consists of persons.
A taxonomy gives more specific terms, more narrowly defined terms. For example, an object can be a construction, which can be a bridge, which can be a bridge for trains. There are also bridges for cars, bridges for pedestrians. There are also constructions such as roads, dykes and pipelines.
In this short blog, I hope I have shown you that data models can be very universal at the highest level and in structure. In the same way, the Internet links data together, you can link your own data in a meaningful way. Even users without a background in data can understand and refine these models.
Note 1: Most aspects can have a relation with each other and dependent on the need for the data model, they can be described. For example, a company has a board, is the owner of an installation, produces computers, has resellers, is located in a certain town, is 25 years in business to date, is profitable, etc.
Note 2: Not all aspects are applicable all the time. For example, if you have a lot of existing installations (brownfield), you will probably not describe most of the purpose, functions, requirements and geometry. It is a lot of extra investment and mainly relevant to the design and build phases (greenfield).
Note 3: Possible expansions of the list are ‘role’ and ‘information’.
A role can make the relation more specific. For example, a person can be the owner of a car, but you might want to describe since when the person is the owner.
Information is a more specific object to describe documents like contracts, data, websites, etc.