CloudBees sponsored this podcast.
The appeal of DevOps, to a growing number of businesses, comes from a very simple observation: It begins with two business units, and at the end, there appears to emerge one, or something closer to one. This implies a scaling down. And if that’s too harsh a phrase for it, there are plenty of candidate euphemisms vying to substitute.
Kohsuke Kawaguchi is Chief Technology Officer of CloudBees, and the originator of the Jenkins automation platform upon which so many development and operations teams both depend. As Kawaguchi told The New Stack, he’s witnessed numerous examples of organic evolutions of automation, where two teams automated their own processes to the extent that the interactions between them get automated as well. In such a circumstance, he acknowledges, the transactions that take place may only exist today because they existed in the past — because that’s the way these jobs were designed to work, back before they became automated.
“I do also wonder, is that an optimal way to do things?” asked Kawaguchi. “If you did the thinking from scratch, do you do automation along the previous organizational boundaries?”
It was a question for which the CTO himself does not yet have an answer. What he realized he was asking was transformational: If DevOps applied itself to the development, testing and deployment of the transactional pipelines for an original business role, devoted to the creation, maintenance, and quality control of an organization’s entire IT asset pool, then would it effectively invent a completely new role where the roles we’d been calling “Dev” and “Ops” were already fused?
Such a new role would not be encumbered by the corporate hindrances and structural overhead of the 1980s. It wouldn’t have to destroy organizational silos, because they will have never been built. It would be a vision of a new organization, free from all artificial compartmentalization. It would probably require fewer people, if their automation system were implemented properly. And in the absence of pre-existing, “legacy” infrastructure, such a system could conceivably be described as “cloud native” while offending fewer people than are normally riled up whenever that phrase gets appropriated by someone.
“When I see newer teams, I don’t see them dividing up along the lines of Devs and Ops,” acknowledged Kawaguchi. “The way they draw their boundaries are different now. But those people who divide their work differently, they’re all relatively new and they tend to be smaller.”
Enterprises that strive to adhere to compliance regimens and governance structures, the CTO said, end up deploying people in roles along the old guidelines anyway, because those regimens are unlikely to change. They may have to change at some point, and he indicated he’d be very interested in witnessing what emerges from such a cataclysm. But until then, he’s making no predictions.
In this Edition:
10:33: Is Jenkins an evolutionary fork that is for a specific class of user?
14:23: Are you saying there are two types of cultures in an organization, and there needs to be a Jenkins that speaks to that individual style of culture more so than the other?
17:06: Are there particular roles that we should pay attention to first?
20:45: Is there a formula in your mind for bringing all of these Jenkins flavors together to try to get them to bake the same recipe?
26:15: If we’re going to achieve cultural change and DevOps transformation, is there a way of doing that while keeping software developers in the organization?
30:25: How older organizations will need to evolve their business processes and practices in the future