Sage shows why bigcos can't be trusted with SaaS
The first of my promised SaaS stories from Europe ends with an uplifting David-and-Goliath twist, but is first and foremost an object lesson in how not to introduce a SaaS offering, courtesy of one of the world's leading small business software vendors, UK-based Sage. I know I ought to start with one of the many positive stories about SaaS in Europe, but I'm steamed up about this one, so here goes.
After a claimed 18 months in development, Sage at the turn of the year unveiled the beta of Sage Live, which combines a free-of-charge invoicing application and a simple £10-per-month accounting product for small business owners. Although to my mind I found it a bit too simple from an accounting point of view (no multi-currency support for example), it has some interesting Web 2.0 features such as integration with Google Docs and Google Calendar, keyword search across the application, support for RSS feeds in the dashboard and a Blackberry mobile client. Online accountancy watchers Ben Kepes and fellow-Enterprise Irregular Dennis Howlett both gave it positive reviews, while noting that this was a beta release and Sage was keen to listen to feedback and evolve the product.
"Almost unbelievably, [Sage Live] show[s] your password on-screen when you log-in — in plain text. It's sent to [Sage's] central 'passport' service using a GET rather than a POST — so your password is actually in the requested URL which is displayed in the status bar ... Make sure no-one is looking at your screen when you log in ...
"A little bit of prodding around the site and I found myself looking at ... pages that only authorised people should be seeing."
Russ McRee, a security analyst with Microsoft Online Services and (via his personal blog) a deadly scourge of flawed SaaS security practices, found additional problems and reported them to Sage, as did many others over the following days. A week after Jackson posted his findings, Sage took the service completely offline and it has not yet been restored.
I'm not privy to what went on within Sage during the development and unveiling of its new offering, but it seems clear that the project was being directed by people with no practical experience of running business-critical on-demand offerings, and no such advice was sought (or if it was, it wasn't taken seriously). What kind of thought processes allow a product to see the light of day without that kind of scrutiny? This is the sort of groupthink that goes on:
- "We're a big software company, there's nothing our engineers can't tackle."
- "We're building this on BEA Aqualogic, a world-leading Web platform."
- "It's only an entry-level Web application, how hard can that be?"
I suspect the root of the problem in Sage's case was an unthinking assumption that Aqualogic was such an established Web platform that basic security would just be built in as standard. This is typical of the blind-leading-the-blind nature of the on-premise software model, in which customers blithely believe that vendors have built everything they'll need into the platform, while vendors naively assume that anything they've missed will be easily spotted and corrected by customers during the implementation process. It's bad enough when it results in catastrophic roll-outs at just a single company, but when the application is being deployed as a service to multiple downstream customers, a far higher duty-of-care is required, because the risk exposure is massively amplified.
Even more galling is that, having failed to resource the project properly, any number of senior managers at Sage are probably even now walking around telling each other 'I-told-you-so', no doubt quoting the CBR Online report of the Sage Live debacle that concludes "concerns over security and the perception that [SaaS] is more prone to breaches and down time than other application delivery options continue to drag on the pace of its adoption." So the groupthink continues.
The true moral of this story is that big, established software companies know diddly-squat about delivering on-demand applications — even platform vendors like BEA (now owned by Oracle). Smaller ISVs in particular should heed this warning. If you want to know how it's done, only ever consult and listen — at first hand — to people who have actually done it. And resource your SaaS projects properly, because doing this right will prove more difficult and more costly than you think.
Some people have said that Jackson was less-than-gentlemanly in exposing Sage to such public embarrassment when he could have contacted them privately. But then perhaps he'd have been more kindly disposed towards the software giant had it not reported his small startup to trading standards authorities for daring to cite a Sage package in a comparison table on its website. Sage has gifted Jackson the role of plucky entrepreneur taking on a much bigger foe against impossible odds — in the mold of action heroes from Star Wars to Independence Day — and to its eternal chagrin it is letting him win the battle, hands down.