Earlier this month I attended the IBM Impact conference in Las Vegas.  The core theme of Impact was "Smart SOA" and how cloud computing comes together in the enterprise, with the emphasis on private clouds.  The core notion of private clouds for IBM is really about extending their experience in virtualization, which is vast, into the more modern world of cloud computing.  They hope to sell some hardware and software in the process. 

IBM considers private clouds strategic to its platforms.  The movement to private clouds plays right into its hands.  Recently they are announced a new software appliance called IBM WebSphere CloudBurst Appliance which is "A secure appliance that provides speed and repeatability for deploying WebSphere environments into a private cloud."   Or, we can call it virtualization-in-a-box, to be more accurate.

IBM and many others define private clouds as scalable computing resources that exist in the enterprise data center that have been configured by IT to run a virtual machine upon demand. Business users are empowered to select an application (service, data, and processes) and submit it as a virtualized workload to be run in the private cloud.  The WebSphere Appliance stores and secures virtualized images of applications on a piece of IBM xSeries hardware that's ready to be plugged into a private cloud.

What's significant about this offering, and others in the market, is that they make the move to virtualization and private cloud computing much easier than it has been in the past.  These plug-and-play offerings have the potential to allow data centers to move to virtualization, and thus modernize much more rapidly than in the past.  That's the good news.

The bad news is that, in many instances, these drop-in replacement resources are not driven by some sort of architecture.  Once again we are driving the development of IT infrastructure that's more ad-hoc, and thus runs the risk of not being the right fit for the enterprise's requirements.  This problem has plagued data centers for years, and we run the risk of making things worse by pushing the replacement of existing systems under the battle cry of virtualization. 

The way you win this game is to put some architectural forethought into your existing needs and requirements, including the understanding all existing issues.  Then, and only then, define the "to be" state: How will virtualization be leveraged as an architectural component, and what is the right enabling technology, perhaps virtualization-in-a-box, that will be right for the architecture? 

It doesn't matter how easy the technology is to implement, even technology that comes in a ready-to-run box.  As with any approach to computing, virtualization requires us to understand the issues and opportunities before we simply toss technology at the problem.