“It’s our challenges and obstacles that give us layers of depth and make us interesting. Are they fun when they happen? No. But they are what make us unique.”
Ellen DeGeneres.
I love looking at data and making sense of it for transferring, sharing and leveraging between systems. There are two distinct layers that the data architect must relate to:
- Format – this relates to the structure of the data, the fields, the tags, the transfer protocols, etc
- Context – this relates to the meaning of the data, the naming conventions, the subject matter relevance, the methods of matching like linking keys, etc
I’ve seen too many data architects who are strong at the first, but have no interest in learning about the second. In my opinion, it is impossible to do this job properly without ensuring that you have an understanding of both. At worst, there needs to be a symbiotic relationship developed between the data architect (item 1) and the data subject matter expert (item 2).
For example, if you’re architecting an inventory model, it is essential to understand how the network elements, cards, ports, services, network topologies, etc are formed and utilised by other members of the team (eg field work-force, network operations, etc) and not just have an understanding of the XML conventions or similar. Otherwise, you face the risk of having perfectly formed data that is useless or unusable by the people you’re architecting it for.