Process, not just product, will save your IT department

Another one for Steve

To repeat his often used mantra RTFM is dead those that do not get it will be also

Last but not least Technology is a verb not a noun ( repeat for security / firewalls ad infinitum )

How many dumb companies have purchased security systems by name instead of what they could ( or could not do.

Cheered on by the sturm and drang IT apocalypse mob

I wouldn't buy a firewall...

... I'll build my own from FOSS. I got skills, baby.

Snooty snobbery aside, if you have to drown your shop in (E)TLA soup to keep it going, you're doing something wrong. Yes, prefab models and methodologies are all the rage these days, but they're like cookie cutters. Useful if you need lots of cookies cut, not so useful if you're a chef and would be far better served with a nice and sharp knife.

Seens to me most enterprise IT is full of cookie cutter users, or at least so would the confident salesmen have you believe, so lusts the pointy hair and so hire the HR drones. Might be at least some of them would be better served with a chef instead.

Personally, I dislike frameworks with a passion. And that's in this as much as in software. There, and I have little reason to believe this'll be different, they're excuses to set up grand schemes full of scaffolding and allusions to universality and such, then fill it in with "useful" code that does things that make sense within the model, but much of that code often enough sees little use and not terribly much debugging. Possibly the warm buzzy feeling of working within a framework is to make up for the overall poor experience and performance, bang per complexity, and so on. In the process field, I need only say "six sigma" and make basically the same point. Mixing and matching smaller "frameworks" to get the same thing is, well, a different approach, I'll give you that. But that doesn't automatically make the whole thing a good idea.

Don't get me wrong: There's nothing inherently faulty about the idea of modelling and framing what you do. It just isn't automatically a good idea to go out and fetch yourself a couple then throw them in the organisation. Modelling is a tool to help you think.

What's happening here, however, is that a few bunches of people thought up a lot of stuff, possibly as a result of years in the field and so on, and are now selling the resulting thick books, reports, consulting services, and so on, and so forth, and are making a pretty penny out of the resulting cookie cutter selling business. And that's fine, of course, it's a free economy. But ask yourself: Does your business really need more cookie cutters?

Compliance, is of no use without accountability. Shirking responsibility seems to be more fashionable in this Oprah winfrey culture.

Frameworks, the alternative to thinking

These models and methodologies are all very well unless you use them; they give a false sense of security as it's too easy to tick all the boxes without fully understanding whether they are relevant to your own organisation.

By all means use them to gen up on the background and give you some general ideas, but if you can't then devise your own plan you shouldn't be in the job.

Of course there's a massive consultancy industry who will disagree (the downvotes from them here could be interesting!) but it doesn't hurt them if it goes wrong - in fact they just dust off another framework and sell that as the next wonder cure.

You've forgotten a 'P'...

All these control frameworks and governance structures are just another product. You can install and misconfigure them just as badly as your off-the-shelf firewall software.

What you're missing here is people. Yes, it's a really uncomfortable idea in PHB-world; that you're not in charge of N number of interchangeable "productivity units" which can be replaced at will, to spec, from a nebulous job market that is in no way full of blaggers, incompetents and even perfectly reasonable IT staff who six months in to the new position decide they'd rather be a lumberjack.

So I've seen companies where they have all of these in place - the CMMI-assessed, ITIL structured framework with rigid transition management, and IT fails because their people go in and wreak havoc in every area they have a password to, and the change management don't have the skills to spot this until systems start falling over. (Which becomes particularly fun when the person who put together the asset directory gathered information in an actively negligent manner, and you discover your business critical system that just went south was on the "doesn't matter, don't backup, rebuild from standard image" list because it was easier to stick it there than fix its persistent backup failure). Ten thousand service health indicators are no good to you if they're all watermelon metrics.

On the other hand I've seen places fly by the seat of their pants and not only get away with it but get amazing results, because they've got the saving grace of a seriously good (and often seriously expensive) head sysadmin who wouldn't give a router password to someone they wouldn't trust with their life. All the ITIL textbooks in the world aren't going to beat the guy who's got a conservatory full of Cisco equipment replicating the core server room infrastructure to run his own penetration tests and experiments against. But you don't get one of those off the shelf.

The ideal, of course, is somewhere in the middle - you need good people within the confines of what you can realistically hire, and a lightweight, lean process that gives you what you need. That requires a very different commitment from the IT manager though - particularly the realisation that management isn't glamourous budget-grabbing, it's furniture-hauling to keep obstructions out the way of everyone doing actual work - and sadly, for every one of us who want to run their departments on common sense and the experience that good people who are invested in their workplace will produce good results, there seem to be about five who'd rather hire cheap with a technical exam of "Q1: Can you breathe unaided? END OF TEST" and spend the savings on an (internal) architecture astronaut.