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


Tableau as an IT Service – Part 4 – Operational Considerations

Hi all and welcome to Part 4 of the seemingly never-ending story called Tableau as an IT Service. Lot of good chat and engagement on this from the community, thanks in particular to Paul Chapman (@cheeky_chappie), Matt Francis (@matt_francis), Kelly Martin (@vizcandykelly), Robin Kennedy (@odbin) and Francois Ajenstat (@ajenstat) for their interest and support.

Must admit I didn’t realize I’d be writing this much on the subject when I first thought of the idea but a number of people have asked for my opinions on a few extra areas so I’m trying to cover them wherever possible. It’s certainly a big subject and one that if done incorrectly can lead to even great tools like Tableau being seen negatively by your user community. So it’s important to get it right.

So far in this series I’ve covered the following aspects

  • Project Initiation
  • Infrastructure Setup
  • Tableau Server Configuration

Those are all well and good but a robust IT service will also have its operational ducks in a row, and that’s the subject of…

Tableau as an IT Service – Part 4 – Operational Considerations

What I mean by “operational” is how your service is performing when you’ve given the green light to your users and people are now actively using it. There are a number of subjects to consider in this space, some of which can make or break an IT service, irrespective of the application involved.

Application Registration

I didn’t really know what to call this category. What I mean is that every new service will need to be registered in a number of other IT systems for it to be fully integrated into your organisation. For example.

  • Payment & purchasing systems – So that accounts and procurement teams can find the vendor details in their directory and ensure payments get through to the right department.
  • Application directories – So that you can accurately track change to your environment and your application is correctly reported on to the business. It will probably be given an “application code” or something cryptic.
  • Business Continuity systems – Required by BCP and control teams to ensure you tick the box for having appropriate control and disaster recovery functions and that your systems are involved in any testing events.
  • Information Security systems – Similar to the above but with regards to InfoSec checks and records.
  • Architecture & application strategy – Make sure that the appropriate architects and strategy departments are bought into Tableau as a strategic tool for the organisation. If they don’t know about it you might find them recommending another tool instead and then you’ve got a fight on.
  • Appropriate contact lists – Make sure your service is listed in any emergency procedures and contact directories. If something fails and users are impacted then they need to know who to call.

This all ensures that when you enter “Tableau” to one or more systems to perform task X, then you get the appropriate details rather than “Unknown application”. Some of these systems may be global or have regional variations.


This subject has provoked a number of questions to my Twitter account. In truth we began our Tableau service without a chargeback model. This decision was primarily due to the small-scale of our initial offering in terms of user licences and also due to the desire to make user adoption as hurdle-free as possible.

Now that our user count is growing and the server usage also increasing, we are looking to implement a recharge model. Chargeback is commonly used by IT departments as a way of charging business units for their utilization of IT systems.

There are a number of advantages for IT departments.

  • Cost visibility – With a solid chargeback model a service owner can easily report the usage of a system or service back to senior management, with an associated cost value. This can be used to better understand the overall cost picture of IT in an organisation.
  • User control – If users have to pay for their level of usage of a system then they are much more likely to use the system responsibly and only use what they actually need. That way service resources are more efficiently utilised. This can also be problematic if the chargeback model is flawed (see disadvantages below).
  • Service perception – A service with a clear chargeback model is more likely to be adopted as a longer term IT strategy by senior management. Being able to demonstrate financial transparency and clear understanding of how much a service costs to run, and how that cost will change with service expansion is manna for senior management and budget controllers.

And some disadvantages

  • Reporting & admin – Every model will force users or service owners to regularly and accurately report their usage to management. This can take a while and can rapidly become onerous.
  • Abuse – Chargeback undoubtedly forces users to change their behaviour. But get the model wrong and you can suffer. I’ve seen cases where job scheduling tools are charged per job, rather than per server or user and that has led to user teams consolidating huge batches of jobs down to a small number of commands, executed by one job group that forks off hundreds of other commands. Saves money, yes – but extremely bad IT practice and ultimately bad for the system health. But if their goal is to save money you can understand how that can happen.
  • Shared components – How to charge back on components that are shared between multiple teams or applications? Can get tricky. Usually a balance is implemented to reduce admin overhead but this can mean one team paying more or less than they should.
  • Adoption – Users are more likely to give your service a try if it is free. Simple. And if your chargeback model is flawed then that could mean your service doesn’t fly at all.
  • Power users – With any service you’ll get your power users. The ones that push you for the upgrades and test the functionality to the limit. If they’re making you spend more on the service for functionality that other teams don’t require then there’s sometimes a case for applying a tiered model to charge them more. You want it? Then you have to pay for it. It’s usually a good idea to keep power users happy as they’ll sell your service for you and help to realise the business benefit.

As stated, we don’t actually have a chargeback model for Tableau yet. It’s currently under discussion.  My initial thoughts are to charge according to either disk space used on the system or by user accounts. I’d be interested to hear how the community is doing this. Let me know what’s been working (or not) for you.

For other services that we look after we tend to charge back on the number of user accounts on the system associated with a particular business unit. Or a flat charge per server using the service. This was done with ease of admin in mind and I think it could do with a review as some teams are paying more than they should and others are getting a bit of a free ride.


So how do you get smoothly and seamlessly from “Hi Paul – I really want some of that Tableau action” to “Cheers Paul – I love it, thank you for bringing Tableau into my life”?

Here’s what you need to consider in your onboarding process.

  • Speed – It needs to be fast fast fast. I work in an area characterized by agility and short time to market for pretty much everything and my users don’t react well to delays. Anything over a couple of weeks and you’ll risk frustrating your users.
  • Clarity – You’ll need proper documentation and ideally a flow chart of the process. Any costs, especially recurring maintenance costs need to be fully understood. If your systems can provide a link or report for the user of where the request process is at any one time then even better.
  • Ease – Ideally it will be one request via ticket or email to the initiating team. Users hate having to revisit a process and often forget to do so, meaning that the whole request process gets held up. There’s nothing worse than users having to fill out some obscure or unnecessary web form with loads of mandatory fields.

Our process goes like this

  • Initial request – Our users start with an initial email to a helpdesk team who then raise a ticket to track the request. Our documentation states that the email must include approval for the desktop licence cost from their manager. This can be a problem in most onboarding processes as chasing a manager to approve a spend can be a real pain.That’s why we leave that up to the user so that the helpdesk team don’t waste their time tracking down the approval.
  • Ordering – Once the helpdesk get the approved request then they place an order in our ordering system. We use a tool provided by Ariba. That goes off to Tableau and payment gets made using the transit or billing code provided in the request, and the helpdesk get a licence key which is passed on to the user.
  • Install – Helpdesk then send a request to the desktop installation team, who deploy our packaged version of Tableau Desktop to the user workstation.
  • Server – If the user requires a server licence then the helpdesk pass the ticket onto my team, and we add their account to server.

That whole process usually takes about a week, which is generally fine for all but the most demanding of users. Crucially it is only one email that the user has to submit to helpdesk so it’s admin-lite from the client perspective. They love that.

