Tableau Recommends BDUF

BDUF - Big Design Up Front

• the bane of everyone who wants to get things done
• the curse of traditional BI, the reason why budgets blew up, time expired and value (or much of anything) wasn't delivered
• the beast Tableau slew to wrest data analysis from the clutches of the BI technocrat cathedral builders and return it to real human beings with information needs

Why, then, is Tableau encouraging BDUF?

Preposterous, you say? BDUF is antithetical to Tableau's raison d'etre. Contrary to its nature. Expelled from its realm. Rejected in favor of a better paradigm.

Well, yes.

For the most part. But not entirely.

Take a look at this snippet from the online help for Tableau Server regarding project-level permissions:

Before you begin the process of creating projects and project-based permissions, Tableau recommends that you outline or document all of the projects and permission levels that you want users to have in each project prior to implementation in Tableau Server. This exercise will help you organize the various permissions you want to implement and may help you identify any user or permission gaps in your solution.

reference here

This is the very essence of BDUF - trying to determine everything that could possibly be needed before anything's actually put in place. Lots and lots of lost time and effort spent anticipating every possible need, all the potential combinations and permutations, identifying and working through all the subtleties, complexities, and consequences.

I love Tableau because as a data analytical tool it is the polar opposite of BDUF. With Tableau you don't need to know up front what visualization is going to give you the insight you need. You don't have to—you can walk the good path to it by simply following the data, using Tableau to illuminate your way.

So why BDUF here?

Why here indeed? What's different about Tableau Server permissions that impels Tableau to recommend conducting BDUF before you implement them?

Here's my starter list of reasons (it's only a starter list because I'm going to have to stop some time):

• permissions, and the objects they attach to, form complex relationships
• Tableau, as an analytical tool, has no ability to model or represent complex relationships
• Tableau Server is not well designed for the presentation of the information about its contents
• there's no straightforward way for Tableau Server to present to you the body of permissions, how they're attached to Sites, Projects, Workbooks, and other content
• there's not even a simple, clear way to see the definitive permissions in place for a given User or Group on a given object - when a permission is identified as 'Inherited' it might as well be labelled "flip a coin"
• without a presentation model there's no way to gain an understanding of what permissions are in effect for any object, much less for a group of objects
• without a presentation model there's no way to provide the ability to manage the permissions – altering them with simple, straightforward deterministic mechanisms, and by this I mean deterministic from a human standpoint, not from a technological or implementation perspective
• without the ability to see and understand the current permissions field it's impossible to know what it is—at best you can build up a mental model by walking around in it
• without the ability to understand and manipulate the permissions field in a manner even approaching utility it feels only prudent to advise people to map everything out beforehand and then code (oops - configure strictly to spec – which is exactly what Tableau freed us from in the first place.

Is this a calamity?

No. It's a huge pain, and an embarrassment when, as the Tableau Server administrator, I can't definitively lay out the permissions in effect for an object in the tool, but its not a catastrophe.

Will it get better?

I hope so, but the irony of it is that I've been so busy managing our Tableau Server environments and trying to come up with some way to train someone without my deep interest in puzzling out the peculiarities, that's there's been far, far too little time for getting familiar and comfortable with Tv8.

What will it take to get better?

Tableau must, must, must break out of its data flatland.

Tableau was designed to handle flat data. Data with a uniform structure, everything in a linear path at a single level of granularity. And it's a fantastic tool for the job, the best there's ever been (this blog's grumping's not withstanding).

But the world's full of data that's not flat, that has all manner of topologies. Simple master-detail hierarchies. Multi-level hierarchies. Multi-level, multi-path hierarchies. Networks without hierarchies.

Quick question: what's the most common complex data that a Tableau user encounters?
Answer: Tableau

A Tableau workbook is a classic example of a complex data structure crying out for analysis. Here's a partial list of the relationships in a Tableau Workbook (there are enough elements to make your head swim–mine's been axle-wrapped plenty puzzling this stuff out building TWIS and the other tools):

• A Workbook can have:
  • zero or more data sources
  • zero or more worksheets
  • zero or more dashboards
  • zero or more parameters (although parameters are structurally really data sources under the hood
• A Worksheet can have:
  • zero or more data sources
  • zero or more row fields (and there can be duplicates)
  • zero or more column fields (and there can be duplicates)
  • zero or more fields in other controls
  • ...
• A Dashboard can have:
  • zero or one title
  • zero or more worksheets
  • zero or containers (and knowing what and where these are is more useful than most people realize)
  • zero or more text, image, web page, and blank objects
  • zero or more actions
  • ...
• A Data Source can:
  • access one or more tables (with 'table' a polymorphic term)
  • have one or more source data fields (at least I think one is the minimum, have to check that)
  • have one or more calculated fields – which in turn can reference zero or more data and calculated fields
  • be used in zero or more worksheets
  • not be used in dashboards directly
  • ...
• And so on
• and so forth
• and such like.

I hope it's clear – Workbooks are pretty complex.

Permissions are roughly as complex in type, although not in number of elements

So... it's going to take the ability to model, present, and allow the user to interrogate complex data before Tableau has a real shot at helping people understand and manage their Tableau environments.

Can Tableau do it?

The evidence is not overwhelmingly in favor of success. Not only is it a really hard problem Tableau may have lost its mojo.

Conceiving, creating, and implementing these abilities is far, far harder than Tableau's initial inspiration–rendering in a visual interface the semantics of organizing and presenting quantitative data in a 2D visual space, with organizing elements providing nested sorting vertically and horizontally. The basic structural semantics were refined decades ago and proven in multiple successful products including RAMIS, FOCUS and NOMAD; of these FOCUS was the most well known. Oddly enough, these products were all capable of working with complex multidimensional data, that being the norm before relational databases decomposed everything.

So far, Tableau has provided a mishmash of different ways to present and provide interactivity to complex data. Formatting, particularly of tables, is the leading candidate for biggest flop–although there are definite relationships between the elements in a visualizations it's fiendishly difficult to keep straight exactly how you go about applying -this- formatting to -that- element. Tableau Server 7 has a plethora of different ways to present Sites, Users, Site Users, Projects, Views, Permissions, etc..

Want to see the relationships between your dashboards, the worksheets they contain, and the data sources they access? Good luck - Tableau doesn't provide this, even though the ability to see it has been available for several years, i.e.:

Gross Structure of the Variety Sample Workbook

It's a hard problem.

Providing a visual analytical interface to Variety's structure is a daunting task. One that abstracts it in a way that presents its type structure independently from its contents is difficult enough so that while to date there are plenty of good XML editors on the market there aren't any good XML analyzers.

Interestingly, at least to me, when I started out building TWIS, which created the diagram above, I was pretty much convinced that understanding and parsing Tableau Workbooks would be the hard part. And it was. But it was a challenging in two main dimensions that were both addressable by simply applying skills and approaches I, and other developers, already had. The biggest challenge, the one the eventually led me to the mini-tools approach of building lots of small Ruby apps (hello again, unix) was how to integrate all of the data from the various paths as I followed them down their individual rabbit holes.

I remain hopeful.

Tableau already cracked one nut–bringing a visual orientation to data analysis that provided a direct connection between the semantics of data analysis and the user interface. Can they do it with the next data frontier? Time will tell.