Doing the right thing

Turns out that Michelin, despite screwing the pooch at the USGP, eventually was compelled to do the right thing by refunding ticket prices paid by attendees. In addition, they agreed to purchase 20,000 tickets for fans to next year's USGP (if in fact there is one).

• Many good and juicy soap-operaesque links at the Planet-F1 site for those who may be interested in a motorsport that doesn't involve amateurs and hillbillies fighting amongst one another.

Having paid to attend a USGP, and hearing that attendance was roughly 140,000 people, I derived that Michelin just wrote a $20 million check. That is impressive. To put this in perspective, that's basically the entire budget for a competitive two-car team for one year in the NASCAR Nextel Cup series. Ouch.

I formally recant my desire for everyone to boycott Michelin tires. Whether or not you patronize Michelin based on their complete and total failure to prepare for a single turn on a 100 year old racing circuit is still your decision. I still won't.

Lots of companies (and people) are provided opportunities to shine, and fail to make the most of them. It's a shame that when someone or some organization does what it should, by rights, that it is 'remarkable' at all. America's expectations of companies, ourselves, and each other have often times become so low, it's outright insulting at best and racist/prejudiced at worst.

Maybe this is why it seems hard for my wife and I to find life-long friends. Our expectations of others are usually no less than those we hold of ourselves. This isn't out of arrogance, it's out of respect. I would not dare assume that anyone else in my neighborhood is any less capable of living their lives to a high standard than are we. Yet time and time again, we are disappointed - by parents who allow children to behave violently and disrespectfully toward others. By adults who have no concern or respect for anyone but themselves. By people who do not consider the consequences of their actions. By people who only half-heartedly believe in personal accountability. By entrepreneurs who openly struggle to manage their businesses, ask for help, then do whatever they damn well please anyway. By people who take friendships for granted, and who assume that friendship implies complete acceptance of their lifestyle choices.

Makes it really hard sometimes...

Work in progress

Found that there is some sparse work in progress by some of those on the ZEN team on the book targeted for IT management regarding use of their product to streamline processes and develop efficiencies.

I think I know how they feel - there's a book that should be written, and they know what should be in it. Find the time to organize it and make it coherent...right. I posted a comment on their blog indicating I'd be very happy to assist if possible. It's been a couple of weeks since they posted on that blog, so who knows how much traction it will get.


For not going out of my way to watch women's sports, I'm seeing a whole lot of them. The Women's US Open was pretty compelling stuff until Sunday, and even then, still fun to watch. I'm also seeing more and more female racing drivers. How cool! Sure seems like half of the female tennis players at Wimbledon have names ending in "kova", but some of them can flat hit the ball. There's some good stories there - especially in racing. I hope they can get some more visibility.

Some days...

Had to let a fairly new HelpDesk technician go today, amid numerous accounts of smarmy, arrogant comments and attitudes, breach of procedure, unprofessionalism, and a cloud of doubt surrounding some missing equipment.

He interviewed very well, seemed more than capable of handling the pressure and demands of the position...pretty sad stuff.

Each failure provides a lesson to be learned. I guess this is why most companies aren't interested in bringing in outside individuals for management positions until they've become "seasoned". Each time we have to cycle someone through our HelpDesk, we're able to learn which traits perceivable in an interview are good, and which ones are not. He had us all fooled though, which makes me at least feel a bit better.

Now we get to see whether or not IBM's anti-theft mechanisms really work. This should be fun.


On another note, it seems that Novell was able to fix the issue with their ZSM product by changing two binaries. It took developers around a week to correct, test, and release the update to us. It was not our fault at all, it was genuinely broken for over 6 years. This was just something that should have been tested and wasn't...and apparently, we're the first Novell customer to ever press them on it. Sweet redepmtion!

Sender Policy Framework

Got turned on to an IETF draft standard that, hopefully, will not only eliminate some spoofed e-mail traffic on the web, but allow our outgoing mail to be accepted more readily.

The draft is entitled "Sender Policy Framework", and allows mail servers a way to check whether or not incoming e-mail originated from the server(s) authorized to send mail for that domain.

It's pretty simple to do with your DNS registrar...if it helps, I can't see a downside to doing it. Those with nothing to hide, hide nothing - right?

By the way, I've never mentioned it, but Postini is godsend to anyone who handles internet e-mail. There are folks who argue that appliances & software in their data center is the way to go - these people must have more money and bandwidth than they need.

Do the math - outsource it!

To-Do List: "Write a book"

In reading another blog operated by someone close to the ZENworks product at Novell, I found a very short but interesting entry.

