Fed up with SOA's Inconsistencies

Loraine Lawson

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?



More from Our Network
Add Comment      Leave a comment on this blog post
Mar 19, 2008 3:26 AM Mike Kavis Mike Kavis  says:
I am with you on this. I am tired of all of the doom and gloom talk about SOA and everyone arguing about the semantics. I keep saying that the problem with SOA is not SOA, it is people.http://blogs.ittoolbox.com/eai/madgreek/archives/why-doesnt-anyone-understand-soa-23102IT historically has not had a great track record of delivering projects on time and on budget. This only compounds when IT takes on huge, culture changing initiatives like BPM & SOA. To do this successfully, it requires a vision, some good (hopefully light weight) processes, and executive level support. I continue to preach that if you don't get the business on board, you will have a hard time justifying the man hours it takes to successfully implement SOA. A lot of people disagree with me which prompted this post.http://blogs.ittoolbox.com/eai/madgreek/archives/why-cant-i-sell-soa-to-the-business-23135 Reply
Mar 21, 2008 4:41 AM Francis Carden Francis Carden  says:
LOL LOL.. Good on you Loraine. Go and have a nice cup of tea and calm down. Then when you come back, you'll find I TOTALLY agree as well. (I was drinking a nice cup of tea when I read this and did actually chuckle).You see NOTHING has changed has it, it 10 years, its all the same. SOA is NO different than what IT could have done before. The big difference is that it allows it to look like someone knows what the end game is. SOA has certainly attracted BIG ($$$) budgets and hence vendors and analysts flock. Call it an SOA bubble if you like and I too think its about to burst. Theres nothing wrong with SOA, just its NOT the panacea, NEVER was and NEVER will be. I was hoping though it would give FOCUS and wed see some great results from it. We certainly have seen SOME successes but NOT enough at all.SOA evangelists would really claim SOA stands for Sorts Out Anything when the truth is, it stands for Saves our Ars.. Now perhaps we can take the best of the ideas from this bubble and focus on the best of the last bubbles and put it all together to come up with solutions that fix short term pains (business) and gives us a goal to a long term strategy (both are not mutually exclusive and must never be). Reply

Post a comment

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

null
null

 

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.