The Great Infrastructure And Operations Divide

What percent of your IT budget do you spend on "keeping the lights on"? If you're anything like a typical company that I work with, the answer is more than half. That doesn't leave much money for spending on new initiatives and projects — in fact, in 2010, the average IT organization spent less than 25% of their IT operating and capital budget in these categories. Most companies that I speak with tell me they wish it was more, but they get constantly caught up in the day-to-day "firefighting" which leaves little time and budget to spend on new innovations, more proactive measures, and new initiatives. And the treadmill just keeps getting faster and faster as more projects are piled on with little or no additional budget to help implement them.

While we can't stop the treadmill, I have seen some organizations slow it down enough to spend more time and money on new initiatives. How, you might be wondering? The key is in the organizational separation of the infrastructure (engineering/design) groups from the operations groups. Traditional infrastructure and operations organizational structures had the design, engineering, operations, and all the support done by the same group of people. Sure, they may be grouped by the supported technology, but often still all sharing the day-to-day operational tasks. Slowly, we are starting to see companies separating the functions by assigning certain resources to operations and others to infrastructure, but the most benefit can be found when the two groups are under separate reporting structures. By taking infrastructure engineering and design resources out of the day-to-day operations, they will have more time to devote to new projects, upgrades, requests for enhancement, and most importantly, innovation. Of course, infrastructure and operations can't each exist on their own; they need to remain tightly linked through governance and service management. 

This trend is not new, but it has been accelerating as IT enters a new industrialized era and as the business becomes more and more reliant on — and demanding of — its supporting infrastructure. Next week, my colleague Glenn O'Donnell and I are leading a track session at Forrester's IT Forum in Las Vegas on this topic as well as on the new skills that are required to survive this evolution. I hope you can join us and join in on the discussion around the IT industrial revolution, the bifurcation of infrastructure and operations, and what impact the cloud and automation will have on our organizations.

Comments

Information Technology

Hello Rachel,

What you're describing in your article is known to most people in IT as "Segregation of Duties" (or Segregation of Responsibilities). Enterprises separate Product Development activities from Product Support activities and put support escalation guidelines in place to only engage Product Development resources, when it's absolutely necessary to do so (i.e. Incident Management Escalation Policies). The thought process is to free up Product Development resource to do what they do best, which is develop new Products, Features and Services so that revenue generation can grow.

The goal, quite simply, is to identify your higher value activities and free them up to perform more higher value work. Most business and IT leaders openly recognize that Product Development activities (i.e. Strategy, Planning, Design & Engineering) are considered to be higher value activities than Product Support activities (i.e. Incident Management, Problem Management). This is not to say that supporting customers is not important. It simply points out the reality that Product Development activities correlate to revenue generation, which is always first and foremost on most leaders' minds. Product Support is considered an "expense" and a consumer of revenue, driving profit margins down.

This is all what I call "Core Activities vs. Chore Activities" (or Core vs. Chore). Core activities generate revenue and raise the ceiling in order to maximize profits. Chore activities drain revenue and are considered "expenses."

If you throw too much into your "expense" side of the equation, you will minimize revenue generation by squashing the activities that are tied to innovation and forward moving.

One of the key and now widely accepted strategies that enterprises use to address the point of your article is "outsourcing." Enterprises segregate Product Development activities from Product Support activities and then do everything they can to outsource Product Support to lower labor cost countries, in order to drive their operational support costs down, freeing up funds to pour back into Product Development (or to raise profit margins).

Thanks for the article.

Frank Guerino
Chairman
The International Foundation for Information Technology (IF4IT)

I agree that the separation

I agree that the separation roles with IT teams can lead to greater efficiency as long as these teams stay tightly linked. As a Senior System Engineer, I've found that even in small teams (less than 10), separation of roles work.

However it requires a change in the mindset of IT managers to make this successful. As the majority of time is spent in maintenance, there's a culture of firefighting which only keeps the team firefighting for longer. Tasks get handed out to anybody because there's rarely a strategy on how to get to a place where more time is spent on innovation and revenue driving activities and less time on 'chore' activities.

A manager needs vision to look past the fires and create a strategy on where the team should be, and how they will get there.

Andrew D

http://frontlineops.net