So why is onboarding so important? One of our other enterprise services hasn’t been set up so well and has a particularly poor onboarding process which can take several months. This means that by the time the user gets access to the system they are already pissed off with the whole thing and this means they have a very low tolerance for any issues or problems with the service. Because we get users onto Tableau quickly and smoothly they are happy and keen to get stuck in from the start – and if they do get any issues it means they’ll cut you some slack rather than escalating to your boss.


Most enterprises will have a central mechanism for deploying software. Typically there will be one for the UNIX server environment (Opsware), one for the Windows server environment (SCCM) and one for the Desktop environment, although SCCM covers both servers and desktop in our case. There are a few steps involved in getting a version of Tableau Desktop (or other application) to the point where the deployment team can hit the button.

  • Packaging – Firstly I’ll download the new version from the Tableau website and then send it to the Packaging team. They’ll form it into an msi package and place it on a repository for me to access for testing.
  • Testing – I’ll then have to test the package. Typically I’ll do this on my own desktop or one of our shared machines. Always a good idea to document this process as you’ll be officially signing off that it works so you may need to evidence that.
  • Staging – Once the testing has been signed off as successful the packaging team will stage the package on one of their “deployment points”. That could be anywhere, the location isn’t important although if your organisation has issues with technology consistency (see part 2 of this series) then you might find a platform team in one region doesn’t have access to deployment points in another region.
  • Deployment – The deployment team should be able to use their admin console to easily and automatically deploy the software to the machine(s) of your choice. The requester will get a report back as to the success / failure of each attempt.

Unfortunately even with a packaging process Tableau is a little harder than most applications to distribute due to the frequency of updates. See the “Upgrades” section below for more detail.


Tableau actually make this quite difficult for an enterprise scale environment. As you know they have an active release cycle of approx 1 month per minor release. Now that’s ace for the average user, who can go and grab the latest desktop whenever they want. But not so good for the service owner. As stated earlier we like to package up any application and make it available through the official enterprise distribution channels so that admin teams can control distribution and upgrades. Unfortunately such an aggressive release cycle means that we just don’t have the time to package each release and make it available for deployment as the process can take weeks. So we tend to re-package our desktop version once a quarter, or if the update has a critical bug fix etc. It’s probably ok if your organisation has an agile packaging method / team but in my place we just didn’t have the resource to keep up with Tableau’s release cycle.

Unfortunately there is also nothing stopping users from upgrading their own desktop application without the knowledge of the service owner. I’ve been contacted by users asking why they are suddenly unable to publish to server, and the answer is because they have upgraded their desktop to server version +1. Luckily Tableau desktop installations can co-exist happily so long as you’re aware what version you’re saving a workbook with. The same challenges exist with Tableau Server upgrades, although these can be even more time-consuming to implement.

All this means we tend to hold back on upgrades unless there’s an important bug fix or significant functionality jump.

Support of the Service

Obviously your service will be supported. But that support model can vary in a number of ways, not least dependent on the amount of resources that your organisation is able to throw at it. The chances are that whatever team supports your Tableau service will also have to support other applications as well. There are a number of key considerations in this area.

  • Service Tier – First off, what tier of service are you offering? If it’s a lower tier say 3, then support will most likely be during business hours only, with no on-call service to fix issues in the middle of the night or weekends. Anything higher and you’ll have that in place. If the business is demanding the service be a higher tier then they’ll have to provide you the resources to deliver that service. There are occasions where that doesn’t happen and it’s a recipe for disaster.
  • Team setup – In your support team you’ll obviously need one Tableau subject matter expert (SME). If you have more people then one of the first things to do is make sure that knowledge gets transferred. The others don’t need to be experts but they do need to be able to address issues and keep the system going when the SME is absent. This all sounds obvious but I’ve seen many a team that is left floundering with a huge skills gap when someone leaves or is off sick.
  • Documentation – There’s no excuse for not having this in place. Key admin tasks and  a list of the common issues and remediation steps should be easily accessible on a sharepoint or confluence page. You’ll be amazed how even an expert’s mind can go blank when faced with an incident. Your docs should also be detail the environment and the appropriate governance. If you’ve done the right things in terms of project initiation (part 1 of this series) then you’ll be ok here.
  • Alert Processing – When your monitoring system generates an alert how does that alert reach a support person? It could ping an email to a support Blackberry carried by the on-call technician, or it could go to a central Network Operations Center (NOC) who would view the alert on a console such as Netcool Omnibus or HP Openview. They would then call out the appropriate technical resource or conduct some initial remediation actions, thus potentially avoiding the need to wake you up. If you are using a NOC then you’d better ensure your alerts are correctly raised, free of junk alerts,  as that team will be calling you up if they get one, regardless of how minor it may seem.
  • Support Flow – Just like the onboarding flow, you’ll get some kudos from your users if you can give them a flow chart that documents exactly what happens from the moment an issue is detected to the resolution.
  • Budget – Make sure you’re aware of any ongoing costs to your service and think well ahead. If you think you’re going to need some more resources either in terms of tech or people then GET IT IN YOUR BUDGET PLAN as soon as you can. Most budget cycles operate over a year in advance and managers hate any unplanned costs appearing when all the numbers have been signed off. Even if you might not need the spend then it’s best to plan for it as it can always be removed.

Luck plays a part in the success of your service support. Some applications are more prone to issues than others, some take more maintenance and some are just plain flaky. Luckily Tableau doesn’t seem to suffer from any of those problems, giving your team a chance to concentrate on helping the users make the best of their experience.

Server Performance

Tableau make a number of recommendations in their documentation on how to improve performance if you have an issue. That’s fine, but you want to be addressing performance before you have an issue. That’s the job of your application monitoring tool (more details in part 2 of this series).

In my experience I’ve seen poor dashboard design and inefficient queries to be more of a problem than actual issues on the server side.

While you’ll get an idea of CPU and RAM usage trends I don’t see any way that Tableau can proactively alert if extracts are taking longer than expected or if queries are running slower than usual. Ping me if you know of a way. I’d like to be able to specify the expected time of a query or extract refresh or ideally have the system work that out based on historical information and alert me if a query or extract has breached the usual threshold.

Capacity Management

This is another tricky subject and one that we haven’t mastered yet in my service. From what I can see there’s little to stop users uploading massive extracts to your system and filling up the disk unless you have a checkpoint in your service model where publication of user workbooks has to go through a central team for approval and analysis in terms of best practices. My team doesn’t have the resource for that kind of setup, you may be more fortunate.

Any monitoring system deployed on the Tableau server (see part 2) would be able to detect when the disk space thresholds are breached on a machine. That may give support teams enough time to prevent the disk filling up.

Interested to hear the opinion of the community on how best to manage resource capacity for Tableau server. I think the best way is probably to make it a procedural checkpoint as described above. That obviously takes resources.

