Data Scientist? It’s a mindset, not a name

Good day to you Tabaholics,

kirkdThere I was the other day, merrily minding my own business playing with Tableau maps when I happened to read this tweet by @KirkDBorne. Did a bit of googling and came across this link regarding whether you should call yourself a “data scientist” or not, a subject that seems to be getting a fair bit of chat at the moment.

Now I think it’s a bit strong to refer to someone as a “fool” for calling themselves a data scientist. What companies like Alteryx, DataSift & Tableau have done with their splendid applications, is allow everyone to be a data scientist. Or whatever else you want to call yourself. I call myself a Ninja – believe it or not I’m not a real one, although I do have a black one-piece. What I am is a real scientist. I’ve got an M.Sc. degree in Molecular Pathology (and toxicology) and a B.Sc. in Biomedical Sciences. None of that matters, I don’t get offended when someone next to me calls themselves a data scientist.

For me being a scientist is a mindset, not a qualification. It’s the mental attitude and aptitude to take on and solve problems through a process of hypothesis and experimentation. Your weapon of choice may be a bunsen burner or a Flow Cytometer or Tableau Desktop – it doesn’t matter. What matters is the desire for knowledge and understanding, even better if you’re of the mindset that you want to share it with everyone afterwards.

220px-William_Perkin

The process of scientific experimentation is what has driven invention for hundreds of years. It doesn’t even matter that you don’t get the results you expect – it’s the journey that counts. William Perkin (pictured) was trying to make synthetic quinine and ended up revolutionising dye making (and making a shed load of cash in the process). He also had a pretty impressive beard as well. Wonder if he dyed it… Even some items as seemingly complex as the human pacemaker was invented by accident – Wilson Greatbatch taking that one down. Other examples of accidental discoveries include the microwave oven, Teflon and Coca Cola.

So call yourself whatever you want. Call yourself a Ninja, or a Jedi or a Yeti or a data rockstar. I don’t care. Just keep on pushing the boundaries and discovering. You should be proud of yourself for trying.

Regards, Paul

Advertisements

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.

VC_diagram

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.

Authentication

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 http://tableau.myorg.com 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 http://se186293.gsdomain.com:8888 to access them.

Backups

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.

andyc

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

tablogowl

Hi Tablites and welcome to what we at VizNinja like to call The Tableaudown. Geddit? Like the lowdown. Only with Tab at the start….. Ok be like that, I thought it was good and I’m in charge here so it’s staying.

It’s gonna be a monthly digest of some of the Tableau and BI related stuff that’s kept us busy/interested/entertained here at Ninja Towers. Hopefully it will prove useful to some of you. There are a few similar digests out there and this isn’t intended to replace or compete with them, it’s just things that took our fancy this month.

Twitterati

Random shout outs to those who’ve made our lives easier or made us smile.

  • @vizcandykelly – Thanks so much for your outstanding blog and fuz viz. Zombies!
  • @jonathandrummey – The only blogger who combines BI insight with parenting! And he seems to be great at both.
  • @cheeky_chappie (& Thasan V) – Thanks for the help with our secret-ish project. We should be able to unleash it on the Tableau world early next year.
  • @odbin – Cheers for the questions and interest in my blog post – Tableau as an IT Service.
  • @DGM885 – Cos your new book is the business and looks mega on my iPad Air.

Books

Some of the publications that we’ve spent time with.

infodashInformation Dashboard Design – Stephen Few

Stephen is a true legend in this field. Be sure to read and digest his every word.

New Ninjas get this as part of their welcome pack. Or at least they would if The Book Depository ever get around to actually delivering it.

tabyourdata

Tableau Your Data – Daniel G Murray 

Now this is the one we’ve really been looking forward to. This is the best guide I’ve seen to getting the most out of Tableau. Make sure you follow @DGM885  as he’s one of the most insightful experts out there.

I’ve gone for E-book this time. Looks lovely on iPad Air.

Interesting viz

Top Tips & Content

More next month,

Remember, keep spreading the Tablove.

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.

Costs

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

Kicking Off

OK it’s time to kick this thing off.

I paid a visit to the Book Depository yesterday, no not that one overlooking Dealey Plaza, this one – http://www.bookdepository.co.uk.

I grabbed a copy of the latest edition of Stephen Few’s “Information Dashboard Design”, one of the bibles of all things viz and a must-read for anyone with an interest in BI matters.

Anyway, upon completing the purchase I noticed this. http://www.bookdepository.co.uk/live

A real-time map of book purchases across the globe. Seems simple but utterly mesmerizing. Someone in Australia buying a guidebook to London – upcoming holiday perhaps? Harry Potter box sets flying off the shelves in the USA, The Moaning of Life purchased in Ireland (hope the book is better than the TV show) – I even saw my own transaction pop up 10 seconds or so after I completed it.

I spent more time watching the map zoom from Norway to Greece to Russia than I did making my purchase.

A bit of googling tells me this has been in place for some time already, but it’s still a lovely touch and something I’ll expect to see on other sites in the future.

Cheers, Paul