Prior to the cloud, application deployment was coordinated by developers and system administrators in data center...
operations. It's from this combination that the term DevOps was created. The cloud has changed all that. Now, applications are increasingly assembled -- not "developed" in the traditional sense -- and the end user plays a much bigger role in deployment and application lifecycle management (ALM). Cloud DevOps success starts with getting the right stakeholders involved from the beginning, coordinating team activities to focus on functional assembly instead of development, and overcoming cultural differences between IT professionals and operations personnel.
From an organizational and business-process perspective, the biggest change created by the cloud is the direct empowerment of line organizations in what have previously been IT-centric processes. Picking an infrastructure as a service provider is a technical problem, but picking a software as a service (SaaS) provider is a business issue. No matter what form cloud services take today, profit and market share pressures will drive them toward a SaaS-like model where end users have a much greater role in selection. They will inevitably have a greater role in deployment and the application lifecycle.
A strong enterprise architect jumping-off point can be valuable here, because currently the major stakeholders in the cloud DevOps future are indirectly identified by the handoff from business processes to IT fulfillment, a handoff that in the future will be increasingly to cloud services. Process definitions at this level have in the past been able to dismiss user input on the pace of application change, or the rate at which new features have to be deployed. This input will now be critical in framing cloud DevOps requirements, so it has to be considered and solicited.
Getting more input from line departments doesn't mean ignoring IT, of course. Cloud projects run by user populism are unlikely to succeed. The line organizations have to be onboard, and so do IT professionals who will help integrate cloud elements with each other and with on-premises applications and tools. These same professionals will have to translate DevOps goals into reality.
When a cloud application deployment team is assembled, one of the first tasks is to establish a functional mission that will overcome the natural bottom-up tactical bias of IT professionals. Focus the team by starting with guidelines on how business processes will dictate application deployment and integration needs. From there, the need to integrate with other applications and databases can be developed traditionally and supported by IT team members.
Even this second level of objectives-gathering can't ignore the business implications. Cloud applications driven directly by line departments change in response to what to IT are external stimuli. Remember that DevOps is classically development-to-operations integration, something IT can plan for because they're initiating it. Early experience with SaaS adoption suggests that companies that adopt a cloud service based on line-department initiatives will probably extend their cloud commitment to adjacent areas fairly quickly and will expect the process of changing adjacent internal applications to be more responsive as well. It's smart to look at all applications touched by a new cloud application and re-examine their DevOps processes.
What to examine DevOps processes for may be the largest change. The "dev" in cloud DevOps is the evolving connection between business processes and IT, the very target of enterprise architecture . Deployment practices for applications are more tied to business processes and goals, so the primary consideration is the functional impacts of deployment, such as availability of features and integration with applications related in a business sense and not in a technical sense.
The latter point raises the most significant point about the team dynamic in cloud DevOps projects. There is nearly always a different viewpoint between IT users and IT professionals. That difference comes down to "what I do versus what it does." Experience shows that cloud DevOps projects often get off on the wrong foot when IT goals take over early and the user input is lost.
Too little IT focus is also a problem. Despite the fact that line organizations are new players in the DevOps game that the cloud is currently changing, it's important not to bend too far. Interestingly, line organizations seem to make more mistakes in DevOps-related activities (including ALM) than they do when they drive development or application selection. Deployment and integration in the cloud is highly technical, and line organizations should not be undertaking it without guidance.
One tip generated by users who have gone through cloud DevOps projects is to employ a light touch on team integration. Leaders of the line and IT groups should meet regularly. There should also be broader team meetings when issues arise, but in general the players on the IT and line sides should interact within the frameworks of specific tasks set by the leadership. Companies report that their efforts are often derailed by personality conflicts among people who barely need to interact but confront each other in poorly organized group meetings. Form sub-teams, set agendas in leadership meetings, and be sure that all group meetings have a clear agenda and a commitment from leadership to stick with the agenda.
Cloud DevOps is in many ways a lead-in to a new relationship between line organizations, IT and enterprise architects. If the experience gained through cloud DevOps is put to good use, it can be used to establish project patterns that will survive as IT becomes more populist over time, as it inevitably will.
IBM adds cloud-based service to DevOps portfolio
DevOps pushes into the cloud
The role of DevOps in the cloud