Since joining Microsoft, I frequently find myself in conversations where customers are focused on their architecture and want to understand how our server products fit into their environment from an architectural perspective. For example if a customer has standardized on an integration platform, and then they look at BizTalk and see its integration capabilities, I often hear "we have standardized on product X for integration at company Z, so BizTalk doesn't fit into our architecture." Nevermind that BizTalk enables an adapter framework for application level integration that may be far beyond the capabilities of what the customer uses today (often file based integration with limited support in the area of transports). In these cases, the customer's concerns around architecture may well be an impediment to progress not only from a technology perspective, but from a business perspective as well. The focus moves from capabilities and benefits of a new platform to internal standards and a "desired state" for their enterprise architecture
My sense is that many people are too rigid in their approach to enterprise architecture and software standards, and lose sight of the capabilities and benefits of new tools. If a new tool or platform is more agile, easier to use, and offers new features to improve the business, shouldn't those benefits drive the selection of what products are used for what purpose. The analogy I like to use is one of roof thatching. If you don't have a roof over your head, wouldn't it be better to have a thatch roof than to get rained on while you're trying to build a house with a spanish tile roof, or worse yet a skyscraper? This is not to compare our products to a thatch roof- it is simply a statement about the need to make progress in small steps and to recognize that sometimes a smaller more agile solution that can evolve may be the best approach.
I don't intend to diminish the importance of architecture, but to continue the structural analogies, before there were architects people managed to find shelter and stay warm and dry. Even in these times, why would you let your techology architecture prevent you from finding shelter for your key business or technology needs?