Raedan AI

Reflections Data Design: Part 3

Home » Mastering data » Reflections Data Design: Part 3

Mastering data

Reflections Data Design: Part 3

Design is an issue of concern to all industries. But in the data profession, the use of the word design is limited to a hierarchical perception of business requirements, or a network diagram.

If your family was to build a ‘dream’ house, everyone who intended to live there would be involved to some degree in designing a home that achieved the functional and aesthetic requirements of each family member. The process needs to discover the most valued characteristic of the home given each person’s different and common perspectives. The dog, the cat, and the goldfish would also be considered stakeholders in the final design.

An architect would likely be engaged to capture your thoughts, encapsulate them in diagrams, align the outcome to the budget and regulations, and then communicate the requirements to builders. The builders’ tradespeople would provide feedback if something was not going to work or could be improved.

Building homes is not an accidental process, but one that has developed over hundreds of years to start from ensuring that the Owners (the Royal Families) got the castle achieved their expectations around functionality and aesthetics. Otherwise, someone loses their head.

The same is true in the design of all products and services in the physical world. From the design of perfect veggies for the supermarket, furniture for homes, jewellery, and cars there is a clear process of design to ensure that, from source to the final product, the desired outcome is achieved and everyone along the way feels good about the outcome.

But in the building of information systems, what I see in many organizations is that the process is compartmentalized and lack a holistic view of the data supply chain.

Each ‘family’ member will ask for their ‘requirements’ separately. An architect will ‘consolidate them’. Someone will determine the budget, a developer will develop screens, an operator will key in data, the ETL developer will load it into a data lake and the analyst will go fishing for value. There are little reflection and consideration for how the process can be improved to maximize the business value produced.

There are two actions to take seriously:

  • Training: Everyone does need training? From the Executive, business, architect, and through to the ETL developer to appreciate that good information outcome only happen by deliberate design across the supply chain.
  • Culture: Recognise that a home-grown design process and culture is required to connect people to the data complex and find more balance in organizing our collaboration

I am pushing the word ‘Design’ because it is an issue of concern to all industries. There is no shortage of ideas and discussions on the nature of a good or bad design process or design artefact. But the use of the word design is limited within the data profession and when it appears, it might be referring to an architect’s perception of business requirements or a network diagram.

A data design process culminates in data models, basically a communication tool to ensure that human knowledge can be shared and understood. The importance of data modelling to the design of business data is why I am the Australian organizer for Data Modeling Zone in Australia.

Article by Andrew Smailes