DevOps, the end of the CIO organization
How agility changes IT Organization
Until now the structure of an IT Organization was clear: On one hand there was a person responsible for the complete application development and on the other hand there was his counterpart for operating those applications and the necessary infrastructure. Both had to report to an IT responsible, the Chief Information Officer (CIO). That is the classical CIO organization of an enterprise and it’s also applied in many mid sized companies. There is a good reason why such a structure became common and proved over the years: this organization has advantages. One of those is the resource utilization: transversal skills and competences need to be retained in development and operations only once. In times of highly specialized business processes and expensive hardware, the resource utilization is optimally guaranteed by using such an organization model.
Nevertheless, it also has a major handicap: the organization is not flexible and agile. What it means is that when a company is selling red shirts and a customer also wants to have blue shirts the organization is flexible when it is able to develop and deliver the blue shirts. When there are no customers anymore for the red and blue shirts because the customers now want to have red pull-overs instead the organization is agile when it is able to quickly change its processes and hardware to develop and deliver red pull-overs. That kind of agility is becoming more and more important with the digital transformation of the economy: common business models become obsolete and are replaced by software and services in the cloud (i.e. selling music CD’s and movie DVD’s versus streaming the songs and the movies or providing computer hardware installation services versus using infrastructure as code in Microsoft Azure).
In an CIO organization, problems with faulty software or operations lead to tremendous increase of communication because they must be reported and clarified over several hierarchical levels until it can be solved. In such processes knowledge over technical and content details is lost. This know-how loss complicates the error analysis and results in systems that do not work and stays in problem state, unnecessarily long.
The organizational structure to solve this problem is simple and named “DevOps”. The basic idea of “DevOps” is a cultural change of the organization focused on the process to deliver value to the customer as often as possible with small changes of software code. Mixed teams of Development and Operations are responsible for certain applications. If there is a problem, the whole mixed team, responsible for the involved feature/issue cares about solving these problems as quickly as possible. The team is also measured against the availability of the solution or service. In “DevOps” organizations there is no more “another department” to which the buck might be passed to.
How DevOps will be applied in practice, I will discuss in a future post.
Finally a hint: “DevOps” is not the final stage. The increasing business alignment of IT, the growing IT skills in specialist departments and the commoditization of the operation make sure that restructurings do not stop at the boundaries of the IT department. “BizDevOps” concepts where business, development and operations work together in software development and operations, are now spread already in startups that rely on the lean startup method. In the future the “BizDevOps” concept will play a greater role than keeping the CIO organization with its boundaries.
I hope you enjoyed the post and please let me know if you already applied DevOps in your company or if you need some help or further information.