In terms of the infrastructure, your platform and storage teams should have capacity management tools and strategies for ensuring the availability of their infrastructure as the environment grows. It’s not easy to proactively keep on top of capacity as there are so many factors involved, but if your infrastructure teams have solid Key Performance Indicators (KPIs) then they may even be able to use Tableau to visualise the trends and head off any issues well before they happen. That’s what we do at my place.

Incident Management

So what happens when it all goes wrong? You’re gonna get incidents and outages so expect it. And the chances are your users will also understand that systems do break occasionally. What the service owner needs to demonstrate is that they have a good grasp of the impact of the issue and that the resolution steps are clear and pursued as efficiently as possible. You’ll also need to make sure that any follow on actions are performed to avoid a repeat of the same issue. Repeat problems don’t go down well.

Most enterprises will have a dedicated team to handle incident management although depending on the severity of the problem they may not be involved in your issue. So it’s likely there may be a chance that you are managing the incident. Here are some things you’ll need to consider.

  • Logging – Make sure the first thing you do is log a ticket in your incident management system and ensure your manager is aware. This ticket should clearly indicate the issue, impact, steps taken so far.The ticket system *should* send a message to your users but you may need to ping them a note anyway.
  • Incident manager – Ensure someone is in charge of the incident and managing it.
  • Fix the issue – Get the appropriate technical teams on a call and get to the root of the problem. The first priority is to get the system up and running again. If you need to log a ticket with the vendor then do that immediately, sometimes it can take an hour or so for them to get back to you depending on your level of support cover.
  • Close out – Once you’re back in the game get the communications out to your users and management.
  • Follow on – If it’s a serious incident then you may have a “Post Incident Review” with key managers in the following days. This will typically detail the timeline of the incident, root cause and any follow-up actions that are required such as patching etc.

You’re going to get issues so don’t kid yourself that you won’t. Even though outages aren’t great, a service owner can often emerge with a lot of kudos for efficiently managing an incident through to resolution.

Change Management

You have to get this right. Most IT incidents occur as a result of poor change management processes or failure to adhere to such controls. Most enterprises will class failing to follow change process as a disciplinary offence, and I’ve seen it cost people their jobs so whatever you do don’t take any shortcuts, it’s just not worth it.

Your incident management team will probably look after change management across the firm or your business unit so it will be a case of adhering to their guidelines.  Again the approach will depend on the tier of your service, but you’ll probably be scheduling major changes for weekends to minimise the risk if something goes wrong.

One of the key considerations is communication. It’s a good idea to place your power users on the approval chain of the change so they need to sign off that they’re ok with it. If you’ve got a change coming up then make your users aware as early as possible, then send a reminder a week or so from the change date and the day before. Also send them the results of the change (even if it failed) so they’re totally up to speed. This will also inspire confidence in your service.

Change management can be a real pain due to the process and paperwork involved. But it’s a critical aspect of maintaining a solid IT service, perhaps the single most critical item.

Vendor Relations

Keep in touch with your account manager. It’s actually their responsibility to keep the relationship going and a good account manager will be reaching out to you regularly. Don’t be scared to put the pressure on if there are any issues or you feel that you’re not getting the right level of service. It’s their job to keep you sweet. I’ve had good experience with Sarah Bedwell (nee Henselman) in the London office who has been great. Good luck for your move back to the USA Sarah!

Other services in my organisation have really suffered from poor vendor relationships so it really is a critical part of maintaining your robust service.

Managing Perception

So you love your service and you want to get as many people using it as you can. That’s obvious. But it’s not as simple as speaking to people and doing demos. You need to manage the perception of your service and crucially see your engagements through to completion.

Let me give you an example. When I was in full Tableau evangelist mode I was trying to onboard loads of people. So I set a demo up with a particular team and it went really well. They loved it and before I knew it I had requests for individual sessions and help to get started. Unfortunately I did all this at a time when I was mega busy with other work and as a result I wasn’t able to give them as much time as I would have normally. This resulted in the initial enthusiasm dying off and I subsequently found out their manager was giving negative feedback upwards about the whole Tableau service as they felt they had been neglected after being promised so much. That was my fault for choosing the wrong time to approach them. I should have waited until I had the bandwidth to see it through for them. Obviously when I got wind of that perception I managed to circle back to the team and finish the job I started but the damage was done.


Make sure your team is up to date on vendor training, ideally get some of the official certifications that Tableau offer. Not only does this help in terms of technical expertise but crucially it gives confidence to your users that they can rely on your team for true support and engineering (unless the service has a separate engineering team). I’ve seen some cases where a support team doesn’t keep their skills up and before long the users know more about the application than the so called experts. That’s pretty embarrassing.


I’m referring to your internal community of Tableau users here. Here are some tips to help spark that sense of community in your organisation

  • Power users – Identify your key users quickly and build a personal relationship.
  • Lunch & Learn – Have regular get togethers, share how you’re using the tool and any issues.
  • External events – Attend as many roadshows as you can. Bring your power users along.
  • Demos – Tableau are more than happy to come in and do demos. That’s really good way to boost engagement and make the users feel like they are dealing with a vendor that actually cares.
  • Social page – If you’ve got an internal Facebook-style site then spin up a community page. Post your issues, changes, events and news on it regularly. Encourage everyone to contribute.
  • Gamification – Do something cool and fun like Andy Kriebel’s “Viz Cup” at Facebook. a fantastic off the wall idea that I’m sure will be repeated. The subject of gamification is one that’s getting a lot of chat at the moment.
  • Merch – Get some freebies from the vendor. I dish out Tableau badges to my users for a laugh. They seem to like it.
  • Evangelise – If you love Tableau, talk about Tableau. It’s not like Fight Club. I don’t shut up about it. Coffee points, meetings, lunch. I’ve had people give it a go just to get me to be quiet. Then they are hooked. Mwuhhahaha! Make sure you’re able to see your promises through though.

Ok that’s it. If you’ve considered everything in this series of posts then I can pretty much guarantee you’ve got a solid foundation for your enterprise service. There are many different variations of these processes depending on your organisation and there’s really no one right way of doing it. For (a lot) more detail on how to run an IT service check out the Information Technology Infrastructure Library (ITIL) methodology. This framework underpins almost all of what I’ve spoken about in this series.

Happy to expand on any of this. Grab me on @paulbanoub anytime. Thanks also to the fabulous Tableau community for the encouragement I’ve had while compiling this guide.

Cheers, Paul

Tableau as an IT service – Part 3 – Tableau Server Configuration

Go back to Part 1 of this series

Hello all. Thanks for coming back. I’m actually enjoying writing this series of posts. Some crazy hit rates for the first two parts that’s for sure. Most of them probably from my mother but I suppose they all count. Thanks in particular to the people from Tableau that got in touch regarding this series as well as associated Zen Masters across the globe.

Anyway here’s part 3 – Our Tableau Server Configuration

