A day in the life of a…..Data Architect

In our ‘A day in the life of a…’ series , we talk to another of our specialist consultants at Start with Data – the data architect. As the name suggests, this role is about building systems, but there’s more to it than that.

I’ll jump in with the obvious opener: what exactly does a Data Architect do?

Data architects create blueprints for data management systems. After assessing a company’s potential data sources (internal and external), architects design a plan to integrate, centralise, protect and maintain them. This allows employees to access critical information in the right place, at the right time.

Can you give me an example of how they work?

OK. Once a company decides they want to overhaul their system and implement a major system like a PIM or MDM, they need a structure for it. So, for example, they need to know who is going to talk to whom. A product manager might need to talk to suppliers, to interact with warehouse people, with the customer, and so on. Will the communication be bi-directional? The data architect deals with dimensions like these. We start with all these high-level business interactions, such as how and when they communicate. We then create an Enterprise Information Model based on satisfying the needs and desires of the client.

OK. An Enterprise Information Model…?

Yes. That contains all the functional areas involved. So we need to get more information on customers, suppliers, warehouse management systems, product categories. Once we’ve established the strategic, senior management level vision and aims – at CEO. CDO and COO level – we move down to  the level of program manager to establish the need for a detailed product area for the transformation project.

How did you become a data architect?

I started my career as a data warehousing developer. Within that, I was involved in data modelling and data cleansing. Then I moved onto being an ETL solution architect.


That’s ‘Extract-Transform-Load’. When data moves from operations to warehouse, you use ETL tools to extract it from the source system, transform it as the warehouse requires and load it into the warehouse. I did that for several years, working with banks and retailers mostly. Then I moved into data modelling, which is what a junior data architect would do. Now, I’m a data architect, a role which is at a higher, more strategic level.

What skills does a data architect need?

Well, a junior data architect needs to understand data modelling firstly. That means developing a high level understanding of how systems interact together, the kinds of interfaces, how data is transferred. But in my present role, the most important thing for me is to understand the business, understand the business’s requirements – then transfer those requirements into these models.

What’s a typical day like?

Mostly, there’s a timeframe involving speaking to stakeholders, understanding and capturing requirements and going away to model it. I spend time developing this model and re-present this to them. They give feedback – for example, they may say there needs to be another inter-system relationship that I need to add. This architecture then passes on to the next level – the solution architect.

What’s the difference between a data architect and a solution architect?

A solution architect looks more at technology – if 2 systems need to ‘talk’ to each other, they analyse what specific technologies they need to fulfil that function. Data Architects are technology-agnostic. That’s to say, we’re unbiased towards the use of any specific technologies to solve the business challenges. We are operating at a higher, more organisation-wide level. I develop a pretty detailed conceptual model, which is business-function-specific. For example, if we talk about products, I’ll create a conceptual model specific to that business’s products – descriptions, dimensions, specifications and so on. That’s defined at a high level. From there, we’ll speak to the product manager to find out exactly what they need  at the specific attribute level – name, description, weight, colours, legal and regulatory requirements and so forth.

And that’s when the solution architect comes in…?

Right. If they need it, we create either a canonical or a physical model suitable for the technology being deployed. So we speak to our business analysts, but later on in the process.

So you’re in regular contact with colleagues?

Yes, we speak to every other person in the team. I inform the technology team about the data structure I’ve created, how it works and how whenever it is talking to other systems, they should be using the structure I’ve established. We may have short stand-up meetings to clarify any doubts or technical problems they may have, but generally, the technology-specific models of the project don’t affect our high-level models.

So you have the strategic overview of the overall structure and the solution architects are working at a more granular level in addressing specific areas that need attention. Then you feed that information on to the provider, right?

Yes. In a nutshell.

So in terms of a PIM implementation project, you’re in there at the beginning…

I am. I’m with the business consultant but also working very closely with the business analyst. They give us the business requirements so we are interacting with them to ensure we act on the right business needs.

If you would like to find out more about how our product data management consultants can create value for your business, we’d love to hear from you – Ben Adams, CEO Start with Data

We’re always looking for talented people! Read more about our culture, the experience required and our current roles available. We’d love to hear from you – Joanna Hall, Head of Talent, Resourcing & People Operations