SaaS Isn’t the Future

After years of claiming it was a  passing fad and that there is no customer demand for SaaS, BigCos have now come round to accepting that SaaS is the future.
SaaS isn’t the future. SaaS is the current – the now.

Just as “The New Economy” became just “the economy” earlier  this  century, “Software as a Service” will soon become just  “software”. The fact that it’s web based and delivered as a service will become a given. The term SaaS will become redundant.

But technology continues to drive change. Software development and delivery isn’t going to stop evolving. Smaller companies aren’t going to stop innovating. And I’m going to make the bold claim that I know where it’s going, I know what comes after SaaS becomes mainstream.

Before I make my prediction, and give it a name, let’s look at what’s driving the change.

The world isn’t “going mobile”

The world isn’t going mobile – it’s going multi-platform. There’s not a shift from the desktop to the smartphone and tablet. Smartphones and tablets are being used  as well as the desktop. Most  people today access email and other services from their smartphone and a tablet and a  desktop  computer.And increasingly they expect to be able to access the same data and software features from whatever device they happen to be using.

To cater for this, vendors are having to build multiple applications for the different platforms and devices. Often 4 or more fronts: the desktop app, the tablet app and the mobile app – with mobile and tablet breaking down further to android, iOS and even Blackberry (if you’re targeting teenage girls). One of the huge benefits of SaaS was the single code base. Multi-platform undermines that. And ultimately customers are disappointed – vendors can’t afford to add every new feature to each of their applications. So –  if not at the outset then certainly over time – the non-web applications become the poor cousins of the main application with features missing. “We’ve  not added that to the iOS  app yet”

Ecosytem is Increasingly Important

As Ben Kepes recently wrote, it’s all about the eco-system: “The foundation building block for this ecosystem is an open and accessible API that enables and encourages developers and other companies to integrate.”

Spot on. A truly comprehensive API  – one that allows you to do everything you can do in the app – is a rare thing indeed. And the API becomes yet another interface to maintain. Just like the mobile and tablet apps, new features  aren’t being added to the API after being added to the main app. It makes more sense for the development team to move on to the next new feature rather than spending time exposing the just-created feature to the API.

This is a problem that grows and grows. Your integration partners need to be able to access all of your functionality – nit just a limited subset of it.

Speed Matters

We’re getting increasingly impatient. We don’t want to sit and wait for a page to load for a nanosecond more than is completely necessary. With most SaaS applications a request for a page of data is parsed at the server end and a complete, fully rendered HTML page is sent to the client, requiring additional http requests of the CSS, images, javascript, etc. Often this can add up to hundreds of kb. That’s painful over a 3G connection. Why are we sending hundreds of kilobytes of data over the web when all the client actually needs is the few kilobytes that represent the data they’ve requested?

The Solution

The technology exists to solve all of these problems.

Responsive  Web Design (RWD) techniques are already common place on websites. When you visit a website and it renders a page optimized for the screen size you’re using, this is RWD at work. If you build your web application using these techniques then it can work optimally across all devices.  It’s not a silver bullet. Using RWD in your application development adds a significant overhead to your development time – espeically when building the foundation for your app. But boy is it worth it. Back to one code base to maintain – yay! And of course, customers no longer need to wait for you to get around to adding that new feature to all of your apps.

“But that’s a web application!” I hear you shout – “What about native apps?”. Well, let’s kill two angry birds with one stone.  Develop the application using javascript as a Single Page Applications (SPA) and you can compile it to run as a native application on many different devices. Not only that, but you’ve cracked the speed problem as well. The gubbins of your application are downloaded to the client in one hit. So now when a user requests a page of data, all you need do is return the actual data needed as JSON. Speedy Gonzales.

Which brings me on nicely to the final piece of the jigsaw. A REST API. REST is by far the easiest API pattern.architecture to work with and  is easily consumed using Javascript. If  done right, it makes for a very intuitive and fast solution that others can use in their own projects and commercial integrations.

Your app is now a consumer of an API, it has no special access directly to your backend like a server-side application would. So it’s impossible for your app to do anything that can’t be done via the API. You’re forced to keep your API  up-to-date and fully comprehensive. Make it public and watch your ecosystem blossom. With this approach, your API  is no longer an afterthought or an alternative way to access your system. It’s actually a product in it’s own right.

Give it a name

We’ve been discussing this a lot internally at KFHQ, so we needed a shorthand way of referring to this approach. RWDSPAREST hardly rolls off the tongue. So we have taken the first letter of each of the key technologies: Responsive Web Design, Single Page Application, REST API – RSR, pronounced as “Razor”.

Building The Future

If you’re starting from scratch building a new application today, why would you not use the RSR approach and get all the benefits it brings?

If you’re an existing SaaS vendor with a reasonable sized application and lots of users, it’s difficult to make a strong business case to re-architect your entire application and develop a new UI from scratch. (Echoes of boardroom conversations at BigCos discussing transitioning to SaaS?). Congrats, you’ve got legacy issues.

I wrote the first lines of code in KashFlow  over 7 years ago. We were building a SaaS accounting application before the term SaaS had even been coined. Being first to market has it’s benefits, but it has its downsides too.  You get show sign of age before others. Some of the technology we use is already dated. Our UI and UX isn’t as slick as some of our more  recently born competitors. we need to add granular user permissions, which requires touching every page of code anyway. So we’re re-architecting  KashFlow as a RSR application.

It’s not as scary as it sounds, it doesn’t require a complete re-write  of everything we’ve done over the last 7 years – re-making the same mistakes, re-creating the same bugs. It’s “just” a matter of exposing our existing functionality via a REST API and building the SPA to consume it.

It feels  good to be pushing the boundaries of technology again and being the first to deliver all of the customer benefits of the above. And it’s incredibly exciting – this approach opens up so many other possiblities that you can’t do with first-gen SaaS – stuff I’ve not even touched on in this post. Stuff that delivers huge customer benefits

The project is well progressed and we expect to be making the  first beta release in a matter of days.