priligy price uk

Contrary to popular opinion, the best business intelligence systems are not driven by the data, or the operational source systems. I recently had a conversation with a group of data warehouse developers who were completely baffled by the notion of building a BI application without first extracting all of the source system data into a single, normalized data model.

They insisted that this was the necessary precursor to building BI applications for end users. I asked them what specific business problems the data warehouse was required to solve. They speculated on a lot of possible ideas, but admitted that they had no business requirements. They explained that their project was an IT initiative, and their first job was to consolidate the data. After that, they planned to begin building BI applications against the warehouse. This was how this group had always worked. When I asked how often their customer/user community was completely delighted with the resulting BI applications, the team chuckled and reluctantly admitted that users had never been “delighted”.

This story is too often the way data warehousing projects go. They fail to focus on the early delivery of business value and lose end user trust and acceptance. We “data geeks” take a data-centric approach to building a data warehouse, and we convince ourselves that we have to solve lots of thorny data issues before we can build the applications for users. It’s all about the data! Many data experts make the wrong assumption that if they get the data right, they can meet all possible future user requirements. Oddly enough, when you talk to the business users, it’s not about the data. The data is just a means to the end goal of handling business problems and supporting business decisions. Users have stories to tell, and they are usually NOT about the data. The data merely plays a supporting role.

Agile data warehousing is a feature-driven or story-driven approach. We are eager to produce user features that enable our customers to do their jobs better or more efficiently. The data just supports this goal. And it just so happens that the best way to deliver that data is via a data warehouse.

Story-driven development is a very gratifying way to work once you get the hang of it. Agile BI developers know how to write good user stories for BI systems; how to make the stories small enough and simple enough to complete them in short iterations; how to prioritize stories; and estimate effort. By the way, Mike Cohn has written extensively about “user stories” among other agile topics. You should read Mike’s book for a deeper dive into this topic. My goal is to show how to do story-driven data warehouse development, and to help you wrestle with the common question, “How can we build anything meaningful in only two weeks?”

6 Responses to “Feature Driven Data Warehousing”

  • Nirmal:

    You are dead right. What you explained is very close to the project that I am presently working on. However, I keep wondering if a generic user story format works for a pure data warehousing project.

    What are your thoughts about the same? Can you share some examples of user stories that you or your team would have written for a DWH project?

  • My question is – Why would you build a pure data warehouse without any linkages to business user needs? Typically the user interacts with a BI system, which is supported by a DW. In this case the user stories are the primary driver of BI features; and the BI features are the primary determinate of what must be built in the DW. Organizations who build a DW in isolation tend to overbuild them to accommodate all imaginable BI features that might be requested, nevermind the fact that many of these won’t be needed. I prefer to build the smallest DW that supports all of the BI features that users really need. Then, as new user stories emerge, the DW and BI system is incrementally modified to deliver those new features.

    I have lots of examples of user stories. In fact, my DW/BI teams orient all new development around user stories. Here’s an example from a recent project, “As a financial forecaster I need the ability see profit and profit margin per customer per transaction for the top 10% of our customers so that I can identify the characteristics of the most profitable transactions.” This story motivates several DW development activities such as adding profit and margin to a fact table; developing business rules for determining which customers fall into the “top 10%”; ETL coding needed to calculate profit and margin; etc. These are all back-end development work needed to deliver the BI feature to the user even if a separate BI team is responsible for the actual BI applications and features to present this.

    I hope this helps, Ken

  • Nirmal:

    Thank you for your clarification Ken. I am on a project on a different nature. We are not building a data warehouse from scratch but making modifications to existing processes to enhance/improve current processes. In most cases the business function is not changing. It is just the processes (batch processes, jobs etc) that will be decommissioned/updated/added to felicitate improvements.

    Can stories in this case be system specific or do you recommend that we still go the route mentioned by you earlier?

    Thanks,
    Nirmal

  • Nirmal:

    Thank you for your clarification Ken. I am on a project on a different nature. We are not building a data warehouse from scratch but making modifications to existing processes to enhance/improve current processes. In most cases the business function is not changing. It is just the processes (batch processes, jobs etc) that will be decommissioned/updated/added to felicitate improvements.

    Can stories in this case be system specific or do you recommend that we still go the route mentioned by you earlier?

  • This is a great scenario. What you are describing is an investment in reducing “technical debt” rather than the creation of new end user value. Technical debt accrues naturally on all projects for a variety of reasons, and is often manifested in a data warehouse as suboptimal performance or high cost of change. If we don’t pay down this debt intentionally, we will eventually find ourselves stuck and unable to respond to the needs of business users. It is admirable that your organization is willing to invest in reducing this debt. One way to do this is allocate significant time in a DW/BI project to make these enhancements/improvements while also delivering a few new BI features to users (perhaps 50% debt reduction and 50% user story development). Another approach is to run the project with the express purpose of reducing technical debt, which is the approach you describe.

    In this case your “customers” are not the end consumers of BI features, but instead are the DW administrators, DBAs, network admins, etc. Identify who will directly benefit from this investment in debt reduction and treat them as your “customer community”. This may even include DW/BI developers, but it is important for these community members to separate their role as “customer” from their role as “developer”. These are the authors of your user stories and should write stories like, “As a warehouse administrator I need the nightly update of data from the Bonobos legacy source system to complete in less than 20 minutes to ensure that the entire warehouse update will finish before 4:30 AM each day.” Your customer community is responsible for prioritizing these “debt reduction stories” on a backlog based on which ones will have the greatest benefits.

    One word of caution – If you let these “debt reduction only” projects run too long, then there may be pent up demand from business users for new BI feature development and enhancements. I prefer to timebox projects like this to relatively short cycles such as 4-8 weeks. This allows DW/BI teams to make quick, high value performance improvements and get back to a business-value focus sooner. Timeboxing your project will help you do the most beneficial things without letting the project drag on indefinitely.

    Please let me know if this approach makes sense for your situation. –Ken

  • sluksic:

    Hi,Ken
    here I am with another question in a few days, but now with another subject 🙂
    I would like to know your opinion about following…
    I am working on international DW where we implemented a feature only for one country because then we haven’t so much input informations for other. And now we have to implement it for some other country. We have enough inputs. But we have to make in way that this new feature began when DW started, we have to go in history with valid from dates in dimensions, and to correct id’s in fact tables.
    What do you think about this, is it regular from developers perspective to make changes in history? Customer wants data for the whole year.
    For me, this can be done with manual SQL queries, but is it regular? Should new feature be valid from the date when it is implemented?

    Thank you
    Stipe

Leave a Reply


I fear that, “agile as the latest magic bullet” has crossed the chasm, but that “agile as a different way of behaving” has not."
- Ken Collier
agilealliance.com
cutter.com
tdwi.org
innovationgames.com
Get Adobe Flash player
Site Meter