Tuesday, 28 Apr 2009

Risk analysis

I’ve got a client who needs to get a critical production system upgraded. Frankly, the risks involved — and indeed the plans one prepares — don’t really change from site to site; but each event is still unique and takes careful investigation to make sure you’ve figured out all the interactions you need to look after.

Anyway, one of the pieces of this system is MQ (which, in case you’ve not heard of it, is a very widely adopted — if somewhat cumbersome and archaic [not to mention proprietary and commercial] — enterprise message queue platform; no, you’re not missing much, and yes, there are open source alternatives). So the other day I was quietly investigating the sequence involved in doing an upgrade of an existing MQ installation. Along the way I came across a forum posting by someone asking a similar question to what I had in mind:

Q: Is is possible to move directly from MQ V5.3 to V7.0???

ie, skipping MQ 6.0. A reasonable thing to ask (even if they did overdo the question marks); these things are not always obvious and sometimes you have to go through an intermediate step. An experienced individual quickly replied:

A: Yes.

Which was terrific. An enlightening answer; to the point, authoritative, direct, and concise. Very helpful. Well done, and much appreciated.

I was certainly well satisfied at that point, pleased to be able to benefit from the shared wisdom of the global village. Our erstwhile original poster, however, under the mistaken assumption that the internet is a place where you can go to get people to do your job for you for free, continued on with a degree of persistent sticktoitiveness that one can only admire:

Q: What kind of challenges do we need to face during this process??

The answer wasn’t long coming:

A: Overcoming any fear of reading the documentation.

:)

AfC

overcoming-fear, posted by Andrew Cowie in operations/enterprise at 2009-04-28T02:52:48Z

Friday, 19 Oct 2007

Too much typing

According to the BBC, apparently, some people get stressed by email:

It seems a backlash against the always-on workplace has truly begun.

It’s not too much email. It’s too much typing

I have long observed that people in the Open Source movement spend far too much time conversing with each other by IRC, instant messenger, or on widely subscribed email lists when they could just pick up the phone and actually talk to each other. It certainly wouldn’t take as long as all the line by line writing does.

The thing that’s lacking in point-to-point voice calls, of course, is the shared collaborative nature of online text channels and mailing lists where everyone can observe and jump in if they have something to contribute.

I think what we need, therefore, are standing always-up conference voice bridges to ride over and in parallel with the text channels. This way people could listen in casually and chime in when they have something to say.

This would, admittedly, be an entirely new practice for software developers. But it’s long been the way things are done in the operations world. Air traffic control, space mission control, military combat teams, securities trading, business critical IT changes events — all are run with a voice loop as a crucial and driving element co-ordinating activities and providing the focus for dealing with crisis. There are certainly a number of mannerisms and practises that are required to make it work that people in the business world have long taken for granted (ie if you’re on a conference call, you mute unless you’re talking, that sort of thing), but the etiquette for who is talking and who isn’t is usually pretty clear. We’ve learned how to make text channels effective; we can certainly work it out for voice ones.

Since the first thing we do when running a mission critical change event for a client is put voice loops in place, how to use radio circuits effectively is something I’m used to teaching. I do realize that getting the distributed global IT world to use it effectively would indeed take some doing, but nevertheless, it’s something I think we should pursue.

Here’s hoping for less typing and more communicating.

AfC

typing-stress, posted by Andrew Cowie in operations/enterprise at 2007-10-19T09:07:04Z

Friday, 13 Apr 2007

Get used to thinking for yourself

Bernard Golden writes:

Fifth, open source. This doesn’t mean occasionally considering it. And it definitely doesn’t mean evaluating it by the standards of how you’ve done things with proprietary software … People criticize open source because it doesn’t “deliver business value.” What they typically mean is that they’re used to letting the vendor do their job of deciding what their infrastructure should look like, then providing them a roadmap of their infrastructure development plans, and then pre-integrating the solution with the vendor’s favored software partners. So, naturally, when you look at open source, it fails to do that. No open source vendor is going to do a dog-and-pony show and then build your proof-of-concept [for you] to get you committed to their solution. Instead of asserting that open source doesn’t deliver business value, run an experiment. Find out for yourself what the costs of doing open source are. And besides, as open source economics eats away at the margins of proprietary vendors … they’ll do less of the legwork for you. So get used to thinking for yourself.

I really like this. For all the FOSS cheerleading I do, I don’t normally get embroiled in proprietary vs open source debates, and I hadn’t really thought of the point that Bernard makes here: one of the biggest reasons that people will resist change is because there are many who want their answers handed to them on a silver platter.

AfC

bernard-golden-on-thinking-for-yourself, posted by Andrew Cowie in operations/enterprise at 2007-04-13T12:48:38Z

---