Hey friends, Happy Monday!
The data architect is the role I loved most in my whole career, and it’s the one I almost never see explained honestly.
There’s no roadmap for it, no course that makes you one, and most of what’s written about it online is a vendor selling a platform.
That why I went last week talking about it and tomorrow continue where I will show you how to create Data Architecture Live! 🕔 17:00 Berlin
Who Is the Data Architect?
Before a company builds anything big with data, someone has to make the plan.
That someone is the data architect, and the job works exactly like building a house:
Listen: sit with the business and understand what they really need.
Draw: turn those needs into a blueprint, on paper, nothing built yet.
Hand over and stay: give the plan to the engineers and mentor them until it works.
That’s the job on paper. In reality you’ll do several jobs at once: I started at Mercedes-Benz as a solution architect and ended up designing, building, and leading projects at the same time.
The architect doesn’t build the house. But if the wrong house gets built, that’s the architect’s mistake.
Architect or Engineer?
Right now some of you are thinking: I’m a data engineer, I already design my own pipelines, so am I not doing this already?
Careful, because the usual answer (”the engineer builds, the architect decides”) is wrong. Engineers decide all day.
The real line is which decisions:
The engineer makes a hundred decisions a day inside one pipeline.
The architect owns the ten decisions a year that the company can’t easily undo: which platform, one copy of the data or many, batch or streaming, build or buy.
And here’s the test I want you to keep, my friend. It’s the cleanest one I know:
If reversing it needs a migration project, it was an architecture decision.
The job ads say the same thing. I put the architect ads and the engineer ads side by side, concept by concept:
Data pipelines is the number one concept in engineer ads at 62%, and in architect ads it falls to place thirteen at 25%. Data architecture runs the other way: 71% for architects, 23% for engineers.
Same data, different job. The architect isn’t a senior engineer with a nicer title.
What the Job Ads Say
I didn’t want to guess what companies expect, so I analyzed 14,600+ real job ads.
Only 364 of them were hiring data architects.
The skills are less exotic than you’d think:
The tasks are where the job really shows its face. Design the architecture is 83%, and then it turns into governance and people:
The experience is the wall. A median of 7 years, and out of all 364 ads, exactly 3 were junior:
To be honest with you: this is not a job you apply for. You grow into it, the same way you grow into being a manager.
Now you might tell me: “3 junior roles, so this is years away for me.”
Well, the title is years away. The thinking isn’t, and the last section of this post is about starting it this week.
The 10 Architects You Don’t Want to Be
I met a lot of architects in my career, and the ones who failed usually failed the same way:
The tool guy: every discussion is Databricks vs Snowflake, never the actual problem. The company’s real pain never makes it into the room.
The theory guy: they know every concept and never built one. You can’t plan a house you never helped build.
The big spender: they plan like the company has endless money. The price reaches the manager, and the plan stops right there.
The overkiller: they bring complexity because they like complexity. The company asked for a few reports and gets a data mesh.
The talker: good ideas in every meeting, and not one of them on paper. A plan nobody can see is a plan nobody can follow.
The diagram factory: 20 pictures, and they keep switching between them. Ask for the plan and you get a folder instead of an answer.
The big banger: they design alone for weeks and reveal it at the end. That’s the meeting where the architecture dies, because everyone is seeing it for the first time with an audience.
The baby defender: the design becomes theirs, so they defend it against the evidence. Changing it feels like losing.
The stubborn one: the whole team struggles with the plan and they don’t move. Being right matters more to them than getting it built.
The ghost: they present the plan and leave. The architect owns the plan until it’s built, and this one is already gone.
And the one that costs the most: the exception becomes the standard. Let one team skip the rules just this once and by Friday three other teams quote it as precedent.
Change the plan for everyone, or hold it for everyone. There’s no third door.
The Career Ladder
As a data engineer or analyst, you have three doors in front of you:
Management: team lead, department lead, and up. High ceiling, but you trade the tech for politics and people problems.
Expert: senior engineer, senior analyst. You keep the tech, but senior is usually the last stop.
Architect: the third door. You keep the tech, you skip managing people, and the ceiling opens all the way up.
And the architect door has its own three levels:
Casual: you’re still building, and you also design the thing you build. Some of the best architectures I’ve seen came from an engineer who stepped up. This was me at the start.
Dedicated: out of the single team. You turn department needs into blueprints, sign off other teams’ designs, and stop two teams building the same thing twice.
Principal: you turn the company’s data strategy into a target architecture, pick the platform, set the standards everyone reuses, and watch the total cost.
Before I left Mercedes-Benz for content, principal was exactly the role I was targeting.
Vendor Architecture vs Data Architecture
Google “data architecture” and you’ll get pages of diagrams packed with logos.
My friends, that’s not a data architecture. That’s a vendor architecture: a company selling you their tools.
Draw one of those at work and they’ll throw it back at you. You’re not solving the company’s problem, you’re just another guy selling Microsoft products.
A real data architecture answers real questions:
Where does the data come from, and where does it go?
What happens inside every box: full load or incremental? Batch or streaming? Which data model?
Who owns it, who may see it, how long we keep it, and what it costs.
If your diagram only shows logos, it’s an ad, not an architecture.
How I’d Start in a New Company
If I got hired as a data architect tomorrow, this is exactly what I’d do.
Phase one, I change nothing. No tools, no proposals, no criticism, no timelines. I’m here to understand first.
Then I talk to everyone, in this order:
The business first, IT second: what do they do, and why do they need data?
The source owners: how is the data born, and who answers when it breaks?
The engineers: what exists today, what are the pains, how long does a load take?
The managers: where does the money come from?
Then I draw the current situation. The mess as it is, ugly and honest, on one page, plus the list of pain points.
That’s my first delivery, and it buys everything else, because most companies have never seen their own picture. Be careful here: no finger pointing, just the picture and the “because” behind every pain.
Then quick wins, small fixes that buy trust, and only then the target architecture.
Then I sell it before the meeting. Security alone first, then the loudest skeptic alone, then the sponsor last.
I’ve watched good architectures die in review, not because they were wrong, but because the security officer saw them for the first time with an audience.
Then I stay and mentor the engineers through it, and when reality disagrees, the drawing changes. Mine lived for 5 years and never stopped growing.
You listen first, you draw second, and you stay until it works.
The Questions You Carry
Every box in a good architecture is the answer to one of these questions:
Where is the data born?
How fresh does it really need to be? What breaks if it’s a day late?
Who consumes it, and with what skills?
How big is it, today and in two years?
Does it already exist somewhere in the company?
The second one saves the most money. When the business says real time, never argue, just ask what they’d do differently if the number arrives at 9:05 instead of tomorrow at 8.
Silence means batch. A real answer, somebody gets paged, an order reroutes, means streaming, and now you also know what it’s worth.
And watch for requirements with a tool hiding inside them. “The data must be in a Kafka topic” is somebody’s favourite answer wearing a requirement’s clothes.
A requirement tells you what and how well. The moment it names a tool, someone else already did your job, badly.
Start Before the Title
You don’t need the role to start, and this is the part I really want you to take:
Be the one who draws. In your next project, draw the picture nobody asked for: sources, layers, consumers. If a diagram already exists, draw your own anyway and bring it as a question, not a correction.
Write down why. One page per decision: the options, your pick, the price, who agreed. The industry calls these decision records, and architect ads ask for them by name.
Count the arrows. Every arrow between two teams is a promise: an owner on each end, a format, a timing, a bill, and a phone call at 3am when it stops flowing.
Learn draw.io. Free, runs in the browser, and it’s what I saw companies actually use.
Juniors count boxes. Architects count arrows.
Diagrams show what you built. Decision records prove you can think. In the architect interview, they ask for your decisions, not your drawings.
So …
If you keep only a few lines from this one, keep these:
If reversing it needs a migration project, it was an architecture decision. That’s the whole job.
It’s not an entry job: median 7 years, and 3 junior ads out of 364.
The path is wider, not higher. No authority, three yeses, paid for the mistakes you prevent.
Half of this job is politely not building things, because every box costs money forever.
A data architect is the person who understands the business first, draws the plan second, and stays until it works.
Next time I’ll take you through the architectures themselves: the warehouse, the lake, the lakehouse, and why companies are now splitting everything into domains.
Hit reply and tell me which one you want first, I read everything.
Thanks for reading ❤️
Baraa
Also, here are 4 complete roadmap videos if you’re figuring out where to start:
📌 Data Engineering Roadmap
📌 Data Science Roadmap
📌 Data Analyst Roadmap
📌 AI Engineering Roadmap
Hey friends —
Hey, I’m Baraa, a Data Engineer with over 17 years experience, Ex-Mercedes Benz, where I led and built one of the biggest data platforms for analytics and AI.
Now I’m here to share it all through visually explained courses, real-world projects, and the skills that will get you hired. I’ve helped millions of students transform their careers.
Hey Baraa, as I was going through the article I kept thinking that the principles of an architect can be applied in other data roles as well... and then I saw the "Start Before the Title" section so I got my confirmation :)
Thanks for sharing your knowledge on this, by the way for the drawing part I find excalidraw also very fun to work with.
Would love to see an in depth discussion of lakehouse builds, as that seems to be what you advocate for on your SQL warehouse build and seem to have done on a large scale. Love the articles!