Blog

Evolving Past Email: Creating Real Collaboration Tools for DevOps

webteam's pictureAdministrator |

Written by Sam Marsh, Product Manager at Opsview

As those of you who know me personally can attest, I’m never particularly enamored with the phrase – “That's just what we’ve always used”, or “That's just how it's been since I started”. I'm a firm advocate of the Winston Churchill quote “To improve is to change; to be perfect is to change often.” And yet, I feel that a lot of companies fail to do this.

A lot of us in IT like to reminisce about “Oh wow, 2.5″ floppy drives – I bet you don't even know why there isn't a B drive in Windows do you?” Or worse still with the older generation – “Oh VAX was the best..," instead of looking at the drawbacks which led to the eventual demise of these technologies. I feel the same can be said for email. It's so engrained in corporate culture that no one has actually thought to product analyze email itself – in terms of:

  • What problems does it solve?
  • Is it fit for purpose and easy to use?
  • Is it advanced enough to allow for further growth and evolution?

In 1971 when ARPANET first devised email, I imagine the above were true – but it was also true that it would be 4 years until Microsoft would be founded, and another year until the breakthrough Intel 8008 microprocessor would be released. Nowadays, email tends to be the cause of more problems than it is worth, especially when used inter-company.

Don't get me wrong, I don't think email is all bad. I think email has the same purpose as the one a postal system holds; content delivery rather than collaboration and speed. However, in the last 10-15 years, email has been used more and more as a collaborative tool between teams and departments, leading to infuriatingly long email threads, reply-to-all’s, and a lack of dynamism that can really hurt companies in the fast moving society in which we currently inhabit.

Email is also prone to abuse – we have:

  1. Spammers / Scammers
  2. Automated junk from websites and services
  3. Junk you might have once thought of as a useful idea (i.e. “Oh its great that Salesforce emails me everytime a lead is created”).

Along with a million other ‘Junk rule’ creating annoyances.

So, what is the answer?

Recently, I’ve been working more and more in the world of ‘integrations’, taking data and events from one tool and doing something in another – and this has exposed me to a world of possibilities in terms of – “Why can’t this idea be taken and applied on a company wide scale?”.

What if, instead of having hundreds of folders containing automated emails – and then having to forward these emails to colleagues, then skype them “Hi, about that email..” – you could both see the ‘event occur’, and then discuss it live, along with the rest of your team?

In my company alone, we use at least 10-15 platforms across departments, ranging from ServiceCloud for customer success (ie, technical support), Salesforce for CRM and Sales, Jenkins for builds, Git for storing magic and dark power crystals, JIRA Agile for SCRUM/Agile, ProdPad for Product Management, and so forth. All of these tools generate events and it would be awesome if we could quickly access and collaborate on these. However, currently we (like many others) are reticent to set up email alerts, as they will inevitably annoy us and be tossed into junk via a rule.

A potential answer? A chatroom-like tool that allows feeds directly from the aforementioned tools, but at the same time, allows for the dynamic creation of rooms/group chats, sharing of files (Docs, images, etc) and more importantly – dynamic discussion and resolutions. Namely, Slack or Atlassian Hipchat.

Hipchat

Hipchat is a free (for normal use) tool from Atlassian, the makers of JIRA, JIRA Agile, Confluence, BitBucket and more. It allows tools such as their aforementioned products to send data and messages into various ‘rooms’, such as ‘Engineering’, ‘Support’ and more – meaning that if a new customer incident is raised in JIRA, it will appear in the Support room within seconds, allowing support engineers to quickly discuss the incident and assign appropriately.

There are a number of Hipchat integrations available here, ranging from GitHub and Drupal through to email and even Opsview (i.e. ‘customers edge router has gone down, send a message into the Networking room to tell them).

Slack

Slack is like Hipchat's better looking, cooler younger brother. It's much more user friendly, the UI design is excellent and I love how easy it is to setup. The main differences I found with Hipchat and Slack are:

Hipchat seems more corporate; you have an IRC style interface for a start – with a list of users on the right that you can double click on to either IM or video chat.

Slack is easier to use and is a hell of a lot prettier from a UX perspective, which ALWAYS helps adoption.

