Thanks for the clarifications, I think we just have different SME client experiences
Well, this is why in my original comment I said that I, personally, was reaping the benefits of getting away with bypassing some change management procedures and put a smiley on the end. Just because that setup works for me doesn't mean it works for everyone. I take the time to learn a lot about the business, and have the fortune of being supported by some really plugged in tech weenies on the local sites.
Also to me "Taking the financials server down for an hour at 3am to hump it up a few Windows versions is not a major outage." would be a major outage with one of my client's, as their Financials is a full MRP system and hence is only supported on a restricted suite of platform software.
Well, yes. Each application is different. Which is sort of my point in the whole conversation in both articles and both comment threads. It's also sort of endemic to the discussion about the ease with which a sysadmin can (or can't) bypass change management.
I know my workloads. Inside and out. I've worked with them for over a decade in most cases. So there are lots of them that I can get away with doing "unscheduled" maintenance if I keep that maintenance to the right outage window.
By the same token, there are a bunch where if it's down for more than a minute or two, I will be shot in the streets.
That's the key here though: the diversity of IT workloads. It's why there is no one response that fits. It's why there is no one set of procedures that efficiently encompasses all endeavors and why migrating to Linux in a month is absolutely impossible for the overwhelming majority of workloads. Hell, migrating from Windows to Windows in a month will be a stretch for many workloads.
Despite that, there are a significant number of workloads where simply humping it up a Windows version is no big deal. One of the measures of a sysadmin is to be able to know into which category their individual workloads will fall.
But the main point which I think we agree on, is that you need to have some form of change management process which gives you a framework in which to make such decisions and communicate appropriately, even if at times the only business visible output is a line item on an invoice.
I don't disagree in general, but I think that all change management processes need to be fairly flexible. As workload and maintenance types vary we need the ability to bypass the more bureaucratic and restrictive bits when and where it's sane.
Where I get my panties in a bunch about change management is where organizations go full bureaucrat.
This one time, while consulting (but not at band camp) I was summoned to solve a problem with an application on an end user device. The device was managed by an outsourcing company that was itself managed by another outsourcing company and five layers up with the consulate of a very large and powerful nation. The endpoints were ancient. The printers were ancient. Everything was ancient and everything was locked right the hell down.
I looked at what was asked, looked at the permissions that had been given my user account to accomplish them and realized that it was impossible. So I booted off of my USB key, loaded the registry hive on the endpoint, made the changed by hand and it worked. The consulate staff got on with their day.
I then spend 16 consecutive hours on the phone with different layers of support and management to get official permission to have my user account granted the rights to do what I'd already done so that it can be signed off on and properly accounted for.
I probably violated about a dozen treaties and maybe some laws in doing what I did. I also saved the day. That country's ambassador actually showed up in the consulate while I was busy playing ping-pong for authorization with support and ended up having to make emergency use of the computers to use the very application I had enabled.
I found out later that the result of that conversation was that the country in question extracted some people from a city that was hit by a tsunami and brought them here to Canada. The Ambassador was relaying the results of his negotiations for refugee status for these folks and his aides sent over all the info on where these people were to live.
The reason I had to get the application working was because the new rules said that certain types of official communication couldn't occur without the new communications software installed. The Ambassador (who normally isn't in our city, so it usually doesn't matter if that software works or not) would have been restricted to firing off information via some form of certified snail mail otherwise. That could have slowed the country in question from moving those people, and who knows what that would have meant for them?
It was that incident that made me appreciate the need for flexibility in change management processes. The more rigid and absolute they become the less the serve the needs of the organization implementing them.
Change management needs to be change managed. :)