Executive Upgrades of the Server Kind

At Gurupalooza, the last day session of IBM Connect where the IBM Champions and Best Practices presenters answer audience questions, my friend Todd asked us something along these lines:

“How do you convince an executive that feature packs must be installed and maintained like formal releases?"

In today’s world, there are no formal releases. Your browsers update automatically, if you let them, your phones update apps automatically, again if you let them. So why should your servers or clients that have helped you to make money and sales likewise not be updated?

A few of us replied with these answers:

• ·         Security, many updates are about security which should not even be a question, especially if you have outside facing servers.
• ·         Compatibility, advances by obvious vendors like Microsoft can cause issues with older code because it cannot understand new drivers or parameters (I’m not a developer so keeping this simple for readers). Even Apple makes choices that can limit functionality for Traveler and device synchronization.
• ·         New functionality, even old dogs can have new tricks although these days evolutionary functionality is more expected. To be fair, non IBM messaging products do not have anything truly new, just different ways of doing the same thing, albeit faster (one hopes).

And these are all good and valid reasons, but for a stubborn executive, or a combatant one against specific companies or products, you need to dig deeper.

My answer was formed from my years of evangelizing the product line and pushing the boundary of what one can say to an executive. I always ask to see their staging and development architecture or environment. This usually creates a long discussion about priorities, resources and good intentions, but also brings the point home. If you want to delay the updates, because of fear of it breaking something, which is a very valid reason, you have no reason NOT to at least have some test environment for the updates.

My friend, and fellow IBM Champion, Bill Malchisky added to this idea by suggesting one look for the feature or function in the updates that best supports the business lines and getting the business lines to do your dirty work in getting the updates pushed through.

If you need an illustration, try referencing an automobile. If they had a service engine light on, they would bring their car in to the dealer. If their headlight died, they would go to Auto Zone or whatever shop, Walmart probably works too, and get a bulb and replace it. Okay, maybe this is too much for an executive who may not even know there are bulbs, but as a parallel reference it works.

The feature packs are that bulb. Safety (security) necessitates your head lights work.

Now ask about changing the oil on the car. The average person has no idea that it does not need to get changed every 3 months, yet that is what the industry started to do because once a year didn’t make them enough money. Anyway, the point is, when you change your oil, and your oil filter and usually the air filter and some other things you are helping your car run better and improve your mileage/gas ratio.

Feature pack 8 works the same way. One nice benefit is you get faster indexing or new enhanced view lookups or as we will see shortly, the index being removed from the NSF itself, optionally, and imagine how much faster your backup could be and your replication once you have these installed. Now to put that in application transactional business benefit, you may be able to do transactions a few seconds faster which makes your customers happier. Every little bit counts.

Like I have been preaching for years, if you did not get any budget for updates or after hours work it is because you never made the proper business case for your Enterprise software. If you treat it, internally, as an expense, rather than an investment with an ROI, you deserve the quagmire you may have fallen into by now.

In two separate conversations with other Business Partners, each were amazed at how many Domino.Doc customers still exist and never went to Lotus Quickr, or anything else. And now they will find it is even more expensive to migrate because at the time it was “just the document management app” instead of the “soul of our organization”.

If you put Domino and your applications up on high, or down low, then your executives will see it as you do. 

Aim high, be proud, be strong....and then present it all as a case study at IBM Connect next year or at a User Group event and be a leader to others.