I'm not much of a fan of this approach. Yes, there's often friction between development and operations, and being part of the same team would undoubtedly improve personal relationships. This approach might incrementally improve the current state by fostering cooperation and less finger-pointing. However, it's not clear that better personal interaction would significantly quicken application functionality release cycles.
In any case, incremental improvement is insufficient. Businesses can't succeed in the future digital business environment they confront with 20 percent faster functionality rollouts. That only trims from 21-day projects down to 18 days or, more commonly, six-month deployments to five months). Todays businesses require 200 percent more speed, if not more.
The culture argument is misdirected, then. It focuses on people, not process - and it's the process that's broken. The faster process, moreover, must extend throughout the application lifecycle.
That said, we've made much progress in software engineering. Development practices, spurred by agile work practices, frequent check-ins and automated build/test via automation, have accelerated dramatically over the past 10 years. This revolution, called "continuous integration," has resulted in faster development, fewer project disasters and better predictability of project process.
For too many IT organizations, however, the rapid pace of the application lifecycle grinds to a halt when it comes time to place new code into production. In the realm of operations, it's all too often a shift back to manual processes performed by multiple, redundant efforts as each downstream group accomplishes its task with its chosen tools.
Until IT organizations achieve continuous deployment, in which code changes move through a fully automated application lifecycle, business requirements in the form of rapid response to unsettled business conditions and frequent functionality rollouts will go unaddressed. Worse still, business units will see all the pride in continuous integration as yet another example of IT self-involvement with little relevance to the needs of the application sponsor.
I've heard many arguments against continuous deployment. They center on the consequence of releasing bad code into production environments and the increased likelihood that bad code will be released if end-to-end automation is implemented. At bottom, this argument is one that asserts that, without human intervention, things are going to go wrong.
In my experience, manual intervention is just as likely to cause problems as to avoid them, so I don't buy the argument. In any case, any justification for lengthy manual processes is going to be overridden by user demands. Clinging to established approaches is going to be fruitless. Just ask the VMware sysadmin who's being bypassed by developers, fed up by the weeks-long request cycle required for in-house resources, who go straight to Amazon Web Services to obtain VMs.
Sign up for CIO Asia eNewsletters.