SJVN is not buying claims that the Microsoft antitrust consent decree has done its job. Of course, that’s his opinion. Personally, I think Vista may do what the consent decree couldn’t… but that’s just me.
VMware’s very own conference, VMworld, is being held this week in San Francisco. And the company has some big news, including an announcement that its VMware ESX Server 3i virtualization software will be embedded in servers from Dell, HP, IBM, NEC, Fujitsu, and other hardware vendors.
But Microsoft is never happy letting someone else get all the attention, so the company has created some news of its own, announcing that it will be previewing its own virtualization technology later this month, when it pushes the first release candidate for Windows Server 2008 out the door.
The Community Technology Preview (CTP) of the virtualization technology, code-named Veridian, is a trimmed-down version of Microsoft’s attempt at keeping up with the VMwares. And it won’t be a real product until at least six months after Windows Server 2008 ships — which, if Microsoft sticks to its latest roadmap, will be in February.
But wait, not enough? Microsoft also announced that the next version of its virtual machine management software, System Center Virtual Machine Manager 2007, will nice with VMware and Xen–when it is released sometime next year. The first beta will be released sometime in the first quarter of 2008.
So, really, there’s not much news there. But it’s the promise of news, and enough to at least momentarily distract some from all the VMware hype in the wake of the company’s IPO.
It seems every time Adobe updates something, it hoses my Mac. The other day, after installing the Flash Player 9 update, Flash ceased to work in any browser. I did uninstalls, re-installs, and all for naught.
Then I remembered what happened after the *last* major Flash update. I loaded up Mac OS X’s disk utility, and sure enough–the disk had become corrupted.
I’m not saying it’s Adobe’s (or the former Macromedia’s) fault that every time I get a Flash update, my hard drive needs to be repaired. I’m just saying it’s a hell of a coincidence.
Everybody in IT has their favorite war story, about that time when they were presented with insurmountable odds, asinine deadlines and insufficient resources, but somehow managed to live to tell the tale—or at least went down with their guns blazing. They’re often told with pride, as well as a little gallows humor; IT professionals, it seems, are happiest when the obstacles are close to insurmountable.
It’s part of our psychological makeup (well, at least mine). I got into information technology for the same reason I think most of us are attracted to it: I like solving problems. There’s an endorphin rush associated with getting a new application to work, troubleshooting a network problem, beating a configuration problem into submission, etc. Sure, there’s the glamor, the big money, and the girls who flock to you when you talk about troubleshooting IP address configurations. But mostly, it’s the buzz from making stuff work.
The bigger the problem, the bigger the buzz. When you’ve had your department taking heroic measures to solve an emergency business requirement, working an all-nighter to beat an impossible deadline that the business side needs to seal that multi-million dollar deal or meet that compliance requirement, development queue and process be damned, the power rush can cloud your ability to reason. You and your team nail it and save the company’s bacon, and prove the value of what you do to the rest of the company.
But what if everything suddenly becomes an emergency?
What if, after seeing that you can pull off miracles without following that precious IT process you’ve created, business managers come to expect you to deliver on every project the same way?
Congratulations, your business execs have become IT co-dependent, and you’re their #1 enabler.
There’s a fine line between being “agile” and being an enabler of a dysfunctional business model. You’re agile if you’ve got a process that incorporates flexibility and plans for “ship early and often” approaches to problem-solving. You’re an enabler if you constantly have to go back and fix implementations you rushed to make business deadlines so that they’ll scale or to integrate them into your architecture so you can support them…or if you don’t have the time to do either of those because of more rapidly emerging business requirements.
In an agile IT organization, IT is engaged with the business side, and watching the road ahead. In a co-dependent company, IT is always heads-down and reactive, trying to sprint to meet emerging requirement because business managers didn’t include IT in the decision-making process. A sure sign that you’re headed toward co-dependency is when decisions about projects that affect the technical aspect of their implementation are made at meetings that don’t have someone from IT at the table–or the IT representative is so junior that he or she ends up being cut out of the conversation.
There’s only one way to break a co-dependency cycle: You’ve got to be assertive. Sometimes it takes more personal courage and leadership to balk at another “Charge of the Light Brigade” style project than it does to get your team to once again jump into the breach. When you finally say “no” (or the moral equivalent of it), be prepared for a lot of screaming.
But it’s better than the alternative. Because eventually, if you’re not taking positive control over the project demands your team is faced with–regardless of whether you’re actually successful at jumping through the hoops that the business side of the company constantly presents you with–you’re going to have to face the fact that you’re not going to be able to sustain the pace much longer. While agile organizations have no problem with retaining good people, the smart people at co-dependent organizations are trying to claw their way out.
And if being assertive isn’t an option, maybe you should start clawing.