Doing SOA the right way

Here are my 4 points:

1. Understand the diversity, and the evolutionary law: everything will always change. You might think that you achieved a lot by homogenising today's mess, but just wait 5 years and then have another look. Thou must always translate - and leaveth that to professionals. There is no one-size-fits-all

2. Diversity as in applications, but also as in languages spoken. In Europe, 2,000 years ago Greek and Latin were cool, then vulgar Latin took over, French was okay since 1600, English rules since 1900.

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.

The sudden death of EAI

After decades of more or less succesfully integrating databases and applications, there was a proven model: hub-and-spoke architecture with a canonical model

It was pretty perfect: the evolutionary as-is and to-be diversity of any IT-landscape was absorbed by an almighty interpreter-translator in the middle, who would take all the different languages and dialects and translate them to an intermediate language that would be that enterprise's business language
Just as in the European Parliament, where they call this a 'relay' language. Now, if anyone knows anything about levelling (language) boundaries, it is right there. They handle 23 different official languages