Call me a cynic, but I've just about had it up to here with SOA.

At first, I thought it made perfect sense. The definition seemed simple: You write the code for a process once, package it, lock it down and call it a service. Then, you can reuse it, calling it with other services (kept in a repository or registry) to build various applications, which you can now create very quickly because you've got a backlog of services sitting around, ever at the ready.

Services are designed to be technology-neutral -- a concept I was always a bit skeptical about, but consultants said you could do it, so fine. This means you can use services to "communicate" with legacy systems and the Web, so it's great for system and, potentially, data integration.

Efficient, smart, effective. My cup of tea.

But lately, SOA's facade has started to crack.

First came news that reuse wasn't panning out as promised. Reuse, it turned out, wasn't a primary "use case." Instead, SOA is about agility. I'm still not sure how that works, since reuse would seem to be an essential quality for agility, but whatever.

Next, no one seemed to be able to nail down metrics for measuring SOA. From my past work writing primarily for CIOs, I knew in my heart that was not a good sign. But did I listen? No. I told myself sometimes it takes time to figure out metrics for new ideas and technologies.

I should've known something was up, though, when everybody said business people wouldn't understand SOA because it's too detailed, too technical, too "IT." This struck me as deeply condescending ... so typical, IT selling itself as magic beyond mere mortal understanding. I felt like saying, like Lost's Juliet, "If you explain it real slow, we'll try to understand."

Then consultants started to warn us that SOA was NOT just Web services and XML -- never mind that this model seems to work for tons of people. It's not SOA. To me, if you say a technology or standard is definitely not SOA, I'd expect you to next tell me what specifically is SOA, but no. Instead, they said SOA isn't about the technology, it's about The Architecture.

This also confused me. I get that there's a need for enterprise architects to be business-savvy and understand the business processes but, ultimately, doesn't the architecture come down to some sort of technology and systems? True, the specifics might vary, but basically, it's all IT, right?

If enterprise architects aren't dealing with IT systems, then what, exactly, are they designing and helping to build? Lego Star Wars models?

(I've even heard it said that EAs are now the ones responsible for IT/business alignment. To which I asked, "Isn't that the CIO's job?" But apparently not. I'm starting to think IT/business alignment is just a bad joke played on companies. Question: How many IT executives does it take to achieve IT alignment? Answer: Just one more.)

Then people started to say that SOA wasn't meant for integration -- this despite the fact that companies report they're very happy with the integration results.

But I didn't really become a SOA cynic until I learned no one could agree on what, exactly, constitutes a service. That's when my reporter's Spidey senses went crazy.

Seriously? There's not a set definition for what constitutes a service?

I wonder: How do you build a SERVICE-oriented architecture if you can't tell me what a service is?

If it can't be measured, defined or bought - does it even really exist?

I know this stuff is supposed to be customized by business, but it seems to me there ought to be some standard definitions by now.

I'm feeling pretty cynical about SOA by now. No doubt, some of you have been cynical all along, and as a journalist, I suppose I should have been, too. But like I said, it made sense -- until the experts started telling us that everything we thought was SOA, wasn't.

Is it any wonder companies are abandoning SOA?