Architecture as a pressure cooker

Right about now I'm reading about a company that wants an enterprise-wide Service Bus "to glue it all together" (my own words) and create an agile, flexible service oriented architecture (their words)

Now, how well have they thought about the different departments, each dealing with different business pieces, consumer sub-markets, various government regulations, different timings (8/5, 12/6, 24/7) etc?

Not at all. It's all tech-talk. Here's the worst part: The ESB must support SOAP over JMS outside, and SOAP over HTTP inside. Described in WSDL. Now I know exactly what that implies, but the authors probably don't have a clue themselves.

Worse, I probably know better what it even means. And, if you get down to a level this detailed with regards to all these so-called "standards", be sure to mention the exact version number, as there's a universe of differences in between

Where are the business agreements? Anything having to do with business? How do you get from just merely mentioning SOA to stating that it has to be XML? Enterprise-wide? How can you draw a draft version of a house, at the same time saying that is has to be made of 8" bricks - and not mention their colour
Not a word about how to collect enterprise-wide services. Or what they are, and what their purpose is. How to describe them. How to maintain them. How to version them. How to have them fit-for-purpose for applications, consumers and businesses alike

I am blaming the rise and shine of architecture as a profession and institution for this. 10 Years ago people would just get fired or figuratively shot for silly ideas like these, and rightfully so
Nowadays these ideas are pin-balled by and through CIO offices and Chief Enterprise Architects and Boards for months and years, and whatever conceptual yet hard-to-read factor of 100 pages rolls out because the money ran dry, it's become a fact of life. No matter how unpragmatic, inefficient, inflexible and guaranteed-to-not-ROI it is. And their will must be done

At the point where architectural doctrines enter an enterprises for the masses to be read (sic!), they're beyond discussions somehow. One way or another, at that point they're a fait accompli only announcing incomprehensible changes to come. Not always, but mostly this is the case
I think architecture has a purpose. The same reason why there are architects IRL. But they should stick to their job description

Stop architecture-as-a-pressure-cooker, serving us well-done, tasteless meals, starter, main course and desert all-in-one. "Architects", if you know so much about SOAP, XML and WSDL, stick to Software Build, Software Design or Software Architecture. And if you don't know a thing about it, then refrain from making statements about it, and just admit you're unfit for this particular job.
Describe the relationships between the three meals, what impressions one should get from it, the colours in it. What type of wine should go with it. And leave it at that!

Yes, I do get excited every now and then. I loathe the way decisions are rolled down from the top through impermeable layers of management and departments
Architecture-as-a-profession has shifted the point-of-no-return to the left on the scale. A lot of investments, research, talks and purchases are discussed, weighed and accomplished in an early stage, in relative perfect isolation.
It's time for architectural evaluation. As in who controls the controllers - who architects the architects?
We don't do IAD, RAD, RUP or Agile. We're partially thrown back onto LAD through our architectural and CIO departments. And that's just dead wrong