----
Plan, Build, Run: Please Don't
// Chef Blog
Several months ago, McKinsey & Company released a report entitled "The enterprise IT infrastructure agenda for 2014" which offers strategic advice to CIOs and other IT managers for 2014. In the spirit of having a constructive dialogue, I have to call out some instances of questionable advice in this document that are incompatible with what we at Chef call the "New IT' or the coded business. One line item stands out especially for my approbation: the recommendation that enterprises implement a "plan, build, run" organizational model for their infrastructure departments.
McKinsey's report overall is worth reading, if for nothing else than to understand how businesses view IT departments today, and how that viewpoint is evolving. There are several great recommendations: for example, building industrial-style procurement capabilities to redesign IT around a primarily services & software business. The author writes that "many infrastructure organizations continue to use techniques developed for hardware procurement" to purchase and implement software, even though implementing software (and in many cases, throwing away that which doesn't work) is a far simpler proposition than acquiring hardware that one has to live with for years. And McKinsey is right on the money when they say that enterprises should "[leverage] automation to facilitate DevOps and give developers more control over their applications". I'm glad it's worded that way, too: "automate all the things" is never a useful goal, and I'm happy to see McKinsey nipping this in the bud.
Reading on, though, I came across the section entitled "Improve organizational execution", and I have some concerns about McKinsey's proposed remedies. It's certainly true that organizational execution needs improvement, because IT organizations today are widely seen as being too slow, bureaucratic and inefficient to keep up with business demands. Why, then, does McKinsey advocate a "plan/build/run organizational model" when this kind of silo-ization is what negatively affects the speed of IT service delivery today?
Plan/build/run is fundamentally incompatible with the culture of sharing and joint accountability promulgated by the DevOps movement, where all parties — developers, operations, and yes, even the business — are all accountable to the performance and functionality of software in production. In the worst case, plan/build/run just codifies existing hiearchies that aren't working: architects who deliver pipe dreams from ivory towers, build teams that try to make something tangible out of those plans, and the poor operations folks who end up holding the bag at 3 a.m.
Let me propose an alternate organizational model. How about IT solutions delivery teams embedded directly with business and product lines? These teams would be cross-functional, comprising members from the various disciplines: architecture, operations, development, application administration, and so on. Team members would quickly develop expertise in the business area and its applications, and meet regularly with the business stakeholders.
No longer would architects and product managers from the "plan" organization be the only ones meeting with the business and understanding it. The end state should be that the sysadmin understands the business impacts of the server she/he is managing, and the business owner truly owns the impact of trading pure functional requirements against "non-functionals" like performance or reliability.
I'm calling this new model "BizOps". Maybe it'll stick. Either way, I do believe this: if IT is moving from the back office to the front office, not only will business leaders need to understand more about IT, but IT folks are going to need to learn more about the business, and fast. What better way to do that than to break down the silos by ditching plan/build/run?
----
Shared via my feedly reader
No comments:
Post a Comment