Data driven interviewing with Tableau

Hi

Continuing the series of posts where I explain how we are building an enterprise grade Tableau Centre of Excellence.

Here at Vizninja towers we pride ourselves on knowing Tableau & data. After all, we need to be able to add value and help users with their myriad queries.

So when we get the chance to hire, it is critical that we get the correct people. People with great skills in Tableau, data & visual analytics. People that can tell stories and make data come to life. People who want to help others see and understand their data. And being a data driven team we use data and visualisation to help us make the selection.

Our interview process goes like this.

  1. An initial screening call with the Agile BI service manager (that’s me!)
  2. A technical interview with the team
  3. An exercise involving Tableau Public
  4. A final chat with the big boss (that’ll be me one day)

Some more detail on a couple of these steps.

 

The Technical Interview

We have a series of technical questions that the team asks each candidate. The questions are split between Tableau Server and Tableau Desktop and also categorised in terms of complexity – e.g. Level 1, Level 2 & Level 3, (see here) with the more complex questions being at L3 level. So I wait until my team are in a bad mood and then I let them off their leash at the candidate….

Our interview viz. Created by @jakesviz

Click the image to get a better view of the tooltips. Apologies if they’re not so clear. Here’s what some of them look like. So we can see the exact question asked, points achieved and any comments.

On the dashboard, you can see the questions asked, the max points available per question and then the points attained per category and complexity. At the end we spit out a KPI that gives us some indication of a candidate’s capability. Note that a low score doesn’t necessarily indicate that a candidate is unsuitable. Often we see people who are super-skilled in Tableau Desktop but not experienced in Server (as in this case). A few weeks with the team will soon change that though. Our job is to create all-rounders in all aspects of Tableau.

So if the data checks out then the candidate moves on to the next stage.

 

The Tableau Public Exercise

For the next test we ask a candidate to choose a dataset from these public datasets and then create a viz on Tableau Public. The candidate then presents their viz to us and we look for the following

  • Good visual analytics best practice
  • Ability to create an engaging story and develop insight
  • Structured design process and ability to justify design choices

And if they’re really unlucky then @jakesviz will download the workbook and rip it to bits in front of them! Yes we are looking to see if you’ve commented your calculated fields!

Here’s what Jakub Jaros came up with..

https://public.tableau.com/profile/jakub.jaros#!/vizhome/SignigicantVolcanicEruptions/Main

Nice work huh? We thought so. So now you know where to go for your volcano information. This is a really important part of the interview process as the candidate presents their work to us and it can lead to discussion, debate and even argument. But it really gives a sense of whether someone loves dataviz and you sure need that if you want to work for me. We plan to add some data points to this stage so that we can come up with a final rating for each candidate.

After this, it’s a final chat with the big boss and hopefully a role with the team. And that’s when the fun really starts!

This approach has really resonated with senior management and as a result we are helping several other teams to adopt a similar process.

So there you are. That’s how we ensure we have the correct people to deliver a great service. Feedback appreciated in the comments.

Cheers, Paul

Advertisements

What we got wrong building our Tableau service

Hi

I spend a lot of time talking to other companies about how to put together a decent Tableau Centre of Excellence. And that’s cool. I love to help people and I also learn a ton from all the other great setups out there.

But that also gets me thinking. We are far from perfect. And we made a whole lot of mistakes on the way to building our service. So instead of talking about the good stuff we did, I thought I’d highlight what I think we got wrong.

So in no particular order of importance, here are our top mistakes

Onboarding

So you’ve done the demo, shown the capabilities of Tableau and your audience is wowed. They want it and they want it NOW! So how do you get them from wanting to having?

Well we didn’t do so well. Our purchasing is handled by another team and the process is fairly complicated. Our mistake was not building a solid enough relationship with the purchasing team early on and making an effort to understand the points of the process that could be improved. We kind of just let them get on with it when we could have offered more assistance. This meant that on occasion users had to wait up to 2 months before they actually got their licence! And sometimes that cost us users, who gave up during the process.

Eventually we got together and helped the purchasing team out. And now things are a lot better. My advice – if you see a team you have a dependency on are struggling, then speak to them and help them out. Sounds obvious, but on this occasion we didn’t.

Setting Expectations

