A data architect designs how information moves, is stored, and is understood across an entire organisation — from the raw feed to the report on a screen.

Every company runs on numbers. Customer counts, order totals, cost per unit, retention curves, sensor readings. The data architect is the person who decides where those numbers live, how they get from where they were created to where they will be used, and who is allowed to touch them along the way.

They do not usually build the dashboards, and they do not write the machine learning models. They design the plumbing underneath both, and the shared vocabulary that lets ten teams say “active customer” and mean the same thing.

Sources are the springs and rivers. Ingestion pipelines are the treatment plants. The warehouse is the reservoir. Dashboards and APIs are the taps in the buildings. Governance is the water-quality report the city publishes every quarter. When one of those links is missing, the whole thing tastes wrong.

Not a database administrator. Not a data engineer. A senior designer whose product is the shape of the company’s data.

The confusion starts with the fact that three closely related roles all touch tables and pipelines every day: the DBA, the data engineer, and the data architect. Each one is real, each one is different, and knowing the difference is the fastest way to understand what the architect actually owns.

You can run a small company with no data architect at all — someone senior on the engineering team just makes the calls. You cannot run a large one without at least a part-time equivalent, because the number of stores, the number of consumers, and the number of regulatory obligations grow past what any single team can hold in their head.

Five things stay on the architect’s desk no matter what team they sit in.

Titles vary. Companies argue about what the role includes and what it does not. But if you look at what data architects actually do — and what quietly breaks when the role is missing — the same five responsibilities show up again and again.

Notice what is not on this list. Writing the day-to-day Airflow DAGs, tuning a slow query for one report, restoring last night’s backup. Those belong to engineers and DBAs. The architect might help debug when the failure is architectural — a bad model, a wrong choice of store, a broken contract between systems — but the ordinary operational work is not theirs.

One idea, three levels of detail. Move too fast between them and everything gets muddled.

When a data architect draws a model, they are almost always drawing it three times — once in the language of the business, once in the language of the schema, and once in the language of the specific storage engine. Each layer refines the one above without contradicting it.

Conceptual: the business vocabulary

Nouns and verbs the business already uses. Customer. Order. Shipment. Refund. No columns, no keys, no types. Just the entities, their most important attributes, and the relationships between them. Non-technical stakeholders should recognise their own world in this picture.

Logical: the schema, tech-agnostic

Now the entities become tables (or documents, or nodes). Every attribute gets a type, every relationship gets a cardinality, every primary key and foreign key is spelled out. This layer is portable — the same logical model could be implemented in Postgres, in Snowflake, in Cassandra.

Physical: the actual database

Now it lives in a specific engine. Indexes on the columns that will be filtered. Partitions on the columns that will be scanned. Clustering keys, materialised views, storage tiers. Choices here are shaped by the query patterns, not by the business.

Governance is where the architect stops being a schema designer and starts being a policy designer.

Governance is a scary word for a very ordinary idea: making sure the right people see the right data, and that when a number shows up on a slide, you can trace it back to where it came from.

A data architect does not personally write the access policies for every table — that would not scale. They design the system that lets those policies exist and be enforced consistently. Five pieces show up in almost every serious governance setup.

The role has fanned out. Five common variants, each with a different centre of gravity.

“Data architect” is a small title covering a big surface. In the last decade the field has fanned out into several specialisations that share the same core skills but pull in different directions.

Small companies collapse most of these into one person. Larger ones separate them. When a job description says just “data architect”, the first useful question at the interview is: which of these is really the job?

Meetings, models, and a lot of asking “what does that number mean?”.

The exact hours differ from person to person, but the rhythm of the day is remarkably consistent across companies. Design work in short blocks, questions and unblockings in between, and one or two longer sessions where they actually get to think.

Three families — modelling, platforms, and people — and the architect has to be at least competent in all three.

Nobody is world-class at everything on this list. The strongest architects are excellent at modelling, very good at platforms, and unusually good at explaining both to non-technical stakeholders.

Almost everyone who touches a number. That is why the calendar looks the way it does.

The architect is a hub role. If you drew a map of the people they interact with in a normal fortnight, it would fan out to almost every function that produces or consumes data.

The single most common problem the role is hired to solve. Here is the shape of a real fix.

A data silo is what happens when a team — usually for good local reasons — builds its own store, its own definitions, and its own reports, and never quite connects them to the rest of the company. Multiply that by a few departments and you have a business that cannot answer basic questions about itself.

You do not fix silos by shouting about them. You fix them by patient, sequenced work.

The role attracts confident opinions from people who have not sat in the chair. A few of them are worth answering directly.

“A data architect is just a DBA with a fancier title.”

A DBA keeps one database healthy. A data architect decides which databases exist, what shape they take, how they connect, and how the whole platform is governed. Different job, different scope, different skill mix. Some architects do come from a DBA background, but so do many who come from engineering, analytics or software architecture.

“Data architecture is only about storage.”

Storage is the visible half. The invisible half — models, contracts, quality, access, lineage, retention — is where the leverage is. Get the storage right and the models wrong, and the platform is fast and useless. Get the storage wrong and the models right, and you have a tuning problem, not a design one.

“Once the data model is built, the job is done.”

The business does not sit still. Products change, regulations tighten, teams reorganise, new sources arrive. A living model is one that a small group of people, led by the architect, evolve continuously. The day nobody is evolving it is the day it starts to drift out of usefulness.

“Data architects slow everything down.”

They can, if the process is bad. A good architect adds review only where the cost of a mistake is high — shared entities, cross-team contracts, regulated data — and gets out of the way everywhere else. Slowness usually means the boundary between “architected” and “delivery-owned” is drawn in the wrong place, not that the role is unnecessary.

The whole guide, compressed into a handful of lines you can carry into your next conversation about data.