I recently had an article published by .Net magazine entitled Why HTML5 is not the choice for enterprise mobility and to say that it caused a little war of words would be an understatement. As so many fellow bloggers reached out to comment on the piece I thought it only fair to put together the following to further strengthen the three main points I had made, but also to clear up some of the misunderstandings of those who had kindly commented on it, so here goes.
From the outset I want to stress that I, like so very many of my contemporaries, am convinced that HTML5 will be the right way to go in the future but in this article I wanted to stress that practically speaking, right now there are just too many issues to make it the perfect solution for enterprise mobility.
That’s the first point, from a technology point of view for the future when all the practicalities of security, bandwidth and synchronisation have been overcome HTML5 will be a great way forward but right now I don’t believe it’s really actually there and ready.
The real issue here is synchronisation and speed of network, and therefore synchronisation of objects, it is correct you can develop synchronisation and you can build a mechanism to deal with that, as Kevin Sweeney pointed out, but then I would argue you miss the point of having a standard.
This is exactly the point I was trying to make when I mentioned “band-aiding” or building another patch then another and then before you know it you get to a point where you are stretched to the maximum.
If I look back at the dot com era and dial up history seems to be repeating itself, think back then we had the same problem of synchronisation, as soon as we had ADSL the whole issue went away but before then this was a huge issue, you merrily shopped online then you went to your cart and nothing was there yet as it wasn’t downloaded or the images were different and so on.
We have to think about this not just locally or from a London point of view we need to think about a global enterprise that wants a global reach, there are some places where even a 3g connection doesn’t exist yet and therefore a different approach is needed.
This is where my suggestion of a Mobile Enterprise Application Platform (MEAP) comes in as it automatically does a high level compression to cope with reduced bandwidth, yes there is a minimum speed but once that is reached the high level of compression comes in meaning it can cope with far lower levels of speed.
My second point was actually the issue mentioned by timw4mail, HTML5 is just a mark up language and Java Script is just a scripting language both offer nothing to manage a situation where you are going to take data from a server side technology and try to push it to mobile devices.
They are purely responsible for the synchronisation between the objects if the your whole infrastructure is built on a mark up language, of course it is something you can learn to work with but there are security issues embedded in that including denial of service etc. This is not just a mobile device issue this is the weakness of HTML in general.
An organisation who ties up their infrastructure and invests millions of pounds in SAP who then try and open it to HTML5 I for one think this would pose a problem. Take any mobile device put it into a wi-fi and route all your traffic through that you can see everything that goes through that channel and this becomes a weak point of entry into the previously secure organisation.
The third point I want to make, a point which Kevin Sweeney, shakyjake, timw4mail, Johnboy, elmarko and scottw all seem to be missing is that I am not advocating creating multi native applications but rather using a purpose built MEAP that communicates in the bottom protocol with HTTP and HTTPs but has built in security mechanism on top of it, has a built in synchronisation technology on top of it and knows how to run to develop it once like HTML 5 and deploy it to multiple channels so you don’t need to rewrite the wheel every time. This is what I am advocating to enterprises to do.
If you look at what Oracle and SAP are doing like scottw said they are enabling a HTML version of their solution to run on a tablet this doesn’t mean they have chosen multiplatform HTML 5, they have simply developed a HTML5 interface and it is up to the users to decide what to use.
This kind of approach of course has different weaknesses in terms of designing different processes to a mobile device and so on. Of course we can take any site today and run it through a browser and call it a mobile solution but the matter of the fact is that the way user interacts with a mobile device is completely different and missing that will be extremely detrimental to adoption.
I agree completely that the HTML5 standard is great for business to consumer apps but when it comes to interaction between companies from one secure environment to another to go into a HTML5 protocol will all its vulnerabilities right now is the wrong way forward. Don’t get me wrong I am not saying the issues won’t or can’t be fixed and it won’t be the best solution in one year or two years time but right now it is exactly the same problem as dial up was all those years ago.
In this article I was asking that people look beyond their developers eyes the technology is one thing but how are you going to implement it and what kind of solution will be brought to the enterprise is a completely different idea. I have years of experience of delivering such technologies to enterprises and we don’t ask them to do individual programming for each device type natively we ask them to look at a more holistic approach not fall in love with one technology but to look at a wider world view and see how it can be used.
And the defence rests your honour ………
