Sage shows why bigcos can't be trusted with SaaS

Sage shows why bigcos can't be trusted with SaaS

Summary: Small business software giant Sage delivers an object lesson in how not to introduce a SaaS offering - but the story has an uplifting David-and-Goliath twist in the tail.


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.

But two weeks ago, Sage Live went dead after serious security flaws were exposed in the product, leading the company to shut down the beta trial. This is where the David-and-Goliath angle comes in. The flaws were exposed by the blogging founder of a tiny SaaS rival to Sage. Duane Jackson, CEO of UK-based KashFlow, which just last week celebrated passing the 2,500 customer mark, decided to have a detailed look at his rival's offering and immediately blogged about what he discovered:

"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.

Topics: Emerging Tech, Cloud, Data Centers, Security

Phil Wainewright

About Phil Wainewright

Since 1998, Phil Wainewright has been a thought leader in cloud computing as a blogger, analyst and consultant.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Not all software vendors are the same...

    Phil - love your characterization of how decisions (probably) get made at large companies like Sage. Very funny, but sadly probably close to the truth.

    However, not all established vendors are the same (though I know the record's not looking good in the SaaS space right now. As we've already said at CODA ( we see the Sage issues as highlighting the strengths of our CODA 2go strategy.

    By building on, we immediately inherit world class security features including password encryption, access restricted by IP address, anti-phishing e-mail challenge/response mechanisms. All proven over many years and 3rd-party audited and accredited.

    Just shows that not all established software vendors are the same when it comes to addressing the SaaS market!
  • RE: Sage shows why bigcos can

    Case in point, smaller, nimble software companies innovate.
    SaaS is very profitable. I share some insider info about our
    returns at DigitalChalk during this current downturn at:

  • RE: Sage shows why bigcos can't be trusted with SaaS

    Sage is clueless about the cloud. It's about savvy, not size. Take a look at what FranklinCovey, Zoho and Bathcbook are doing--not to mention Google, of course.
    In fact, Sage has presided over the overbloating of the once wonderful ACT!, which doesn't even have an online version.
  • RE: Sage shows why bigcos can't be trusted with SaaS

    After building and running a significant SaaS application for years, I can say with confidence that these types of issues are not uncommon. And the knowledge on how to prevent them in the first place is hard won by only a few industry veterans.

    The "I can figure it out on my own" is a common theme I hear when talking to CTOs about my company's SaaS Conversion Services. I suspect that this is because most of the pitfalls to watch out for in the SaaS world are not immediately visible. So developers and architects tend to think that SaaS is a simple variation on a premise based application design - until all the problems present themselves.

    As more of these failures occur, I suspect this situation will change. But for now, technologists seems to be their own worst enemy.
  • History tells us most application vendors can't change

    Every time there is a fundamental change in the operating platform, most of the established software vendors get left behind. Whether they leave it too late, or rush out half-hearted products, it is just too hard for large vendors to abandon their comfortable existing products, legacy user base and developments teams. DOS, Windows, PC Networks, Client/Server: each time most didn't make it. Meanwhile nimbler and hungrier vendors eat their cake. Will most of the existing application vendors make it across to SaaS? History says no.

    John Paterson
  • RE: Sage shows why bigcos can't be trusted with SaaS

    A sobering story that every software vendor considering the move to SaaS should read and take to heart!


    Joanna Lees-Castro
    "Providing marketing, sales and business planning guidance for software and services vendors"
  • RE: Sage shows why bigcos can't be trusted with SaaS

    Wow. A public outing like that must be devastating for a company like Sage. While I don't agree with how Jackon dealt with the issue, I'm sure we can all see why he took the opportunity to blog about it.

    I don't think this problem is limited to any particular software business. Security is certainly something to take seriously. But most of these applications beeing SaaSified are being run by the same managers and leads of their desktop version.

    On-demand software is an entirely different world. It's a different set of skills, languages, and design that can't be taken lightly. I think many managers simply overlook it. I've been fortunate enough to start in the SaaS environment where security is taken into consideration from day one. Having your application accessible on the Web is significantly different that having your application run behind your firewall.

    <a href="">MHelpdesk</a>, <a href="">Service Management Software</a>