Quocirca's Straight Talking: Simplify the basics

For the IT department to endear itself to the business, it must demonstrate flexibility and fleetness of foot. But, says Quocirca's Clive Longbottom, it can't do this until it stops being bogged down with routine maintenance and changes to existing systems.

First, a couple of figures, averages of those that are doing the rounds from ourselves and our colleagues in the analyst community: around 70 per cent of corporate spending on IT is used on maintaining existing IT assets and around 80 per cent of problems with existing IT assets are caused by human intervention.

Those of us who work or have worked in IT know we have to change the configuration of assets - whether it be to bring them to the latest level of security patch, to introduce new functionality or to ensure that we maintain a vendor-supportable platform - but how come we seem to get it wrong so often?

Well, it's down to the complexity of what we are dealing with these days. We have an environment where we have evolved from basic server-centric mainframe/mini-computers, through client-server to a complete mish-mash of web-based, thin-client, thick-client, server-centric, client-server applications and services that require an integrated subsystem to just, well, run.

And it's got more difficult for us to understand this environment. We may well know that we have 1,200 servers and that server A is running Windows whereas server B is running Linux. We may even have some means of identifying that server A is running Windows Server 2000 SP4 and that server B is running Novell/SuSE Enterprise Linux.

But do we know this about every one of our 1,200 servers? Do we know the exact patches that have been applied to every one of them? And what about the thousands of desktops we have, the laptops, the switches, the routers? Individual applications and services? It's increasingly unlikely.

The real problems start when we need to look at interdependencies - if we change the underlying operating system platform, how does this impact the application server platform and is there any impact on the application itself? If we change the firmware on this switch, does this have any impact on network traffic originating from a completely different area? If we apply this patch to this desktop, will all the existing device drivers continue to work?

It's hardly surprising that mistakes happen. We generally look at managing this environment through sets of rules, dealing with exceptions as they come along. The problem is that the exception is now the rule and any broad-scale change requires armies of technical staff on hand just to deal with these 'exceptions'. These are dealt with manually - and this further compounds the problem, as we now no longer know the status of all the assets we are looking at.

Failed rollouts not only cost us in time but this lack of complete understanding of what we are then left with means we cannot be sure of layering on the next level of solution. After all, if the platform rollout failed, what's the point of rolling out the solution itself?

Is there a way around this? Quocirca thinks so. We have to utilise tools that enable us to gain information on all our assets, right down to the most granular level - configurations, sub-assets, driver versions, firmware versions, patches already applied and so on. A lot of this information will already be available through existing tools. For example, systems management tools often utilise Management Information Bases (MIBs) to gain some of this information. Many network devices maintain their own log files which will have such information contained within them. And later pieces of kit will have direct capabilities to interrogate the hardware, firmware and software directly.

Trying to pull all of this data together into one place would require the construction of yet another data warehouse - not something we would recommend. But utilising an aggregation engine that knows where the data resides and can gain access to it rapidly is the key to building such a knowledge base of your assets.

We then need to understand the inter-relations between the assets. This is where the real hard work can be involved. As we move more towards solutions than just applications, an action upstream can involve many assets before it has its desired effect. Tools are beginning to be available which can create base topologies for these interdependencies, thus removing a large part of the drudgery involved.

Once we have this knowledge, we can look at what changes we need to apply and what the requirements for those changes are. For example, with a basic level application update, we are looking at questions such as: is the existing operating system on the target device up to running the application'? Is there enough storage available? Is there enough memory available? We also need to look at patch levels, auxiliary devices present, device driver versions and so on. We can then provide a report of which systems can take the update automatically, which ones need to have remote work carried out on them to prepare them for update and which need manual intervention to prepare them.

This activity will also have provided us with a snapshot of each asset's current, working position. Therefore if something should go wrong with the automated update, we can automatically roll back to a known position - so minimising risk to our ongoing business.

Having over two-thirds of our IT budgets blown on maintenance is not a good idea. Spending should be focused on bringing extra value to the company - areas such as mobility, convergent voice/data, service-oriented architectures and grid computing.

It is imperative that we in IT concentrate on making ourselves more effective as an agent of change. After all, when a business is going through massive changes in its market, IT should be able to demonstrate flexibility and fleetness of foot. Being bogged down in managing existing change will not endear IT to the business.

Automating change to an extent where exceptions are true exceptions means we can carry out basic and fundamental changes to the environment with fewer technical staff serving as back up, freeing them to concentrate on technical innovation and support for changes in the business processes.

Change happens - fire-fighting it is costly, error-prone and a damn good way to go out of business. Being pro-active in our approach to change is not an option. It must be an imperative as we look to the future.

Quocirca has written a business paper on the subject, which can be obtained by visiting our website.