I spend a lot of time talking to users, often at a senior level, asking them to feedback on their experience with Tableau. On the whole it’s great stuff that comes back, but occasionally I used to get surprised with users informing me that their experience was poor. Tableau didn’t do what they wanted, it was inflexible and hard to use.

That didn’t sound like the Tableau I know and love. So I did some more research and it turned out that the users who didn’t like Tableau were trying to get it to do something that it wasn’t designed for. Now that’s fine if you’re Allan Walker or Noah Salvaterra but most of my users aren’t that level – in fact few people are. And of course that meant the users were getting frustrated.

I think the comment that really resonated was “Tableau? That’s Excel online isn’t it?”. Er – NO IT ISN’T!

The problem was obvious. Users thought Tableau was something it wasn’t. And naturally they would get a degraded experience. So we created a document that clearly states what Tableau is good at, and what it isn’t good at. We make users read this doc when they sign up for the service so they know exactly what they are getting.

This was very successful and really cut down the instances of poor feedback.

Some related posts on this subject from Dan Murray, Matt Francis & Peter Gilks

Training from the Get-Go

I’m a self-learner. So is my team, and most of the people I work with. I’m sure you are as well, that’s why you’re here reading this. And as a result I expect others to be the same. And for the self-learner, the world of Tableau is great. Tons of bloggers, forums, help articles, Tweeters, online videos and all sorts of quality learning materials. It really is one of the strengths of Tableau IMHO.

So we created guides & 101 pages etc and told users to go and help themselves. And to be fair, some of them did. But not as many as we’d have liked. And as a result we got tons of newbie questions and consequently poor quality content on our server.

About 8 months into the service we decided to implement a structured, instructor led training programme, amongst other training initiatives. More details here. Much of the syllabus is covered by Tableau’s own online videos and other resources but for some reason, new users really responded to this structured course. As a result we saw a corresponding improvement in the quality of published content and a reduction in the basic level questions to the team. In hindsight we should have implemented this right at the start, rather than assuming everyone would be keen to self-learn.

Commercials

Much as I love Tableau, their commercial operation isn’t the most flexible. That’s not just my opinion, it has been mentioned in Gartner reports. As a result we’ve struggled to negotiate the most competitive packages that we could have done. There have been some valid reasons for that but I don’t think we put as much effort into resolving the related issues as we should have.

And that’s important. I don’t want to get the best price for the sake of it, in big enterprises there are a lot of competitive threats from other tools. If Tableau isn’t competitive with pricing then the people that make the technology decisions will be perfectly happy to rip it out and replace it with something else. Not what anyone wants.

Again much of this is down to relationship building. As our relationship with Tableau has grown, we’ve seen improvement in this area.

Gamification

I’m a big fan of gamification. It can really boost engagement and turn a good initiative into an awesome one. We’ve had a couple of half-hearted stabs at competitions, to try and get things going but there is so much more we can do. Hackathons, viz games, competitions and internal Iron Viz – we’ve got a ton of ideas but never made it happen yet.

I think that’s partially down to the wide geographical spread of my user base. It would be really hard to get people to show up in a particular location. Users are also insanely busy, would I be able to round up enough people to make it worthwhile? So lots of excuses and not a lot of achievement in this area. I’m open to ideas if you’ve got this one nailed.

That’s it for now. There may well be a part 2 to this as I’m sure there are more things that will come to mind as I cry myself to sleep thinking what a mess we’ve made of it all… 🙂

Thanks to the awesome Matt Francis for inspiring this post.

Happy vizzing, VN

How To Set Up Your Tableau Server Environments

Hi,

Guess what this post is about – yes TABLE CALCULATIONS…. haha. No chance. Talk to Jonathan Drummey about those. This is of course yet more info that I hope will help you guys set up a dream Enterprise Tableau deployment.

Today we are gonna talk about Environments – i.e. what Tableau environments should you create in your organisation to give your team the best chance of success and keep your lovely users happy?

As always, I’m not saying this is THE way to do it. There are tons of great setups out there. I’ll just tell you what we have. Feel free to suggest better methods in the comments.

 

Environments for your users

This section is concerned with environments that you will provide for your Tableau users to do their work. Typically this will follow the standard Information Technology Infrastructure Library (ITIL) environment definitions, but there are a few things you can do to add extra options for your users.

