No, centralise the core data governance team, those who manage a common semantic understanding of your terms, models and usage across your domains, ideally a core ontology team that owns the conceptual ontology, and distribute data teams close to each domain that use the conceptual model to harmonise towards the conceptual model.
You get speed, agility, ownership, democratisation in the data teams, and a common semantic, controlled, small, conceptual ontology to manage data governance, including tech debt.
Centralising all data teams create a bottleneck for all the data domains.
Morten - yes, bottlenecks would be a terrible outcome! I'm glad you got my main thesis, eliminating technical debt. I'm really interested in which industries you've managed data in. Balancing these definitely takes experience.
Yes, it is a delicate balance and there is no true, single solution for all. I have worked with information and data across different business areas. Banking, finance, insurance, retail, industry, transport, health, and others, and mostly the problem is lack of governance, or misusing governance as a controlling function, no common understanding of what kinds of data are where and ownership and I could go on.
But a single central function for the entire data domain will be a bottleneck. You only need to centralise the conceptual layer. It is not a big job in itself, but it requires some maturity, and an understanding that dashboards with customer stats will never be right unless you understand an organisations 8, 12 or 18 different definitions of customer.
Many of my ideas come from Cal Newport and his book "A World Without Email." Super thought-provoking on the idea of governing knowledge work. It's definitely outside-the-box thinking.
Maybe bottlenecks happen when BI teams don't really understand the business? Many semiconductor companies integrate BI into every business decision, and nobody questions centralization. I'll be writing more on this soon.
Thank you so much for your feedback on this article. I really appreciate it!
Centralizing everything comes with it's own set of problems. I would argue that those teams aren't really incentivized to say "Yes". What I have seen is teams that lose the muscle memory of the business and friction builds up in the middle where people try to translate their needs to a data team that has been optimized on technical skills. Data people work best when they are close to their business partners.
In a large Enterprise there is no perfect answer, but I think hub and spoke style federation tends to give the best outcomes with the least friction.
100% agreed, especially on the federal model. Real business partnership is so rare, and we need to keep that as the main focus.
The thesis in this article didn't hit me till I started writing on "technical debt". I think the org chart itself contributes to adding or decreasing it. What do you think?
It certainly can, but there isn't a"golden org chart" that fixes it. It has more to do with culture than anything else. Is there a strong architecture practice? Is there oversight (Technology and DG) that has the ability to escalate concerns? You want innovation, but innovation without oversight is chaos. 40% of technical debt is "We thought it was a good idea at the time". Another 40% is "I know there is a better way, but this is what I know how to do." The hammer in search of a nail approach. It's not a simple fix, but the orgs that invest in practices, training, and engaging the dev community do better in the long run.
The best book I've read on this topic is "Enterprise Architecture as Strategy" from HBR (2006). It's not specifically on tech debt but on aligning business processes with tech stacks.
Clearly, you understand this subject better than most anyone. I'm planning a follow-up focused on deciding which roles, responsibilities, and parts of the architecture should and should not be centralized. I'd love to get your feedback on it, even before publishing.
You are too kind. I am just someone who has been around long enough to watch the pendulum swing back and forth on this topic a few times. I am happy to provide feedback if you want.
No, centralise the core data governance team, those who manage a common semantic understanding of your terms, models and usage across your domains, ideally a core ontology team that owns the conceptual ontology, and distribute data teams close to each domain that use the conceptual model to harmonise towards the conceptual model.
You get speed, agility, ownership, democratisation in the data teams, and a common semantic, controlled, small, conceptual ontology to manage data governance, including tech debt.
Centralising all data teams create a bottleneck for all the data domains.
Morten - yes, bottlenecks would be a terrible outcome! I'm glad you got my main thesis, eliminating technical debt. I'm really interested in which industries you've managed data in. Balancing these definitely takes experience.
Yes, it is a delicate balance and there is no true, single solution for all. I have worked with information and data across different business areas. Banking, finance, insurance, retail, industry, transport, health, and others, and mostly the problem is lack of governance, or misusing governance as a controlling function, no common understanding of what kinds of data are where and ownership and I could go on.
But a single central function for the entire data domain will be a bottleneck. You only need to centralise the conceptual layer. It is not a big job in itself, but it requires some maturity, and an understanding that dashboards with customer stats will never be right unless you understand an organisations 8, 12 or 18 different definitions of customer.
Many of my ideas come from Cal Newport and his book "A World Without Email." Super thought-provoking on the idea of governing knowledge work. It's definitely outside-the-box thinking.
Maybe bottlenecks happen when BI teams don't really understand the business? Many semiconductor companies integrate BI into every business decision, and nobody questions centralization. I'll be writing more on this soon.
Thank you so much for your feedback on this article. I really appreciate it!
ZH
Centralizing everything comes with it's own set of problems. I would argue that those teams aren't really incentivized to say "Yes". What I have seen is teams that lose the muscle memory of the business and friction builds up in the middle where people try to translate their needs to a data team that has been optimized on technical skills. Data people work best when they are close to their business partners.
In a large Enterprise there is no perfect answer, but I think hub and spoke style federation tends to give the best outcomes with the least friction.
100% agreed, especially on the federal model. Real business partnership is so rare, and we need to keep that as the main focus.
The thesis in this article didn't hit me till I started writing on "technical debt". I think the org chart itself contributes to adding or decreasing it. What do you think?
ZH
It certainly can, but there isn't a"golden org chart" that fixes it. It has more to do with culture than anything else. Is there a strong architecture practice? Is there oversight (Technology and DG) that has the ability to escalate concerns? You want innovation, but innovation without oversight is chaos. 40% of technical debt is "We thought it was a good idea at the time". Another 40% is "I know there is a better way, but this is what I know how to do." The hammer in search of a nail approach. It's not a simple fix, but the orgs that invest in practices, training, and engaging the dev community do better in the long run.
The best book I've read on this topic is "Enterprise Architecture as Strategy" from HBR (2006). It's not specifically on tech debt but on aligning business processes with tech stacks.
Clearly, you understand this subject better than most anyone. I'm planning a follow-up focused on deciding which roles, responsibilities, and parts of the architecture should and should not be centralized. I'd love to get your feedback on it, even before publishing.
Thanks!
ZH
You are too kind. I am just someone who has been around long enough to watch the pendulum swing back and forth on this topic a few times. I am happy to provide feedback if you want.