Back in the mid to late 1970s the battle for control of corporate IT was in full swing. One side, the corporate data processing group in Finance, maintained an almost absolute ideological purity with deep commitments to one vendor and the One Right Way while, on the other, line managers all over the businesses involved were deploying application appliances in everything from word processing to production planning and shop floor management.
By the early eighties data processing had won most of the battles on the strengths of a single argument: that efficient use of corporate resources required a single corporate systems architecture - which only they were in a position to design and implement. Suddenly people were doing production planning in batch mode on MVS, IBM was selling a lot more gear, and machines from companies like Harris, Gould, Wang, and Data General were being moved out.
One reason this argument worked so well was simply that it's valid: a consistent, centrally administered, IT infrastructure should be more efficient than a bunch of IT islands working either separately or against each other - and unfortunately that reality combines with the human tendency to grab control where ever possible to turn most large scale Windows client-server implementations today into what data processing used to be: centralised, vendor driven, authoritarian, non-responsive, and luddite.
One area where an echo of this affects those of us working with Unix is in the issue of appropriate staffing for Linux deployments, because the general corporate strategy of standardising the platform and hiring accordingly is an echo of that argument from the 70s. Organizations standardising on Red Hat Enterprise Server generally try, for example, to hire people with Red Hat Enterprise Server experience and then press the combination as the one size fits all solution for whatever Linux needs line managers may have.
Take a close look, however, at the Linux staffing issue and you should see notice that the average tenure generally exceeds the average life of a distribution -meaning that when you hire Joe, he's likely to be around longer than the particular Linux distribution you hire him to run.
Today, for example, the people you hired because they knew Debian Linux might be wrestling with Ubantu - and the SuSe 10 experts you brought in last year will probably be transitioning to some other distribution by this time next year.
What doesn't change is that you hired them to do what they're doing: run Linux - and the next step in generality is to first recognise that Linux, the BSDs, and Solaris are all variations on a theme and then to conclude that people who are good with one of these are likely to be equally effective with the other two.
The strategic consequence of this is that you can probably weaken the consistent corporate architecture notion to broaden the umbrella of what's acceptable for departmental or other non centralised IT without sacrificing corporate efficiency in staffing and support activities simply by accepting experience with any distribution, or even any Unix, as equivalent for hiring purposes. That will broaden both your hiring pool and your on board experience base, let line management pick from a much broader range of software, and perhaps even bring back some of the creative chaos responsible for so much productivity growth during the seventies and eighties.