The origins of software-as-a-service

SaaS dates back to IBM’s service bureau of the 1960s when it was called time-sharing or utility computing. 

Banks, for instance, used a provider’s excess capacity during lumpy end of accounting periods to pay for only the computing resources they used. During the first dotcom boom of the ’90s, SaaS re-emerged as an application service provision, but was often cruelled by a few standards, poor connectivity and lack of repeatable implementation models.

After a decade of incremental gains, 2008’s GFC sped SaaS into the mainstream. IT projects were especially exposed and those that could not show an immediate benefit or immediately align to profits faced the chop. 

At the same time, the line-of-business was under pressure to rapidly shore up revenues and etch out markets, which was behind the early success of start-up Salesforce.com. Data storage and telecommunications soon followed in other parts of the business. The IT department was also relying more heavily on emerging cloud vendors such as Amazon Web Services.

Now even traditional software giants such as Microsoft – which had dabbled in SaaS with peripheral ventures such as Hotmail and Passport/Live – hurried to ready their applications to be delivered through the cloud.

By 2011, the cloud had arrived with a bang, not a whimper.

But the ease of implementing SaaS was also its Achilles Heel. In their rush (and some say greed) to establish direct sales, SaaS vendors had disenfranchised partner channels. End customers were on their own when it came to designing their architectures, and a model intended to stop IT bloat became part of the problem as unsanctioned, unsupported and sometimes risky services spun up like topsy all around the enterprise. Start-ups are another reason for cloud’s growth because investors spend on metal when services are dialled on demand.