I’ve written previously about development of Tableau analytics capability from single user to multiple teams across an organization. This article is intended for those who may have first installed Tableau Server to enable folks outside their own sphere to interact with their Tableau creations. For the way ahead, it presents a few guidelines for successful development and deployment that data analysts should internalize as their analytics product grows.

The theme is, from the very start, to develop dashboards as if they serve hundreds of users and access millions of data records. If you do that, then as your analytical tools grow in usefulness and popularity, you’ll avoid difficult conversions and retooling later.

Use a Relational Database to Integrate Data

Tableau offers different ways to blend, union, or join data from within the tool, detailed in this webinar (login required). While each of these techniques has its place, the performant option for data of any volume is to do that work at the database level. As the webinar details, Tableau performs best against dimensional star or snowflake database designs. Relational database management systems (DMBS) like SQL Server, MySQL, Oracle, Teradata and the like excel at managing such schemas at scale.

This isn’t to diminish the value of non-relational NoSQL data platforms. Relational DBMS best suits Tableau because Tableau works best with data shaped according to relational principles: data structured in rows and columns, each column always contains the same kind of data, columns don’t contain embedded structures, and so on. In addition, well configured relational databases can house as much data as Tableau can practically handle. I write this as I wait for a test dashboard to populate, one summarizing ~20 million records: it is at 12 minutes and counting. This site recounts an example of a dashboard with better response time working with over 2.5 million marks (data points).

Finally, using a DBMS to gather analytics data provides a central data server that can support many different analyses. Rather than repeating similar integrations in separate Tableau data sources, each integration can be done once over all reports in the database.

Separate Development and Test from Production

There are many ways to organize Tableau workbook development, test, and deployment, but one thing they all have in common is that development and test environments are distinct from production. If you’re just starting out, then perhaps setting up a test project and production project on your Tableau server site will suffice. Your work pattern might be to develop on your desktop, publish to test to review and share your work for approval, and publish to production when it is fully vetted.

The test project gives you a location not only for testing, but also for various types of workbooks that are worth keeping for a while but, for whatever reason, aren’t appropriate for production. For example, a special purpose version of an analysis for a specific user, or a pilot analysis to see if it resonates with your user community.

Build a process that fits your organization for migration of workbooks from test to production so that you can maintain quality control. And by all means give all of your production users access to the test project so that they can participate in test and approval.

Set Up a Feedback Mailbox

Even if you are the lone analyst building and publishing visualizations, go ahead and set up a team mailbox on your organization’s email server. Put a “questions and feedback” link to your inbox on your dashboards, and publicize it among your user community as the way to communicate about your Tableau dashboards.

As your analytics product grows in importance, hopefully your team will grow accordingly. Establishing the shared inbox early helps prevent a situation where one person (perhaps you) is the hero who must always be available.

Establish Development Standards

Right from the start, an analytics team should establish a standard look and feel for their dashboards and development standards for their workbooks and data sources.

Look and feel standards are important to establish a trademark image for your analytics product, but dashboard standards are about more than branding. Making all of your dashboards generally attractive and always arranged the same way has the effect of making dashboard components invisible to users, thereby making the data analyses more visible. Users should see what they expect every time they open a new dashboard, with no distractions and no fumbling to find definitions, filters, and parameters.

Dashboard standards should specify things like use of colors and fonts, placement of headings, filters, visualizations, tool-tip content, etc. Here’s an example of a Tableau standards document for an organization, and here’s a page describing a style guide on Tableau Public.

Beyond dashboard standards, a budding Tableau team should specify workbook and data source coding standards. Just as standard dashboards make data visible to users, standard workbooks and SQL queries save developers a cognitive step when they open one up to enhance or maintain it. Imagine opening up a workbook and finding calculated field names Calculation1, Calculation2, and so on!  Here’s a link to a Tableau development standards page, and here’s an example of a SQL development standard (pdf).

Finally, establish a peer review process to ensure the standards are followed. Workbooks and data sources should have affirmative peer approval before they move from test to production.

By building performant relational data sources, separating test from production, setting up a feedback inbox, and setting development standards, teams will go far to establish a firm foundation for success as they start on their analytics product journey.