May 22, 2006, 2:30 PM — I distinctly remember the day when it dawned on me that any application that can be made to work on the Web could be made to work on a private Web (i.e. an intranet). This might sound obvious now but I was thinking this thought a long time ago when Windows for Workgroups and Novell Netware were all the rage. Running a private Web - an Intranet - was not at all common at the time.
Then came a period when Intranets were common and all of a sudden, software companies were not only hosting their own applications online but also making them available for deployment on intranets for a suitable fee. I would argue that part of the (fading) attraction of a big application framework such as, say, J2EE, was the idea that once developed as a J2EE webapp, an application can be hosted locally in exactly the same way as it is hosted on the Web.
Then began an awful period - which continues to this day, sadly -- of companies developing intranet applications and then concluding, erroneously, that the application can be deployed on the Web by just flicking the proverbial switch. There is an important asymmetry here between intranets and the internet. Applications can scale downwards - from internet to intranet - easily but the reverse direction - from intranet to internet - is rarely simple and often impossible. Millions of users, flash flood characteristics[1], five nines availability[2] are just some of the reasons (collectively referred to as "non-functional" requirements) why this asymmetry exists.
That's ok. I can live with that. Applications can scale down easier than they can scale up. Fine. So where are all the Internet-class applications that I can deploy on my local intranet?...
There are some, but not as many as you would perhaps think. I can get Google in a box (although I don't know of anyone who has one). I can host a Confluence WIKI online[3] or buy it to run locally[4]. I can use Wikipedia or download MediaWiki[5] to run something similar myself...
This list thins out pretty quickly. I wonder why that is so? Are there technical reasons why applications like JotSpot or Writely or Flickr or SalesForce etc. could not be made to run locally? I don't believe this is the case. I think the reason these applications do not "scale down" has nothing to do with engineering and everything to do with business models.
Simply put, it is hard to build a business around building off-the-shelf web applications that are hosted by your clients rather than hosted by you. There are so many moving parts in web applications that maintenance can be a nightmare. So much so, that the maintenance you would have to charge to cover costs would render the product uncompetitive. On top of that you have all the headaches of deploying software - bug fix distribution, backward compatibility and so on. Not a pretty picture. Unless perhaps you are shipping hundreds of thousands of copies.
The principle asymmetry on the web today is the result of commercial concerns not technical concerns. That is fine, but it does create a big problem. Perhaps the biggest problem that the Web revolution has faced to date. If all these great applications only exist on the Internet and are not available on my Intranet then my data is out there "on the cloud". It is way beyond the confines of my buildings and rather too exposed for the vast majority of commercially sensitive data.
Would you put private documentation up on a hosted wiki site? Would you feel comfortable using an online accounts package for your business? My instinctive answer to these questions is "no" but I must confess that I have been quite surprised at the extent to which people are happy to use Web-based E-mail, Web-based CRM, Web-based Collaboration tools with nothing more enterprise-class for security than a username and password.
Perhaps I will continue to be surprised. Or perhaps the asymmetry will be addressed in some clever way that I cannot envision. Perhaps PKI or something similar will make a comeback. For now, the choice we face is to use some of these online-only applications and mitigate any associated risks, or do without.
[1] http://en.wikipedia.org/wiki/Slashdot_effect
[2] http://www.networkworld.com/details/5642.html?def
[3] http://www.adaptavist.com/display/ADAPTAVIST/Home
[4] http://www.atlassian.com/software/confluence
