Enterprise Applications are not yet ‘Born on the Cloud’


The term ‘Born on the cloud’ means that an application or a package was designed and built from the ground up to take advantage of a cloud platform. For instance, those applications that can make use of cloud infrastructure such as auto-scaling, auto node provisioning, automated instance restarts, etc.

The current elephant in the room is that born on the cloud currently implies “build not buy” as there are very few packaged applications that are truly born on the cloud.  "Build not buy" is the direct opposite of many organisation’s IT strategies. This is a problem when you consider the types of non-trivial packaged vertical applications that I am talking about: CRM, order management, billing, finance, HR, etc.  There are also the higher order middleware platforms to consider: ESB, BPM, MDM, etc. The cloud argument might be that an enterprise should be using SaaS versions of those software products.  However not all enterprises are ready, willing or able to move to SaaS.

Why are enterprise applications not born on the cloud?  One reason is because they almost all rely on some traditional middleware such as relational databases and application servers to underpin their capability.  It is this reliance on the traditional underpinnings that reduces an application’s ability to take full advantage of the cloud platform.

In time, middleware will transform to be more cloud aware.  For instance, packaged applications may move away from traditional databases and Java application servers and move more towards standardised platforms as a service such as Bluemix, Cloud Foundry and Azure. This may then allow the applications to be designed to take advantage of the cloud based infrastructure they run on.

Deploying an enterprise application to cloud is certainly feasible today and many organisations do just that.  It is just that the application is not able to take full advantage of the cloud infrastructure.  Rather it is a ‘normal’ deployment with ‘normal’ change management regimes.  Therefore what is the advantage of cloud?

There are advantages. There are the rapid provisioning and pay for for what you use type benefits.  These cloudy features can really really help during development and test phases of a delivery project.  Outsourcing IT infrastructure operations to a cloud provider can also reduce in house run costs and provide operational cost savings.

One other wild card to consider is the impact of container technology such as Docker. If enterprise applications are containerised with all of their dependents included in the deployment package then it may allow the package to take better advantage of the cloud infrastructure. Containerisation of an enterprise application is potentially a large undertaking and so it may be years before we see containers making a difference in this area.

Maybe we will see a new generation of true born on the cloud vertical packages that are built from scratch to run on a cloud platform.  Just as enterprise applications are built to support multiple middleware options from the likes of IBM, Oracle and Microsoft, maybe the enterprise applications in the future will be built to support multiple cloud platform options to allow organisations the choice to deploy the applications either on an internal cloud and an external one.

To summarise, enterprise packaged applications are currently limited in their ability to take advantage of a cloud platform.  When either the middleware is transformed or the package is redesigned around cloud and/or containers then we will see the difference at the enterprise level.  I predict that this transformation will take a number of years.