How are standard libraries, tools and app server platforms typically selected in large organizations?

Question

I'm looking for a list of criteria for selecting standard development libraries, tools, and application servers (specifically JEE) that is common across large organizations. If your experience doesn't span across multiple large orgs, answering with how this is conducted within your current org is still helpful. Also - 'standard' doesn't mean mandatory or exclusive, only that alternatives must be technically justified.

1. Who selects or recommends dev tools? Does it come from a low, mid, or high level? (actual developers/subject matter experts, project managers, middle management, upper management, a Gartner/Forrester/etc, ?)
2. Who or what is the final say in resolving the inevitable disputes in selecting a standard? (Ex. say you have X developers or Y group representatives who cannot agree on some standard tool, library, etc) Is there a committee which votes, a management authority figure (at what level?), some set of subject matter experts, etc?

Extra points:

Are there standard development libraries, tools, and app server software within your organization at all? If so how well are they adhered to? Are there "de facto standards"? Is there no standard or a decentralized way of doing business? Are there primary/secondary or "recommended" standards?

Answer 1

I have seen as many cases as large companies I have worked in. In some places, there is a strictly standardized technology stack, while in others tools and platforms are selected ad hoc by each dev team and project. And of course anything is possible between these two extremes. I don't think there is any "typical" case.

My current employer has small developer teams in several countries, who have been working separately from each other up to now - so much so that some projects have been duplicated over several countries with close to the same business goals and content. We have just started the first steps toward standardization and selecting common dev tools. The solutions will be built pragmatically, based on the current choices, unifying gradually over a longer period of time.

In another place several years ago, we had a strictly standardized dev environment and an extensive proprietary GUI framework to build everything upon. All has been decided and designed in advance, top-down. Even for refactoring ideas, we had to get permission from the boss of the boss of our boss - who then in the end said "no" :-/

Answer 2

Large organizations that I've dealt with are always dynamic ecosystems that are evolving all the time. They tend to oscillate between "dispersion is better" and "centralization is better" with a period that is somewhere between 1-5 years.

If the organization is on its "centralization is better" cycle, there's an enterprise architecture group that will claim tool selection and standardization as their responsibility. They'll have a committee of wise men/women that dictate selections from on high. They're usually conservative, as all large organizations tend to be. They like mainstream, proven technologies that are produced by other large organizations that have deep enough pockets to be sued if anything goes wrong.

This enterprise architecture group will usually have the final say. They own the production servers, and nothing unapproved can appear on production servers.

But there's always a guerrilla war going on in the lines of business. Depending on their appetite for innovation and risk, each group can be searching for unapproved technologies to give them an edge. They'll prototype things to see if they can persuade the enterprise group to allow them to continue.

This continues until the "dispersion cycle" begins and someone, usually a new incoming CIO, decides to break with the past and try "new ideas".

And the circle of life continues.