These are the environments our users have at their disposal:

  • Production – The main business & user facing environment. Content published here is authoritative, follows best practice (hopefully) and is actively supported.
  • Testing – aka UAT. Generally used for final testing of uploaded content
  • Development – The environment where content is first shared as part of the development process.
  • Scratch – An extra environment for content that doesn’t need environment management. E.g. User wants to temporarily share content with a couple of colleagues.

Providing these environments gives users crucial options and flexibility. Your Tableau service will most likely serve many different business areas and teams, each with different practices for content development and release management. Some teams will rigorously follow Systems Development Lifecycle (SDLC) processes, creating content in development, promoting to User Acceptance Testing (UAT) and then eventually to Production. Other teams are totally happy to change content directly in Production, as and when they feel like it.

Crucially we don’t mandate what our users do, it’s a self-service model and so long as they follow their own due-diligence and governance procedures then that’s cool with me. The important thing is that we give them options to work with Tableau in the way that they want. If they break anything then they know it’s down to them.

The scratch environment is an interesting concept. It started with good intentions but realistically not many people are using it. So it looks like we might bin that.

Note that we use Tableau sites to segregate our environments.

 

Environments for your team

This is different from the above user-facing environments. These are the environments that your team uses for the service you provide. Obviously all this costs money in terms of hardware procurement and usage, depending on the spec you choose.

  • Production – Main environment that serves your users. In our environment this also includes the UAT, Development & Scratch sites for users – but we class it all as production. That might seem odd, but remember that many teams will be development teams, and to them the development site / area is their equivalent of production. So if the development site is down then they can’t work.
  • Disaster Recovery (DR) – For use in the event of a Production outage that can’t be easily restored. Exact same spec as Production. Totally identical, so that config can be restored and this server can be used as Production. You’ll need to make sure this environment gets the same upgrades as your Production environment.
  • UAT – This is UAT for my team. If we want to make a change to Production, it gets final testing here. This environment is also the exact same spec as Production to ensure an accurate test. If it fails here then it’s likely to fail in Production as well. We use UAT for testing maintenance releases, config changes and other potentially disruptive non-Tableau related changes to the server. Additionally, we make this environment available to users for a couple of weeks UAT prior to releasing new versions to production.
  • Engineering – Lower spec than prod & UAT. For testing the latest available release from Tableau. That is likely to be a higher version than production. Is useful for spotting bugs in new versions or confirming that bug-fixes work.
  • Beta Test – We are proud to be part of Tableau’s pre-release testing audience. We use this server to test releases in the Beta programme. Lower spec than engineering. To the point that the server only just meets the minimum requirements.
  • Alpha Test – We use this to test the alpha releases or any extra work we may be doing with developers at Tableau. We love to be involved in the genesis of new functionality.

So that’s what we are lucky enough to have. It’s not perfect but it allows us to give our users a ton of flexibility in how they use Tableau, and also my own team always has a place to test new releases, plan upgrades and help Tableau with their pre-release programmes.

Interested to see what the community has in terms of environments. Let me know in the comments. Remember there are a load of other posts on this blog about Enterprise Tableau considerations.

Cheers, Paul

How to Build a Tableau Support Team

Hi

So you want more about how to build that awesome enterprise Tableau service? No? Oh. Well tough – I’m gonna crack some more knowledge eggs on yo ass. That’s what the kids say these days isn’t it?

This time, it’s a big one. How to build a team to support that Tableau environment. As with most of my posts there are many ways it can be done but I’m going to describe what I’ve got in place. And it’s working pretty well even if I say so myself. Ner ner…

This post is going to concentrate on people-related aspects of your support team, rather than technologies. There may be another post on the way about that depending on whether anyone bothers to read this one other than Mrs Ninja.

Before I kick off, I am aware that most of these IT service posts don’t have the sexy factor of all those other cool blogs about Level of Detail (LOD) calcs, viz design or those games that people keep creating in Tableau. BUT – if you want to get Tableau to take off in a massive Enterprise then these are the things you’ll need to consider. Get one of them badly wrong and your dream could become a nightmare. So I don’t care if you don’t think it’s glamorous.

 

Some assumptions

