Cloud is confusing, period!
· Is SaaS Cloud? Or is it multi-tenancy ASP?
· What’s the difference between Server Virtualization and Private Cloud?
· Where are the standards in the Cloud?
· Is SOA a prerequisite for success in the Cloud?
· Is an ESB required in the Cloud?
· Is the Cloud secure and low risk?
· Will Cloud mean the demise of the IT Department?
Many enterprises are exploring Cloud computing. A select few vendors, such as Amazon and Google, are already delivering serious revenues. Others such as Microsoft, IBM, HP et al view Cloud as central to their long term strategy but are less far along the road. Many smaller enterprises are embracing SaaS, often as business driven initiatives, but may find they are up “dead end street” when they try to integrate with core business applications. Most large enterprises are going slowly down the early learning route with Private and Hybrid Clouds.
It’s clear Cloud is still at the top of the hype curve. There’s huge debate and uncertainty which is inevitable before a new concept stabilizes. One of the primary issues is that Cloud is all inclusive of many existing technologies, including grid, virtualization, automated infrastructure management, ASP etc. So many organizations find it hard to understand what’s on offer.
For large enterprises particularly, the question is highly relevant because they are under pressure to reduce costs and increase time to market, but the security issues surrounding Cloud are self evident. If an enterprise implements VMware-tuned servers with automated, self service provisioning for multiple internal user usage, surely that’s the same as a private Cloud? And the answer is a qualified yes – because even if end users are charged on a pay per use basis, someone has had to make the investment to establish the capability. And the investment costs, as well as the additional capacity to allow for elasticity, have to be shared within the enterprise.
Cloud is clearly a major trend that will eventually have profound implications for IT architecture, economics, organization and markets but its still in a very early stage of evolution. The level of uncertainty is very high, perhaps because it’s becoming clear that Cloud will not be a simple market similar to other utility industries such as electricity. Rather it will be a complex market with many layers and points of entry that mirrors the complexity of the IT product stack.
In this edition of the CBDI Journal (free with registration) we commence with guidance on definitions of the components of the Cloud. Clearly large enterprises will have complex Cloud strategies that comprise a mix of solutions, and a need to sort out the nomenclature, not just of the Cloud, but also of the momentum business which will include many of the Cloud technologies deployed as point solutions.
Then we explore a Business Driven Cloud Strategy - how large enterprises should make explicit links between their Cloud computing strategy and their business goals in order to move beyond the tactical and technology centric activity that is inevitable in early markets. Of course nearly everyone (well in large enterprises anyway) is focused on Cloud as a technology for infrastructure because this represents low hanging fruit. And that’s fair enough because there’s a lot of learning to be done. But we recommend strongly that this needs to be undertaken with an eye to the future roadmap. Just consider at what point did Amazon realize it had a major new business in prospect?
Finally in the third CBDI Journal report this month we push the envelope further on information architecture in context with responsive business processes. Over the years we have published several reports on the intersection of information architecture and business intelligence, and tooling is now available to realize the concepts we have been exploring. We illustrate how business process behaviors can expand beyond the transactional to incorporate rules and automated, real time responses to a wider range of events, rather than after the fact from data warehouse or similar systems. Clearly in order to do this we need to rewrite the book on how we architect data requirements for the business process.