Is It Time For IT Role Reorgs?

When I was hired in to a utility to head an Automated Meter Reading project that was just getting organized – R&D was largely done, but implementation was not started – the team was set up in a rather odd manner. We had our own datacenter, we had our own networking, we had our own well, everything. And that was a conscious choice on the part of management. As it was presented to me, they didn’t want the early phases of the project mired in “we can’t set up load balancing for our app, you have to go talk to the network team” type issues. The long-term plan would make a complete mirror of IT for this project – operations, networking, appdev. Again, as presented to me, the point was to have a group of people completely knowledgeable in the ins-and-outs of the applications and networking (including power line carrier, phone lines, cell towers, and satellite) that tied it all together. The project was huge, and by the time I left for another part of the company, had grown to be the largest I’ve ever been involved in – in terms of staff, dollars, however you want to measure. And my team knew those systems in ways that most IT projects never have to, largely because of the initial design.

Traditionally, the issues that concern network staff are not the issues that keep systems admins up at night. Generally speaking, the application people worry about whatever is bothering these other two groups plus whatever is wrong with the application. In a highly complex environment – like nearly every datacenter is these days – it can be downright painful to track all of the pain points from the moment a user logs in to the culmination of application usage.

The traditional silos – particularly around appdev, whose managers tend to jealously hoard their time as if the next rev of the application is always the most important thing in the future of the company – make it difficult to get a clear view of the application. The ecosystem in which a given application lives is massive. Really very massive. And there are a lot of places where improvements could be made… If the right group is available and that group has statistics on that bit, and, and, and.

So across the board performance reporting is needed. The type that can track how long it took ADS to respond to the login request, and how long it took to get a response from the database, and how responsive overall the application is… How much CPU is being utilized on both the virtual and physical machines, how much disk usage the entire system is overseeing, and if that’s a bottleneck…

We’re getting there. ADCs can manage load across multiple servers and report on responsiveness, VMWare VCenter, for example, can help with system resource usage monitoring from a more holistic point of view, and now F5 products support iApps reporting to get detailed reporting on a wide variety of app and server metrics. No doubt (if they can) our competitors will implement similar functionality. It returns managing an app to being a discussion about the app, rather than a bunch of disjoint discussions about generic resources.

So what’s next? As the title implies, it just might be time to rethink silos. Now some of you will strongly disagree, and I’m good with that – but consider the possibilities along the lines of that AMR project I worked on.

VCenter offers management at the physical machine level, but views into the application (actually the VM) itself. iApps offers management at the network level, but views into the overall impact of the network on a specific applications’ performance. Network hardware still exists and has to be maintained, servers still exist and need to be maintained, but much of that maintenance has been moved into an arena that allows less specialized staff to interface with it. Thus, you will still need a router jockey, but most of your resources could be realigned to focus on the application itself. Call them “Application Management Engineers”, and give them knowledge about the application. This only works well for some big and not-likely-to-go-anywhere applications like Oracle DBMS, or Microsoft Exchange, but that’s a lot of staff time that can be moved over. And conveniently, iApps has customized templates for most of the really big applications out there, from VDI to Exchange to Oracle to Sharepoint. Of course it can work for smaller applications, you’ll just need people to juggle a whole collection of applications at once.

Less hardware management staff and more application management staff. That’s what I’m thinking. Add that to my last post about making developers more involved in operations, and you start to look like a different organization. The focus having been shifted dramatically from hardware bits to overall application health.

These types of shifts always have some issues though – we all know that if you specialize a bunch of people in Sharepoint, then you  lose some synergies with similar networking applications. But then you have a group that does Sharepoint-like applications. Essentially all web based information sharing across the organization. For small orgs this type of organization would not be feasible, but that’s true of today’s organization too – how many  shops don’t have dedicated security or storage staff because they just don’t have the people for it. Then people simply take on multiple responsibilities.

The benefit is a stronger focus on the only thing your users (be they internal or external) care about – the application. Because in the end, it is (or should be) about the apps.