I’m gonna assume that you’ve already been through the aggro of fighting for precious headcount and that you have what you have. Hopefully that will be a good few people, more likely it will be n – 1 where n = the bare minimum needed… You’re just gonna have to accept that – you’ll never get enough bodies. If you work somewhere that gives you tons of people – give me a call…. (just kidding boss).

 

Where you gonna put them?

A few options here. We’ve located the whole Level 3 (see later for L1 / L2 / L3 roles) team in London. The main reason for that is that I’m here, so is my manager and the infrastructure is also in London. That gives us better oversight as we get this thing off the ground.

You may wish to consider splitting your team across regions if that is the company strategy. This can give advantages that you have close to 24 hour L3 coverage. It’s great if you get an towards the end of UK time, and are able to then hand off to your USA team, who then run with it and resolve while you’re enjoying forty winks.

In the future the demands of your service may determine where you locate additional people. Much of this may be down to your company strategy, where there may be a preference for lower-cost locations as opposed to paying the big bucks to people to come to London or New York etc.

But you should also be mindful of where your service usage is growing. Using our Custom Admin Views (post on it’s way about them) we can see exactly what regions our Server is being hit from and where our Desktop users are located. If you see adoption in a particular region going through the roof then maybe you should consider recruiting in that locale? We got a tremendous response from our Singapore user base  when we went live. They LOVE a bit of Tableau. But when they are online, we are asleep so they get delayed response to queries. I should probably put someone out there to give them better service.

It’s not all gravy though. Managing remote teams is difficult and takes a lot of organisation.

I’m sure you get the drift. You may not have much choice in location, but then again you might…

 

Support Levels

Typically large organisations will have a standard Information Technology Infrastructure Library (ITIL) model of support roles and responsibilities. To summarise.

  • Level 1 Support – Detects and registers incidents. Can apply basic remediation but more likely to escalate to Level 2. Level 1 also performs incident triage and communication to affected user base.
  • Level 2 Support – More skilled technicians with access to your production environment. Can often solve incidents and manage appropriate user communication. L2 also assist us with Tableau Server upgrades and failover tests etc.
  • Level 3 Support – That’s my immediate team. We have break-glass (non-standing) production access to assist if L2 can’t solve the problem.

More info on these roles and responsibilities here.

It’s really important to get this working well. An efficiently functioning L2 will come to be your team’s wingman, taking the pressure off your engineers. We’re lucky to have a good L1 & L2 setup, so only approx 10-20% of incidents ever filter all the way down to my L3 team to fix. L2 can usually deal with most.

Your L1 & L2 teams will tend to operate exactly by the book, so make sure they have appropriate process and documentation to allow them to succeed. They’ll also probably be supporting more applications than your precious Tableau Server so bear that in mind. Yes some people actually work on other applications not just Tableau – the fools.

 

What’s Your Service Model?

This is a topic that can make or break your service. As far as I’m concerned the only option for a big organisation, where you’ll never have enough people is to go Self-Service.

That means – my team doesn’t create visualisations for anyone. Users don’t submit tickets to us for us to create their vizzes. Why?

  • Context – Users know their data best. They know how it hangs together.
  • Volume – My team wouldn’t be able to handle the sheer volume of requests coming in and that would lead to a slow service.
  • Agility – So many tools at big organisations are mired in red tape, delays and bureaucracy. Not my Tableau service. We’ve cut through all of that crap to give users a tool that they can use as they wish, get results and get into production fast. What’s the point of giving someone an agile tool and then making life hard for them to get results?
  • UX –  I love it when a user thinks they are not technical enough to use Tableau. I tell them to go and try it and come back in a day if they are still stuck. I find they come back in a couple of weeks instead, having had a blast. If we just did the work for them, then they wouldn’t get that magical UX that we all love, and they’d think Tableau was just another tool. So I want them to do it themselves, and get that brilliant realisation that they’re using a fantastic application.

So we make sure users know this is a self-service model, and a true Data Visualisation Centre of Excellence. Check this post for how I constructed our CoE. I’ll be doing another post later on how this service model hangs together.

In summary, because we don’t create vizzes or datasources for users, we have time to concentrate on the extra value items that differentiate us from other IT services.

 

Your Team’s Roles