In short, this individual was musing about the fact that a book entitled "How ZENworks Saved My Life" could have a very real market. This person and another colleague were agreeing that a book designed for management moreso than the rank-and-file IT staff, that outlines what a sound desktop management and/or standardization strategy can do for your bottom line, would help eliminate a substantial sales barrier.

I agree. For a long time, I've argued that the net result of Novell's marketing efforts could be captured in the phrase "all the wrong people get it".

There are lots of good technical guides on the product, but the 1's and 0's are only about 25% of the picture in my estimation. Having been at a number of organizations that shaped their policies and processes around use of a management suite such as ZENworks, this book seemed to write itself in my mind. The rest would be Mozartian "scribbling and bibbling" so to speak.

He said 'one day it might get written'. Hate to seem as if I'm about to plagurize an idea, but I had actually started writing such a book about 4 years ago and was stopped by a career. I think my title was something along the lines of "ZEN Nuddhism" - I was younger then. Perhaps I'll be the one who writes it, or at least one who contributes largely to it.

I think such a book should be required reading for IT managers, CIO's, CFO's, etc. It really is hard sometimes to make the connections between standardization and return on investment if you've never seen it happen. I'm continually surprised at how many IT shops are still doing things the hard way. If management realized how much time and money are being wasted by IT staff working hard instead of working smart, they'd likely suffer an involuntary bodily reaction of some kind.

I'm not advocating that costs be cut and people be fired - I'm advocating that spending on IT be made and measured at a level that can actually generate a return, not simply considered a recurring expense. Not every IT manager knows how to convey this story, but any IT manager (or CIO for that matter) worth their salt will know that selling it to their organization is mandatory if they are ever to reach the next level.

Too many resources

You know a company has too many resources when they develop an entire suite of products from scratch, aimed at 2% of the corporate IT market.

IBM's ThinkVantage Tools are, largely, very well written and certainly add value over the Dell garbage we had been buying until recently. For notebooks, it doesn't get much better than IBM Access Connections. This is a great technology that simplifies IP and wireless connectivity to an "Even-the-CEO-can-do-it" level. The Rescue and Recovery tools are very well done, easy to use, and actually could serve to get a PC back up in the event Windows will not start. Kudos to IBM for this.

However...

IBM is going to market - not aggressively mind you - with some rather half baked tools that offer similarly-intended functionality to products such as ZEN and Altiris. The development of Image Ultra Builder, as well as their "app distribution" and "asset management" tools, indicates to me that IBM may have too much time on their hands.

As a consultant, I've seen plenty of different organizations. I can't think of a single one that would select the IBM TVT suite for managing images or application distribution.

Why not? Because they aren't free. If you have to pay for something, you might as well get what you want. Be it Altiris, SMS, ZENworks, etc - there are a number of commercial products that do exceptionally good jobs of delivering applications, managing images, and capturing inventory.

Granted, the market for these utilities should be quite large... but faced with the mature offerings already available... I just... if you can't do it better than the other guys... seriously, why bother?

I wish I had IBM's problems.

"Significant Architectural Change"

Well, after having been host to a Novell employee for two days (actually very long nights, fortunately not for me), we've confirmed what we have believed all along. Our issues with the ZENworks for Servers product surrounding the Monitoring components have been attributed to a long-standing defect (the code was dated 1999) which had never been addressed.

The situation is basically that, when using the IP Ping agent to monitor devices, ZSM is very erratic and unreliable at reporting when services are actually up or down. You can generate hundreds of false alerts over a very short timespan, and the problem is easy to reproduce.

The source of the problem is quite laughable. Those who know ManageWise know that it was written and sold long before TCP/IP came into prevalence within corporate LAN's. The TCP/IP Ping monitoring component, again last updated in 1999, sends pings out in some type of sequence, and - get THIS - expects to receive them back in exactly the same sequence. If they come back out of order - something OTHER than first-out-first-in - viola! False alert!

I wish I was kidding.

It makes sense, sort of, that this problem would have existed. IPX was rarely ever routed across WAN links. Usually, only big IT shops had something like ManageWise in place. They usually only wanted to monitor local services - in fact, in some cases, they only could manage local services. Really big IT shops had network groups that used OpenManage or something along those lines. Using it to monitor a large WAN with slow links was just never considered.

What doesn't make sense is that the feature remained in the product all this time, and that the problem was never again tested for or uncovered.

The solution, as the title of this post implies, requires a "significant architectural change". Which is to say you evaluate each ICMP reply based on it's merits, not the order in which it arrived back at the server (why would this concept be so foreign?).

A number of software developers in Bangalore will be working to correct the problem over the next few days - hopefully it'll bear fruit and we will have again facilitated a fix to the ZSM product that nobody else ever found or yelled about loudly enough.

