Let's go a little further down the rabbit hole of PowerBI's awesome agility. You should start thinking right now that that rabbit hole is not the home of a fluffy, complacent bunny. No, this is the home of a nearly feral, fang-wielding lagomorph.* Treat her well, and she'll reward you with great insights. Anger her, and you'll wish you'd never laid eyes on a scorecard.
Once I had an initial view of the relationship between average drive time, average points scored, and victory percentage, I wanted to see if there were any significant differences based on time of the season. My ArmchairAnalysis data includes a week number in the [GAMES] table, but I thought it would be nice for my slicers to include groupings of weeks.
There's certainly more than one way to build this slicer set. I chose to add table [WeekType_dim] to my data model. It took about three minutes, and I spent two of those answering a text message from a recruiter.** Turns out I wasn't a good fit for the potential position, so back to PowerBI. Fifty seconds of adding a table to the PowerBI data model, ten seconds of formatting a new slicer.
Figure 1: Regular season drive time averages..
I know you're dying to see the comparison, so before I get back to that feral rabbit, take a look at Figures 1 and 2. You can click on them for a magnified view.
Figure 2: Post-season drive time averages.
Conclusion: the average drive time needed for a greater likelihood of victory doesn't change tremendously between the regular season and post-season.***
Back to the data model, and the slicers. Remember, I added a table to the PowerBI data model, not to the reporting warehouse. That's great for my on-the-fly work, provides me with some agility, but there's a lot of potential here for brewing up some huge problems.****
Consider this: I've assigned weeks 1-5 to the "Early Season" bucket, weeks 6-12 to "Mid-Season," and weeks 13-17 to "Late Season." Suppose my buddy David, working in the next office, creates his own season segment buckets. He might assign different weeks to these same buckets in his model, or he might choose a scheme with only two buckets.
And what if my model choice is simply wrong? I pulled this categorization scheme right out of my...imagination. The NFL's Vice President of Football Operations and her staff might have their own business rules defining season segments. Even worse, my field-based, unsupported report could become a staple of my organization over time, with some stakeholders relying on it for insight while other stakeholder rely on a conflicting report.
I certainly don't suggest that you and your BI/BA shop completely eschew the wonderful power of agility. I certainly am stating that consistent, exhaustive governance practices are a must, even when applied in a somewhat retroactive manner.*****
Here's my recipe for allowing the analytical agility while preventing confusion and conflict in the long run:
- Agility constructs like this one should be clearly called out in any presentation -- best if they're called out in the report itself. Choose a standard for your org, similar to "This drug has not yet been approved by the FDA."
- The agility developer(ish) should be responsible for submitting these kinds of constructs to the proper data/business rule governance process.
- The governance processes should include an origin notation -- this helps governance owners remain aware that remediation is likely necessary in the future.
- Post-governance, the item constructed in the PowerBI should (most likely) be incorporated into the reporting layer.
- Once the reporting layer is updated, ideally the report itself will be "productionalized" and the agility item will be remediated. If your organization chooses to allow non-IT reports to live indefinitely, the agility developer should at least be notified to remediate the original report.
This may seem like a pretty obvious process, but face it -- governance is second only to documentation in the "nice to have" department. Want world-class intelligence and analytics? User PowerBI and embrace the agility, but make sure those governance processes are a solid part of the strategy.
My PowerBI data model. You won't find [WeekType_dim] nor [FirstScoreTDLabels] anywhere in my SQL Azure database.
* A rabbit is a type of lagomorph. Good writers don't use the same noun twice in a paragraph until all the words have been used up, you know.
** Yes, IT recruiters now text to see if you're interested in an opportunity. Go figure.
*** While it would have been exciting to stumble upon a significant insight toward NFL victories in this rather not-data-science method, the important thing here is that we're adding to the data model and using slicers, right?
**** I'm going to call this kind of problem, "Releasing the Feral Rabbit." If I start hearing this phrase from other IT professionals, I'll know I've made my mark on the data world.
***** You're welcome, process managers.