SOA 'anti-principles' more important than success principles?

Sometimes, the best path to success is knowing very clearly what doesn't work.

Steve Jones, who initially coined the notion of SOA "anti-patterns" a few years back, has published a new set of no-nos he calls "anti-principles."  Understanding these anti-principles is probably more important than understanding SOA itself, he says. (Thanks to Mark Little for surfacing this gem.)

Principles that are well understood to be part of the SOA equation include loose coupling and clear interfaces. However, it's not understanding the anti-principles that trip up SOA efforts, he says. Three examples of anti-principles include the following:

• Small return values: A carryover from batch thinking, this is "just return a code and description rather than returning a decent amount of data."
• Direct calling: "People just get a WSDL and consume it directly without any proxy or intermediary.""
• Interface generation: People design interfaces up front, versus generating interfaces from code."

There's plenty more that can be said about this, and I urge readers to contribute their examples of anti-principles. Just some additional suggestions for anti-principles, based on the guiding principles laid out in the SOA Manifesto:

• The organization doesn't know what it wants, let's just go ahead and create this for them -- they'll thank us later: Yes, many organizations don't know what they want or where they're going. But creating SOA-aware services and infrastructure without their input will result in another stovepipe.
• This new application server environment we're putting in will go a long way in finally getting applications service-oriented: Maybe, but SOA is not about relying on products to make it happen.
• Designing single-purpose services: There are many cases where single-function services make sense. However, the design of some services need to be considered for the long run.