So what type of Tableau work will your team need to cover? We kinda bucket our tasks into the following groups

  • Engineering – Building, customising and integrating our beautiful Tableau Server with other systems. Upgrades, tuning & generally being nice to it.
  • Training – Delivering our World Famous training syllabus, Dr Sessions and all the other goodies detailed in this post.
  • Consultancy – Helping users with visual analytics, issues, performance, or anything else they want.

So you’ll have to decide if you want each person in your team to be able to cover the whole spectrum of tasks, or do you want to have specialists? I’m lucky enough to have a cracking team, where my girls and guys can swap between any of these buckets with relative ease. It’s still cool to dedicate one person to user work and the other to engineering for a time though, but be aware there may be an impact when one is on holiday.

We have chosen to keep the training programme operated by one person though, as this has allowed us to build up a more consistent programme that can be tweaked and refined.

So because we empower users to create their own content, we can dive head first into all this juicy work. It’s interesting for us, and users love it.

 

Adding The Gloss

Some other activities my team perform as part of our service. I class these as the glossy items as I don’t see any other IT services doing them. And the reaction we get from our users is phenomenal.

  • Makeovers – We pick a viz, download it, make it loads better, send it back to the user with some notes on what we did and what they can do to better understand why we did it. Always a winner. Who doesn’t like their work being made better for free? Needs sensitive communication though as we don’t want these to be seen as a criticism of someone’s work.
  • Competitions – We’ve got a weekly challenge competition going on and we periodically do other larger viz-offs. We get Tableau involved in the firmwide Hackathon events and offer swag or dedicated time from the team as prizes. We also encourage users to get involved with things like IronViz.
  • Interviews – Our series “Agile BI talks to…” is proving popular. Basically an internal version of the “2 minutes with…” interviews that we do on this blog. Users love a chance to sell themselves so we have a queue of people wanting to take part.
  • Champions – This is an internal version of the Tableau Zen Master programme. It is great for building engagement, encouraging competition and driving up standards across your user base. We currently have 2 Champions but I know there are several users who are desperate to be recognised as a Champion. This is a 2-way initiative, Champions sell and evangelise our service and in return we give them extra insight into the product, vendor etc.
  • Proactivity – Using our Custom Admin Views (wait for post on those please) – we can tell when users are having a bad experience with Tableau – usually down to slow performing visualisations. So rather than have them complain, or suffer in silence, we can reach out and say “We think you might have a problem, let’s fix it”. This usually blows them away. I’ve had comments back like “This is the first time I’ve EVER had an IT team come to me and tell me I may not be getting the most out of their tool – I usually have to complain first – it’s incredible!”.
  • Tableau Touchpoints – Again, using our Custom Admin Views – we can tell who is engaged with our service. And we can tell what rank they are, and where they work. So I spend a lot of time reaching out to these people (the more senior the better), and making sure they are fully aware of the services we offer. I’ve packaged it into a standard experience called Tableau Touchpoints. Told you I was into branding…
  • Polls – Simple. Think of a question, put it to a fun vote. We have one on the run at the moment called “What is your favourite chart type?”. Gets people talking and interacting. Sometimes it gets heated. But it always gets people clicking on your community page.

 

You’re Certifiable Quint!

quint

Quint was certifiable, just not in Tableau

Try and get your team certified. You want to be seen as the experts then you need to wear the badge. While certification certainly isn’t a substitute for on-the-job experience, it does give that air of confidence to your users. It’s also fun to do.

Senior management will also like to demonstrate to the business that your Tableau service is manned by highly skilled, vendor certified technicians. So more of a branding exercise but still very much worth doing…

For more info on Tableau Certification check this out.

 

Monitor Your User Base

One of the things that tends to happen with Tableau is that *some* of your users will totally fall for the tool. Just like I did and many of you out there. These are people you should be aware of as they are heading down that path to wanting to make Tableau their whole career.

Keep an eye on users that are spending lots of time with the tool, have seriously engaged with your mission or that have been demonstrating great expertise. They could be potentially interested in moving to work for your team. I get asked regularly by my user base if there are any jobs going in my team. That’s obviously cos I’m an amazing boss and we have it totally going on – who can blame them. It’s got nothing to do with Tableau…

But seriously, rather than going out to market and risking getting the wrong person in, the answer to your resource issues could be right under your nose.

 

Freedom of Expression

