Too many stovepipes

Everyone's a specialist. Network specialists, storage management specialists, application specialists and so on. In large organisations today, no-one has the ability to consider the overall landscape and see the whole of IT as a single entity.

What this means is that while we have nice, well-defined and compartmentalised services, it's bloody difficult to get all these disparate teams to interact in a timely and efficient manner. Not only do teams have their own vocabularies, ways of doing things and performance related targets, but they frequently have a huge incentive to play cross-charging games for anything that's outside their "business as usual" activities.

For example, say you want to grow a production database, as one of the central tables is getting near to full. You can't just log into Oracle and do a quick ALTER TABLESPACE to add a few more gigabytes. Oh no. You have to submit a change request that needs sign off from the database team (not unreasonable), the operating systems people (as it's running on their platform), apps support (the database hosts their product), storage management (for the disk space), the backup guys (to ensure the new files get backed up), the network team (for networked storage), plus DR, maybe finance and then negotiate to test the change and then schedule a time when it can be promoted to the live environment. So a 1 minute fix involves approvals from, explanations to, decisions by and responsibility shared across 7, 8 or more teams - all of whom have a vested interest in preserving the status-quo and refusing to allow the change as it's not in their interests (and besides, you haven't got a cost code for the thousands of pounds at the internal charge rate that all these meetings, testing and sign-offs will require).

So, we have got away from the days where an enterprise had a single mainframe, that required 4 teams of 4 people each, running 24*7 shifts just to keep it up and running - plus more people to apply patches and ZAPs, and more to write, support, document, maintain, test, QA (ooops - missed that from the list above) and manage the O/S, database and applications. However, we've replaced this huge body of people with another even less flexible setup: all in the name of structure, ITIL, best practices and "cost saving". And if the whole mess is outsourced, it's even worse. While the management consuiltants reckon that all this is necessary for best practice, running "software as a service", having a "correctly architected" solution and every other Dilbert-esque buzz-phrase under the sun, it does nothing to help reduce costs, improve quality or simply to GET THINGS DONE. Maybe we need fewer Service Managers, who all think that their opinions count. A few less reviews meetings and control points and many less consultancies promoting their over-prices wares as "best practice" and a lot more JFDI by skilled individuals who know what needs to be done and can just get on and do it.

Now, what was the question again?

@'Too many stovepipes'

Don't blame IT. Blame business and law. All this is very predictable.

IT can sometimes be accused of being an immature industry that sometimes skimps on best practice. Now the industry is more professional, people complain.

As systems increase in complexity, the end user (i.e. business) becomes less tolerant of problems and more insistent on tracking and documentation. Result : IT provides what's required, with the resultant increase in costs and slowdown in implementation time.

This is fundamentally about trust and everyone playing fair. If IT accepts that the requirements of the end user are basically sound (albeit possibly needing some refinement due to implementation details) and the end user accepts that IT's timescales and requirements are mostly accurate, things can be implemented somewhat faster and without acres of documentation.

Sadly, and to be rather blunt, this falls down when fuckwits are encountered. Because said fuckwits either won't accept their own responsibilities or mistakes or acknowledge that the price of IT taking care of end user fuckups is the occasional bit of leeway with IT, the management systems get put in place. This is then followed by The Fuckwits asking why things now take longer and cost more.. (the flipside is incompetent IT, where business forces monitoring on them).

Of course, some management systems are absolutely required, but there is a limit to what is actually necessary.

No such thing as a 'one minute fix'

@Pete2 as it should be, unless you're running a shop full of cowboys. There's no such thing as a 'one minute fix' when supporting production systems and environments. Whatever you change will always impact other teams, and because they're (presumably) more knowledgeable in their sphere that you are, they need to be allowed to provide an impact. In most cases that impact will be 'no problem' but when it is a problem, isn't it better to have caught it now, rather than suddenly finding your backups are failing because extending that tablespace meant it no longer fits onto one tape, or there was a staging area that also needed expanding that you weren't aware of...

@Old Geezer

> How is it in anyone's interest in IT to maintain the status quo?

That is a very good question. It probably won't come as a complete shock that a lot of employees don't have their employers best interests at heart.

Some like to stay within their comfort zone - not having to learn new things, but just repeating their past experience, year after year after year.

Others don't want to be disturbed by inconvenient job requests, while they're spending their days surfing

A few like the feeling of power they get from being passive-aggressive and telling requesters how hard their request will be, how it's much more complicated than they thought, how it will take forever to do and cost so much more and even how it's not (really) the right solution anyway.

Quite a lot don't actually have very much work to do, so will drag out a job for as long as possible. if that means spending days attending meetings, rather than being productive - so much the better.

There are even one or two who are simply indolent. They'll come up with reasons why they have not done your job, why they are thwarted at every turn, how they want to help but are not getting vital information from others, how "the process" means they have to do things in the least efficient way possible and how it would be folly to make a start without considering all possible situations that could arise: no matter how ludicrous or unlikely.

To all these people, ITSM is a godsend. It hands them, on a plate, as many reasons for not working, delivering or innovating as anyone could hope for. These individuals have made a life's work of hiding behind processes, making up ridiculous resourcing demands, delaying, prevaricating and inhibiting every decision at every turn and finding ways to pad out their working life with as many make-work and non-tasks as humanly possible - while not actually ever achieving anything useful.

All I can say is that if a garage was run the same way, with all the overheads, meetings, sign-offs, buy-ins and reviews that some large organisations approach their IT processes, it would be quicker, cheaper and more reliable to buy a new car than to take it in to have a headlight replaced.