Big mail blues
Posted on 26 Oct 2006 at 11:31
Steve Cassidy battles ingrained attitudes to email and tackles the knotty problem of hospitality networks
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.
- How to sell more ebooks on Amazon
- 10 ways to make your business more secure
- Top five VoIP mistakes
- How to add in-app purchasing to an iPhone, Android or Windows app
- Remote-control ransomware: TeamViewer and software hardball
- Why laptops with serial ports matter to the Internet of Things
- Make your mobile battery last longer
- Small steps into handling Big Data
- Nexus 5: does it really run stock Android?
- How to get broadband to a garden office
- Google Glass: mugger bait, pub problem and other lessons learned from two dangerous weeks
- Twitter, please don't fiddle with my feed
- How Satya Nadella can get some pay-raise karma
- Windows 10: a step back to go forward
- Michael Dell: Cloud infrastructure is the roads, bridges and highways of the 21st century
- How to check your identity hasn’t been sold to the hackers
- Tim Cook: this is how much TV has changed since the 70s
- Westminster wins the .London battle
- 20 years of PC Pro: from deep pan pizza to virtualisation
- Five reasons why the Apple Watch leaves me cold
- Will HP finally split into two companies?
- Chromebooks get version of Photoshop
- Toshiba beats retreat from consumer PC market
- Ellison steps down: but who's really running Oracle now?
- Microsoft set to make more job cuts
- Is Peter Pan panto tickets email genuine? Oh no, it isn't
- Intel triples Xeon E5 chip performance, adds DDR4
- Patch Tuesday targets critical IE flaw
- Microsoft refuses to hand over customer emails
- Microsoft yanks Windows 8.1 update after crash reports