An abundance of quality, partner-built or community created add-ons is often the sign of a healthy software platform. While it signals that there are still niches that the core product does not fill, organizations recognize that no product is going to address every need for everyone. Instead, the developer is open and supportive of the broader community helping to enrich the core offering and build an ecosystem of supporting tools.
As with any important endeavor, businesses should be in a position to document and have a plan to mitigate any possible risks associated with deploying software. It is no different with Microsoft Power BI.
Note that the purpose of this post is simply an encouragement to evaluate risk exposure and consider how you would overcome potential future issues that could arise from any cause–it is not a caution against using external tools created by the wider Power BI community.
What About Power BI?
“My business uses Power BI” does not reflect the overall scope of the platform. It does not even stop at Power BI Desktop, Service, Gateway, Report Server, or anything else that Microsoft develops.
- Visuals – Power BI has encouraged “custom visuals” for nearly five years (although the term “custom visual” seems to be going away), has an evolving SDK for building visuals, has a marketplace with over 250 visuals, a process to “certify” visuals, toggles to block all visuals or only uncertified visuals in Power BI service, and has built support for private organizational visuals into Power BI service.
- Connectors / Data Extensions – Power BI has a Power Query SDK to build custom connectors and a process to certify connectors
- External Tools – At its Business Applications Summit in May, Microsoft demoed and wrote about the upcoming feature to open “External Tools” right from a tab in the Power BI Desktop ribbon (DAX Studio, ALM Toolkit, Tabular Editor, and anything else you want to define)
- XMLA endpoint – With XMLA read/write in Power BI Premium, you can now connect a wealth of external applications to Power BI models (even non-Microsoft BI tools could be part of your “Power BI deployment”)
Even within these categories, there are several areas within Power BI Desktop and Service to apply different settings. These may be at the model or report level, the workspace level, or tenant level. Do you know what different options exist and their impact on your organization’s Power BI experience?
Why Should We Assess Risk?
Identifying and planning for possible risks is not a sign that something is wrong–it means that you’re prepared in case something does go wrong. It should be a core part of a deployment strategy.
Two recent articles and some customer conversations have caused the concept of risk to be top of mind for me.
- CloudScope Ends Support for Power BI Custom Visuals by CloudScope — both the article itself and follow up discussion around the community
- I Am Done Using Visual Studio! by Paul Turley — he does not quite give up on VS, but Tabular Editor is clearly the future of large-scale model development
- A question about why Microsoft would even allow uncertified custom visuals
- A question about whether DAX Studio can be “trusted” on company assets when Windows Defender provides a warning prior to installation
- A question about how reliable DAX Studio is if it’s a single developer publishing it
I materialized a few thoughts into this post today after Paul published his blog post. I think people should be prepared and able to “state the case” for external tools in the Power BI ecosystem as they become widespread and actually promoted in-product by Microsoft. In particular, Tabular Editor and DAX Studio are poised to become even more widely adopted.
Here are some sample questions that could help get you started as you evaluate different aspects of third-party tools around the Power BI ecosystem (some serious and some light-hearted):
- Have you read about differences between uncertified and certified custom visuals or connectors, and are you prepared to describe accurately the differences and their implications of use to coworkers?
- What custom visuals and extensions are in use at your organization? How are they distributed? How are they inventoried? Are they inventoried?
- What is involved in Microsoft’s certification process for visuals and extensions?
- Will your IT department or other relevant areas in your organization support the use of external tools such as DAX Studio and Tabular Editor, and to what extent?
- Does your business use Organizational visuals, and if so, what are the processes around the development, deployment, and support of visuals–especially in event of turnover?
- Are your third-party tools of choice open source, and if so, have you looked at the code?
- What level of support is available for third-party visuals, extensions, and tools that you use? Does the level of actual support differ from your expectations?
- What happens if Darren Gosbell, Daniel Otykier, Andrej Lapajne, or others creating community tools hypothetically get “hit by the bus”, or otherwise decide to stop supporting their work for whatever reason?
- Do Marco Russo and Alberto Ferrari secretly collect, read, and laugh at your mortal-level DAX if you submit it to DAXFormatter.com?
- What would happen if a third-party tool in use at your organization disappeared tomorrow? What alternatives would be available, and how long would it take to implement alternatives?
I’m not here to answer all the questions and make judgments that would universally work for every organization. Rather, I simply want people to be intentional about their use of third-party tools in Power BI and be able to answer questions rather than panic if a boss or executive asks about something specific. Everything has an element of risk–it’s up to you and your business to decide how much you tolerate, and what your plan is to overcome possible issues if they do arise.