This part focuses on how we set up our Tableau Server application to run on the infrastructure described in Part 2. There may be some overlap and there may be some things I miss – I’m happy to discuss individually. Note there was some evolution of this environment from the initial design and build to what we have today. I’m going to describe the end state rather than the baby steps to get there. Note our service is still fairly immature and a little way off what I would consider a full-spec enterprise deployment but you’ll get the general idea. Tableau Server configuration is a relatively simple affair in comparison to most other enterprise applications I’ve used.

Hardware Specifications

  • Main Server – 4 core CPU, 8GB RAM, 250GB disk space
  • Worker Server, 4 core CPU, 16GB RAM, 250GB disk space

Both servers would share the processing load, in particular the VizQL and dataserver processing. They would both be allocated a significant amount of RAM for snappy rendering and have a large amount of disk space for extract storage. We’ve found this performance to be adequate rather than fast, although that may be due to the fact that the users are hitting the server from a number of geographical locations. Tableau make a number of recommendations to improve server and desktop performance. They also have a really detailed whitepaper on scalability. This sort of professional looking doc is loved by management, even though they’ll never read it.

I must say that this kind of document is a real bonus for users trying to get a service signed off. Scalability is the sort of subject that will be grilled by senior bosses and I’ve been in situations where vendors haven’t provided any guidelines meaning I’ve had to conduct my own scalability tests to satisfy the check point. Having an official whitepaper from Tableau shuts down that question immediately. Great stuff. In my experience the server specifications seem to be less of a factor than poor dashboard design and inefficient calculated field queries. We’ve also seen some dramatic improvements in speed from basic database maintenance such as applying an index to key tables. Tableau have some decent docs on this subject. Obviously this is easier if you’ve got control of the datasource but sometimes you’ll be connecting to an ancient DB thousands of miles away, used by hundreds of users with vague ownership at best so it’s a tricky and risky process to go messing with the configuration.


Think I mentioned this in part 2 of this post so I won’t go into this here. It’s pretty key to being able to manage your service as it scales. Don’t even think about local accounts, integrate with Active Directory from the off.


The level of resilience depends on a few factors, in particular the budget you have available and also the level of service tier you class your service as. Obviously a Tier 1 service would have a resilient backup server, with the application able to failover seamlessly and quickly, ideally with no interruption to the service for the end user. In the case of our initial Tableau Server deployment we did not configure a failover server as the service was classed as a Tier 3 service. That meant if we had an outage to the application management had accepted (and signed off) that Tableau would be out of action until it was resolved. We made this clear to users as they were onboarded (more about that in part 4) in order to head off any complaints. As our service evolved and grew the usage of Tableau became global and critical to the operations of some business units. Because of this we upped the service tier to Tier 2 and implemented a failover server to allow the service to continue if we had an issue. We didn’t sign up to any SLA agreements as often happens when a new service is commissioned so there was no pressure to provide a four or five nines level of availability, something that is often required by the business. Tableau provides decent docs on configuring your environment for failover and we found it a pretty easy setup process.


We’ve got big local disks in our Tableau server machines, easily expandable due to the fact we are on the Virtual Machine environment. The key take away from this is that you can’t really predict the disk space requirements of Tableau. You might be fine for ages and then have one user upload a monster extract that fills the entire disk. We tried to hammer this home to the users in terms of best practice and education during the onboarding stage. More about onboarding in part 4 of this series.

Geographical Location

We ran both servers in the same locale. This was down to ease of setup and a necessity to get the project completed (and the service live) as quickly as possible. On reflection we should have considered the location of our potential user base and the fact that adoption of the application was likely to be fast and viral. We certainly underestimated the impact and popularity that Tableau would have. Configuring a system globally has a number of specific challenges.

  • Time – It’s usually easy to get something delivered in your immediate locale. You know the people, you know the process and you can easily wander over to someone’s desk and encourage them to work on your request ahead of other work. If there are any problems then it’s easy to escalate and if someone doesn’t understand your requirements it’s easy to have that face to face discussion to clarify. That’s not always the case when you’re trying to get something installed in a datacenter thousands of miles away from where you are. Processes invariably take longer, and it’s harder to expedite with the personal touch when it’s often someone you’ve never spoken to before that picks up your ticket.
  • Consistency of process – One of my pet hates this. In my organisation I have deployed several global services over the last 4 years. Recently I deployed an enterprise monitoring tool across multiple business areas. We had infrastructure and application masters installed in New York, London, Toronto, Hong Kong, Sydney & Tokyo. Typical tasks involved in the setup were commissioning of the servers, setup of user accounts, filesystem configuration and then installation of the application. Each of those tasks involves a different request process to be carried out by different teams. That’s fine, just needs a bit of organisation on my part. However, the ludicrous fact that each of those processes also varied per region added even more red tape to the process. Unbelievably irritating to the end user to see such a failure to globalize common tasks.

IT management often speak about wanting to “appear like McDonalds” to the end user. You know, you order a Big Mac (Server) in Tokyo and it’s the same process and product as in London or anywhere else. That’s what they always talk about and in reality it’s the absolute polar opposite experience for the user. We completed the monitoring project in 8 months. I think we could have halved that if the setup process has been globally consistent, it really was that much of a handicap.

  • Consistency of technology – This is kind of related to the point above. In my case the standard Windows or Linux VM offerings that you can choose from vary significantly in each region. Same for the available databases (Oracle in New York, Sybase in London), and same for hardware model and numerous other components of the technology stack. Again, adds to delay, inconsistency and user frustration. 
  • Support – Again similar to the two posts above. Some support teams are merged (e.g. Server teams supporting both Windows and Linux with the same process) or they could be completely separate in another region. Some regions might offer 24×7 support, some might not. The monitoring of the infrastructure might also be different (varying disk space thresholds and partitions) and the alerts generated might be handled in contrasting ways. It’s a real throw of the dice in terms of the user experience.

As you can tell the subject of globalisation is one that is a key frustration of mine. In terms of technology and process it’s not that hard to do – but tends to always fall down due to politics, agendas and red tape. It’s disappointing that the ones that suffer are the users and the support teams.

Run As User

networkserviceThis is important. By default Tableau installs and runs as “NTAUTHORITY\NetworkService“. The application will run fine as this user, but we found that the server was not able to access some data sources. In particular we were unable to access UNC paths to Windows Sharepoint environments to monitor Excel spreadsheets. This is a commonly used data source in IT and it was critical that Tableau was able to point to them. In order to allow that we modified the application configuration to run as a domain user, in our case DOMAIN\tableau. That meant Tableau could see the data sources via UNC paths provided the sharepoint was permissioned to allow DOMAIN\tableau to have read access. Tableau make this recommendation in their documentation.

Alerts and Subscriptions

We set up Tableau 8 to send email alerts to our support team (me initially) in the event of a server health issue or extract refresh failure. This setting is useful but needs some refining as it doesn’t seem possible to be able to send emails to different audiences depending on the workbook. I’m not keen on getting woken up for a poorly configured extract failure for one of the user workbooks. Maybe that will come in a future release. For now we just absorbed that headache.

Data Connections

