Given the hype and interest surrounding cloud computing a senior business person is bound to take the bait and ask “Great, now how do I run my SAP HR on the cloud?” The answer is muffled and accompanied by body language tells such as shuffling of feet and sheepish, downward looks. The simple truth is that existing enterprise applications have architectures that are incompatible with the needs of the cloud and cannot remotely fit without serious rework, resignations and personal injury. The only solution is to use ‘CloudCentres’ (a recent term resulting from string concatenation which is so popular in IT) which are simply virtual datacentres in the cloud and are, in my opinion, not really the kind of clouds that will make any difference to how we do things.
When talking about existing enterprise applications I am referring to two types, the (mostly large) vendor provided enterprise applications such as SAP and Oracle Financials as well as the bespoke applications that are developed or assembled in house for a specific business requirement. The main reason why these applications cannot migrate is their dependency on the relational model which, in it’s current incarnation, doesn’t scale out very well. Although architects have tried to abstract data access there is still a fundamental dependency on a whole lot of tables with rows, columns, foreign keys and all the goodness that we have come to expect from SQL databases. The relational model in general, and SQL databases in particular, do some things so darn well and have served us for so long that it would not have made sense to try and engineer an enterprise application without them. They are simply hardwired parts of the enterprise application DNA. Even now, if you are starting with a greenfield project, you are probably safer, at least in terms of short term delivery, going the relational route than the cloud route.
So large vendors, including SAP and Oracle, will exclaim loudly that the cloud is risky and can’t be trusted, and isn’t complaint, and can’t something else, and doesn’t something the other. While there may be some essence of truth in their claims, they also have products that are so grossly misaligned to the cloud paradigm that it will take them years to migrate, if they can do it at all (which I don’t think most can). I don’t mean to single out those two, but I have worked with them both and can see how the culture and the philosophy of the products is at odds with the cloud computing movement. I don’t want to start a rumour, but just think for a moment – what if Google announced tomorrow that they were taking signups for a beta of a Google-based ERP system? Crazy idea? So was entering the (now fat client) email market and the browser market.
Apart from the big vendors, departments that have been building applications based on the current pattern of database with a web server, and maybe a tier in the middle – will not be able to port those applications to the cloud. The database will not be easily extracted and the development paradigms and architectures are so different on the cloud that the developers would find themselves seriously underskilled and incapable of taking on the new architecture. The cloud requires thinking and architectures that are asynchronous, message based, transactionally inconsistent, loosely coupled and a whole host of concepts that are completely foreign to the average enterprise developer who is quite happy using datasets (thank you very much).
It may seem then that the leap into the cloud is like it sounds – jumping out of an aeroplane (into the clouds) without a parachute. Luckily there are sound and pragmatic architectural approaches that make this easier. The first is the concept of off-premise (cloud based) and on-premise architectural components bound with glue that helps them communicate (service bus). The idea being that you can run a portion of your application in the cloud and another part in your own datacentre. So, for example, the high load online sales portion can be in the cloud, which in turn sends data back to the on-premise system for fulfilment, reporting and other needs.
So, a part of the system, possibly limited to one basic transaction can be in the cloud, backed-up by an on-premise operational datastore that reflects those transactions. As time progresses, skills are available and the need arises, various other parts of the system can be moved across until one day large chunks, or most of the system, is in the cloud – without too much pain and suffering along the way. (Disclaimer – this applies to bespoke enterprise applications, the large off-the-shelf vendors will have a much harder time and would probably be better off running in circles bleating like sheep and issuing anti-cloud press releases)
So, if you are looking at the cloud, and looking to really leverage cloud computing, be prepared for a shock in terms of how different it is. Plan, not to port your existing applications onto the cloud, but look for newer or smaller projects that stand a much higher chance of success.
Update
Seems that SAP’s cloud strategy, by their own admission, is ‘Partly Cloudy’. Also their head of the cloud computing business is the former head of Oracle applications development and his name is ‘John Wookey’ – which is so Star Wars seventies retro that I want to rush out and buy a partly cloudy light sabre.
Simon Munro