Take a look in the mirror. How would you describe the person staring back at you? Do you see a 'mover and shaker', ready to take your IT strategy by the scruff of the neck, give it a good shake, and re-focus it on the precise business requirements of your organisation? Or do you see a tired, dishevelled IT professional, working 25 hours ( eh? Ed) a day without so much as a thank-you, and never quite managing to meet the exacting targets set by those 'above'? Whatever you see in the mirror, there's a pretty good chance that it's the image you present to the user population as well.
The relationship between IT and 'the business' fascinates me. Consistently, in Xephon's research, IS directors tell us that they are becoming more influential within their companies: more IT chiefs are being appointed to the board, and even those that haven't made it to the top yet are becoming more involved in strategic business decisions. Yet those same CIOs and IT managers say that one of their biggest challenges is keeping up with changing demands within the business. 'It's not so much our influence that has increased,' the CIOs seem to be saying, 'it's our level of accountability. Our company is now working to a 24x7 schedule, and somehow we have to provide IT systems that support these requirements.'
It all comes down to that elusive concept - service. I don't know if you've noticed, but there's a great deal of 'service' around these days. I blame e-business: since the Web explosion, we've been inundated with Internet Service Providers and Application Service Providers (more of which later); Web services are flavour of the month; and vendors now much prefer to sell services to products. Even the good old help desk has been reinvented as the service desk: it somehow conveys a more positive image.
So we're all agreed, then: we're delivering a service. Does that mean we're all part of the same team, with common objectives? Well, yes and no. In most enterprises, IT and the business are still quite separate entities, bound together by that most fragile of documents, the service level agreement. SLAs are great tools for negotiation. The business managers explain what level of service they would like, the IT managers explain calmly that these requirements are out of the question within the confines of the available budget, and eventually - after much hand wringing and soul-searching - the two sides reach a compromise.
That system has worked reasonably well for many years, but is it really acceptable in today's digital economy? If, as a result of the e-business revolution, IT has really moved into the heart of the organisation (as so many pundits claim), can we afford to compromise on business continuity, to let response times slip, to allow security loopholes to go unnoticed, to provide users with anything short of a first-rate support service?
A year or so ago, there seemed to be good reasons for outsourcing many of these thorny service issues. With specialist software houses and consultancies transforming themselves hurriedly into Application Service Providers, there was a strong temptation to pass the responsibility for business-critical e-business systems to a third party. But, while there are still strong arguments for small and medium-sized organisations to opt for ASP services, larger enterprises need to think very carefully before following this route. Recent months have seen a whole host of ASPs and Internet Data Centre companies running into difficulties - Exodus, QSP, USinternetworking, Vistorm, PSINet, and so on. Even the larger outsourcers have experienced unexpectedly tough conditions in the marketplace. Suddenly, the idea of letting those business continuity responsibilities outside the company seems less attractive, even with rigid penalties in place.
So if you can't outsource with confidence, you need to find a way to tie business and IT professionals together with something more substantial than a grudgingly agreed SLA. Both sides need to start with a top-down view of the enterprise, which addresses the real service requirements of the 'always on' business and the availability implications of the whole application process (rather than dwelling on the reliability of individual servers or network components). Both sides need a common understanding of what 'service' really means to the organisation. And both sides should remember to take a long, hard look in the mirror every now and then.