Tableau Server offers a neat feature to control the level of server caching that occurs. I can imagine this being an important tuning point in large deployments. For my case we simply selected “Balanced” and cache for no longer than 1 minute. We’d keep an eye on performance and revisit that setting if required.

DNS Alias

See Part 2 for recommendations on this.

History Tables

Our server was V7 so I didn’t get a chance to try this out initially but will get around to it in the next few weeks. I don’t really need to say too much as the brilliant Russell Christopher has covered it all perfectly. Thanks loads @russch – If you’re not following his blog then you’re missing out. I’m envisioning using history tables and other queries into the Tableau postgres database to produce a live dashboard of the heath of the system. User logons and usage patterns, extract refreshes, hot queries and other metrics all up there for managers and support teams to see. Perfect. Looking forward to having a blast at it.

In Hindsight

Some things that we either didn’t consider or chose not to implement..

  • Load balancer – Our initial service offering didn’t really need this but it’s something I’d certainly consider in the future as the service grows. Some details from the vendor here.


A few things that I’d love to see in future versions of Tableau.

  • Version control – If I’m building an enterprise service I’ll always look for version control. The recent monitoring project I refer to used Subversion to automatically check in configuration files after each modification. It adds that extra level of safety and trackability to changes involving the user xml files. I’d like to see some form of in-built version control in Tableau for those (luckily very rare) occasions where user delete their workbooks not only from the server but also from their local disk.
  • Simpler permissioning of workbooks & projects – Maybe you’re all totally happy with this aspect of Tableau Server? I certainly don’t hear many complaints. Maybe it’s just me but I find permissioning awkward and difficult to keep a proper track of. I’ve ended up just leaving it to the users to permission as they see fit when they publish.
  • Alerting on extract refreshes – 8.1 is a lot better in this respect with the emailing feature but would be nice to see some form of integration with formal alert protocols such as SNMP. I’d also like the ability to configure variable alert destinations based on workbook ownership and other context. It might be a good idea for Tableau to not spend much time on trying to be an alerting tool and instead just dump everything to a log file (with guidance on what patterns to monitor) for integration with a more enterprise class monitoring application like Geneos.
  • Dedicated Sybase connector – I know you can connect to Sybase using the generic ODBC connector in V7 but it seems Sybase was being ignored a little when it comes to the portfolio of connectors. This is no longer an issue now support has been added in V8.

So that’s how we configured our Tableau Server. There’s no one right way to do this and part of the fun is responding to feedback on the service and evolving the offering. You’re not gonna get it right first time. As discussed in part 1 of this series I brought Tableau into the organisation as a small-scale side project and it expanded with popularity. If you’re lucky to have a signed cheque and a go from your managers to implement a service from the start then the approach may be different to mine but ultimately the same considerations apply. This is only part of the journey though, there’s a lot to consider in terms of the actual service you provide to the user base and that will be the subject of the next part in this series.

Next up is Part 4 – Key Operational Considerations

Tableau as an IT service – Part 2 – Infrastructure Design and Configuration

Hi fellow Tableau worshippers! Hope you’re all rocking the 8.1 action. Bummer that the free Starbucks thing was only applicable in the USA. Booo. Here at VizNinja we love a free coffee. We take it black, obviously.

Well I didn’t expect that level of response to my first post about how I recently brought Tableau Server into my organisation as an IT Service. Thanks to everyone that commented, followed and favourited – meant a lot. I literally couldn’t believe it when I started getting shout outs from Zen Masters. I’m even hearing that some senior product managers at Tableau have been sending this to potential customers. Totally, totally cool. Thanks again.

One thing to note. This is a BIG subject. I could write whole posts on each bullet point, so this is very much a summary. If you want more detail do ping me an email. I’m happy to meet anyone to discuss if you’re in London. Given the level of interest I think this might turn into a full on presentation. I’ll let any interested parties know if it does. My fee is some Jaffa Cakes.

Anyway this is part 2 – Infrastructure Design and Configuration

Usually you’ll have some form of design ready before the project gets full approval and you might even have had to submit an architecture diagram with the Project Charter document. In my case we didn’t have to do that as the project was low rigor, so we began the hardcore system design after approval.

The beauty of bringing an IT service in from scratch is that you can often have total control over the system design and configuration. Sounds good eh? Well it is and it isn’t. I’ve been involved in projects where we’ve brought in a system and set it up in good faith, only to have the user experience be one we’d rather forget. And the real pain is that going back to correct mistakes, especially in a complex, globally distributed system is sometimes almost impossible. It’s actually very upsetting to be flooded with user complaints in situations like that, as you’ll have worked hard and in good faith to do what you and the project team thought was right – but it hasn’t worked and unfortunately you’re the one that’s accountable.

In the case of Tableau server it was kind of my pet side project and didn’t have any real business pressure to implement so I had a bit more freedom. If it worked then great, if not I’d look a bit stupid but there wouldn’t be an almighty shitstorm. Contrast that with an application that is out of support or legacy, or needs to be upgraded quickly due to regulatory requirements, or is a significant spend – if that goes wrong then you’ll be involved in some conversations that might turn out to be fairly uncomfortable or even career limiting.

Operating System

OK so what OS to run this bad boy on? Pretty simple decision this one as Tableau Server is a Windows application. Unfortunately to the IT professional this is a pretty bad thing. I’d have taken a system that runs on a Red Hat Enterprise Linux OS all day long over Windows. Here are some of the issues that we typically get with services running on Windows and why I prefer Linux.

  • Patching – Windows tends to have a lot of security issues. Luckily Microsoft release regular patches and hotfixes. Unfortunately that means that those patches have to be applied, and then the server rebooted and that means the application running on the box is down. We do that every month for our Windows estate – and we’ve got over 1500 servers. It’s a colossal pain. We have to notify our users, get their OK, schedule the resource to do the work (usually at a weekend – annoying to the individual and costs the firm overtime charges), perform the work, check that all is well with the server and also deal with those occasions where the patch knackers the box. You still need to apply patches to Linux but this is much less often.
  • Stability – Windows just isn’t as stable as Linux. Simple as. Hung servers, slowdowns are commonplace. Windows is also more susceptible to out of memory issues caused by memory leaks. This is a situation where an application is badly coded and doesn’t manage memory usage correctly, gradually using up all the RAM on the server until it falls over. That happens on all OSs as it’s usually down to the application, but more so on Windows. Linux is also better at handling multiple running processes than Windows.
  • Security – This is pretty key for enterprises like investment banks running systems with trading and regulatory data. Linux was designed to be multi-user from the start, and only the root (super admin) user can make critical system changes. Then there’s the separation of user mode from kernel mode. This means that only certain trusted code can access the heart of the operating system – the kernel. User programs have to run in user mode and as a result are restricted from modifying key kernel settings. If the application needs to do this it must use a system call, a trusted instruction into the kernel. All this means user applications, programs and malicious scripts have a much lower chance of doing something nasty to your Linux system.
  • Total Cost of Ownership – Linux wins this hands down as the software is usually free. Commercial versions like RHEL will need a support agreement to be purchased, but you’ll still be quids in compared to Windows.
  • Configuration changes – Many Windows configuration changes need the system to be rebooted, much less so on Linux. It’s incredibly annoying to need to change a simple system parameter and then have to reboot. It means that you’d probably have to schedule the change for outside of business hours and get the application team to give their ok for you to take their service out. With Linux, you’re more likely to be able to make the change during the day (depending on risk) without impacting the application. That’s actually pretty important with Tableau as you just never know when someone is going to hit that report. Could be at any time, on iPad etc so you want that service to be available.
  • Troubleshooting – I’ve had plenty of experience debugging issues with applications on Linux and Windows systems. Both offer a variety of tools and commands to assist investigation but in terms of speed and ease Linux is a clear winner. Debugging using the Windows GUI interface is slow and difficult in comparison to using the command shell in Linux. A good Windows system administrator could probably disprove this but I’m much happier in a Linux environment.

