Giving them options in Architecture

Respecting and ​partnering​ with your business teams often means ​giving them options​.

You can build this thinking into your data architecture by designing for options. It’s safe to assume that data consumers won’t want the data in the same way every time. That use cases will change, needs vary, and curiosities expand.

So give them options.

Here’s a great example from Go Daddy of a Data Architecture that intentionally provides ​data consumers with options​. It’s a fairly typical layered architecture (sometimes called Medallion).

After they described the nature of each layer in their data architecture, this part stuck out to me:

“Ultimately, clearly defining the data in each layer helps consumers determine the best place to source data for their use case. For some use cases, reducing latency is of the upmost importance so consumers may opt to consume from Clean and Enterprise layers. This means their jobs will likely have to perform many joins, process lots of rows, and implement complex logic. In other cases, consumers have a high tolerance for delays and opt to use more curated data sets to keep their processes simple, light-weight, and fast.”

Options. Does every data consumer value ease of use and minimal joins? No. Does every user want low latency and “closer to the metal” structure? No.

But presenting clarity about what’s available empowers the business teams to get the data they need in the way they need it.

I’ve talked with several Directors of Data over the last few weeks. Many of them were at the stage in their data journey of dreaming about the “art of the possible” and taking an initial step into the cloud.

There are hundreds of decisions to be made at that point. But the first and most influential decision is to embrace business-focused solutions, rather than cool tech toys.

It was good to see you today,

Sawyer

from ​The Data Shop