I’ve written before about how to keep up with technology. In the post, I describe 3 currencies we can spend to extend out learning: time, focus and actual money. As you get older, you start to get less time and even less focus, but your pay rate goes up. So, every year it becomes more and more important to learn on curation to find just the good stuff.
As part of that I’m starting my own curated mailing list for BI links. Power BI changes on a monthly basis and it’s such a pain to keep up with it. This week is the 3rd week so far.
So what’s the catch? Well, I’ll also be including whatever things I’m up to at the bottom of each email. So if you don’t like me, maybe don’t sign up, hah. Here is this week’s weekly BI 5:
David Eldersveld talks a bit about #MakeoverMonday. This sounds like a great community program and I always find making things pretty to be the hardest part.
Wolfgang Strasser is keeping track of all the November updates for Power BI. I keep seeing memes about this from Microsoft employees, so I’m expecting something big to drop at Pass Summit.
Ginger Grant continues her series on SSAS best practices. I love seeing posts about how to do things right instead of just how to do the basics. Great stuff.
Three years ago, I started learning about Power BI and I thought, “Man, this is a really crappy replacement for SSRS.” Three years later, that’s still true, it’s a crappy replacement for SSRS. But that’s missing the point. Microsoft’s ambitions are MUCH, MUCH bigger than replacing SSRS.
Let’s review the many tentacles of Power BI; or, Microsoft’s not-so-secret plan to take over the world.
Tentacle 1 – SQL Server
It is unsurprising that Power BI is often compared to SSRS. If you come from a SQL background, there is a good chance that you need to report on the data in your database in some way. While there are a multitude of tools available to do so, often it’s easiest to go with whatever Microsoft recommends. You already paid for it, right?
For many years, that was SSRS. And for half a decade, between 2010 and 2016, not much changed with SSRS. Much like some of the plants at the Phipps conservatory, it wasn’t dead…just dormant.
If you come from the SQL world, this is all old hat by now. Microsoft is investing a lot of time and money into Power BI, so it’s tempting to think that Power BI is replacing SSRS, but it isn’t. If we look at the traditional BI pyramid, Power BI and SSRS occupy two totally different strata.
SSRS is designed for things that need a page number on them. This is generally detail-heavy, pixel perfect kind of work. This kind of operational reporting is descriptive, it tells you facts, but doesn’t add a lot of spin. This is at the base of the pyramid
Once we have the business up and running, we can move from “is” to “ought”. What should we do? Where should we go? This kind of reporting is higher-level, less detail oriented. You are looking at the company as a whole or at multiple years of history. You may drill down deeper, but generally speaking someone else is sweating the small stuff. This kind of reporting is prescriptive and where we find Power BI.
Finally, once we are moving and we are moving in the right direction, we can be even more forward looking and make use of predictive analytics. What’s going to happen in the future? What can the data tell us? This is where tools like Azure Machine learning and R can start to help us.
Power BI and SSRS are aligning
Power BI and SSRS are aligning and getting closer. If Power BI was a drop-in replacement, I wouldn’t expect to see this. I would expect to see Microsoft heavily pushing one over the other and that’s it.
By contrast, look at SSAS tabular and multidimensional modes. Tabular is available in Azure Analysis Services and multidimensional mode isn’t. Yes, I know it’s on the roadmap but it’s definitely not a number one priority. Every time I hear about SSAS, people are talking about tabular mode. In economic terms, DAX and MDX are subsitute goods. Sales of one reduces sales of the other. Think Coke versus Pepsi.
Power BI and SSRS, on the other hand, are complimentary goods. Think peanut butter and jelly. Yes, they are both things you can put on your bread, but they go better together. Yes, I know that seems strange, but look at what’s going on.
Last year, they announced Power BI Report Server, which is basically SSRS server with Power BI rendering on top. This year they announced SSRS rendering in Power BI Premium. Now, whether you are on-premises or in the cloud you use Power BI and SSRS in the same place.
Give it another year, and I bet the alignment is going to get even closer. I bet they will add Power Query as a data input for SSRS, just you wait and see.
Tentacle 2 – CRM, ERP, and business data
Microsoft wants your business data and it wants it badly. Last week I spoke at the Phoenix Power Summit, and I was really out of my element because it was all about business. It was basically 5 conferences in one, focusing mainly on all of the dynamics products (AX, NAV, Great Plains and Dynamics 365).
It was strange walking around the 250 vendors and 4,000 other attendees. Out of everyone there I only knew 2 people. And what those 4,000 people represented was something that I had never fully considered: standing there was Power BI’s core audience. It’s not me and it’s probably not you. It’s Chris in accounting. Let’s meet Chris.
Say hi to Chris
When I first learned about Power BI I was confused. Why did I need Power Query? Why did I need DAX? I already had all this stuff. I had T-SQL and SSIS. And the truth was, those tools weren’t for me, they were for Chris.
So much of this stuff clicked when I came up with the persona of Chris in accounting. This is the kind of person who is great at vlookups, okay at SQL and is stuff in the land of spreadmarts, flat files and Access databases. This person understands the business intricately and just wants to get things done. And many time, she has almost no IT support to get her job done, so she has to make do with the tools she has. For her, Power BI is a life saver.
And walking around me last week was 4000 Chris-es from accounting. This is going to be big.
Microsoft shoots across the bow of Salesforce
It doesn’t take a genius to realize that Microsoft and Salesforce are direct competitors. Both were interested in buying Linkedin, and more recently Microsoft fired a warning shot to Salesforce.
At Ignite, Satya announced the open data initiative along with Adobe and SAP. Guess who isn’t in the picture? That’s right, it’s Salesforce.
Part of that announcement was them talking about the Common Data Service. When I first heard about CDS months ago, I was again confused. It sounded like some weird semantic layer for the data in Dynamics CRM. Maybe useful if your data lives in Dynamics 365, otherwise who the heck cares.
Oooooh boy was I wrong. Microsoft is aiming for something much, much more ambitious than an awkward pseudo-database layer for people who don’t like SQL. They are aiming for a common shape for all of your business data. They want to want to create a lingua franca for all of your business data, no matter where it is. Especially if it’s hiding in Salesforce.
Now, do I expect them to succeed? I’m not sure. I’ve learned the hard way that every business is a unique snowflake, even two business in exact same industry. But if anyone can do it, Microsoft has a good shot. They’ve been buying up CRM / ERP solutions for decades.
Tentacle 3 – Data Science, Machine learning and Azure
Last week I had the pleasure of attending the Phoenix SQL user group and listen to Matthew Roche talk about Power BI Dataflows. When I first heard about dataflows, like everything else in this space, I didn’t quite get it. It sound like Power Query, but for the Power BI Service directly? Weird.
The way Matthew described it made a lot of sense. Dataflows represent an intermediate layer for your data, much like a traditional data warehouse. This is after all of the boring ETL bits, but before all of the sexy BI semantic layer bits. This is, metaphorically, chopping all your broccoli and putting it into plastic bags. The end user still has to decide what the final product looks like.
And guess what shape they let you put your data into? That’s right, the common data service. Microsoft wants to act like as a clearing house for your data. They want to act as a middle man for all of your data sources and all of your data consumption.
One weird thing about dataflows is that it’s saving the results to flat files in a data lake. Now, it was about this point that the DBA in me started freaking out. Why are we storing things in flat files? Flat file databases are older than I am!
(Sidenote: SQL Server 1.0 is about 6 months younger than I am.)
Well apparently, that’s standard fare for data lakes and how they scale. But the part that excites me is all the avenues that opens up. Because you can Bring Your Own Storage Account and gain access to all of that delicious data.
This is some seriously cool stuff.
Summary
Power BI remains a poor replacement for SSRS. But it’s a fine compliment to SSRS and is a growing way to report on the data living in you SQL Server.
For business users, especially Dynamics 365 users, it represents a way to get at and visualize their data. Power BI, PowerApps and Flow represent a huge step forward for business users, especially those stuck living in spreadsheets and access databases.
Finally, Microsoft wants to Power BI and the Common Data Service to be a central hub for all of your business data and analytics. This is going to expand into providing easy ways to take your business data and pipe it into Azure Machine Learning or Azure Databricks.
My third Pluralsight course is out now, and it covers all the myriad ways of deploying Power BI:
Manual sharing
App workspaces
Content packs
Publish to web
Office 365 embedding
Power BI Premium
Power BI Embedded
It can be overwhelming all the different ways of deploying Power BI, but in this course I walk you through the smallest, self-service options all the way to the large, scalable options.
I recently quit my job so that I could make more courses, so if you like what I do, please go watch it. You are supporting my family by doing so!
This month’s T-SQL Tuesday invitation is to write about a project that went horribly wrong. And hoo-boy, do I have a project that comes to mind.
My biggest project was my biggest failure
The biggest project I ever worked on, that I ever led, was also my biggest failure. In many ways it has defined the early trajectory of my career and shaped what I value in my new career.
About 8 months into my previous job, my boss wanted us to move to a different ERP system. This would allow us to consolidate 5-6 different pieces of software into a single piece of software. The theoretical business benefits would be quite significant. No longer would we need to have this awkward patchwork of integrations between different line-of-business applications. And while we eventually did it, I consider it the biggest personal failure of my career. So what went wrong?
The software was built in-house
So the first issue was that the software was built in-house by another company in the same industry. Imagine, for example, if a large bakery had created an ERP system and another large bakery wanted to move to that system. Sounds great, right? Well, you run into two issues in that scenario.
First, a bakery is not an independent software vendor. Programming, by definition, is not their core competency. Which means that you may run into fragility or issues that you wouldn’t run into with a commercial piece of software. It also means that there isn’t going to be any documentation on migrating to the software or implementing it. Why would there be. If you built software for one company, why would you create scaffolding to move other companies onto it?
Second, not every business is the same. A lot of the fundamentals are the same, but you will run into many edge cases. We do invoices this way. They do workorders this way. We handle purchase orders this way. They handle inventory that way.
The way that I think about it is like a sea shell. It’s this intricate curve that’s grown over time, organically, to fit that creature. If you just try to fit a different snail or mollusk in that shell, it may not work out.
I was not qualified
This was my second real job ever and I had been working less than 2 years in the industry. I always tell people the jobs said .net / SQL developer, and it turned out to be a lot more SQL and a lot more DBA.
When I started that job, I didn’t know what a stored procedure was. I didn’t know what a view was. 8 months later, when this project started, I had never done any large scale integrations or migrations. At that point I had done some small integrations between pairs of systems, but nothing nearly at this scale.
Add on top of that the need to staff up and add someone to the team. So, about year in to my new job I was also now a manager.
The software stack was older and different
Because this software had started way back in the Apple II days and grown over time, much of the technology stack was quite old. The application was built on VB6, MySQL, Classic ASP, Crystal Reports 9 and Adobe Flex. This presented challenges in getting it up and running, as well migrating to it.
Migrating data from SQL server is a giant pain. MySQL workbench has an import wizard, which works decently well, but it can be a bit of tedious process. Later I was able to set up linked servers, but that involved looking up strange property settings and forcing char padding on MySQL.
The software made a lot of assumptions
Because it was homegrown, the software made a lot of assumptions about the data. Project numbers under 1000 were reserved for certain pay codes. Half of the columns would crash the software if they had null values. A lot of the tables had to be populated for the application to even run.
So, so, so much of the process was modify a view, migrate the data, see what blows up, repeat. This is a big part of what made the weekly data load so painful. So much of the migration work was sheer trial and error.
Migrating ERP systems requires understanding 2 businesses
Migrating from one ERP system to another in this case require understanding the business that created the software and the business intending to use the software. This is a lot of learning and a lot of weird edge cases. I think I deeply underestimated the sheer complexity of running a business and all the departments therein.
When we deployed, there was a whole chunk of functionality we hadn’t implemented because “certificate of work” meant one thing to use and something totally different to the other company. They whole system updated maintenance cycles based on these certificates, whereas we had assumed they we merely customer deliverables and thus optional.
What would I have done differently?
Ultimately the project took 13 months instead of the estimated 8, and even then that was only because I decided for us to have a hard cutoff at the calendar year. So, if I could travel back in time, what would I have told my younger self?
Tighten the feedback loop. Migrating the data from one system to another was a largely manual process and quite painful, so we only did it maybe a week. Near the end I had started automating the process. In retrospect, I should have made it a nightly process.
Learn SSIS and BIML. So much of the pain came from the slow turnaround cycle. I suspect that if I had learned SSIS, I could have made things into a daily or even hourly migration process and saved so much time.
Read Rapid Development. I wish I had a better idea of what I needed to know from the outset. Rapid Development was a revolutionary book for me and had so much good advice in it.
Identify a measurable list of use cases. When we made the cut-over, a number of basic things did not work because we hadn’t tested them. What would have been smart would be to have a checklist that we could run through before hand to test the use cases.
Don’t take it personally. I was young and I treated things outside of my control as my responsibility. I was sore for a long time about how things went, and I thought too much on how that reflected on me and my abilities.
So now what?
Even to this day, I’ve got a certain amount of skittishness around the idea of large projects. There is a whole suite of soft-skills, of methodologies involved in making sure an IT project is successful, and I’ve learned the hard way what happens when you don’t have those skills.
For now, I’m excited to focus on course authoring and projects where I just need to create content.
Finally, I’ll leave you with a favorite quote of mine:
Good judgement comes from experience. Experience comes from bad judgement.
This week we’ve got another episode of SQLChefs with Bert Wagner, where we talk about the different between datasets, reports and dashboards in Power BI.
What are datasets?
A Power BI Dataset is a series of Power Query queries that have been shaped in a DAX model. Each dataset can combine different files, database tables and online services all into one tabular model. In our cookie analogy, these are all different “ingredients”.
Unlike SSRS, a dataset in Power BI does not represent a single table or query of data. A dataset should be considered more like a “flavor” of data used to accomplish a specific type of reporting: financial, operational, HR, etc. So in our analogy, the dataset is the “raw dough”.
So in Power Query, you are going to have a set of queries which each combine a data source with a usually linear set of transformations.
Then, in DAX, you are going to take each of those outputs and combine them into a model. This consists of defining relationships between the outputted tables and adding business logic via calculated columns and measures.
For more on the difference between Power Query and DAX, see our previous episode of SQLChefs.
What are reports?
A power BI report is a series of visualizations, filters and static elements on a canvas. Power BI reports are saved as a single PBIX file and connect to a single dataset. Remember, a Power BI dataset can have many data sources.
Each report can have multiple sheets, just like an Excel workbook. In our analogy, this is us placing our “cookies” on multiple “cookie sheets” making one big batch, all of the same “flavor”.
One report per dataset
A quick aside to something that used to confuse me. In most cases, a report and a dataset are going to have a one to one relationship. A dataset can have one report and a report can have one data set.
Recently this has changed, however. A while back, they added the ability to use an existing dataset as a data source for a report. and at Ignite they announced the ability to share datasets outside of the app workspace they were made in.
That being said, while you are still learning Power BI, it’s easier to remember that in many cases, your dataset and your report are going to have a one-to-one relationship and be tightly linked.
What are dashboards?
In Power BI, dashboards are a way of pulling together visualizations from various reports. When you think dashboard, you are probably thinking something like Microsoft’s definition: “A Power BI dashboard is a single page, often called a canvas, that uses visualizations to tell a story. Because it is limited to one page, a well-designed dashboard contains only the most-important elements of that story.”
However, if you look at the report example above, it probably fits that definition. It is not a Power BI Dashboard. In Power BI, a dashboard is tool for pinning visuals from different reports and other sources of data.
In my opinion, a Power BI Dashboard is as much a tool for organization and navigation, as it is for actual reporting. I think that’s the real value add with Power BI dashboards.
If you are using R as a data source, you may want to be able to refresh the data or run that R script on a schedule. However, if you try to configure a On-premises Data Gateway to refresh the data source, you will see this error.
Extension{"extensionDataSourceKind":"R","extensionDataSourcePath":"R"}Cannot be added to gateway
Back in August 2016, Microsoft added support for refreshing R scripts but only for the personal data gateway. So, in order to schedule a refresh where you are using R, you need to install and configure an on-premises data gateway in personal mode. The Microsoft documentation for r query steps reflects this limitation as well.
I once had to some auditing for a customer and it was a complicated, multi-stage process. We had to be able to demonstrate who had admin access and what kind of activity was going on, on the server. But before we could do any of that, we first had to identify who was actually logging on.
Triggers to the rescue
So what are the different options for telling who is logging on to a a SQL server? 5 options come to mind:
Configuring login auditing really isn’t a good solution. What you are doing is changing the base settings to log successful logins in addition to failed logins. The problem is that these events are written to the SQL Server event log, which isn’t convenient to parse.
Well what about using a trace? Well I’ve always been told that traces are expensive in terms of performance so I shied away from using one of those. In retrospect, I doubt it would have been too expensive since it’s only tracing logins. If anyone knows, let me know!
The next option is to use Extended Events, which often have better performance. Unfortunately, this server was SQL Server 2008 R2 and there was no GUI support for extended events. So that wasn’t ideal.
What about SQL Audit? Underneath the hood, SQL Audit is just Extended Events. That being said, there is at least some GUI component to it. For 2008R2, it required Extended Edition. while that wasn’t an issue for us, it seemed like overkill.
So what’s the last option? Creating a server level trigger. This was simple to implement and easy to dump the data into a SQL table for reporting purposes.
Proceed with caution
So, what’s the downside. Wellllllll. What happens if you have an error in your code? If you hit an error, then you can’t login. At all. Anyone.
There are ways to resolve this issue, but it requires shutting down the SQL Server and taking an outage to fix it. Suffice it to say, I spent a looooot of time testing before I pushed this out to production.
Overall, triggers provided a simple solution to a simple problem. But the solution required a good dose of caution.
I recently saw on Twitter some abusive behavior, and I know that Twitter and trolls go together like peanut butter and jelly, but for whatever reason I’m angry. Maybe because I know the person who was abused, maybe because the abuser is a part of our community. I don’t know. But I’m feeling angry.
If you have to ask “Why are there so many tech events only for girls?” you are either:
1) Trolling
2) Severely lacking empathy and imagination
3) or both.
I want to do something, but there’s not much I can really do at this point. The abuser has deleted his account and I’ve already said my piece online. So, I thought I’d write a blog post about doing the bare minimum. For you, this post is likely to be utterly banal (“Well duh”), somehow offensive (“You are being too politically correct”), or both (“That’s your minimum? You can do better Eugene.”).
Well, damn it all and fire the cannons. I’m angryblogging.
Step 1. Be a safe person
The person you have the most control over is yourself. The person you have the least control over are abusive people, especially narcissists, psychopaths and anyone else who doesn’t feel a healthy sense of shame. So the most effective thing you can do is be a safer person.
Safe people apologize. Learn to apologize, practice apologizing, and understand that apologies are more than saying I’m sorry. In the book Apology Languages, the author breaks and apology down into 5 different parts.
Expressing regret. “I’m sorry.”
Accepting responsibility. “What I did was wrong.”
Making restitution. “How can I make amends?”
Genuinely repenting. “I won’t let this happen again.”
Requesting forgiveness. “Will you forgive me?”
We all know how to say I’m sorry. It’s a cliché of mothers forcing small children to apologize, but often what’s more effective is putting your money where your mouth is. It’s taken a lot of practice for me to be able to say, “What I did was wrong, full stop.”, without needing to explain my motivation. Being safe takes practice.
Safe people listen, without always trying to solve the problem. Sometimes the other person just needs to be heard. Sometimes by trying to fix a problem you can accidently take away someone’s agency. I often ask my wife, “Do you want to vent or do you want advice?”. Her response is 50/50 each way.
Sometimes it’s not about the nail:
Safe people empathize and validate. I was in a really bad relationship once, and one of the things I understood later was the other person never said, “I can see why you’d feel that way.” They never said, “That’s understandable.” They never said, “I would feel the same way, in your shoes.” Validate the person’s feelings.
Toxic people are often unwilling or unable to empathize. For narcissists in particular, it presents a threat to their sense of self. Even worse, many do something called gaslighting, where you make the person question their own senses. Validation is a antidote to gaslighting. Let people know they aren’t crazy.
Step 2. Be aware of different experiences
I’ve written bad emails, angry emails. I’ve gotten in a feud with a co-worker. I’ve been stressed and blown up on people. And never once has someone told me I’m “too emotional”.
I’ve presented dozens of times and never once has some given the feedback that I should “smile more” or “present in lingerie”.
I’ve walked down many streets and I’ve never been catcalled or sexually harassed. I’ve never had to worry if someone was following me around. I’ve never had to run up to someone and say “help me, I’m being harassed.”
And all of this presents a challenge for me, because it makes it harder for me to empathize with women and their lived experiences. Because some experiences are so incongruous with my entire life that there is this cognitive dissonance. This dissonance can be quite uncomfortable.
It’s means that by default, certain experiences feel less credible because I’m never lived them. I don’t want to believe the crap people endure. Some of it seems too horrible to be true.
So that means I have work at it. I have to listen to the stories of other people and have a willingness to feel uncomfortable. The default is me minimizing and invalidating the experiences of others because they don’t match up with mine. So I have to do better than the default.
Step 3. Be alert
An embarrassing story: in the last year, I had the opportunity to stop some harassment in person and I didn’t. It wasn’t because I was scared or unwilling. No, it’s because I wasn’t paying attention.
I take martial arts and if someone was beating another person, I’d like to think I’d intervene. I haven’t been tested on that and hopefully never will, but I’m pretty confidant I’d jump in. But harassment can be subtle, almost invisible. And so I didn’t jump in.
In this case, nothing in the conversation was harassing. Nothing offensive was said. But something felt off. The non-verbals were screaming at me. And I didn’t hear them because I wasn’t listening.
You know when you cook some food and it’s 2 days expired and it smells off? Not moldy or anything, it looks perfectly fine, but you eat it and feel sick an hour later? Harassment and abuse can be like that. Nothing blatantly wrong but in your gut you know that something isn’t right.
Being able to stop harassment requires being alert and being aware. If you are someone like me who doesn’t worry about getting harassed personally, doesn’t get harassed regularly, this can take work. I never want to miss the signs ever again.
Step 4. Speak up. Step in. Intervene.
I hate conflict. I am a people pleaser. I have poor boundaries. So the idea of stepping in the middle of something gives me shivers.
I don’t like getting involved in Twitter fights, I don’t think they accomplish much. I don’t like the mob mentality on Twitter and online. When I think about the dog-pile culture on Twitter, I worry someday I’m going to say something tone deaf and lose my job over it. I say stupid things a lot.
But you know what? Say something. Do something. Step in.
I’m not encouraging people to put themselves in danger or incur abuse themselves. But for many of us that’s not a serious risk. I’m 6’ 2’’ and practice self-defense. I can afford to intervene in a conversation. My safety is not at risk.
Stepping in might mean just being physically present and making knowing eye contact. It might involve saying “Sir, that behavior is inappropriate.” It might involve entering the conversation and asking pointed questions that belies the true intentions of the abuser.
Online it might mean calling out bad behavior. Saying, “This is unacceptable.” or “This is harassment.” It doesn’t require being some internet crusader or dog-piling. You have a line personally, and you know in your gut if something crosses that line. You know in your gut something is wrong. If something is wrong, then say something.
I’ll say it again. I hate conflict. I’m a people pleaser. I have poor boundaries. But I’m working on speaking up more when I see something that I feel is harassment or abuse.
And remember, calling out bad behavior is not just about shaming the abuser. They aren’t likely to listen to you anyway. It’s about letting the victim know that they are seen, they are heard and they are not crazy. It’s about setting a standard for everyone else. There is a saying that “locks keep honest people honest”. Healthy accountability keeps everyone honest.
On doing more than the bare minimum
I’m not saying that we should all aim for just minimum. If your bare minimum is more than this, awesome. I’m not trying to encourage doing less. But for people like myself, the minimum is not the default. The minimum is a destination, not the starting point. Let’s change that.
What I’m trying to say is there are small, simple things we can all do without making a big leap out of our comfort zone. And that minimum bar is getting higher every year and we should all be aware of that. Times, they are a changin’.
This Friday at SQL Saturday Philadelphia, I will be presenting a precon on implementing Power BI. I’m excited about it because it’s the kind of presentation I would have attended two years ago.
One of the big challenges of learning Power BI is that everyone wants to sell the sizzle (great visuals) and not the steak (Infrastructure). And because of how it is to get started with Power BI, you can get a nice looking dashboard together in a few hours. But the hard part is answering “What’s next?”.
In my precon I break it up into two pieces Data Wrangling and Administration. Power BI works great when you can just drag and drop, but most of the time the data we have to work with is just plain ugly. Power BI gives you two languages for cleanup and modeling and both require a new mindset to understand.
Once you have your data cleaned up, you have to deploy and administer the thing. And boy are there a lot of ways to deploy it. And there are gotchas too. Like the fact that you need a pro license to deploy that content, even if you have Power BI Premium or Power BI On-Prem. Nobody get’s excited about data governance, but if you want a production solution you’ll need to learn the ins and outs.
If you are interested, there is still time to sign up.
Last week, I had the pleasure of recording some video with Bert Wagner about Power BI. In the video, I got to use one of my favorite analogies for M versus DAX: Are you chopping broccoli or planning a menu?
One of the challenges with learning Power BI, is that you have to learn not 1, but 2 new data manipulations languages. And it’s not always clear what they are good for, especially if you come from the SQL world.
Is M a general purpose knife, or one of those weird egg slicers?
Head Chefs versus Sous Chefs
I have never worked in the restaurant business, but I’m going to make some gross generalizations anyway.
Sous chefs, as far as I can tell, do a lot of the prep work. They are cutting vegetables, cleaning food, making sauces, etc. While this is all important work, much of it doesn’t inform the final outcome. If you are making beef teriyaki or if you are making broccoli salad, you still need to chop the broccoli.
The head chef however, gets paid for her brains just as much as her hands. The head chef is figuring out the menu and how to combine all of the ingredients. She is involved very heavily with what the final result is going to be. A head chef has to think of the broader goals and strategy of the restaurant, not just how to get the immediate task done.
M is the Sous Chef; DAX is the Head Chef
Again this is all a gross generalization, but in the restaurant called Casa De Meidinger this is actually the case! I do a lot of the grunt work when we cook a meal. My wife says, “zest this lemon” and I mindlessly do it. I could probably be replaced with a robot some day, and that would be fine by me.
Annie, however, actually enjoys planning a meal, deciding what to cook, and thinking about how to make the final product. To me, cooking is just a necessary evil for eating. I don’t necessarily get any joy from the process itself.
Working with M
I like to think of M as this sous chef. It does all the grunt work that we’l like to automate. Let’s say that my boss asks for a utilization report for all of the technicians. What steps am I doing to do in M?
Extract the data from the line of business system
Remove extraneous columns
Rename columns
Enrich the services table with a Billable / NonBillable column
Generate a date table
This is all important work, but I would have to do the same work for a variety of reports. Many of the steps tell me nothing about the final product. I would generate a date table for most of my reports, for example.
Working with DAX
Now, if I’m working DAX, what am I going to do?
Ask what the heck “utilization” really means
This was a real-life example that happened to me. What is utilization as a key metric? Well it turns out it depends what you are trying to report on. A simple definition is usage divided by availability. If a technician billed 20 hours and clocked in 40, his utilization would be 50%. Or so you would think.
How do we handle internal projects? Let’s say we have a technician who billed 2 hours to a customer, but spent 38 hours on an internal database migrations. What was his utilization?Well, if we are looking for billable utilization, it’s 5%. If we are looking for total utilization, it is 100%. These are questions that you are going to encapsulate in your DAX formulas.
The whole idea of a BI semantic layer is to hide away the meaning from the end users. When someone orders a cobb salad, they don’t want to have to articulate the ingredient list. They just want a darn salad.
Are you paid for your hands or your brain?
In the SQL Data Partners podcast, episode 114, there was a question: what’s the difference between a contractor and a consultant. One of the answers was this: a contractor is a set of hands, and a consultant is a set of brains.
I think this answer relates to M versus DAX. M is an automated set of hands, able to do work you’d normally do by hand in Excel. DAX let’s you take your domain knowledge and encode it into a data model. It’s an externalized representation for your brain.
And if you think about it, which do you want to be paid for? Do you want to get paid to unpivot data by hand every week? Or do you want to get paid for thinking, for understanding the business and for working at a higher level.
M allows you to automate the first step, so you can do more of the latter with DAX.
