You'd think everyone would agree that complexity and unnecessary differentiation in an IT infrastructure make it harder to achieve corporate goals. So it should be easy to get to a set of pragmatic guidelines that everyone can accept and use.
It's rare to see an enterprise IT shop that has had the discipline to stay with a consistent set of guidelines over an extended period. That's not to suggest that the guidelines don't need to change--they do--but the changes need to be managed as another lifecycle process, instead of being allowed to happen haphazardly or, sometimes worse, not to happen at all.
Fashion plays a part in this. When best-of-breed approaches are in vogue, product proliferation increases. When single-stack approaches predominate, diversity is reduced, but only to the extent that previous fashion cycle decisions are retired.
Whichever approach is chosen, the IT organization must deal with a persistent barrage of vendor suggestions that their products can improve what's being done with other vendors' products. I spend a lot of time listening to pitches for new or alternative technologies, but very seldom does the vendor provide enough insight into what is to be done with deployed technologies in order to show how they can solve the challenges we face. We try to centralize this flow of information and attendant hype via our vendor management process.
To make matters even more complicated, our development teams are schizophrenic about architectural guidelines. On the one hand, they really want to be working with the latest and greatest technologies. On the other, they are reluctant to give up what they know--or think they know--how to use.
Sometimes both extremes exist within the same project, and we can end up with a brittle mix of old (sometimes unsupported) and new (often unproven) technologies. This does not make the operational support folks happy with the development teams.
No one likes being told they have to obey the rules imposed by corporate. My infrastructure architecture team tries to be collaborative when developing guidelines, but it's inevitable that we block some things that the developers want to do or force them to make changes that they would rather not have to make.
From an enterprise perspective, we are absolutely doing the right thing, but it doesn't always seem that way from an individual project's point of view.
By enforcing standards, it seems as though I'm making developers pay a local tax on their productivity--even though the overall benefit is significant.
My team spends more time than I would like reviewing project proposals and infrastructure designs before they go to engineering. Fortunately, this catches most of the deviations from our guidelines. Unfortunately, it generates rework that could and should have been avoided.
Still, we are making progress. A new outreach program from the infrastructure architecture team is beginning to get the developers to spend more time thinking about how to use what we provide and less time dreaming up things to which we'll have to say no.