Big mail blues

It’s nice to get some reassurance, periodically, that one is doing the right thing, but such pats on the back are few and far between in the IT business, at least according to a couple of bosses I’ve had who moved into the sector from elsewhere. Nevertheless, in the case I’m talking about here, my little dose of feel-good came from an organisation so huge that it’s quite literally visible from space. Don’t imagine that I’m going to give its name away – nor any clues to its true identity – as the lesson we learned together this last summer was all about the need to remain anonymous when you’re unburdening your soul (which isn’t easy when email is the subject).

Regular readers will know that, in my opinion, email is the right solution, but frequently delivered by the wrong methods. My own personal exposure to email dates back to way before the days of the internet, so complaints that the platform we’re all using is architecturally inadequate come as no surprise. In the case of the phenomenally huge client organisation I’m talking about, the problem is pretty mind-boggling: an engineering firm with 25,000 employees spread across the whole of a fair-sized European country, who all use standard internet technologies to pick up and send emails through a central hub that was attracting a lot of attention. Why? Because it had entered a steep decline from “just working” in a completely unnoticeable fashion, down to needing to be rebooted half-a-dozen times every single working day.

This wasn’t my first client in the engineering sector, so I was alert to the possibility that it might be rather too exacting in its operations, which might sound like a very strange problem to have if you’re in a more commercial or entrepreneurial business (especially a smaller one). I mostly deal with people for whom anything that works at all is good enough, perhaps to be followed eventually by stuff that works properly. Engineering companies on the contrary are far more likely to adopt something that hardly ever does the job right but which is immaculately conceived, was delivered on time and adheres to every word of the relevant standard document – because that’s how they benchmark their own projects. The standard document is their starting point, and if it doesn’t happen to properly describe what was wanted then that’s too bad.

This client’s email system had been designed by two separate edicts issued from on high, one of which of course was “stick to the standards”, while the other was “deliver all messages within 20 minutes of the author hitting Send”. Those familiar with the original specification of the SMTP standard may see the trap coming up. Traditional email systems can do the job in under a second these days (given sufficiently small emails), but when anything goes wrong their retry behaviour is clearly specified in the relevant standard; namely, have another try every half-hour for the next four days, and start reporting back that there’s a problem after some lengthy period, which could be eight hours, could be 12, all depending on the whim of the systems administrator.

In this client’s case, the sysadmin was already pretty demotivated because the other standard they’d decided to stick to involved outsourcing a sizeable part of his job. For whatever reason, this process had dragged on for more than a year, quite possibly as the organisation’s inherent schizophrenia became more and more apparent to the new contractor, who felt it necessary to alter the terms and scope accordingly. As a result of this, even though a fix for his and my problems was within reach using standard tools and techniques, he couldn’t progress to implement that configuration without causing even more upheaval in the outsourcing relationship, which would mean that money would be spent twice – once on the fix itself and once again to placate the outsourcer.