Why Can’t We Have Both?

I love reading stories by John Dvorak – he is very opinionated – and I love that (I’m a tad opinionated as well). I read his column at PC magazine and watch his streamed show called “Cranky Geeks” on a regular basis.

John’s latest tirade is against Web 2.0 applications. The subtitle on the Article entitled “Stormy Weather for Cloud Computing” sums up his view very succinctly: “Cloud computing apps are for suckers. If there is an alternative that runs locally on your own machine, it will always be better.”

He goes on to list 7 things that are wrong – or could go wrong with software that’s hosted in the cloud. I have to say – that I totally agree with him on some points, and totally disagree with him on others.

First – where we agree: whenever you host something off premises – you’re going to run the risk that it will be offline. Either your connection will go “down” or theirs will – or there will be a server issue or whatever. That’s the case with all Internet-based applications.

I would even take it a step farther and say that even with completely in-house applications – there is going to be down time. I guarantee it. The reason is because we still host applications on servers – and servers go down. The hard drive dies, or the processor melts or Windows has a spaz and just ups and dies.

Either way – it’s downtime.

However, I do think that John is throwing the baby out with the bath water (an American saying). Hosted applications save people tons of money and tons of time in terms of buying, managing and maintaining a whole IT infrastructure in-house.

When it comes to designing a network topology, buying (and updating) server hardware, network storage, database servers, performing backups, ensuring redundant everything, paying heating and cooling and electricity bills, updating and installing patches and new application versions – it’s just a heck of a lot easier to let other people handle that part of the equation.

Especially if you’re an ISV (Independent Software Vendor). If you’re an ISV – your business is building software – not managing a data center.

At the same time – if you’re building applications – you often have to choose whether you’re going to use browser-based technology or client/server technology. It’s apparent that with the outsourcing of the hardware becoming a more affordable option – more and more people are looking to develop browser-based applications.

However, there are times when a client/server model or having a native client or having an offline version of your software is necessary (or even preferred over a pure browser deployment model). For example, what if you have a POS system that must interact with local hardware like scanners and cash drawers?

Try doing that in a browser!

In general, we find that people who use an application all day every day want a native, rich, thin client (we call it a “Smart Client” here at Servoy). The native client means that the user can work in their preferred operating system and the application will have the same look-and-feel as all the other applications they are already used to using. It can talk to hardware, the local file system, etc. – things that are impossible to do with straight HTML.

On the other hand – browser-based application are great for occasionally connected users, for end-user customers to check status, or answer a particular question, update their account information, etc. It’s also great for portions of the application (think an executive dashboard, a remote sales report, etc).

The big question to ask yourself is: “Why can’t we have both?”

The answer is usually: “Because we have to build the entire application twice.” And, in general, it’s true. Most products require that you re-build the data entry screens and reports in HTML for the browser, IN ADDITION to re-building the business logic behind the calculations, validations, etc.

This means that you are doing double the work – and maintaining two separate code bases quickly becomes a nightmare! Not to mention the fact that you have to then manage how you’re going to roll out new features: is it a client/server-feature only? Both? Only browser-based?

I can’t tell you the number of times I’ve seen this approach taken by well-meaning companies trying to gain the advantage of either first-mover advantage or because their struggling to modernize their aging application and immediately think “browser.”

At Servoy our answer to “Why can’t we have both?” is simply this: YOU CAN. Not only that – you can have a SINGLE code base – and deploy your solution as a client/server application as well as a pure HTML/CSS browser-based application. At the same time. From the same server.

Not only that – but you can also sell it to your customers as a SaaS (Software as a Service) application either with a native client or a browser client; you can also sell it as an on-premises solution that your customer can host inside their firewall or in the cloud and deploy to their employees as client/server or browser-based. From the same server. At the same time.

You CAN have both – the solution is Servoy.