From data engineer to data architect
Many data architects started as data engineers. The step up is less about learning new tools and more about changing what you're responsible for: from building one system well to making many systems fit together.
What actually changes
| Data engineer | Data architect | |
|---|---|---|
| Main question | How do I build this pipeline well? | How should all of our data fit together? |
| Scope | A pipeline, a dataset, a platform component | Many systems, teams and domains |
| Output | Working code and data | Decisions, standards, models and roadmaps |
| Time horizon | This sprint, this release | The next several years |
| Success looks like | It runs, it's fast, it's correct | Teams build the right things in compatible ways |
Skills to build
- Data modeling at enterprise scale. Not just one star schema, but shared definitions of customer, product and account that many teams use.
- Integration patterns. Batch, streaming, APIs, change data capture: when each is right, and what each costs.
- Trade-off thinking. Every choice gives something up. Architects make the trade-off explicit and pick deliberately.
- Governance and security. Ownership, classification, access, lineage and quality, designed in rather than bolted on.
- Business understanding. Knowing why the data matters to the organization, in the business's own words.
- Communication. Diagrams, short decision records, and the ability to explain a design to an executive and an engineer in the same meeting.
Habits that get you noticed
- Write decisions down. A one-page architecture decision record (context, options, decision, consequences) is the architect's most underrated tool.
- Look one level up. When you build something, ask what else depends on it and what it depends on.
- Draw the current state of a messy area nobody fully understands. That map alone often changes how a team works.
- Review other people's designs kindly and specifically. It builds both skill and trust.
- Say "it depends", then say on what. Name the factors and recommend a path.
Your first architecture work
You rarely get the title first. You do the work first, then the title follows. Good first opportunities:
- Lead the design of a new data domain or data product.
- Propose a standard (naming, layering, data contracts) and get two teams to adopt it.
- Own a modernization plan for one legacy system.
- Volunteer to document data flows and lineage for an audit or compliance effort.
Common mistakes
- Designing in isolation. An architecture nobody adopts is just a diagram.
- Chasing tools. Principles last longer than products.
- Stopping coding entirely. Stay close enough to the technology to keep your judgment honest.
- Ignoring the operating model. Who owns what matters as much as what connects to what.