Bladewatch.com

Rpath

The notion of politics is often discussed with such scorn and indignity that it’s difficult to appreciate that this perfectly imperfect process is fundamental to facilitating decisions, actions and outcomes in any group context.

Compromise is the currency of the political process, and pragmatism is the bridge between often bitterly divided ideologies. What makes politics work is the knowledge that something is better than nothing, and winning the philosophical battle is often losing the war of getting something done.

Of course, we’re seeing this play out on the main stage of the American political process as the President reaches across the aisle to negotiate a stimulus bill. But we can see elements of this everyday in the world of IT.

These were the thoughts running through my mind on a call I had recently with two of the most politically divided factions known to man: Application development and IT operations. I’ve written at length about “the gap between apps and ops,” but I had never really thought about the political aspect of this longstanding IT problem.

It wasn’t much of a stretch to make this connection.

The ops advocate joined the call first, punctual as always. As we made introductions, the apps advocate rolled in — at which point, his ops counterpart hurled the first shot: “Oh, boy. The conversation just swung left.”

At first, I thought we were talking about politics in the capital “P” sort of way — the “third rail” of polite conversation. Of course, we were talking about the politics of IT.

It was clear that the apps and ops guys liked each other and had a mutual respect in the way you appreciate someone’s passion, conviction and thoughtfulness, even if you believe their views lie somewhere between curious and crazy. But beneath the surface, this was two worlds divided — not unlike the politics of the nightly news:

Apps: freewheeling, ideological, collaborative, self-organizing, and organic

Ops: policy-driven, command-and-control, focused on repeatability and efficiency

Of course, one isn’t fundamentally better than the other — both serve a distinct purpose and act as a healthy counterbalance against the other. The reality is that you probably wouldn’t want apps or ops ruling the roost. With apps in control, IT may become untenably expensive and risky. With ops driving the agenda, application innovation may be stifled and business value may be constrained.

But this doesn’t mean that the answer is making the gap between apps and ops the logical equivalent of the halls of Congress (now that’s an unpleasant thought!). The answer is providing each group what they need through policy-based automation, in a way that puts the speed of self-service in the hands of apps, while allowing ops to dictate policies that control how application images are constructed and deployed.

Automation becomes the pragmatic bridge between apps and ops — allowing apps to focus on application innovation and ops to focus on control and cost containment.

It’s the compromise both sides can live with.

It’s the bridge between silos of automation.

It’s the political hand that reaches “across the aisle,” aligning the worlds of apps and ops.

An interesting article with some great points, and in some respects that’s why we have seen more separation of duties, of infrastructure and application which doesn’t always go hand in hand with the technical possibilities. The example being I can deploy VMware tomorrow and have a fully working platform ready for business, but how do I charge out a virtual machine, is it done by usage or capacity, what basic rules should I have in place and who owns what. How in effect do we move the provisioning, support and administration from the olden days concept of a server per business line, per application or role, to a session a workload requirement – I need 300 cpus for 9 hours a day at 95% availability. With those requirements, with business backing and understanding of how we’re going to achieve it, how do we manage the IT aspect of a locked down, supportable platform with the dynamic on demand requirements of the business users. How to merge the application and infrastructure mind sets, is it not a two way thing?

I want my app guys to:

• Abstract themselves from the server
• Understand the server and the application – to know what feeds are needed for it all to work
• Follow the change process and document deployments, improve logging and reslience to failures

At the same time, I need my infrastructure guys to be:

• Business and impact aware – the mindset just reboot it has to go
• To have an application and infrastructure viewpoint of the infrastructure – have you tried…. it could be..
• Follow the change process, but understand how that fits around the business need, I really can’t wait 7 hours for the change guys to come on site and approve a change, if people can’t trade.

I’ve often wondered how things were changed if we moved development, application support into operations? But as we go forward are we not moving the other way anyway? As the IT becomes increasingly integrated to your business, the business want to run IT, to have it deliver with a business centric viewpoint, ‘get on with it’ so to speak, but how do we negotiate this need to deliver with the olden days need to report, to audit and account for, to illustrate that the quickest way might be the most expensive – how short term, how commoditized an infrastructure are we wanting IT to be….

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.