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

10 Thoughts from Tableau Conference 2015

Howdy y’all,

What a setting..

What a setting..

Yeah it’s 2am and I’m wide awake. Coming down from a great week at Tableau Conference 2015 in Las Vegas. So I thought I’d knock up a post about how the week was for me.

 

 

Thought #1 – “WTF?!”

Er...

Er…

Turning up for registration on the Sunday, the last thing I expected to see was an 8 foot high poster of my ugly mug grinning out at me. I saw some younger children at the event and they would surely have nightmares at such an image. Then there’s the question of my image rights… Tableau we need to talk about that…

Although it did allow people to get their #picwiththepauls

Francois gets his #picwiththepauls

Francois gets his #picwiththepauls

 

Thought #2 – “Wow it’s so great to meet you at last / again”

TC is all about the people. It was great to meet people that I’ve been interacting with all year. Some of these were existing relationships, and others were meeting for the first time. Too many to name but I was really pleased to finally meet George Gorczynski, Steve Fenn, Mat Hughes, Jen Vaughan, Fiona Gordon, Jon Boeckenstedt, Ken Black ( & Jett) & Mike Moore.

It’s great when I meet someone that deals with Server rather than all you Desktop jockeys. See us Server folk have a secret handshake and knowing look in our eyes. We know what really matters in Tableau!

It was also great to see the new Zen Masters. Especially the British contingent – my pals Chris Love & Rob Radburn. Awesome stuff.

 

Thought #3 – “The devs smashed it”

I was delighted at the product enhancements announced this year. Functionality that is really going to make a difference to the ~4000 users I support.

It will be interesting to see which features really capture the imagination of my user base, but I can anticipate cross DB joining, union &  global filters being very popular, as well as the user home page on server.

We're not worthy..

We’re not worthy..

But I kinda gave my position away as to what made my day in terms of new functionality – yes that pic does show me bowing down in homage to Version Control. In front of 11000 people. Hey I’m not embarrassed, it took all of my self-control to prevent myself from storming the stage and giving the guy a hug.

 

Thought #4 – “Isn’t technology great”

My conference experience was massively enhanced by a couple of tech items.

Firstly the hugely useful Tableau Conference app. I love the way the organisers monitor the number of favourites a session gets in order to determine of the room allocation is suitable for thee demand.

Secondly, WhatsApp. Despite having a crappy name, this app was great for keeping in touch with colleagues and friends. My pals at The Information Lab are always super-concerned with the social aspect of events and set up a WhatsApp group to allow us to sync. Before we knew it there were 50 members and it became the prime method of determining what bar everyone was in or what session people were at. Great stuff.

 

Thought #5 – “Las Vegas – oh dear me”

download

Fabulous? Erm…

I’ve been to Las Vegas once before. Just for a couple of days passing through. I recall not being too impressed back then, and this visit just confirmed my earlier thoughts. While I’m undoubtedly amazed at the imagination and brilliance of the designers that constructed some of the buildings, I’m still left with a feeling of disgust and depression at the underlying tone of seediness and corruption. It offends pretty much everything that I stand for.

I hope some of you managed to take a virtual shower by getting out to the Grand Canyon or surrounding areas like Bryce Canyon which are stunning. That’s Las Vegas for me. You can keep your Casinos.

 

Thought #6 – “Why can’t we just have one big global time zone?”

Jet lag sucks. I propose we have one mega time zone (GMT of course) and stick to that. The rest of the world would have to work in perpetual darkness but you’d soon get used to it. Change your goddam date format while you’re at it.

 

Thought #7 – “That’s the best session I’ve ever seen at a Tableau Conference”

I hope some of you went to the talk by Jeffrey Shaffer & Andy Kriebel entitled “Dear Data Two“. Read the abstract if you want to know what it was about but suffice to say I found this talk incredibly engaging. It covered a huge variety of data viz examples, all done with fun and humour. It was also technical enough as the vizzes were also constructed in Tableau. I loved it. Original, brilliant and emotional at times, this was everything a TC session should be. And told by two natural presenters on stage.

Another stand-out session was “The New Tableau Web Data Connector: APIs, JSON & Javascript for Dummies” by Craig Bloodworth. This was a perfectly pitched run-through of the WDC and gave me real confidence that I could go and build one myself.

 

Thought #8 – “Nice one @cheeky_chappie”

Safety first at Paul's talk

Safety first at Paul’s talk

I tend to hang around a lot with Paul Chapman. No I don’t know why either, but it happens. And it was great to see him absolutely smash it with his presentation “A Single Shade of Orange“. He’s a #futurezenmaster for sure.

He has been ably coached by an expert road crew (myself & Tom Barber) so we take some (most) of the credit for his success.

 

Thought #9 – “I wish I was on that stage”

