Business Transformation around cloud

Cloud computing is growing up. While market growth estimates vary, all agree that the only way is up, with annual growth rate estimates well into double figures.

What this means in practice is that cloud is no longer seen purely as a piloting exercise, somewhere to park test and dev because it's cheaper to source servers that way. Rather, cloud computing is seen as a phenomenon that can deliver value to the business.

What's more, events are pushing enterprises inexorably in this direction. This includes the ageing of legacy application developers and the increasing cost of hiring new ones, user expectations to be able to access data from anywhere, any time -- think big trends such as BYOD, remote working and the porous enterprise -- as well as technological and social developments that enable the Web 2.0 trend, such as Ajax, mash-ups, wikis, and social media. The browser is the platform.

However, enterprises have some way to go towards that transformation of legacy to cloud-enabled mission-critical applications, so the question is how they get from the lowlands of siloed applications to the sunny clouded uplands. And what does it mean for legacy applications, and how can they adapt to a cloud-centric world?

To transform to the cloud, business applications need to meet a range of criteria that can best be summarised as inter-connected, agile and available. A key element of this transformation is a shift in development paradigms, away from COBOL and Visual Basic towards service-oriented methods of application development. To that end, CIOs need to start thinking now about how to migrate their workforce in that direction, whether it be special training or changing hiring criteria. There's also a range of vendors providing tools and services to support this shift.

Modern web-based applications look quite different from legacy applications, so a key question is whether you should convert existing applications or start afresh. Many argue that the best way forward is to modernise existing applications, not least because the business case for such applications is well-established, each application is already specified, and much of the back-end code can be re-purposed.

This still does not imply rip and replace: mainframes hung around for decades after many predicted their demise, not least because it was possible to tuck the green screen behind a new graphical front end. Similarly, the process of cloud-enabling legacy applications can entail layering service-oriented architecture on top.

The IEEE defines SOA as "the fundamental organisation of a system embodied by components, their relationships to each other and to the environment and the principles guiding its design and evolution." It is, arguably, as much something you do as something you buy. Effectively, it means using legacy applications' inherent capabilities while adding new connectedness. In some cases, this may be the only way to proceed if the developers of older applications have long since departed, taking knowledge and documentation with them.

In an SOA, applications become components in a system, rather than individual, stand-alone monoliths so, when changing how those legacy applications inter-operate, the next logical step is to think about and plan for the inter-relationships that applications will have with each other, as much as each application's format.

It's been said that the cloud changes everything. Stacked up against some of the hyperbole around cloud computing, the differences between the way that applications operate now and the way that they will need to operate in a cloud-enabled organisation show this to be no exaggeration.