1000509261001_1231344818001_Bio-Biography-Jackson-Pollock-LF-FIX

Let your team express themselves (with data, not paint)

I think it’s really important to allow your staff to express themselves. Data visualisation is a creative art, and allowing your team a free mind is critical to their creativity, enjoyment and success.

I make sure my team know that I’m all for them blogging internally & externally, interacting on social media, building contacts and going out to our user base proactively to help. If they see a viz on our server that they think they can improve then they just go for it. If they want to dive more into a particular user’s requirements then just do it. Wanna write a blog – do it already!

This applies to contractors & consultant staff also. I want consultants to leave having developed into more able technicians from having worked with my service – I don’t regard them as hired gun resources to squeeze work from, they are valued contributors to our mission.  I find that consultancies really appreciate this approach and it has led to us building some great relationships with consultancies and individuals alike.

I’ve heard you even have to give your team days off. They’re called “holidays”. Yeah I know, it’s a legal thing apparently. Won’t catch on.

 

Freshen it Up

I actually operate a model where I swap out consultants every 6-8 months regardless of how well they are doing with us. I do this because it is useful to get a fresh perspective on our environment, with each new person bringing something different to the table. I also do this for the benefit of the consultant themselves. No-one wants to be stuck in a single role for 18 months, so I like consultants that work for me to work hard, learn lots, then take those skills away to their new roles. Again this is really appreciated by the management at consultancies as part of our strategic partnerships.

 

The Human League

human-league

We’re only human…

You know what users hate? They hate it when they have to submit a ticket or email to some faceless system, that gets picked up and processed by someone they’ve never met, in some region thousands of miles away. It feels, well, inhuman.

Not in my team. We’re all about being as human as possible. My team all have their individual profile pages on our community site. They have blogs. They have photos and backstories of their career and interests. They advertise their social media presence. They are contactable and approachable. People know who they are, what they look like and what makes them tick. When you deal with my team you are getting a proper service, from real people that you know care.

We get much better user engagement like this and as a result my team has gotten to know some users really well.

 

Change & Incident Management

Ah everyone’s favourite subject. So Tableau is great right, but it’s still only a piece of software. And as such you’re gonna get issues. So you need to handle them correctly.

Firstly, make sure you’re utilising Level 2 support for your changes and handling your incidents. This will take so much heat off your Level 3 team. L2 should be able to do all of your paperwork, manage the communications to your users, and even perform the majority of standard changes like upgrades and config changes.

We always make sure we over-communicate on changes and incidents. We involve power users and get them really ingrained into what we are doing and why we are doing it. Your power users will love to know why something broke, what Tableau are doing about it and when that fix will be implemented because they want to really understand the application. Often they come up with good suggestions as to what you can do to help prevent a recurrence. So get them involved.

I’m not going to go into too much detail on this, there’s a ton of ITIL related reading you can do. The message is – you can get a lot of positives from handling a negative situation well. Show empathy to your users for the impact they have experienced, show you care, don’t hide anything and be totally transparent.

 

A Big Thank-You!

To give great support you have to have great people. People that are skilled, passionate and dedicated. People that care about the service they provide and your mission. If you don’t have great people then don’t mess about – get someone else. You’ll be the one judged by users and management, so there’s no room for sentiment.

I’m lucky. I’ve had really great people. So a big thanks to Jake, Carl, Andy, Emma, Jonathan & Dave for helping to build and run our service!

OK that’s it for this one. There may well be an update to this post as it’s such a huge subject that I’m sure I’ve missed some things.

Now if you’ll excuse me my team seems to have gone to the pub… Err guys? GUYS???

How to manage Tableau upgrades in an Enterprise environment

Hi,

Been a while since my last post. Been exceptionally busy at work due to widespread adoption of Tableau at my organisation. Usage has doubled in the last 3 months and we now have thousands of users to keep happy. That takes some doing, hence the blog hiatus.

Anyway, time to continue the series on Tableau as an IT Service, with a subject that I’m asked about a lot – just how do you manage your Tableau upgrades in an Enterprise environment?

This is actually a pretty big subject, especially in an Enterprise setup. There’s no perfect way to do it but hopefully some of these tips will be useful.

 

Section 1 – Pre-Upgrade Considerations

To upgrade or not? That is the question