I’ve spoken at the last 3 Tableau Conferences (2 in London & also Seattle). My application was rejected this year to rightly give someone else a chance. That’s cool.

But I was super-jealous of those that did get the opportunity. Speaking at a Tableau event isn’t like other events (of which I do a few). At TC you’re presenting in front of friends, and people that share your mission. They want you to do well. No-one is watching you and judging, or hoping you don’t do well. They all want to learn from you and want you to rock.

It’s a mega buzz to be up on stage and I’d recommend anyone to do it, even if you feel you’re not a natural presenter.

 

Thought #10 – “This whole thing isn’t the norm”

Code. That’s all Tableau is. Computer code. So why has it changed my entire working life in less than 3 years? I think I know the answer. You see in order to achieve this perfect storm an organization needs to nail each of the 3 pillars

  • Application – the tool has to rock. It needs to be easy to use and needs to be able to make your job easier, not harder.
  • Company – The company needs to be solid. Progressive, innovative and approachable
  • Community – You need a great set of users, with a true sense of collaboration and friendship.

In my career I’ve seen many tools, companies and communities. Most organisations nail 1 out of the 3, occasionally you’ll get a really good one that hits 2/3 – but in 15 years of IT, Tableau is the only one I’ve seen that nails each of these pillars and then some.

It sounds almost cheesy to say it but this isn’t the norm. If you’re a 20-something graduate in your first job using Tableau and you think that all tools and organisations are like this then you’d better wake right up now. This is NOT the normal experience. I’m just grateful I found it at all, mid-way through my career. If you’re lucky enough to have discovered Tableau in your youth then WELL DONE! Enjoy it! You’ve hit the jackpot!

So those are my thoughts on another stellar event. See you in Texas everyone!

Paul

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

How to Monitor Your Tableau Server – Part 1 – Infrastructure Monitoring

Hello there,

I hope you are all well and recovered from #data14. What a great event that was.

I’m gonna get a bit serious on yo now. It’s time to talk monitoring.

For a Tableau service manager (or any IT service for that matter), the worst situation that can possibly occur is getting a phone call from your users to tell you that your service is down. At best you’ll look stupid, at worst it will cost you credibility and is a sure-fire way to destroy user confidence in your service.

So how do you avoid this? You could not have any outages – well you can forget that, it aint gonna happen. You’ll get issues so get ready for them. What you can do is monitor your service big time. That way you’ll get the heads up and you can answer that phone call with a “yep we know, we’ve just raised an incident ticket and we are on it” – or better still, get to the incident and fix it before users even notice! Remember that effective incident management can actually gain you plus points from your user base, and senior management.

The problem with monitoring is that it’s BORING. I should know I did it for 12 years! But it’s also essential! Get it right and you’ll be making your life a lot easier. It also traditionally doesn’t get a whole lot of investment thrown its way as there’s no immediate tangible business benefit.

Monitoring falls into these categories. This is likely to take me more than one post to explain and it’s a big subject so I’ll doubtless miss some bits out. As always, I’m happy to connect offline and explain.

  • Infrastructure monitoring
  • Application monitoring
  • Performance monitoring
  • Capacity monitoring
  • User experience monitoring

Infrastructure Monitoring

As the name suggests this is all about monitoring of your infrastructure. That’s your hardware and network, peripherals and components of the platform your Tableau Server application is running on.

Chances are the infrastructure will be owned by an IT team. You’ll need a great relationship with these folks so if you haven’t then start buying them some doughnuts now. From what I can see Tableau is often brought into organisations by business users and that then antagonizes IT, meaning this relationship isn’t always the best. That’s a separate conversation however.

 

How does infrastructure monitoring work?

Chances are your monitoring team will have decided on an enterprise monitoring tool for the whole organisation. It will probably take the form of a central server, receiving alerts from an agent that is deployed as standard on each server in the estate.

NagiosSome examples of commonly used monitoring tools include the following. I’ve got a fondness for ITRS Geneos myself but am not going to go into the relative merits of each tool. You won’t have a choice what tool is used in your org anyway.

So what happens? Well the agent will have a set of monitoring “rules” that it adheres to. These will take the form of something like “check the disk space on partition X, every Y minutes and trigger an alert if greater than Z percentage full”. That’s all the agent does. Polls the server for process availability, disk space, memory usage etc on a scheduled frequency and triggers an alert to the central server if the condition is breached. Those parameters should be fully configurable.

consoleThe central server will then display the alert on an event console such as this one (pictured). Alerts will be given a criticality such as minor, major or critical. The alert console will be viewed by a support team, usually an offshore Level 1 team that provides an initial triage of the alert. They may then pass it onto a Level 2 team for potential remediation, or they may also pass it on to Level 3 – the main support team. That’s the usual process in a big organisation.

