Wednesday, January 07, 2009

SOA is dead (again?)

For the umpteenth time SOA is dead apparently. It's been shot so many times over the past year or so that you'd think it had a role in a Sam Peckinpah movie! However, maybe it's got 9 lives or you need to use a silver bullet, because each time it dies it keeps coming back.

This time it's my friend Anne who is reporting the demise of SOA. I've known Anne for many years and respect her, so unlike a few other obituaries I take note of this one. However, like Duane I have to disagree that SOA is dead. OK, the term may have been overloaded over the past few years almost to the point of being meaningless (analysts are as much at fault as anyone in the industry) but the concepts behind it are still very much alive and relevant (more so in today's economy.) Where we have lost our way is perhaps in having an agreed architectural definition for SOA: it is the 'A' after all, so surely we can agree on what that means (REST doesn't suffer this problem) as well as pushing the mantra that "SOA is not just a technology" (though given the number of people who have been saying this over the years I suspect that this is more a case of individuals simply not listening, certain vendors muddying the waters or it being lost in the noise.)

There is no global panacea for IT woes. There never has been and I doubt there ever will be one. For the most part software engineering practices evolve over time (Darwin would be proud). There are a few evolutionary dead ends on the way. I doubt we'll see any extinction-level events though (not unless they're associated with human extinction.) But these things take time (I'm sure the dinosaurs laughed at the evolutionary path that created the Coelacanth, but who's laughing now?)

We can't afford to keep jumping from one lifeboat to another just because some use cases don't match, or someone didn't quite understand that you need to think about how to use SOA before coding. The underlying requirements of loose coupling, security, federation, reliability etc. date back decades. The term SOA should have been good enough. It still is as far as I'm concerned. If it's not SOA then are we in for yet another round of acronym generation, like SOA 2.0, WOA etc? None of which really add much to help the people at the sharp end of IT problems!

I think in Anne's recent SOA obituary she is trying to indicate that the principles are fine but it's the term that needs to go. In the first case we can agree. In the second I don't think it's worth the industry wasting another 4 years to disagree on yet another acronym (if we do, I'd like to nominate XYZZY.) As I said above, for people actually using these principles and associated technologies it won't make a difference to them. (It may be good for analysts though.) So let's just stop this madness and start concentrating on where it really matters.

In this case I think it's definitely more a case of what Mark Twain once said, "The reports of my death have been greatly exaggerated".

3 comments:

Anne Thomas said...

Mark-as you say we are in agreement that the concepts are *important*. And I don't propose a new acronym. But my point is that organizations should no longer attempt to sell "SOA" to the business anymore. The term must be removed from our vocabulary. Don't use an acronym. Just talk about "services".
Anne

Mark Little said...

Hi Anne. The term "services" doesn't really do it though, otherwise CORBA, DCE and even the bespoke distributed systems implementations of the mid-80's would have been "it". SOA encapsulates more than just "services", even if that is through an implicit association.

Anonymous said...

Mark,

My post "Understanding SOA" from last April sheds some light on a few of the issues raised in this and Anne's thread. It discusses:

SOA definition
ARCHITECTURE
SOA ARCHITECTURE PRINCIPLES
TECHNOLOGIES
SERVICE DISCOVERY
IDENTITY MANAGEMENT
CONCLUSION

http://www.keystonesandrivets.com/kar/2008/04/understanding-s.html

Paul