In our trainings and consulting practice, we often pitch the idea of “focusing on the business value” to the audience. Business value in enterprise data warehousing is defined as “something of value to the business” (believe it or not, we believe it should be said sometimes).
Typically, the reason by business setups a budget for the enterprise data warehouse is that they want some reports or dashboards with actionable information.
On the other hand, the most important counter-argument is that the enterprise data warehouse is more than just reports and dashboards. There is actually a lot of more technical components (non-functional requirements) to be built, including but not limited to:
- Infrastructure and storage
- Networking setup and security
- Multiple environments
- Performance tuning
- Maintaining security
- Privacy obligations require the deletion of consumer records
- Automated Continuous deployment
- Testing strategy is required
- Auditability and data lineage
- Operational aspects
- Data quality and data cleansing (good, bad and ugly data)
- Data and information governance
- Metadata management
- Data warehouse automation
This is all right, and we fully agree with that. However, all these non-functional requirements are of secondary priority for the business user. They (typically) don’t care that the enterprise data warehouse is developed with a fancy new technology or that the deployment is performed in a fully automated fashion.
I do, because I’m a tech person. But should business actually care?
The Short answer is “well, maybe”.
No, because it is not their primary intent why they came up with the idea to introduce an enterprise data warehouse in the first place (I bet because of the need for reporting and dashboarding).
Yes, because they are interested in a solid solution, documented, tested, stable, etc. So having implemented all these non-functional requirements has priority, but sorry, just secondary priority.
And nobody expects that these non-functional requirements are implemented in the first sprint – instead we typically have more time to implement them. And yes, everybody expects the availability of the functionality eventually. But again, not after the first sprint.
But the regular delivery of business value, again, reports or dashboards, demonstrates project progress to the business user and makes it more transparent what (and how much) they pay for.
That’s why we have this focus on delivering actual business value in our projects but without losing our view on the non-functional requirements, too.
But just as a second priority.
What do you think? Do you agree? Or can you get a third perspective into the discussion? Happy to see your comments!