So what’s the issue with that? Well there’s the time factor for one. It can sometimes take 20 – 30 mins for an alert to get to the person that matters. That’s obviously not great. Also there’s the sheer volume of alerts, a big organisation can be dealing with tens of thousands of active alerts a week, many of them junk. That increases the risk of your alert being missed. There are also a lot of break points in the process, and sometimes alerts just go missing due to lost packets, network issues etc. It happens. On the whole the process works though.

 

Who’s responsible and what for?

Your infra teams are 100% responsible for the monitoring of these components. This encompasses

  • Server availability (ICMP ping)
  • CPU usage
  • Memory usage
  • Disk space (operating system partitions only)
  • Network throughput / availability

trustnooneThey’ll tell you not to worry about this. They’ll tell you that any alerts will go to their support teams and they’ll be on it should they detect an issue. My advice – don’t trust anyone. There have been many times where I’ve had an issue and lo and behold the monitoring hasn’t been configured properly, or hasn’t even been set up at all. Or there’s been a bad break in the process somewhere. That aint cool.

 

So what should I do?

Take these steps to keep your infra teams on their toes. They’re providing you a platform, you are entitled to ask. They might not like it, but stick to your guns – you’ll be the one who gets it in the neck if your Tableau Server goes down.

  • Ask for a breakdown of the infra monitoring thresholds – What’s the polling cycle for alerts? What thresholds are being monitored? Who decided them and why?
  • Ask for a process flow – What happens when an alert is generated? Where does it go? How long does it take for someone to get on it? How is root cause followed up?
  • Ask to have visibility of the infra changes – If there are changes going on to the environment that might affect your server, make sure you get notified. Make sure you attend the appropriate change management meetings so you know what’s going on.
  • Ask for a regular report on server performance – There will probably be a tool on the server that logs time series data on server performance. That should be accessible to you as well as them. Chuck the data into Tableau and make it available to your users.
  • Understand the infra team SLA – It’s important to realise that you are a customer of the infra teams. Ask them for a Service Catalogue document for the service that they are providing. Understand the SLA that they’re operating to. Don’t be out-of-order, but if you find they’re not giving you good service then don’t be scared to wave the SLA.
  • Ask for a report of successful backups – Just as important as monitoring
  • Ask for the ICMP ping stats – How many packets get lost in communications with your Tableau server? How many times does it drop off the network?
  • Be nice – The infra teams in big orgs have a tough job. They’ll have no money and little resource. Cut them some slack and don’t be a prat if they let you down occasionally. It happens.

Start with that lot. Your users will also love it if you can make this information available to them. Again, it inspires confidence that you know what you’re doing.

OK that’s it for infrastructure monitoring. Next up I’ll dive into how you monitor your Tableau Server application.

Cheers, Paul

 

Welcome to the new bloggers!

Hi

Short post this. Just to say how ace it is to see new bloggers appearing on the scene since data14. There were a number of sessions in the schedule designed to encourage people to engage with the community in terms of blogging, twitter etc. And it’s great to see that even in the short time since the conference a number of new bloggers have emerged, as well as some established community members finally starting to record their thoughts.

So keep an eye on these guys. I’m sure their blogs will become must-reads. Apologies if I’ve missed anyone.

Bloggers

 

I’m sure there will be more. Keep an eye out.

Cheers, Paul

Thoughts from Tableau Conference 2014

Howdy y’all,

I’m writing this onboard BA48 from Seattle to London after attending my first international Tableau Conference. My mind is still buzzing after such a great week, packed with emotion, knowledge, pride, fear and more.

I’m going to try and make sense of the week by attempting to document my key thoughts and takeaways. Maybe some of them will apply to others, I’m not sure.

Thought #1 – “This must have cost a fortune!”

Right from the off it was apparent that Tableau have chucked a whole load of cash at this event. The conference venue was huge, brilliantly decked out in Tableau colours. Helpful signs were everywhere, as well as tons of eager Tableau employees all dedicated to making sure you got to where you wanted to go. There were refreshments whenever you needed them, tech stations, games and all the requirements you needed to work, rest or play. The keynote arena was phenomenal and created an electric atmosphere.

I loved the keynotes. Brilliantly relevant subject areas, from passionate and engaging speakers. Particular highlights were John Medina & Neil deGrasse Tyson. I imagine that caliber of speaker doesn’t come cheap though!

A fantastic effort and one that really made me feel that this event was critical to the company.

Thought #2 – “What a lot of nice helpful people”

So many Tableau guys and girls around to help us navigate or fix any issues. We were guided into the arenas and shown exactly where we needed to go – it required no effort and no scrutinizing of maps and guides.

I also found great help when setting up for my speaking sessions. Expert tech-checks, and attentive audio-visual assistance got pretty much any problem resolved is super-quick time allowing me to concentrate on my talks.

