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
- Documentation
- 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.
Who cares?
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!
Best,
Michael Olschimke
Hello Michael,
Agree on it. But how do we ensure the prioritized non technical requirements are been on boarded into subsequent sprints if business is too focused on the
business value.
Is there any middle path approach you suggest when it comes to Non functional requirements of EDW.
Hi Prabhu,
in our sprints, we always have some non-functional requirements included in the workload. While the focus is clearly on business value, every sprint is also delivering some non-functional requirements. The prioritization of both sets of functionalities is done by the business side (while I have to admit that the prioritzation of non-functional requirements is more “driven” than “done” by the business).
Hope that helps,
Mike