I can’t speak for other data architects, but one of the things I do most frequently is answer this question. I have used every metaphor imaginable in an attempt to turn something that is inherently abstract into something tangible.
Data architecture is like a waltz. Two parties learn to speak a common language while moving in the same direction as all the other parties around them.
Data architecture is like a rail network. Data is like trains which must be moved sequentially from station to station.
Data architecture is like a washing machine (I didn’t get very far with this one).
The metaphor approach tends to have the opposite of the desired effect – the poor individual tends to go away talking about dancing or trains or dirty laundry but still with no real idea what any of it means. So, instead, let’s talk about a couple of real-life examples.
A case study
A project comes to data architecture. They have been tasked with upgrading a legacy database to something cheaper, simpler, and generally more up to date. In order to do that, they’ll need to abstract the 1s and 0s of the data to something a bit more human-readable – a physical data model. This represents the tables and columns and relationships of data in the database’s own terms. A database administrator could take this and rebuild the database from scratch.
But there’s more to do! To move this data, they’ll need to understand it as a generic database rather than a specific one. So, they abstract their physical data model to a logical data model. Now the business analysts start to nod along – they don’t really know what the diagram means, but they recognise the term ‘address’ and the term ‘customer account’, they see that they are linked by a line, and they begin to get a picture of how the underlying data is structured. They believe that each customer account should be allowed two addresses instead of one, and this rule is added to the target model.
The role of the data architect
Data architects come in at every stage of the process I’ve described. They define a standard way for those models to be created, approved, and published. They define the roles for the people in that process, from the data modeller who makes the model, to the subject matter experts who approve it, to the data stewards and asset owners who have the responsibility for the data itself. If the database needs to interact with others, they will produce the high-level designs for the information transformation and flow from one store to the next.
A well-resourced data architecture team frequently lends out its members to specific projects across the organisation. But they also carry out their own projects to support the overall data strategy.
Your organisation’s data strategy may vary, but in general, a data strategy should support the discovery, use and management of information by the appropriate people, processes and technology. The goal is to allow data to be easily used and reused and thereby increase its value.
Linking to a business glossary
One of the most common ways to promote reuse of data is to create a list of common business terms (AKA a business glossary), with a definition of each. The data architecture team can then link apparently disparate data stores to this business glossary, by identifying occurrences of those business terms. You now have links between your previously disparate data stores, with the business glossary acting as a proxy.
For example, you have ‘customer reference number (CRN)’ in your business glossary. By investigating this term, you find it is stored in two different databases. You can now choose to delete the CRN from one database, and just link to the master source in the other one instead. In most cases, this makes the data easier to maintain – it’s easier to maintain one thing than two!
Hopefully that served as a good introduction to data architects and a few of our favourite buzzwords. The bottom line is that data architects help the organisation squeeze more value out of their data. But don’t just take my word for it. Data architects love to talk, so ask your friendly neighbourhood data architect what they can do for you!