Last fall I wrote about the changing state of the network management marketplace. This summer we did some research to test out a few hypotheses and explore a few others about network ops and the role of networking more broadly. The results confirmed some of my ideas and surprised me in a few ways—addressing areas ranging from application management, to the management of remote locations, to changes in organizational structures, to changes in attitudes and patterns of collaboration.
So, you may ask, what does this specifically have to do with your role as CIO? Well, for this article, I’ve tried to select what I think are things you should care about because the roles, responsibilities and processes within networking are changing in many IT organizations. These changes potentially impact not only the effectiveness of network operations in of itself, but much of the rest of your IT organization. I’ve chosen a handful of examples drawn from interviews and data that you might use as a litmus test but what it comes down to is one question: is your network team a leader, helping to pioneer new types of cross-domain collaboration or is it an “Archie Bunker” hold out—clinging to the past and the notion that the network is a separate fiefdom with castle walls of politics and attitude protecting it from change?
First of all, based not only on our data, but on our active consulting work with IT organizations, “Network Operations” and its various affiliates, engineering, design and capacity planning, or IT infrastructure management isn’t just about managing network devices in most shops. Our respondents (all of whom were affiliated with managing the distributed network infrastructure and the application services it supported) showed quite a range of skill sets. This included 70% of respondents with skills in systems management, 66% with security skills, 63% with strong backgrounds in change and configuration, 55% with storage backgrounds, 54% with application management backgrounds.
Overall, what seems to be going on is a move to manage the distributed infrastructure more holistically in support of the delivery of application services. This may sound cliché, but for years network managers have cared deeply about server performance with a growing attention to application services. What’s new is these trends seem to be accelerating. For instance, 81% of those in network operations feel that they’re responsible for managing critical servers in the data center. And 74% feel they’re responsible for managing some or most systems and other non-network devices in remote locations. Of these, the majority are responsible for the full lifecycle management of these devices, including active configuration!
The story on managing applications is just as interesting. In our survey, we asked our respondents about the veracity of the following statement: “Informal (or formal) teams/meetings emerge to tackle problems regarding networked application service performance. These teams combine network, application database and other data center personnel.” Eighty-two percent said this was either “very true” or “somewhat true.” What might be a shocker is that 46% claimed that network operations led these teams most of the time, while an additional 39% said that network operations led these teams only some of the time.
Taking the Lead
Networking is taking the lead in these triage teams in many IT shops for two fundamental reasons. First, it’s the first place of blame when users can’t access information or application services. And that’s, of course, not new. But what is new or new-ish at least is the second reason—network operations tends to have the best triage tools to see where an application problem lies. In dialog with respondents, or in consulting, these are almost invariably flow-based tools that look at application traffic in terms of volumes, response time and in many cases even transactions. These tools often offer visibility from the application server right down to the receiving desktop. Nearly 70% indicated these triage teams were using these types of common tool sets to validate who owned the problem.