There are tons of different Linux distributions out there. Some more suited to enterprise usage than others. You’ll need to ask a real Linux geek why, but I’ve had  positive experiences with Red Hat, SUSE & CentOS. Don’t bother running Linux as a desktop environment though and certainly not in an enterprise.

Doesn’t have to be Linux though, you could run on another UNIX platform like Solaris. This isn’t the trend though as many big enterprises are migrating from Solaris to Linux due to prohibitive licence costs amongst other factors.

Come on Tableau – let’s make sure version 9 of server runs on Linux eh?

Physical or Virtual Machine

This is a decision that you may not need to make depending on how your organisation works. At my place we have a well established Virtual Machine environment, hosting many tier 1 applications and systems. Over the last few years we’ve migrated much of our estate off physical servers.

Our VM environment looks something like this.


At the bottom is the actual hardware that provides the compute power. I think we run HP servers although I’m not sure of the model. The ESX server layer runs above that and is carved up into logical Virtual Machines which can be moved, split and reallocated dynamically. That’s pretty much it. Very simple and very effective.

So what are the key considerations here?

  • Cost – The primary driver for virtualising server estates is cost. VM environments benefit from lower costs in terms of hardware, datacenter occupancy, power consumption and maintenance. Operating system licences will be the same though as they’re charged on a per-server basis regardless of VM or not. Many organisations will undergo a project to move applications from physical to virtual servers. It’s not that difficult actually, as the VM technology today is fast, agile and stable so it’s a pretty safe move. New applications will always be steered down the VM route.

You’ll need to have a VERY good reason why you can’t use a VM for the platform teams to allow you to purchase and install a physical server and it will need to be approved by all sorts of senior managers.

  • Setup – Want a physical server? You’ll need to get the cost approved, submit your order and wait for it to be delivered. You’ll then need to get some datacenter space allocated and get someone to rack it. Then you’ll need to get the OS installed and configured before it’s ready for you to use. I’ve seen that process take 3 months and longer.

With a VM it’s a simple software operation using the VMWare admin tool or equivalent. The operating system install procedure can also easily be automated using tools like Opsware. Altogether a much faster process from making your request to getting your hands on the server.

  • Efficiency – Most dedicated servers run at a fraction of their capability. Some servers in our environment are barely used at all. That’s a lot of expensive, wasted compute cycles. In a VM environment the overall pool of resource (memory, CPU) is centrally managed as part of the ESX server and can be allocated to each VM as needed. Not perfect but much more efficient in terms of overall utilisation of available compute resources. VMs  mean less physical hardware, so that’s less power and cooling costs to deal with also.
  • Failure & Disaster Recovery – Most VM environments come with a form of management software that allows administrators to maximise uptime of a VM. Using these tools, an admin can effectively pause operations on a server, and resume at a later time or even move a VM instance from one ESX host to another, while the application remains uninterrupted. On VMWare that’s a feature called VMotion.

Our VM environment is spread across two datacenters with seamless failover. So if we lose the whole of site A then VMware automatically fails over and your service continues pretty much uninterrupted. That’s an awesome thing to demonstrate to management during a failover test as it means the application team don’t have to do anything when the site A is shut down. All in all it gives your system some serious resilience.

Another extremely useful feature is the ability to snapshot the state of a VM server. Worried about applying that upgrade in case you hose the system? Take a snapshot and you can snap back to the pre-upgrade state in seconds should you need to. Very handy. You can’t do that easily on a physical server.

  • Expansion – Big one this. Let’s say you’re having performance issues. Either the box is running out of memory or it’s running slow. With a physical server you’ll have to shut it down, take it out of the rack in the datacenter and open the thing up to add more RAM or other upgrade that you’ll need to purchase and wait to be delivered. That takes ages to plan and execute, and you’ll probably have to take your application down. With VM it’s a request to your friendly platform team and a couple of clicks later you’ll be ready with a more powerful machine. Your outage will be no more than a reboot. All they have to do is allocate a little more resource from the overall capacity of the ESX host. No brainer.

All this meant it was an easy decision. We’d run as part of our standard virtual environment.

Monitoring and Alerting

Monitoring of your system often gets overlooked as it’s not one of the more glamorous areas of IT infrastructure services. But get it wrong and you’re in a world of pain. The idea is that when you get a problem you’re notified and can get the message out to the users before they even notice they have an issue. There’s nothing worse than being called by your users to tell you that your system is down. It’s a sure-fire way to lose their confidence.

There are a ton of choices when it comes to monitoring tools. Chances are you’ll be using one of the systems that your own monitoring or system administration team will be providing as a service to you. So it will just be a case of utilising one of those tools to configure your monitoring. Monitoring effectively breaks down into these categories.

  • Infrastructure Monitoring – That’s the monitoring of the platform and operating system you’re using. Typically every server commissioned would come with pre-configured monitoring rules for disk space, CPU usage, memory usage, reboots, and ping (availability) monitoring. You might even get more complex checks for swap space, inodes, etc. The key message is that you shouldn’t have to worry about any of this. Infrastructure monitoring should be set up and managed by your server teams. If an alert is generated by these rules then it should be them that deal with it and fix the problem. However, the more advanced user will at least want some visibility of these alerts, either on some form of alerting console or email.

