Through the fog… Management of utility IT

Quocirca's Jon Collins provides some practical advice for those considering one of IT's big questions…

In the early nineties, there was much talk about frameworks for network management, which claimed to be able to monitor and control network elements (routers, hubs and other hardware) from a single point. Various companies had frameworks for sale, including BMC, HP and Sun. Some smaller companies such as Boole and Babbage, Candle and Tivoli were also setting out their stalls.

Memory fails as to exactly when each of these products came to market but the buzz was unforgettable. Buy one of these frameworks, the marketing used to read, and your network management issues will be a thing of the past. Not to mention doing your washing and resolving marital conflicts, no doubt.

Unfortunately, the brave new world promised by the management frameworks never happened. There are a number of reasons for this, not least the ever-increasing complexity and scope of the things to be managed. Network management was never enough, so server management, application management and database management were added to the pool. But even that was not enough and, to add insult to injury, the damned thing to be managed kept changing without leaving the tools any time to keep up. The cheek of it.

Today, the management landscape appears as hyped as ever. We are told that utility computing, the flavour of the month with many vendors, cannot exist without management software, which is being given another shot at the limelight as a result. Today, several companies occupying front line positions of utility computing – BMC, CA, HP, IBM and Sun, for example – include management as an essential element of their solutions.

It's probably best not to get into a discussion about whether or not utility computing is a good model. For now, consider it as the latest incarnation of delivering IT as a service - a few years ago the solution was outsourcing and more recently there were ASPs, both of which were different sides up the same mountain, so to speak. Rather than worrying whether this services 'mountain' is right or wrong (as it happens, we think it's right), let's consider what a management framework needs to be able to deliver if it is to support the utility vision.

For a start, if IT is delivered as a service, then services need to be considered all the way down through the IT stack: applications, databases, computers and connectivity all need to work as a service. Management also needs to be provided all the way down, so that issues with service delivery can be traced to the source and dealt with accordingly. Higher level monitoring and fault resolution need to interoperate with facilities at lower levels. It should be possible, for example, to reallocate server time or storage space without running off to several different consoles in other buildings.

It may never be possible for one company to provide management tools for every situation, therefore it should be possible to incorporate components from several management providers into the same framework.

Of course, different parts of the IT stack may be managed by different departments or even external providers, for example connectivity may be provided by a third party ISP. Therefore there should be interfaces between management applications, for example between enterprise and telecommunications management platforms, to enable monitoring from a single point.

To support the utility vision, this should include support for charging mechanisms, whether services are internally or externally provided – how interesting it would be to see exactly how much a specific service costs, when all of its components are taken into account.

Second, information needs to be delivered at a business level. Database access times, for example, are interesting but a lot less relevant than the speed of delivery of, say, an ecommerce transaction or an inventory check. It should be possible to enable the monitoring of true business processes – 'customer buys a product' would be a good example of a process which is directly impacted by an IT service being delayed or restricted. Therefore, management frameworks need to interface with tools higher up the stack, not least to helpdesk applications, but also to workflow platforms and even business applications such as customer relationship management (CRM) tools.

If information is being delivered upward, you need to consider what information needs to be seen – a jumble of mnemonic-clogged alerts or flashing icons will not mean anything to an application or business manager. Management tools need to deliver information in a way that business users can understand – for example, following the conventions of a corporate service level agreement (SLA). Tools also need to deliver information to other management tools, for example in a web-based form that can be viewed within a portal – this should include both online information and historic reports. Similarly, a framework that offers its own portal interface will be better placed to integrate information from other tools.

Third, a management platform should be proactive, not just reactive. It is useful to have a monitoring station that says when things have gone wrong but it is better to include mechanisms to fix the faults at the same place. Better still is to incorporate a level of intelligence so that problems can be identified before they happen – a simple example is, “Given the speed at which that disk is filling up, it is going to run out of space soon,” and a more complex example is, “The last time we saw this much interest about one of our website special offers, the server crashed, and it looks like the hit rate is going to exceed what we saw last time, so we’d better take steps.”

Once a problem has been identified, its resolution should also be made as simple as possible, for example through automated reallocation of resources or the provision of simulation mechanisms to ensure that a fix will not cause more problems than it solves. Management frameworks need to incorporate policy-based engines that can incorporate pre-defined policies (“No user allowed more than 2GB disk space”) and generated policies (“If network load increases beyond this point, we may have a problem”, or “The number of failed website transactions has become unacceptable”), and there is no reason at all why these cannot be linked to business policies and rules.

Finally, the management framework itself should be cost-effective out of the box. Licensing has long been an issue for management tools, which have priced themselves out of all but the most expensive markets, leaving smaller organisations in the lurch. It should at least be possible for these companies to have some visibility onto the services they are being provided with.

Incorporation of management components that could be used in an on-demand basis would help smaller organisations benefit from better management, as well as enabling companies large and small to operate their IT on a more utility basis. Simply put: “If you don’t need it, don’t use it and don’t pay for it.” Facilities such as auto-discovery are indispensable to enable monitoring to start as soon as possible after installation; provision of management best practices as policy templates would help reduce the learning curve.

It goes without saying that deployment of any management facility should minimise disruption to the services it is designed to oversee: there should be no performance overhead for applications or networking, there should be minimal security implications for the applications being monitored, and of course, the framework’s resilience should exceed that of the infrastructure being managed. Last but not least, a transparent migration path should be offered from other tools.

Sounds great – but does such a framework exist? Not quite. Current platforms tend to remain inside their comfort zone of managing infrastructure, without too much attention to what is happening outside this space. Delivery of business information is possible, and even tested in some cases, but is not yet the norm.

Meanwhile, standards-based integration with the lowest levels of the stack may become possible with the recent, joint announcement of collaboration between the Distributed Management Task Force (think infrastructure) and the TeleManagement Forum (think telecommunications).

Perhaps the last remaining issue is how to get a shared understanding between all parties – the framework software companies, the IT vendors and service providers - about what businesses really need to gain true, service-based management of their IT, to enable it to be delivered as a utility.

Like so many innovations of the 1990s, management frameworks were not wrong but premature. And frankly, they still have a way to go.

**Quocirca is a leading, user-facing analyst house known for its focus on the 'big picture'. For a full summary of its activities see www.quocirca.com, or reach the company's founding directors by emailing quocirca@silicon.com.

Also in this series: Through the fog... How to buy content management software Through the fog... Getting your business processes finely tuned Through the fog... Better connecting users to technologies Through the fog... Better connecting users to technologies Through the fog... Predictive texting Through the fog... Business continuity and disaster recovery Through the Through the fog... Wireless email at work dilemmas Through the fog... Storage as a service Through the fog... Buying an application server Through the fog... Corporate content management Through the fog... Automated speech recognition Through the fog... Public Key Infrastructure Through the fog... Vendor-channel relationships Through the fog... What future photo messaging?

For Quocirca's 'What's the fuss about...?' series for silicon.com, see this page

And for their earlier 'Surviving the Recession' series, see this page.