Structure before Content and why Application is King of your data.

Having worked with data for a long time now, it has come to my attention that we always talk about the same problems and rarely manage to properly address them, because it all gets lost in the practicalities of implementation. Too often we fall on the sword of Legacy, and claim that the effort of improving the overall value of our data is too costly to do.

My general observation is that we often misinterpret what sets the course for our data. And rather than come to a common conclusion we add complexity to fix the issue. Pushing data into systems and structures to solve a local problem. Which in turn sets up a basis for missing updates, lose of knowledge and responsibility. Large systems are created to contain all the data needed, variations of the same data pops up because the extent of data fields make it impossible to grasp… “but it is being used for something vital and as such we cannot get rid of it.”

It is easy to think that data itself defines the structure in which to store it, that the data itself has the property to give us the overview we all need to understand it. This I think is an error, not that it is not vital, to understand the data itself, but it often ends up being either too generic or too spread. An example would be to take colour of a product and say that anything related to colour goes into a data field called Colour. Colour is a good structure to define the visual presentation of a product, because it sets limitations for what it can be used for. It does only allow for data that specifies colours, eliminating other possible inputs, giving the data purpose and quality.

Once a structure has been defined it will all have to stand the test of the King; Application.

Why do I call Application king? It is rather simple actually. We design most of our data structures with the purpose or should I say Hope, that it will carry the data through the entire value change. From product features to calculations, but often we don’t take into account the intricacies of the use system and what purpose it has. Taking the example of colour, in our background systems, like ERP, it may be fully valid to indicate the RAL colour code which a product is to be painted with. It makes sense for a purchasing department to know that the company is running low on RAL3004. But for the customer it may simply be Red, that it a particular nuance of red, that may be as it is, but the customer buys it as Red.

The application of the data dictates a lot about how we should structure our data, what content to fill in, and where it is consumed. A seemingly simple thing, such as the colour of the product now has variation of application; RAL3004 and Red. Question is should they both go into the same field for colour or should we create separate sections to contain either of them. E.g. RAL_CODE holding the specific code and Colour defining the common names for colours.

Should all of it be contained in one big system or be split along the supply chain. That is a full topic on its own, suffice to say that any solution requires the input of knowledgeable people. First it requires someone to actually define a Base; the technicalities of a product and its features and benefits, and who takes ownership of this knowledge going forward. At other points it requires another expert to interpret the Base to make the distinction between a technical description and the needed Application e.g. RAL3004 to Red.

Hence Application is king, it challenges the structure and the content and can even require that we create new content and structures to suit it. It can also help define where data may be created and maintained and how we should work with it.

Is it easy to take all of these things into account, easy answer is of course a straight “No”. But by allowing for flexibility and having appropriate resources to manage the interactions along the value chain, can I believe alleviate much of the problems as long as there is an inherent common understanding of the data and where it comes from.