The problem arises when users start telling the platform teams that their monitoring should be modified or is inadequate. In my experience its best to trust the server teams as they are experts in their field and will know the OS inside out. Plus you’ll always need a good relationship with that team as it’s best to keep them onside as much as possible. If you really do want them to change their alerting thresholds then they’ll certainly do it, but chances are the alert will be waking you up instead of them. In my case we use Microsoft Operations Manager (MOM) to monitor Windows infrastructure. In my opinion that tool isn’t fit for purpose, there are much better tools available such as Geneos by ITRS.

  • Hardware Monitoring – The monitoring of the actual hardware used to run the OS. Again this is one you shouldn’t need to worry about but again you may want some visibility for added sanity. Metrics include system temperatures, power throughput, BIOS errors or other lower level system issues. Our platform team uses a system called IBM Director for this. I’ve not used it much, all I know is that my colleagues don’t like it at all.
  • Application Monitoring – The monitoring of your application. You certainly need to pay attention to this. It’s up to you to decide what you want to monitor and you may have to set the rules up yourself. So what to monitor? Well some vendors will help you with this and provide a guide of stuff they advise keeping an eye on. You don’t have to go with it, I prefer to make my own mind up so that’s what I did. Here’s are some of the main things you should consider when monitoring your application.
    1. Process Monitoring – Is your Windows service actually running? You’ll want an alert instantly if it stops running. It’s a simple up or down check. Gets a little harder to detect when a process is running but not actually responding. This should be the first monitoring rule you set up.
    2. Application Performance – What is that process actually doing? Worth setting up rules to monitor memory and CPU usage for the Tableau server process. This can be tricky to optimize though as CPU and memory usage can spike, triggering an alert when there’s no real issue. To get around that you can implement rules that look for a sustained threshold breach over a few minutes or several polling cycles. Some applications run quite hot in this respect so you’ll need to get a feel for how the application runs and might want to delay implementing this monitoring until you get a feeling for the application behaviour. You don’t want to get woken up to check a CPU alert and find it back to normal by the time you’ve logged on. 
    3. Log file monitoring – Tableau has excellent logging. Both on desktop and server. I’ve debugged countless performance issues by analysing logs. Using MOM we were able to scrape the logs and send an alert when a particular string occurs. I wasn’t able to find a list of strings that Tableau recommend monitoring for (is there one?), so I kind of free-styled it. When I get an issue that is exposed in the logs I’ll configure monitoring for that string. There are obvious messages such as “Error” or “Fatal” etc but these don’t always indicate a system failure or issue. It’s a case of building up a series of log file checks to cover all major eventualities. It’s also worth monitoring the Windows event log as  many applications post alarms there by default. You’ve also got to be careful with log monitoring as some applications go error crazy and if you’re not set up correctly you may end up with hundreds of alerts in a short space of time. 

While I’m on the subject do check out @interworks Tableau performance analyser. It’s an ace tool that parses your desktop log and allows you to visualise those dodgy queries slowing down your viz.


Luckily Tableau server has simple Active Directory integration. Was a very simple process to connect the server to our AD environment. Even better was the ability to add AD groups in the server configuration. I often needed to add accounts for dozens of people at a time and groups made the process a lot easier. You can use locally added accounts in server but I certainly wouldn’t recommend that in an enterprise setup.

Domain Name System (DNS)

Simple one – give your server a DNS alias. That way your users wont have to remember what the server name is, they can just go to and they’re in. Sounds simple but you’d be amazed by how many badly implemented systems require you to remember to type some crazy address like to access them.


You’ll need to ensure your server is getting backed up on an OS and application level. This should be taken care of by your platform team but it’s always worth asking them for some evidence that they’ve actually done this. Either a log of the setup request or a report of successful backups. I ask for a positive confirmation of backup every quarter. I’ve seen it many times where a system is lost and then the backup hasn’t even been set up or has been failing for months. It’s just not worth taking the chance.

Typically most enterprises will have a backup policy similar to this. We went for the 7 year retention for our Tableau Server data as some of the reports may contain sensitive information.

  • 7 years – Business related data (e.g. trading information)
  • 1 year – Non-Business data (e.g. application configuration or logs)
  • 1 month – Short term data (e.g. development or UAT environment)

It’s also worth checking that the backup includes your application partitions or drives. Sometimes the platform team just set up the OS related backups and the rest is down to you.

Database Environment

This isn’t a worry where Tableau Server is concerned as all the data is stored on the local file system as part of the application. For other enterprise services the database connectivity will be a key concern. I’m no DBA but here’s an example of the database choices available to users in a typical enterprise. I’ll keep this brief as it’s not relevant to Tableau.

  • Sybase – Fairly niche but a good balance between cost and functionality
  • MS SQL Server – Cheap but sometimes unreliable
  • Oracle – Functionality rich, enterprise grade database environment. Expensive.

You also may need to decide whether to host your database on a local dedicated server (need to consider replication and DR) or on a consolidated database environment.

The Other Big Option

There is of course another option here. And it’s an option that is getting increasingly more traction with enterprises. That option is to make all of the above someone else’s problem.

There are a good number of companies (Amazon, Google etc) that will happily provide you with somewhere to host your applications. It’s known as Platform as a Service (PaaS). We’ve spoken about it for a number of infrastructure services such as email, and there are some advantages but also some disadvantages. I may elaborate on this in a future blog post.

Right that’s it for part 2. If you’re enjoying it or finding it useful then do let me know.

Coming soon – Part 3 – Our Tableau Server Configuration

Cheers, Paul

Social Data Day @ Google

Hello Tablegions,

I’ve just spent a very enjoyable afternoon at the shiny and brightly coloured offices of Google in the City of London.

