Nice read! Just curious, how would you apply these taxonomies to a very small startup with a nonexistent data team or a team of one engineer?
I’m wondering mostly about architectural and tech stack decisions that can be made at an early stage to enable flexibility in either staying centralized or moving towards hub and spoke with company growth. This could be a separate topic. 🙂
With a nonexistent data team or one engineer I would focus on centralisation, while inviting business stakeholder to remain close to the analytical tooling builds. As you scale, then consider more decentralisation, but focus on building the data knowledge, culture and literacy of those relevant business stakeholders at the same time (maybe assign them some data ownership or stewardship)
Key is to just think about your long-term goals, where do you want to be and how does your org structure and platform facilitate that growth
Haha love to publicly call things out! Honestly I did a ton of research on it and fail to see why it is the next big thing. I'll do a whole article on it/ a holistic data platform at another point, and hopefully it will be less confusing that time around
This is an excellent exposé, Dylan. In my experience, aside from business goals, your data platform architecture also depends a lot on the operation model of the business.
I prefer using a centralised approach with more sales-driven businesses or businesses with fewer tech-savvy people.
The Hub & Spoke model works great for more tech-oriented organisations. It's essential to mention that collaboration is critical here. The central data team may not have control but still can influence the technology choices when that makes sense.
Thanks! Yes the operating model and org structure is honestly the biggest driver, hence why I referenced those so much in the article. I like how you think btw, that is how I would approach it too with more of a centralised lean until the domain/ spokes became comfortable with how to use data
Nice read! Just curious, how would you apply these taxonomies to a very small startup with a nonexistent data team or a team of one engineer?
I’m wondering mostly about architectural and tech stack decisions that can be made at an early stage to enable flexibility in either staying centralized or moving towards hub and spoke with company growth. This could be a separate topic. 🙂
With a nonexistent data team or one engineer I would focus on centralisation, while inviting business stakeholder to remain close to the analytical tooling builds. As you scale, then consider more decentralisation, but focus on building the data knowledge, culture and literacy of those relevant business stakeholders at the same time (maybe assign them some data ownership or stewardship)
Key is to just think about your long-term goals, where do you want to be and how does your org structure and platform facilitate that growth
"The Data Fabric platform philosophy is confusing"...Finally, someone's had the guts - and nous - to say this publicly!
Thanks for another great article, Dylan, that clarifies these approaches to operating a data platform.
Haha love to publicly call things out! Honestly I did a ton of research on it and fail to see why it is the next big thing. I'll do a whole article on it/ a holistic data platform at another point, and hopefully it will be less confusing that time around
This is an excellent exposé, Dylan. In my experience, aside from business goals, your data platform architecture also depends a lot on the operation model of the business.
I prefer using a centralised approach with more sales-driven businesses or businesses with fewer tech-savvy people.
The Hub & Spoke model works great for more tech-oriented organisations. It's essential to mention that collaboration is critical here. The central data team may not have control but still can influence the technology choices when that makes sense.
Thanks! Yes the operating model and org structure is honestly the biggest driver, hence why I referenced those so much in the article. I like how you think btw, that is how I would approach it too with more of a centralised lean until the domain/ spokes became comfortable with how to use data