How to make data architecture decisions

If you spent any time in college or grad school you likely read a lot of books. Or, were supposed to read a lot of books. Most of the book titles you can’t remember, let alone any of the book content.

However, one book from grad school (about academic writing of all things) stuck with me. They Say/I Say

It makes a simple point: Don’t just share ideas, respond to others’ ideas.

The temptation of the average college or grad student when they sit down to write a paper is to just launch into opinions. “I think this here, that over there, and especially this up there”. After all, aren’t we supposed to write original ideas?

But nobody cares just about your ideas. The argument of They Say/I Say is that the only way to create compelling arguments is to position your ideas in relation to others’ ideas.

This person says xy, while I agree with x, I disagree with y, I would add this and that, and the conclusions I have from these ideas are z

They say/I Say

Data architectures and technology choices are often like a college student writing a paper.

Someone picked out a bunch of technologies based on their opinions. Maybe they read a blog once about data lakehouses. Or saw a webinar about a fancy new data tool.

It’s a collection of ideas. It might work. But it’s not in response to anything in the business.

Last week a client showed me their proposed data architecture diagram. I started asking “Why this?” to a few things on the diagram. Their response - was “I like that tool” or “I read a blog about it last week”.

Every technology decision and every design decision needs to respond to a business need.

They say/I Say

The business shares its goals and objectives. The data team responds with technology and design to meet those needs.

I’m here,

Sawyer