Monthly Archives: October 2018

The many tentacles of Power BI; or, Microsoft’s not-so-secret plan to take over the world.

Power BI, Uncategorized

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.

“I’m Not Dead, I’m Dormant” T-Shirt

So what changed around 2016? A couple of things. First, Microsoft acquired Datazen which would later turn into SSRS mobile reports. Second, Microsoft rebuilt the SSRS rendering engine to take advantage of HTML 5. Third, there was a new kid on the block: Power BI.

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.

image

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.

Image result for ignite open data initiative

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.

Bigger ambitions

My favorite slide from Matt’s presentation is this one. (Courtesy of James Serra).

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.

New Course: Deploying and Publishing Power BI Reports

Course Updates, Deployment & Administration, Power BI Service

My third Pluralsight course is out now, and it covers all the myriad ways of deploying Power BI:

  1. Manual sharing
  2. App workspaces
  3. Content packs
  4. Publish to web
  5. Office 365 embedding
  6. Power BI Premium
  7. 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.

image

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!

T-SQL Tuesday #107: Death March

SQL Server

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.

#SQLChefs: Power BI Datasets, Reports and Dashboards

Visualizations

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.

image

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.

image

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.

image

(Demo file courtesy of Microsoft, MIT License)

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.

image

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.