What is a data architecture?

Depending on the size of your organisation, you often consciously or unconsciously think about how data is stored and processed. Perhaps an architecture has already been set up for the purpose of data quality within your organisation, and processes have already been put in place.

Even if you have not done that intentionally, it is still an architecture. You probably have a folder structure and use certain definitions.

A good data architecture lays the foundation for manageable data processes and high-quality data. In the ideal situation, such an architecture is drawn up by (a team of) Data Architects. But what exactly do they do?

What does an Architect do in the data/IT domain? 

Architecture in the data/IT domain is a diffuse and broad term. Common job titles often have a preceding descriptive term, such as Solution Architect, Enterprise Architect, or Data Architect.

Each of these roles has in common that the architect makes determinations about blueprints, guidelines and decisions that are made at a certain level in your organisation.

For example, a Solution Architect determines how a certain solution (think of a software solution) is implemented within an organisation. What are the interfaces between this solution and the rest of the organization's IT architecture like? And within the solution, which problem-solving directions are preferred here?

An Architect ultimately delivers system plates, guidelines and documents with which the organisation, and especially Data Engineers, can continue.

Build a data architecture? It's just like a house!

The work of an Architect in the data/IT domain is comparable to the role of an architect when you want to have a house or building built. You have an idea of what you want (a house…) and also what you want from it (living room, 3 bedrooms, 2 floors, a garage), but that's where your knowledge ends.

An architect can translate this into a concrete plan that explains how such a house can be built, taking into account your wishes and requirements. A contractor then works with these plans to actually build the house.

The 'building' is what the Data Engineers or a Systems Integrator do. 'Designing' is what the Architect does.

To maintain the analogy of building, an architect of a house would, for example, be a Solution Architect (the solution to the issue of 'living'). That Architect, on the other hand, has to work within the framework of a zoning plan.

Such a zoning plan is, in turn, drawn up from a different architectural domain – the municipality wants to have a residential area here with certain characteristics in its spatial plans. Someone who designs that would again be comparable to a domain architect in the IT landscape. This is how the levels within architecture are stacked.

A view of architecture: ideology versus pragmatism 

A good Architect can strike a balance between the desire to structure and order things (= ideologically) and to get things done (= pragmatism).

The design, the architecture, describes the ideology of what the Architect has in mind to be realised within his scope. Subsequently, things are then developed and delivered within that scope.

Generally, a Data Engineer produces a design based on the given architecture of how they want to solve an issue. Depending on how an organisation has set that up, the Architect can approve, reject, or advise on another solution direction.

The difference in data architecture between commercial and government organisations 

In practice, we see that commercial organisations attach less value to architecture than government organisations. The value of a solid architecture generally only pays off in the longer term, while commercial organisations often do not have such a long-term view. This process is similar to the technical debt principle of agile working, only on a different scale. 

In commercial organisations, an implicit architecture often does arise – the working method used and to which Data Engineers hold each other. The disadvantage of this is that because the team changes over time, the vision and knowledge level also changes.

In government organisations, an architecture that is too rigid often arises – there is little room for a solution outside the proposed frameworks, with which inefficient solutions are created 'because it has to be done according to the architecture'.

The best way to look at your architecture 

When it comes to architecture, our advice is to take the middle path. You want to have guidelines, frameworks and a vision of where you want to go, but at the same time, keep the flexibility to be able to develop in a way that is workable.

Good architecture offers the possibility to deviate from the ideal picture, and a good Architect realises that reality is often more unruly than the ideal desired picture.

At the same time, a good Data Engineer knows the importance of that same ideal architecture and the benefits it offers in manageability, portability and comprehensibility, to work according to architecture as much as possible.

Going back to the example of building a house: not every house is exactly the same, but it is rather nice that the electrical wires mean the same thing everywhere, water pipes are laid with the same connections, and that this way, there are even more standards we can use.

Need advice? 

Do you want to start setting up a data architecture, or do you see room for improvement in your current architecture? We are happy to think along with you! Contact us directly. 

Receive data insights, use cases and behind-the-scenes peeks once a month?

Sign up for our email list and stay 'up to data':