Unfortunately for enterprise IT, the fact is that most employees (and their workstations, phones, and all the associated local infrastructure) work in one form or another of branch office. That is, they are remote from central data centers, applications, and IT staff. Some enterprises address this by stripping the branch down to bare essentials - Ethernet and thin clients. For the rest, this dispersal of the enterprise, coupled with the continued increase both in the importance of IT services to daily operations and in the complexity of the IT infrastructure, makes it increasingly important to have clear visibility into what is going on inside branches as well as inside the data centers in order to manage the delivery of baseline IT services.

In addressing problems in branch offices, most IT shops participating in Nemertes’ service delivery and management research even now often fall back on the familiar triple-play: use simple up/down monitoring; respond to reports of trouble; and use basic tools like Web GUIs for specific pieces of hardware, or telnet, VNC, or Windows remote desktop access to reach into remote sites. They often layer on tools aimed at monitoring the data center and managing the core network; only occasionally do they add tools aimed outwards at their branches.

These IT shops also know that this approach is now insufficient (or soon will be); they want better, less staff-intensive, more proactive solutions. They also know that continuing to add point-products to address various subsets of their management issues has a limit, as it creates its own complexities.

However, when we asked IT executives in the ongoing Service Delivery and Management benchmark about whether they used a management framework package - a manager-of-managers - more than 60% said "No."

The reasons for the "no" varied, of course, but centered on two factors: cost and complexity.

Many, especially in smaller shops, cited the inability to dedicate human resources to untangling the frameworks as an insurmountable problem. Their understanding of the need to do so was in many cases rooted in an earlier, failed attempt to deploy such a tool. Managing across a complex, multibranch infrastructure was sometimes an issue, but often enough deploying at the center was so difficult that they never got to deploying across their WANs before efforts were abandoned.

So too with paying for the needed software - assuming that “the needed software” could even be defined prior to purchase. Ponying up enough to do everything they wanted to do in order to get a “single pane of glass” for monitoring and managing their infrastructures turned out to be, again, an insurmountable problem for many. Even some people who did stick with their deployments rather than abandoning them (or deciding not to even start) bemoaned the subsequent nickel-and-diming. They spent and spent again adding the modules required to achieve the function they had understood to be part of the initially purchased products.

Just as interesting as the number of, and reasons for, enterprises saying “no” to frameworks, is the fact that among the "yes" organizations, the norm was to have more than one framework on hand - CA and OpenView, for example - with none clearly the primary.

So though enterprises still yearn for that single pane of glass that will show them their dispersed infrastructure’s current state and status, for both center and branches, they either are not looking to traditional management frameworks to fill that need, or, having gone that way, have arrived at only partial solutions.