One man's Service is another man's Application

The world of the developer is a simple one. You write code. If it compiles, you got yourself an application. It could be a client application (web or desktop) or a service (web or server).

When you're an architect, or even worse, a BDM, a CxO, a business analysts... things get mote complex. Services, applications, systems they are all juggled around and in the end mashed up in a way that no one really knows which one means what any more and all can continue to charge serious amounts for consultancy or analysis before a single line of code will be written.

My (overly simplified and extremely put with a wink) statement is triggered by a ZapTake piece written by Ron Schmelzer that basically says that Microsoft doesn't get SOA. (here). This is the part where you can see the clowns juggling...

Even the customers they trot out on their conference calls and in their events claim to have implemented SOA on Microsoft products, but when pressed admit that it's nothing more than Web services-based EAI.

And:

The real power of SOA is not simply in standards-based integration (didn't XML and EDI provide that, too?), but in the power of composing heterogeneous services in environments of continual change.

I believe the author pressed submit a little too soon and forgot to include ESB. That would have added at least 30% to the consulting fee!