Obviously you’ll need to make some sort of decision as to whether or not you actually need to upgrade. Each time you upgrade a production system you risk impacting stability, introducing bugs or human error. It also needs testing, planning and eats resources and time. So if there’s no good reason to upgrade, then don’t.

Tableau release new versions at a pretty impressive cadence, generally once a month for ‘maintenance’ releases. So for each newly advertised release, take note of the following in order to make your decision.

  • Compelling functionality –  New features are entering the product all the time. Determine what may be useful to your user base.
  • Key bug fixes – Each new version will squash a few bugs. If there’s one that is affecting your users then it may be prudent to upgrade and quieten the noise. Remember that your upgrade may introduce new issues. Take note of the known issues section in the release notes.

Both of these are fully documented in the Release Notes. Review them carefully each time Tableau announce a new version. There are occasions where bug fixes are not announced in the release notes but your account manager will make you aware of those.

Also be aware that new versions might also introduce new bugs / issues. We have had situations where we have been stable, decided to upgrade and then spent the next few months battling newly introduced issues to the point that we probably should have stayed on the older version.

Be aware of compatibility issues

I hear a lot of complaints about compatibility issues between Server and Desktop. So it’s important to be aware of the behaviour between versions. Get this wrong and you may be in a position where users have overwritten content originally created in an older version and don’t have a back up to roll back to. If you are crossing major versions (8 -> 9) for example, then you’ll certainly need to upgrade the Server and Desktops at the same time.

