Architect Obstacles

I've been invited to participate in a podcast next week, to discuss challenges today's IT Architects face. I would like to open up to a broader audience, please send me any of your most pressing obstacles, and I will include it in our discussions.

I've listed a few that I have experienced most recently:

• Non-Enterprise IT Dept:Individual pockets exist within the IT Dept. Even though architects exist in various areas throughout the organization, it is a disparate, federated architecture without a centralized framework. IT groups are not thinking “big picture” on how their individual kingdoms impact the greater enterprise. They are architecting in silos.
• Businesses making IT decisions. This really annoys most IT departments and for good reason-- businesses don't know technology, IT feels undermined, but the business has the money! So, everyone says you "must sell to the business", but I say "don't leave IT behind!" We have businesses buying software, consulting, and trying to do architecture without IT's input. Often times, the Line of Business decisions doesn't necessarily fit into the architecture. This is why you find organizations with 3 BPM tools, 15 SOA products, and God-knows how many web and database products. All the vendors are licking their chops to sell to business, but remember that IT has the expertise to help with standards, architecture, and to bring together enterprise-level thought processes.
• Industry and Technical Standards overload. It's funny, because some IT areas have too many standards to learn and try to digest (webServices, Security), while others have too few (i.e. Cloud Computing). Architects are confused which standards to use and when, which to ignore, and how to incorporate and apply the selected standards across their enterprise.
• Architecture not tied to a “business initiative”. Because architecture often doesn't get tied to a specific business initiative, it often gets underfunded. Many times its a foundational IT initiative, and therefore businesses believe it doesn't help improve business (increase revenues)...This frustration is often a failure of the architecture team itself-- they have failed to show a direct linkage to benefits, and now can't prove their value. To their defense, that's not always easy task, but it must get done to validate their initiatives and ultimately prove their existence. Architecture is important, necessary, and should not be ignored-- but can quickly be undervalued or under appreciated by the rest of the organization.
• Educating stakeholders This is one of the most frustrating aspects of the Architects job. They need to teach others the importance of Enterprise Architecture, SOA, Cloud, etc. If you think architects are challenged educating their Line of Business on what architecture is, but guess what-- not everyone in IT “get it” either. That is why you always see the architects so stressed and pulling their hair out :-)
• Commoditization Many folks across the organization just assume architecture gets done and most don't even know it gets done. It's like when you move into a house, many of us don't appreciate all the work that went into building the house, all they way from digging the dirt to framing the house-- we only lavish at the beautiful bathrooms and granite counter tops. We don't see all the labor that occurred underneath. This is the same for users of software-- we only appreciate the end product and if the web page or dashboard looks nice. Certain things are expected to be there and to always work-- like a commodity. Therefore architecture team receives minimal respect and little patience from stakeholders and customers. Rarely does anyone know about all the blood, sweat, and tears that went into building and architecting the system from scratch!