There was also great help from my assigned Tableau partners for my speaker sessions and other interactions. Big thanks in particular to Morgan and Jewel for helping me out.

Thought #3 – “This App was a good idea”

Messages, updating schedules, announcements and much more, the data14 app was a key companion for the whole week. Also very useful for the organisers as well I imagine, with the favourites function allowing them to gauge potential interest in talks and allocate rooms accordingly. Don’t get me started on that gameon thing though.

Thought #4 – “I wouldn’t mind living in Seattle”

What a nice city. I flew in a couple of days before the conference so had a good look around, including a great tour of the area in a seaplane (flown by @cheeky_chappie(!). Some stunning scenery and a great chilled out vibe. And that’s not even mentioning the greatest music scene ever (I’m a bit of a grunge kid at heart). We also went off to the ball game which was cool.

Thought #5 – “Wow! It’s so great to meet you at last”

I20140911_090609 lost count of how many times I said that. The opportunity to meet and thank members of the Tableau community was my top takeaway from data14. I must have met several dozen people that I’d been regularly interacting with over the last year. I’d be here all day if I mentioned everyone but meeting Ramon Martinez (@hlthanalysis), Mark Jackson (@ugamarkj), Emily Kund (@emily1852) and Kelly Martin (@vizcandykelly), and being able to thank them personally made me feel incredibly happy.

Thought #6 – “I don’t know much about data viz”

Despite learning an absolute TON of new skills at the conference I still left feeling that I’m faced with a mountain to climb. So many insightful, passionate, and clever people. I met many of the Zen Masters also, and was very humbled by their skills and also by their willingness to pass the skills on. In fact my first lunch break featured an impromptu masterclass in data densification from Jonathan Drummey. Superb.

Thought #7 – “I know quite a lot about data viz”

Yes that does contrast with the previous thought doesn’t it. How come? Well if I think about it then several hundred people came to see me speak across my 2 sessions. Lots of people stopped me and asked questions about my blog articles and other presentations etc. In fact I couldn’t go anywhere without being stopped and engaged in some great data conversation.

Then on the final day, a data fan stopped me and told me that my work, blogging and community interactions have helped him to get out of bed every day and do a better job. That was fabulous to hear. If a little surreal.

So I left thinking yes I do have tons to learn and take in, but I’ve also got my own skills that people want to hear about.

Thought #8 – “Everyone should try and get up on stage”

BxMOf9QCEAAzYetI used to be scared about presenting. Not with the Tableau Conference. The community is so strong that it’s like presenting to a group of friends. I was lucky enough to be able to present 2 sessions and both were a great thrill, despite a couple of technical hitches!

So if you think you’ve got a Tableau story to tell then try and get involved. Tableau open the speaker applications early in the year so look out for it. You’ll love it.

Thought #9 – “This whole thing isn’t the norm”

Code. That’s all Tableau is. Computer code. So why has it changed my entire working life in less than 3 years? I think I know the answer. You see in order to achieve this perfect storm an organization needs to nail each of the 3 pillars

  • Application – the tool has to rock. It needs to be easy to use and needs to be able to make your job easier, not harder.
  • Company – The company needs to be solid. Progressive, innovative and approachable
  • Community – You need a great set of users, with a true sense of collaboration and friendship.

In my career I’ve seen many tools, companies and communities. Most organisations nail 1 out of the 3, occasionally you’ll get a really good one that hits 2/3 – but in 15 years of IT, Tableau is the only one I’ve seen that nails each of these pillars and then some.

It sounds almost cheesy to say it but this isn’t the norm. If you’re a 20-something graduate in your first job using Tableau and you think that all tools and organisations are like this then you’d better wake right up now. This is NOT the normal experience. I’m just grateful I found it at all, mid-way through my career. If you’re lucky enough to have discovered Tableau in your youth then WELL DONE! Enjoy it! You’ve hit the jackpot!

So those are my thoughts on data14. I’ve been to dozens of conferences. None have been like this. Many companies don’t sign off on conference attendance as they are often seen as a waste of time. And many are. But Tableau events are better training than any classroom course and I’d say invaluable to anyone that wants to make a career in this fantastic field.

See you in Las Vegas 2015!

Paul

Building a Tableau Centre of Excellence – Additional Resources

Hi

If you’re reading this then the chances are you attended my talk at Tableau Conference 2014. I hope you enjoyed what I had to say. I certainly enjoyed delivering it. As mentioned in the presentation, this blog post lists all the resources referred to in the talk.

Link to Presentation – on Prezi

Screen Shot 2014-09-13 at 01.08.07

 

In order of reference

Grab me anytime @paulbanoub if you’d like a chat about anything.

Cheers, Paul