In a great InfoQ talk, John Allspaw (Flickr, Etsy) presents a compelling argument for really aggressively breaking down the barriers between IT development and operations. The talk presents lots of simple examples that anyone who has ever managed development and/or operations can relate to. It also shows great tech leadership attitude, IMO.
One thing that Allspaw mentions off hand is that the organizational scalability of the model is still being proved out. It is ironic that the secret behind manageable massive scalability in some of the largest web sites may be small team size. When the whole tech team consists of 20 people, it is not hard to get them all in a room and develop and maintain a completely shared vision.
There are two questions that I have been thinking about related to this. First, how do you scale it organizationally - i.e., how do you make it work in large organizations with multiple applications? Secondly, while I think the basic principles of DevOps are great, how do you manage the collision with ITIL and other traditional management processes and structures? I find myself more than a little amused by this post that basically points out the lack of any kind of blueprint or methodology worked out beyond "break down the silos" and do the obvious in terms of config management, continuous integration and "infrastructure as software."
The scaling problem here is the same problem faced by "new management" principles such as the transition from bureaucracy to dynamic linking advocated by Steve Denning. Part of what is needed is the management equivalent of inversion of control - some kind of "execution framework" enabling small, collaborating but decentralized teams to achieve their goals without either having a static master plan or detailed knowledge of everything everyone else is doing [1]. The other is a scalable approach to prioritization, planning and performance measurement. Again without a static top-down process, we need a way to develop plans and measures that maintain direct and strong connection between each small team with the end customer and product.
The second question is even harder. Allspaw acknowledges for example that trying to throw out traditional change management altogether is a bad idea, even with the greatest, most well-coordinated team. For some changes, you need to, as he puts it "get out the stack of ITIL books" and follow a more traditional process. The problem here is both what to aim for and how to engineer the transformation, especially when the point of departure is a large group with traditional processes and detached, bureaucratic management.
[1] For another way to see the analogy here, have a look at Robert C Martin's, Dependency Inversion Principle. Look at the small, self-directed teams as the "lower level modules," senior management as "higher level modules" and the "abstractions" as the higher level goals and values of the enterprise.
No comments:
Post a Comment