Why hasn't this problem been found in 6 years? Based on what we know, there are but a few rational explanations for the situation as it had evolved:

• Hardly anyone else is using the product - or this portion of it - in production.
• Those that are, might be in single-campus environments where all of the remote links are high-speed.
• Others have tried to use it, unsuccessfully, and gave up - perhaps citing excessive difficulty in it's configuration or faulting their own abilities.
• Still others may have found the problem, opened incidents, and got nowhere - again, disheartened, they punted in favor of another solution.
• Nobody tested this in a real-world network (we are also solely responsible for the "Unnumbered Links" fix that is now in ZSM).
• Novell very plainly does not eat their own dog food, despite any claims to the contrary you may hear.

Ask someone at Novell's IS&T if they ever clustered GroupWise on NetWare prior to OES. Ask them if they use ZSM to monitor & manage their network. You'll be surprised how little of what you buy is actually used by the people who make it. That's not the way I would run a business, but hey, that's just me.

It's not unreasonable for us to feel like we're beta-testing product when we uncover problems like this. Again, if technology companies develop for worst possible case - which is honestly not that much harder to test around - they are able to accommodate any case. Heaven forbid anyone spends some additional time to get something right.

Apologies in advance to whomever coded this thing way back when, but everyone responsible for this oversight between 1999 and mid-year 2005 should be blackballed from ever developing, testing, or managing a software product ever again. This is just so simple and obvious to anyone using the product, that it's oversight is paramount to wanton neglect.

Boycott Michelin!

I just witnessed the travesty that was the United States Grand Prix at Indianapolis, and I can only say that I'm very glad I wasn't able to go this year.

I had attended the 2000 and 2001 GP's, and found them to be amazing spectacles of engineering and driver talent. Nobody who knows what it takes to put a competitive F1 car on the grid would ever claim that it's not the pre-eminent form of motor sport in the world. These machines are magnificent works of engineering art. If you're a techie and you like racing, F1 is for you.

What happened today will be spun and politicized by all sorts of people, but the bottom line is this. The idiots at Michelin got it all wrong. They owe everyone with a ticket to the race a complete refund of their money and travel expenses.

Figure 140,000 people at around $500 a piece to lodge and buy a ticket to the event...I think it'd have been much cheaper for them to have brought a tire to the race that could handle a 6 degree bank at 185 MPH, even if it was a little slower than the Bridgestones. No, they realized that there was no chance they could win, so they all quit. Like a bunch of spoiled 3-year-old's. Tres' French.

Since you will probably never see a refund check from Michelin, the best you can do is to never buy a Michelin product of any kind ever again. This shouldn't be asking too much. First of all, the company is French...enough said. Second of all, if they can't be trusted to make a tire that can last 350km while spending probably a grand total of two minutes during the race on a simple 6 degree banking at speed, I'm not sure we should trust them to make the tires on our family's cars that will go 30,000 - 50,000km.

Bridgestone got it right - their tires performed very well, and would have lasted 100 laps (the race was 73 in total). Amazing that Bridgestone (who owns Firestone) has the "reliable" tire, and Michelin suddenly is scared of their own shadow.

