They may not be your customers, but that doesn't mean you should treat them like dirt -- or like idiots, miscreants, dolts, or any other variant of the dreaded "they."
Put it differently: The concept of "internal customer" may not have a place in most modern businesses, but IT shouldn't treat its business collaborators the way Apple treats its actual, external paying customers.
[ Also on InfoWorld: Java security comes down to "war of attrition" | Find out how to block the viruses, worms, and other malware that threaten your business, with hands-on advice from expert contributors in InfoWorld's "Malware Deep Dive" PDF guide. | For more of Bob Lewis' continuing IT management wisdom, check out his Advice Line newsletter. ]
In case you weren't paying attention, last week Apple decided to disable all but the most recent Java browser plug-ins on just about every Macintosh everywhere, without telling anyone. The Java vulnerability that led to the decision is very real. It was coupled, though, with the assumption that its customers -- forgive me, its licensees -- lack the judgment necessary to make this decision for themselves.
To be fair, many of Apple's consumer licensees probably lack the expertise needed to make an informed decision. For many, that's why they bought Macs instead of some form of Windows PC in the first place.
But its enterprise licensees? That's a different matter altogether.
The cost of change by fiat
Let's go back a step. There's this tiresome phrase "best practice" that's been bandied about for the past 10 or 20 years. It should be banned, because while it sounds like it refers to the best way there is to do something, what it usually means is "the minimum standard of basic professionalism."
When it comes to IT, the minimum standard of basic professionalism is that you don't change a production environment without first testing the change to make sure (1) it does what it's supposed to do; and (2) it doesn't break something else that currently works.
Imagine this didn't come from Apple. Imagine the information security department got wind of the Java plug-in's worrisome security holes. (By the way: Codgers who remember, as I do, Java's introduction and the downright gushing plaudits it received for its unbreakable security model -- I hereby give you permission to say, "Pthhhhlpth!" Under Oracle's enlightened product management we're now treated to "hack once, intrude everywhere" security. Brilliant!)
Where was I? Oh, yes -- information security, incensed at Oracle's ongoing unwillingness to fix Java, instructs IT operations to immediately and without warning disable Java in all browsers throughout the enterprise.
What's the proper response? It depends, of course. If information security declares this to be a crisis -- a code-red threat that could sink the company without a trace -- the proper response is to disable Java browser plug-ins everywhere in the enterprise as fast as possible. Afterward, the head of information security should be unceremoniously booted out the door or, better, out an upper-story window or, even better, installed as the head of information security at your fiercest competitor.
Whatever the identified threats, they aren't crisis-level problems, which means IT operations should respond as it does for every other proposed change to production: Prepare an impact analysis. In this case, the impact analysis would reveal whether any business activities would immediately grind to a halt from the change that might cost the company many multiples of any Java-delivered intrusion -- or it might not. That's why change control is what it is.
Apple and the minimum standard of basic professionalism
This is also how Apple should have dealt with the problem: Give its sophisticated enterprise licensees the information they need to understand the threat and deal with it properly, in accordance with their preferred security posture.
Is Apple the only company that releases disruptive patches? Of course not. Microsoft has had its share of disruptive "patch Tuesdays."
But there's a difference. For its enterprise licensees, Microsoft provides lots of information about what's in each patch and delivers them in a form that facilitates internal regression testing, as does every other software vendor that claims to support enterprise customers. Why would they do anything else, and if they did, why would any business license their wares?
Let's make this personal just for a moment. Developers generally detest change control, considering it an annoying bureaucratic aggravation. If you're a developer who shares this attitude: You're supposed to detest it.
Here's how it works: IT operations succeeds by maintaining a stable, unchanging production environment. IT applications succeeds by changing the production environment. Ops and apps are natural enemies, and the change control process is where they meet. If apps likes the change control process, something is seriously wrong. For that matter, if ops likes the change control process, something else is seriously wrong -- it's probably so restrictive that it prevents real progress.
Now you know. And thanks to Apple, now you know what it's like when an entity responsible for keeping things running doesn't respect change control fundamentals -- the minimum standard of basic professionalism.
Last November I pointed out that whether or not Apple is truly an enterprise-ready company depends on more than just product features. I guess not. Based on this fiasco, maybe it's time for Apple to change its slogan from "It just works" to "It just stops."
This story, "Apple's Java sabotage is bad IT business," was originally published at InfoWorld.com. Read more of Bob Lewis' Advice Line blog on InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.