Beyond SaaS, The Future Of Software Development and Delivery

Back when I launched KashFlow, my online accounting software business, the phrase “software as a service” hadn’t been coined yet. The recently popular catchall phrase ‘cloud computing’, now frantically highlighted in every marketeer’s notebook, was practically unheard of. iPhones didn’t even exist yet.

Seven years later, SaaS is widely accepted as the way software (with a few exceptions) should be developed and delivered. SaaS is the industry standard, not something revolutionary or cutting edge. Today, you’d have to be insane to be working on software to be delivered as a locally installable application.

But as Sage, Oracle and the rest of the industry finally turn up to the party wearing their “I’m SaaSy” T-shirts, they find that Bungalow 8 has closed down and the cool kids have already Hailo’d a cab and are on their way to Adam Street to plan the next wave of innovation and disruption.

What’s The Problem?

One of the key benefits of SaaS, for the vendor, is the “single codebase”. No longer does one have to worry about supporting multiple versions (multiplied almost exponentially by a number of operating systems) or rolling out upgrades. There’s a single application on a web server, and all customers use that via their browser. Update one place and all customers are on the latest ‘version’.

It means that new features can be rolled out to everyone in a matter of minutes, it means that bugs are squashed almost as soon as they’re discovered and it means that the support team never have to worry about what version of the software a user is running.

When I look at the approach being taken by competitors, and many others in the SaaS industry, I already see this benefit being lost. They are maintaining multiple distinct sets of code, essentially several separate applications, all with different use-cases and requirements – web, mobile web, iPad, iPhone, Android. Even Blackberry, if 13 year old girls are your target market.

SaaS products are constantly evolving, so when you introduce a new feature you need to add it to all of these different applications. Not a trivial task. You’ll often see new features appear first in the web-app, then take months to make it into mobile apps…if they make it at all.

Then there’s the API. Don’t underestimate it. If you’re serious about SaaS, then comprehensive open APIs are essential. But they don’t remain “comprehensive” for long if you don’t continue to expose new functionality in them.

It’s a cliché, but the world really is going mobile. And mobile means multiple devices on which a web application is less than optimal. Which really buggers things up.

Presenting: The Future

All of the above can be easily resolved. Build your app as a one-page application using pure JavaScript and HTML, then connect it to your servers using a REST API. Simples.

This works beautifully for the web, and gives a great level of responsiveness. Compared to a typical MVC-type application it moves far less data between the server and the client. There’s no HTML that needs to be sent down the pipe.

It’s just JSON or XML going back and forth. So not only does the application respond much more quickly, it also reduces the amount of bandwidth your application uses. And because so much of the data processing and rendering is done on the client side, you’re reducing the CPU and memory load on the server. Guessing I’ve lost any non-techies by now, right?

Using responsive web-design techniques means that you can render a much more suitable display when someone uses your app from a mobile device, totally eliminating the need for a separate “mobile-friendly” version of your application. You can use the same responsive web-design techniques to hide or display certain elements that might not be applicable on all platforms.

But what about native apps? Easily dealt with too. Put your code through something like PhoneGap, and your JavaScript application can then be deployed natively on iPhone, iPad, Android and Blackberry.

As much as we might like it to be so, not everyone is connected to the Internet all of the time. Lack of continuous and reliable Internet connectivity means some geographies just can’t use web apps. Even in the UK, there are areas where Internet isn’t reliable enough to run your business in the cloud. Introduce HTML5 into the REST/JavaScript app and you have localStorage, which can make it so your app can work offline. When it comes to maintaining your API you have no choice – there is no compromise. Your main “web app” is just a consumer application for your API. It’s impossible for it to do anything that isn’t exposed via the API.

This all sounds great in theory, right? But it actually works in practice too. We’re already well progressed on a massive upgrade to our SaaS application using exactly this approach. And it works.

If you disagree with my prognosis, then I hope we can at least agree that the development and delivery of software will continue to evolve. In any case, I’d be keen to hear your thoughts on what the future of software looks like. Comment form provided below!