Buy Bridgestone. Buy Firestone. Even if you hate the commercials (I know I'm sick of them by now). Send a message with your checkbook.

I just hope F1 will be welcome in America again - it sure seems that quite a few people have tried very hard to ruin it for us.

A note on Gordon Ramsay...

Incidentally, every manager who struggles with getting more out of his or her people and has had no success with using "the carrot" may want to see how effective a motivator "the whip" can be by observing the aforementioned Gordon Ramsay at work on BBC America or Fox's "Hell's Kitchen".

His affinity for swearing aside, he demonstrates that passion about one's work and a refusal to accept anything less than perfection can effectively lead as an example that people of substance will follow.

The challenge is to get people to go beyond the boundaries they've set for their own capabilities - so few people set limits for themselves that allow them to truly shine. Ramsay is adept at getting people to shatter their illusions of their own limits and capabilities, even if his methods are found to be questionable. You can't argue with results. This guy was England's "Chef of the Year" for 9 years running. If you know how hard it is to get three Michelin stars, you understand how good he is at what he does.

Being the Squeaky Wheel

After having an issue with a ZEN product open with Novell Support for over 6 months, we're finally getting some real attention to our problem. The issue relates to the ZENworks Server Management product - specifically, the Ping agent that lets you know when servers / services are up or down. It's acted flaky for over two years, across three versions of product, two hardware platforms, and two versions of NetWare OS.

A bona-fide Provo resident will be here to ensure that neither we nor Novell Support have missed anything, and will climb on the phone with developers in Bangalore, India to figure out what the heck is going on here.

It's good when you can get that kind of attention, but it's bad when you need it. I wonder how many other IT managers feel like they're unwitting Beta-testers for software they've purchased. We feel that way a lot - with all sorts of products. It's one thing for a vendor to tell us "You did it all wrong." We hardly ever hear that. We always hear "You have it right, it should be working." Yet it takes months sometimes to figure out what is broken or why.

I don't know how software with such easy to find deficiencies ever makes it out the door of these companies. My favorite chef, Gordon Ramsay, likes to say "Keep your mistakes in the kitchen." The ability to do that implies that someone - who knows what they're looking at - is actually reviewing every aspect of the product. Just like a chef would.

I'd rather get served a great meal 30 minutes late than to have utter garbage put before me on-time. The mentality that says "meet your dates at all costs, and fix it in a Service Pack" is nonsense.

The mentality should be "get it right the first time, at all costs". 99% of the time, schedules and deadlines are artificial creations in the software development business. Many products are so complex that facilitating a 3-month development and release cycle does nothing but dilute the quality of the product. It's the IP networking equivalent of using a very small MTU setting on a robust backbone. Projects, like ethernet packets, have a minimum overhead. The more payload you deliver under that overhead, the more efficient the mechanism becomes. I'd love to see development and release cycles move to 6 months - especially at Novell.

Hello, world.

So I finally decided to do the Blog thing. Why, you ask, bother? Well, I was inspired. In a recent ComputerWorld article (May 30, 2005 - Vol 39 No. 22), Patrick Thibodeau quoted a Sun Microsystems executive as saying (about Blogs by CIO's)...

"If a few of those guys started [Blogging], you can darn well bet that we would be reading them. I sure would."

What this disconnected Sun executive doesn't realize is that not a lot of CIO's have the time, aptitude, or inclination to Blog. It's unfortunate, but true. They'll come along eventually.

However, CIO's are also usually very seasoned (at companies the size of those Sun is interested in), meaning the whole concept is a little foreign and possibly uncomfortable. The next best things to CIO blogs are the blogs of the people reporting to those guys.

That's where I come in.

I have assumed the moniker of ZEN Master, after having the title jokingly or lovingly bestowed upon me by coworkers at Novell Consulting. I am not the only ZEN Master any more than Phil Jackson would be, but I wear the title with pride. ZEN, for those who don't know, is a (brilliant) suite of products that - properly implemented - dramatically improve the ability of IT groups to serve and support their customers.

I've not worked for Novell for a number of years, but my career has been closely tied to the company and it's products for over a decade. I'm not a Novell bigot - in fact, I'm usually one of the first people to tell you where Novell's got it wrong and what I think they should do about it. Rather, I'm a fan of what works best. It just so happens that, in a number of cases, what works best are Novell products (although the instances of this being the case are dwindling).

The company I work for does about $1.2 - $1.5 billion in total revenue each year. It has offices in nearly 100 locations throughout the southwest, south, and east coast. All of the IT functions are centralized - there is no IT presence in any office outside the Headquarters. In many ways, we represent "worst possible case" for our vendors.

The upside is that this IT staff is good. Far above average. I should know, I've been around a bit. We regularly push the limits of every product we touch.

In short, if it works well here, it will work well anywhere. If it has a weakness, we'll find it.

For quite a while, my wish is that IT vendors would plan around environments like ours instead of the pristine, blue-sky lab environments that are so delicately crafted and maintained. There are probably 10,000 A+ certified techies that could build a Novell "Super-Lab" like environment to stress test networks and applications. Sure it wouldn't have the bells and whistles, but the point is this - figuring out how to provide services to a single campus or multi-campus enterprise is a walk in the park. Figure out how to make a product work well in an environment with as many variables as ours, and your product will work well anywhere.

The most annoying thing we find is that, most of the time, if a product doesn't work here, it's because the vendor has spent too much time focusing on all the wrong things. Usually it's something like a vendor who decided to include configuration options that look and sound neat, but are thusly architected in such a way that they cannot be implemented without additional hardware.

Try to deploy Patchlink in a 100-site WAN without implementing a new server or internet caching appliance at each and tell me how you fare. So much for increasing ROI, improving simplicity, reducing maintenance, etc. You're hopping out of the frying pan and into the fire.

Apologies to Dell, IBM, HP, Compaq, etc...your business model shouldn't depend on the endless proliferation of crappy software. I think if software vendors spent more time figuring out how to architect their products so that they did not require more hardware, the world of IT Managers and vendors alike would be a happier place to live and do business.