Posted by John Strykowski
August 16, 2018
When I was asked to write a blog about Tableau Server Governance, I pondered how to make it somewhat entertaining. And I don’t think I can. Unless you’re a nerd like me, it’s not an exciting topic. With that in mind, I’m writing this blog as if I were having a friendly chat with a very quiet person. One more thing – you won’t find answers in this blog post because I can’t give them to you; only you can provide those. What I will endeavor to provide are some tools you’ll need to start thinking about those answers.
The Tableau Server Governance process starts by asking the right questions. I’m going to try and clarify a few points and hopefully set you on your way. Keeping in mind that the process is more complex than the questions we’re about to go over. The first thing I usually do after setting up a fresh Tableau Server is, organize a little workshop with my clients and go over, at a high level, some of the key administrative features of Tableau Server. This is done, in an effort to uncover how those features can be operationalized within the context of their organization.
There are 3 basic types of governance models: centralized, decentralized, and federated. Each model has pros and cons and will serve an organization in different ways. Some organizations, as they progress along their maturity model, will find it useful to start with a centralized model of governance and work towards the decentralized and finally the federated models. While other organizations, will spend more time upfront to asses which model makes the most sense, based on organizational process assets and enterprise environmental factors.
In a centralized model, one person serves the Tableau Server Administrative needs of the entire organization. It’s simple enough to deploy, and it’s easy for anyone with a request to know who to talk to.
Caveat: the potential problem with a centralized model is the single point of contact. Once the needs of the organization start to grow, the person taking care of all the Administrative requests quickly becomes a bottleneck and nothing gets done easily from there onwards.
The big difference with a decentralized model is that site and lower content hierarchical levels are pushed out to the departments and teams, rather than being managed by the central IT team. In a decentralized model, there are at least two power users responsible for Administering Tableau Server. The “blue people” in the diagram would be responsible for server-side administration while the “green people” would be departmental power users. That should take care of the bottleneck issue for a while.
Caveat: A potential risk in this configuration would arise if no rule or process were in place to enforce some level of coordination between Power Users. One common pitfall that can be avoided through coordination, can happen when two departments with conflicting needs require changes to Tableau Server (permission, project structure, scheduled tasks, …). For example, one department wants to make use of the Web Authoring feature which allows content creators to edit a dashboard directly into Tableau Server without the need for Tableau Desktop. Another department views this feature as a potential security risk and prefers to turn off the feature at a server level. There might be a way to accommodate both parties, but that would need to be coordinated across departments.
The federated model of governance is one where a steering committee made up of all the decentralized Site Administrators and or Power users is set up. This committee will do two things: it will serve the Tableau Server needs of the organization and will also make decisions regarding the implementation and configuration of Tableau Server that have been coordinated across all departments within the organization.
There’s one key concept specific to Sites; they are “share-nothing” environments. When deploying Tableau Server, one default site is created, and everything happens in that site. Creating additional sites can be useful for splitting Tableau Server into different environments, possibly one per department, or to create Development, UAT, and Production environments. The thing to remember about sites is that they are entirely isolated from one another. Nothing can be shared across sites except for Users. Users are imported or created at the server level, but they must be given a role before becoming operational and that is done at the site level. Otherwise, groups, workbooks, and data sources all have to be manually replicated across sites if they need to exist in more than one environment. Another thing to keep in mind is that a Tableau “Project” can be configured to segment content within a site and can fulfill most, if not all, of the requirements a site would. The major difference is that a project needs to be configured to become a share-nothing environment, whereas a site doesn’t. It isolates its content from other sites by virtue of being a site. So, from a security perspective, a site is safer at isolating content than a project.
There are two different kinds of hierarchies in Tableau. There’s the content hierarchy, which consists of server, site, project, workbook, view, etc.; then there’s the “hierarchical projects”. The content hierarchy defines how elements are structured inside Tableau Server. It starts with Server, which breaks down into one or more Sites. Each site contains projects. Those projects will contain, workbooks, dashboards, views and data sources.
Hierarchical projects, in Tableau Server, are found at the project level not at the site level. In laymen’s term, it means that a site can’t exist inside another site but a project can exist inside another project. In fact, since Tableau Server 10.5, with nested projects, we now have control over how we organize content in a site.
First, we need to talk about the relationship between Site Administrators and Server Administrators. And we’ll start with something they both have in common. Both server and site administrators have unrestricted access to content within the area(s) they administer. So much so that you can’t restrict content from these two roles.
The difference is Server Administrators administer the server itself as well as all sites, whereas Site Administrators only administer individual sites. One of the outputs of a Tableau Governance workshop, delivered by Unilytics, is an answer to the question: who should be a Server Admin and who should be a Site Admin? The next step is to define who should administer which site(s) and why.
Depending on the organizational structure, a Site Administrator and a Server Administrator could work closely together or could be very much independent of each other. This may be because they work in different departments and have no reason to interact. The implication, in that case, is that certain communication channels will need to be opened for those two people to be able to coordinate and collaborate on Tableau Server. This can be done by email or by using a ticketing system such as Freshdesk.
Content promotion, in the context of Tableau server, is the process of taking a data source or a workbook from the development environment to production. Tableau Server doesn’t actually have built-in content promotion functionality, so it’s up to us to implement a solid process for promoting content from development to production.
There are ways in which the content promotion process can be automated, in part or in whole, but that’s a topic for another post. I will quickly mention a few topics for you to look at:
So, what’s involved in promoting content? Well from a governance standpoint, it’s again about defining who will be responsible for what.
These are some of the questions we need answered if we want to insure:
We basically need to make sure that when content is promoted from development to production, it doesn’t take the server down or slow it down to a crawl because of a messy data source or a dashboard so poorly optimized that it takes 3 minutes to render and uses 100% of all the Tableau Server resources to do so.
We do it through permissions. The most important thing to remember about permissions is that they are Project-centric. They don’t apply to users but to projects and their content. That means that we assign permissions to a project and then assign users to that project and that is how permissions and users interact in Tableau Server.
An important concept, when discussing permissions is Groups. They allow us to aggregate users into entities that we can then assign to one or more projects. It’s considered best practice not to assign individual users to a project but groups. Because project permissions can get pretty granular in Tableau Server, it’s easy to imagine how messy things could get if every permission to project / workbook / dashboard / data source were all being managed at the level of individual users. Which is why we highly recommend assigning users to at least one group and assign permissions to that group. Those permissions will then trickle down to the individual members of that group.
A Tableau Server “group” is an extremely simple feature; its only property is its name. It’s also an extremely powerful feature as it can affect a large number of users.
Groups come in two flavors: they are either created inside Tableau Server or imported from Active Directory. And in the latter case, there’s an added requirement which is that the groups in Tableau Server be synchronized with the groups in Active Directory. This is done by selecting the group or groups needing to be synced, then selecting “Synchronize” from the Action menu. Nothing to it.
So, what exactly happens when you sync groups? Simple: users that have been added to the Active Directory (AD) group since the last synchronization, get added as users in Tableau Server, and users that were removed from AD since the last synchronization, stay active in Tableau. That’s right, you heard me. That’s done so that administrators can reassign the content owned by that user before removing the user from Tableau Server. A user can’t be deleted until the content they own has been reassigned to another user or users. That’s how we roll in the Shire!
One last thing about Tableau groups and Active Directory – if your AD is part of a forest or if your organization is large enough that your Active Directory contains more than one group with the same name (for example, a department with the same name exists in two different offices or regions), there’s currently no way to tell Tableau which group to pick. In other words, Tableau Server does not currently allow a client to differentiate an AD group if it exists in multiple Organizational Units (OUs). This is a feature request that has been identified for future updates of Tableau Server.
This concludes our little intro on Tableau Server Groups.
If your organization puts the required effort into asking and diligently answering these 5 important questions, it will be well on the way to a successful Tableau Governance strategy. However, as I stated in my intro, the process of defining a Tableau Governance strategy can become quite complex. If you’re feeling daunted, Unilytics can help with a Tableau Server Governance Workshop (1 or 2 days) that will guide the process to enable everyone and ensure data quality, content security, and consistency.