IT looks like this.  The specifics vary, but the functions are pretty generic.

The issue is one of conflicting priorities between functional groups within IT itself.  Their motivations are different.  For example, when you are talking about things such as improved utilization, consolidation, people scale, etc. you are talking about the wants and direction of the IT Op’s and Infrastructure folks. Their primary motivation is to lower costs and to increase overall efficiency – from a cap-ex and op-ex perspective.  While those goals make sense universally, they are often at direct odds with many Application groups.  The App’s group is chartered with giving the business better deployment times, better code functionality, improved SLA’s, etc.  In order to meet these goals, the LAST thing they want is consolidation or improved utilization.  They want to create even more stove-piped IT infrastructure.  Why?  Because the best way to ensure their objectives are met is to eliminate anyone else from screwing up their stack. Cost is low to non-existent on their priority list.  Time is their enemy.  Anything that makes their delivery slower is BAD.

An imperfect argument certainly, but where it does hold true, it makes it easier to understand that we very much need to learn to speak in a language that takes differing perspectives into account.  No wonder IT is not aligned with the business – it isn’t aligned with itself.

When industry speaks of IT in terms of “the business”, it is speaking of the App groups. The App/Business is where the power and control points are and will continue to be.  By not understanding that, and by not understanding their motivations, both industry and the operations teams themselves do each other a great disservice.  This might explain why infrastructure specialists cling to their hyper-specialized knowledge so tightly – they feel it is job security.  In reality, it creates a greater chasm between organizations, and one that simply can’t (or shouldn’t) end well for those of us who live and love the infrastructure.

Instead, we need to focus on how our specialized knowledge and skills can expose new ways of helping our brethren in the Apps groups to further their own goals and objectives – instead of looking for ways to run around us – or ditch us altogether.  There is a reason why the early corporate adopters of Amazon S3 were all application/coders.  We need to show those groups how the infrastructure services we offer can not only fit their time tables – but can actually accelerate them.  When is the last time someone in infrastructure sat down with their Apps contemporary and explained how to leverage things like snapshot so they could radically decrease the risk associated with Test and Development?

There are huge gains to be had for all concerned when we acknowledge the realities of the way IT really functions – and how it doesn’t.  If we can, we’ll find that we can all be on the same mission after all, and taking a few minutes to look at decisions through the lens of another group can bring us together versus pushing us further apart.