Top tip – it is possible to hack the xml of a workbook to change the version and rescue the situation, provided no edits have been made to the content. The ever-so-talented Jen Vaughan (@butterflystoryexplains all here.

For more details see this article.

Don’t upgrade to version zero

Most risk averse IT managers (like me) will resist the temptation to jump right into that new shiny Vx.0 release the day it comes out. Version zero releases of any software are notorious for bugs and issues, that’s just the nature of software development. So at my org we always let at least one maintenance release slide by and instead go to the Vx.0.1 or Vx.0.2 release.

It can be hard to resist temptation, especially when your users are clamouring for that shiny new version but if there are major bugs in that zero release, then best let someone else find out about them rather than you.

Caveat: This doesn’t always work of course. We waited for 9.0.2 and that ended up being one of the buggier releases. Oh the irony.

 

Understand the new version resource demands

This is important. You may be rocking away on your existing version, confident that your hardware can satisfy the software. But then you upgrade, and all of a sudden that new version eats up double the RAM or batters your CPU. You didn’t see that coming.

For version 9 Tableau released an updated scalability document. Annoyingly it was released quite a while after V9 went live. I was expecting a comfortable read but noticed phrases like the following, which were pretty alarming.

Screen Shot 2015-09-04 at 23.03.31

Screen Shot 2015-09-04 at 23.05.20

Whaaaat?! That led to some discussions with Tableau tech folks (thanks Meredith!) and some fevered testing and all turned out to be ok. But those figures took us by surprise for sure. Don’t be in a position where you upgrade and then suddenly hit a capacity issue that your older version didn’t have.

 

Test it!

Let’s say you upgrade. And it goes wrong. One of the first questions you’ll get asked is “Did you test this?”. You really don’t want to be answering “no” to that question.

You should have at least one non-production environment that you can run tests on. Due to the complex nature of Tableau it is impossible to test every aspect of functionality but you should at least be able to cover a good number of scenarios. You may also not be able to simulate your production load on your test environment but it will be better than nothing. You may find the load testing utility tabjolt handy here. Check Russell Christopher’s guide to tabjolt.

I have the following environments to play with. This gives me a lot of options.

  • Production – Main user facing environment
  • BCP – Disaster recovery environment in case production fails
  • UAT – A mirror of production. Same spec
  • Engineering – Lower spec, used to test the latest version available from the vendor
  • Beta – Even lower spec, used for testing beta versions
  • Alpha – for testing the alpha versions

Ensure that the tests you conduct are consistent, repeatable and that the outcomes are recorded. We use a tool called Quality Centre and the tests are performed by my level 2 support folks. This gives consistency and frees time for my main analysts.

Verify your licence details

Double check your licence maintenance end date for both Server and Desktop. If you’re out of maintenance then you won’t be able to use the application after you upgrade. I’ve seen licence issues way too many times with many applications after an upgrade. You won’t want to be trying to contact your account manager on a weekend to sort out a licence issue.

Opinion – IMHO I would much prefer it if applications didn’t crap out due to licence expiration. In 99% of cases there’s some paperwork misunderstanding that is easily sorted by your account manager. By all means let the application hit you with some warnings and also alert the vendor, but it shouldn’t mean a loss of service.

 

Your upgrade process & strategy

I’m not going to go into it here as it’s a full on subject in itself but make sure you follow your organisation’s Change Management procedure to the letter. Failure to follow change processes is generally a dismissible offence in most Enterprises.

Make sure you advertise your strategy for upgrades and maintenance to your users. You’ll get asked, so ensure this is specified in your Service Document. You may even have standard maintenance windows (e.g. on a weekend) where you can reserve the right to take down the system. Again, make sure that is documented and your users are aware.

 

Section 2 – The Upgrade

Create a package

Most enterprises will use some form of package deployment tool / team to perform the actual deployment of new software. That’s pretty handy. I have over 500 installations of desktop to support and we need to ensure they all get upgraded at the same time. So I can create a software bundle, send to the packaging team and they will then schedule and deploy.

This gives you the chance to include those little extras in your package to give your users the best experience. Here’s what’s in our Tableau Desktop package.

  • The installer exe file
  • A sample “Getting Started” workbook with tips, best practices & help.
  • Preferences.tps file containing customised colour pallettes
  • Most used drivers (Oracle, MySQL etc)

I would love to be able to customise the “Discover” pane to point to some of my internal resources but it doesn’t seem to be possible. Boo.

We also supply custom instructions for the packaging team, such as running the installer with a flag / registry update to disable the auto-update feature that has been implemented in the upcoming 9.1 release. A really baaaaad idea for Enterprise deployments.

One thing to be aware of with packaging is that it can take a long time. From request to deployment, the typical time at my org is an insane 7 weeks! By which time another version is out. We are hoping to speed that up a bit obviously.

Communicate to the max

You can’t over communicate any potential disruption to your service. Make sure a broadcast message goes to your users via whatever system your firm uses. And it doesn’t hurt to follow-up with your power users / senior stakeholders with a personal reminder that work is planned.

Take a backup

Whadda ya mean you didn't take a backup?

Whadda ya mean you didn’t take a backup?

Tableau is one of the easiest applications to upgrade that I’ve worked with. A simple uninstall / reinstall does the trick. But don’t take that for granted – make sure you take a manual backup prior to your upgrade. If you’re not doing this as a matter of principle then you’ll be getting a visit from the boys. And they won’t have had their dinner.

Handily, the uninstall process takes a backup anyway but don’t rely on that, take your own.

You should also back up all your .yml configuration files and ensure you know what each setting is. Tableau should preserve these settings during the upgrade but just in case it doesn’t then it’s handy to have a copy to refer back to.

Server specific considerations

When you uninstall Tableau Server it backs up the content and the settings in the main yml configuration files. That’s cool, but do remember that if you’ve changed any of the other config files then they will be overwritten and you’ll have to make the changes again. For example we change the webserver timeout settings in the file “\Tableau\Tableau Server\data\tabsvc\config\httpd\httpd.conf.templ” – that gets blown away by an uninstall.

There may also be other settings in the Postgres db that you may have modified using tabadmin. Not all are retained from what I can see. Note I’m still researching this so not 100% sure of the behaviour.

Finally make sure you understand any changes to the Tableau Postgres DB schema in the new versions. It has generally remained pretty consistent but if any tables or fields are renamed then that may well break your Custom Admin Views.

Section 3 – Post upgrade

Test it! Again!

Not all issues come to light immediately. Perform testing, keep vigilant and liaise with your users closely in the next few days to understand if the application is behaving as it should be.

Ask for help!

Tableau Upgrade Assistance

Tableau Upgrade Assistance

If all this sounds a bit daunting and you’d like to get assistance then Tableau offer an “upgrade assistance” programme which might be worth looking at. Talk to your account manager for more information.

There are also other guides around. Have a look at this one from our good friends at Interworks.

That’s it for this post. As I said it’s a big subject so do post comments if you feel I’ve missed anything.

Happy upgrading! Cheers, Paul