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