20131126_132946The event was part of Social Data Week (#sdday) and was billed as a discussion about social media, data analytics and such like with a product demo of Tableau from Andy Cotgreave (@acotgreave) as well as a couple of panel discussion sessions.

Here’s how the afternoon panned out.

The event was hosted by Rob Easton (@robeaston33), Head of Enterprise Cloud Platform at Google, and he opened up with a brief introduction before handing over to Tim Barker (@timbarker) of DataSift.

tbarkerI wasn’t aware of them prior to this session and Tim laid on an excellent introduction to their services and then a demo. DataSift suck in massive volumes of data from social platforms, filter out the crap and irrelevant content and then feed that to big enterprises who use tools like Tableau to perform their analytics. It was amazing to find out that a single tweet contains about 140 different data points that DataSift can report on. Sounds a really good tool. Tim was also super chatty in the breakout sessions and provided some great insight into their business.  “It’s not information overload, it’s filter failure”.

Next it was over to Rishi Kumar of Unilever (@Rishi_NK) to discuss how they’ve used data analytics tools and in particular Tableau to achieve their business objectives. It featured how Rishi’s work has allowed them to gain valuable insight into data on social platforms. Very interesting stuff. “Data trumps opinion” was one memorable quote.

Then a bit of a panel discussion where Rishi was joined by a couple more guys including Nathan Sage of PA Consulting. Unfortunately I can’t recall too much about the Q & A session but there were a good few questions from a very engaged audience.

bradkNext up was Brad Kilshaw (@bradderskilshaw), Google’s head of Social, who gave us a tour of the Google portfolio of social tools. He seemed very confident in Google’s ability to be the best in all areas. I’ve got some opinions on that which I’ll elaborate on in a future blog, and also around the area of Platform as a Service which is a big topic in my area at the moment.


The final presenter was the always entertaining Andy Cotgreave (@acotgreave) of Tableau. He gave a demo of the tool and how easy is to turn data into insight. I’m interested in what people thought that have not had any previous Tableau experience. Let me know.

Then it was the final wrap-up panel discussion and again more cool questions.

All in all a good afternoon. I look forward to future sessions.

Cheers, Paul

Tableau as an IT service – Part 1- Project Initiation

Alright Tablites? Welcome to the first in a series of posts that detail how I recently brought Tableau Server into my organisation as an IT Service.

This is part 1 – Initiating your Tableau Server project

It was about 18 months ago that I decided to share the Tablove and bring the application into my organisation as an enterprise level service. We’d have it sitting alongside other infrastructure services such as monitoring, scheduling, storage, server hosting and databases as another tool that application and infrastructure teams could use. The idea was that we’d farm out installations of desktop to user workstations, spin up a resilient instance of Tableau server and empower the user base to generate their content, post to server and share accordingly. I’d also get to realise my goal of bringing in an application that I truly believed would be a game changer. Lovely.

My team would run the service as part of our portfolio and my organisation would gain the benefits typically associated with IT Services – namely the following.

  • Greater financial transparency and cost control
  • Standardisation and control of user experience
  • Improved operational efficiencies such as support, change and incident management

The following series of posts detail how we did that, and the key factors that we had to take into account along the way. As with the commissioning of any new infrastructure service there is much to consider, some of it valuable, some of it just red tape, but all of it necessary for one reason or another. It’s generally a good idea to cover all the bases as the user base in the investment banking world do seem to take a form of delight in exposing any gaps.

Anyway here goes. I’m not going to go into massive detail so if you want more info then do ping me in the comments or on Twitter (@paulbanoub) and I’ll elaborate.

Note that this isn’t intended to be a textbook guide on how to manage a project, it’s more a description of my own experiences and recommendations at my particular organisation.

Project Management

a. The Sell

Project initiation is always a tricky task. First off you’ll need to convince your manager that your beloved idea is a goer and will bring business benefit. That can take some time and it’s often a good idea to make the request at the end of a live run, to make the manager decision a no brainer. In my case I ensured that we’d been using some of my manually generated viz on a weekly basis for a number of months. My manager doesn’t really give a lot away in terms of what he thinks so I did cheekily make the report deliberately unavailable one week to gauge the reaction. Turns out it showed just how valuable he regarded the reports as the meeting was much less effective without them. That gave me a degree of confidence that I had some buy in prior to asking if we could bring Tableau in as a service. Once I had that then a detailed email highlighting how I thought the business could benefit was enough to convince him that the project had legs.

b. project governance

Next it was time to engage our Project Management office / team. If it’s a project then it has to go through them. Sometimes they’ll play an active part with governance and assistance, other times it’s down to you. That depends on the level of “project rigor” that they class your project as. Rigor level is also directly related to the amount of paperwork hell that you’ll have to go through and how much scrutiny your project will come under from upper management and the project office. High rigor projects typically involve high cost, high risk and span multiple groups or geographies. High rigor also requires high level reporting and stakeholder management tasks which can be a lot of work.

In my case the Tableau service project was deemed as “low rigor”. That meant a fraction of the paperwork, although I still needed to make sure that the project office dashboard was updated with status, issues and milestones on a weekly basis. Very important to fully understand the reporting and governance requirements required by the project office so I’m not missing any of the reports or updates that they need. They’re a sensitive bunch and need to feel involved. Unfortunately low rigor projects don’t (in my organisation) qualify for assistance from a dedicated project manager so I was on my own in that respect.

c. Initial project documentation

Now it was time to fill out two key documents. The “Project Charter” and “Project Approval Request” (PAR) documents. The PAR is a higher level summary of the project and the costs involved and is effectively where the project is sold to the people who sign off the money. Once I got the green light for the PAR then the Project Charter provides the greater level of detail.

In particular

  • Project background, requirements, scope, drivers and success factors
  • Schedule, milestones and risks
  • Roles and responsibilities, changes and communication

In my case we were starting small, with a less than 50 licences for Tableau Server. The plan being that when the system was key to the business with all of the appropriate buy in I’d have a case for the expensive unlimited user core licence. That made the PAR a reasonably easy task to get approved, although it still came in for scrutiny. Unfortunately IT is a cost center rather than a profit center and any spend tends to get questioned.


Cost wasn’t as simple as just the number of licences we needed. There are many components to an infrastructure service that may not all be obvious.

  • Application licences – in my case the server licences and desktop licences for my immediate area. Our model was that interested users from other teams would fund their own purchases of desktop. Most software licences are perpetual, meaning that you’re allowed to use their software indefinitely.
  • Maintenance – Ah maintenance. The often overlooked ongoing cost. Maintenance costs are yearly charges per licence that are needed for Tableau or any other vendor to provide you with support. If you don’t pay the maint then you’re on your own if you get a problem. In Tableau’s case it’s about 20% of a desktop licence cost every year. Often good to detail out how the 5 year picture will look to your organisation. It’s also critical to get this ongoing cost into your budget plan for then next few years so managers don’t get taken by surprise. Also vital to make sure users know what they’re signing up for.
  • Recharge model – IT recharge (or chargeback) is a method of recouping IT system costs from the users of that service. It usually takes the form of a regular annual charge and can be based on a number of factors. We went for number of users on our server per department. For more detail on recharge – see here.
  • Server hardware – each box has a cost to the business, usually a flat figure depending on the specifications and platform. These costs generally include – hardware, operating system, data storage, datacenter occupancy charges and also any additional services that might come with each server by default such as monitoring, scheduling and backups.
  • SAN Storage – If you’ve got a lot of potential data to store then you’ll need a Logical Unit Number (LUN) carving off from your Storage Area Network (SAN). That can be pretty expensive so we decided to keep this to a minimum and expand should the need arise. For more on SAN – see here.
  • Disaster Recovery – In most environments you’ll need to replicate your infrastructure to the DR or backup site. In the event of a site failure from either a technical issue or human disaster the IT systems will need to be able to run from the DR site. These costs need to be built into your service model. Some vendors will charge less for a DR licence than for the main production licence.
  • Development / QA environments – You may want a development environment to test with. Very useful for trying out upgrades and bug fixes to reduce the risk of outages and risk to the production systems. Development environments tend to have lower costs than their production equivalents, usually because they have lower specifications. Ideally you’d want the environments to be the same specification but this is often an area that management see as potential cost savings. Vendors also usually charge less for development licences and sometimes give them away free. In this occasion we decided not to install a development environment to keep the costs as low as possible. We could always add one later.

For anything cash related it is critical to make sure you’ve got some involvement from your friendly local Procurement team. They’ll take away much of the pain in terms of getting the contracts signed etc and might even negotiate a bit of a discount. In my case that wasn’t really an option given our lack of licence volume leverage.

So – after all that I had a project. With appropriate documentation and approval. Costs were clear and management knew the score – no nasty surprises. Managers hate surprises. My licences had been delivered and I’d had a good few chats with Sarah Bedwell (nee Henselman) of Tableau. She was great and seemed positively interested in building a relationship with me as a customer. That made a change to experiences with many other technology vendors.

Next up is Part 2 – Design of the Tableau Server architecture

Check back in a week or so for the latest episode.

Remember – keep spreading the Tablove.

Cheers, Paul