I could have sworn that I mentioned "JaBoWS" before here on this blog but I can't find the reference, so it must have been somewhere else or I just dreamt it. The term, if you hadn't heard Joe McKendrick's coining before, stands for "Just a Bunch of Web Services"... or, what you get when you try to build a Service Oriented Architecture and instead get a mess of unrelated and unused services instead.

Architecture guru Nick Malick has posted a manifesto calling for broad community resistance to JaBoWS which I link to for your further perusal and edification. I'm not sure I have a strong opinion on his post yet. Perhaps obviously, JaBoWS is no substitute for a real, functional SOA, and many of Malick's suggestions seem well oriented toward avoiding the slippery slope of working toward SOA but winding up with just a bunch of web services... and as Nick suggests, simply buying new tools with "SOA" stamped on the side isn't going to magically result in real SOA, either.

Still, there is something in me that recoils slightly at both his simplistic characterization of what is bad and leads inevitably to JaBoWS, and which resists his call to better define what it means to build an Enterprise SOA. I feel as though part of the problem with many of the tools which he rightfully decries is that they attempt to do exactly that; but I think that it is those restrictive, imposed definitions which cause many of the problems in enterprise SOA implementations. Instead, I feel about SOA as I do about ITIL: it's a concept that needs some flexibility to be useful in every instance. Imposing restrictive stamps on what it is and is not makes a lot of sense within a given organization, but I'm not sure it's a good idea for the concept as a whole.

Similarly, I think that you can see a lot of benefits out of certain implementations even if they are not "pure." There is a failing of sorts in many of us who are technically inclined, in that we want to see precision and perfection (elegance, a compsci professor of mine called it) in the systems we design and work on. But those things aren't always necessary, or even desirable, in the business world; something that works, today, is better than something that works perfectly next year, in many cases. Making compromises in architecture isn't always wise, but it doesn't always debase us, either; there are times when compromises are the best thing for the business. That's hard to see from the system architecture side of the table, perhaps, but it's a choice that CIOs face all the time.