Integrations

The issue I found with trying to setup Slack and Hipchat as my email-killer, is that whilst they offer integrations, they don't offer an all-encompassing range that fits my needs perfectly, and as I'm not a developer I’d have no idea where to start in terms of writing my own integrations.

For example, with Hipchat the integration with JIRA Agile is excellent, you can be notified for all sorts of things – which is what you’d expect from 2 tools from the same vendor, however they offered no integration with Salesforce or ServiceCloud. Likewise, Hipchat had some neat integrations via webhooks, but also fell down on Salesforce integration, and their JIRA integration is pretty poor.

In order to get messages from these vendors into the ‘chat tools’ I just mentioned, you have to use another product that has popped up in the market in recent years, an ‘event broker’.

Event brokers

An event broker is essentially a middle man, who takes data from one tool, formats it, and sends it to the other tool – for a nominal fee (or free, depending on your tool de jour).The benefit of using event brokers is that as long as they can talk to your chosen client (Hipchat, Slack, etc) then it's generally much easier to setup integrations as that’s their bread and butter.

A few examples of event brokers are:

  • Zapier
  • IFTTT (If This Then That)
  • Cloudwork
  • Elastic.io
  • We Wired Web

IFTTT

Verdict? It's OK – probably more use for home users and script kiddies than to a business, judging from the list of integrations:

It doesn't have Salesforce support, JIRA support, or other items like Jenkins etc however it does have GitHub support.

Zapier

Verdict? Pretty good! It is incredibly simple to configure and use, and linking your accounts (i.e. the Salesforce account you want to get information via) is VERY simple to do. The configuration of what you want to send is also very simple as it sucks the fields in from Salesforce, Twitter, or any other tool you want. For example, I want to send a message into my marketing room whenever my company was mentioned on Twitter, so they can discuss if they need to respond, etc.

To do this, I set up a new ‘Zap’ as below:

Trust me, it IS as easy as that. And now, whenever anyone tweets with the words ‘Opsview’, it will appear in our Marketing teams Slack/Hipchat room. Observe:

We can now discuss the tweet, respond if it's a query, pass it onto Sales if it's an enquiry, and so forth! All done without a single email. Ah the bliss.

What next?

The end goal is to have a fully automated solution, that takes in inputs from all of our chosen tools, uses an event broker (if required – some tools can output directly into Slack/Hipchat using Webhooks), and puts them into the correct room, in the correct format – allowing for quick diagnosis, recognition – and most importantly, COLLABORATION.

Here's a little screenshot of what I've set up so far:

Here, we are sending a message into the #sales room in Slack when a new opportunity is created (via the website or an account manager). We are sending an alert into the marketing room when we are tweeted about, and when a customer raises a ticket in ServiceCloud – the support team gets an alert. The plan is to roll this out to our other functions, then start the most painful part – driving adoption!

Potential barriers to adoption

So – this thing is bloody marvellous, why wouldnt anyone want to use it? Well, there are a few areas:

  1. It doesn't have a calendar functionality- people will still be using Outlook to send calendar invites, and view other users diaries.
  2. People are familiar with Outlook- meaning that when driving adoption, highlighting the advantages of this disruptive move (Crossing the Chasm, Geoffrey Moore) is going to be key to its adoption throughout.
  3. People use Outlook for task management- Simple, use something designed for that purpose like Wunderlist, my personal lord and saviour of time management. Again however, there is likely to be some pushback on this – given people are still using IE, I'd be amazed if they jumped on something like Wunderlist without reticence.

Conclusion

To conclude, email is good for external communications, but in my opinion, stay away from outlook when thinking of internal communications. It might have been the way to do it 20 years ago, but with the rise of event brokers, tools like Hipchat/Slack, and an onus from software vendors on creating an easy to use API to allow for automation, the days of “email for everything!” is coming to an end – collaborative tools will drive customer success, and eventually the success of your business as a whole.

I see event brokers becoming more and more prominent amongst a user base that wants integration without the development headache – forcing vendors to create ‘recipes’ for these platforms such as IFTTT, Zapier, and co. Overall, software will become better at talking to other tools, which can only be good for customers.

Administrator |