Forum Discussion
Generic Data Capability Question
- 1 day ago
Hi CeeVee33
Thanks for sharing this, and no need to apologise for posting it here. It's a fair question and one that comes up regularly.
My short answer is Option 2, but with the shared foundations agreed up front.
I would not recommend the big-bang model. Starting from almost nothing, it's very easy to spend a year or more designing around assumptions about the business and the source systems. Requirements will move while you build, and you'll have little to show the business in the meantime. With no existing BI function behind you, that's a difficult position to hold.
At the same time, I wouldn't build each use case in isolation. That tends to produce duplicated pipelines, conflicting definitions and disconnected models, which is close to the Excel situation you already have, just on a newer platform.
The middle ground works better. Spend a short period agreeing the things that are expensive to change later: key business definitions, common dimensions, modelling standards, data ownership and platform direction. Keep it to weeks rather than months. Then deliver one business area at a time, with each delivery extending the shared model rather than working around it.
A useful way to think about this is Kimball's enterprise data warehouse bus matrix, which sets out business processes alongside the dimensions they share. Their guidance favours building in manageable increments rather than attempting, in their words, "a galactic Big Bang approach."
One other thought. You mentioned money and resources aren't a constraint, but in my experience budget is rarely the limiting factor. The harder problems tend to be data quality in the source systems, agreement on definitions, and whether the business trusts and adopts what you produce. Those take time rather than money.
On your regulatory reporting, that's where your credibility will be won, but also where mistakes are least forgiving. I'd start with something visible and genuinely painful today rather than your most critical report, and move the higher-risk work across once the process has proven itself. Regulatory work also needs lineage, auditability and clear sign-off, so it's worth building those in from the start.
- Kimball Group — Enterprise Data Warehouse Bus Architecture
- Kimball Group — DW/BI Lifecycle Methodology
- Microsoft Fabric adoption roadmap
Best Regards,
C Srikanth
Community Support Team
Hi CeeVee33
Thanks for sharing this, and no need to apologise for posting it here. It's a fair question and one that comes up regularly.
My short answer is Option 2, but with the shared foundations agreed up front.
I would not recommend the big-bang model. Starting from almost nothing, it's very easy to spend a year or more designing around assumptions about the business and the source systems. Requirements will move while you build, and you'll have little to show the business in the meantime. With no existing BI function behind you, that's a difficult position to hold.
At the same time, I wouldn't build each use case in isolation. That tends to produce duplicated pipelines, conflicting definitions and disconnected models, which is close to the Excel situation you already have, just on a newer platform.
The middle ground works better. Spend a short period agreeing the things that are expensive to change later: key business definitions, common dimensions, modelling standards, data ownership and platform direction. Keep it to weeks rather than months. Then deliver one business area at a time, with each delivery extending the shared model rather than working around it.
A useful way to think about this is Kimball's enterprise data warehouse bus matrix, which sets out business processes alongside the dimensions they share. Their guidance favours building in manageable increments rather than attempting, in their words, "a galactic Big Bang approach."
One other thought. You mentioned money and resources aren't a constraint, but in my experience budget is rarely the limiting factor. The harder problems tend to be data quality in the source systems, agreement on definitions, and whether the business trusts and adopts what you produce. Those take time rather than money.
On your regulatory reporting, that's where your credibility will be won, but also where mistakes are least forgiving. I'd start with something visible and genuinely painful today rather than your most critical report, and move the higher-risk work across once the process has proven itself. Regulatory work also needs lineage, auditability and clear sign-off, so it's worth building those in from the start.
- Kimball Group — Enterprise Data Warehouse Bus Architecture
- Kimball Group — DW/BI Lifecycle Methodology
- Microsoft Fabric adoption roadmap
Best Regards,
C Srikanth
Community Support Team