It's not what you do, it's what you call it ... huh?

Blogger: JP Morgenthal

Staying out of this "SOA is dead debate" is like trying to stay out of the circle at at Greek wedding.

It seems there's a good amount of traffic focused at commenting on Anne's blog entry stating that the principles of SOA are sound, but you don't want to call it SOA.  This has led to very satirical representations, such as the one by Miko Matsumura, calling it the "Artist formally known as SOA".  However, this notion makes the hair on the back of my neck stand up.

In response to David Chappell's thoughtful blog piece, I responded, "the whole sordid process has brought me full circle and I don't know that SOA was ever really born".  My basis for this statement is that there has never been broad spectrum agreement on what SOA means.  There's the OASIS Reference Model definition, the software engineering definition--I built a web service, therefore, I SOA, the Enterprise Architecture perspective--save the architecture, save the world, just to identify a few.

Moreover, the examples of successful SOA that have been put forth, primarily by the vendors, all look like re-hashed former architectures.  I see many examples of EAI, OOD, component architecture, BPM, workflow, etc. and mashups of these architectures used to form a solution, but I don't see anything uniquely SOA, unless you buy into the definition of SOA as having used an interface to expose these efforts as reusable chunks.  As I also pointed out in my comment on David Chappell's blog, "if you use a term that is amorphous and identify success by that term, then the success is circumspect."

The reason why we cannot summarily dismiss this notion of lambasting the term 'SOA' without throwing away the whole notion, is because at the core 'SOA' represented semantics--the semantics of business.  Its like the fact that no one talks about Iraq and the weapons of mass destruction anymore; the original premise has gotten lost.  The underlying principles of what is now known as the 'Artist formerly known as SOA' were the relationships between services and their semantic representations of the business' faculties.  It was a way to look holistically at the organically grown rats-nest of applications and their awkward "intertwingling" (Chris Haddad's superb description) and apply a methodical reorganization of those assets against a template representing the core business.

So, IMHO, to say "do SOA", but don't call it "SOA", is at the core of why so many have reacted so strongly to this message.  We hate the unknown.  It's better to have a bad name, then no name at all.  But, even better, would be to have a name that describes the task at hand.  I also believe that if you go management with a message of, "we should clean up our intertwingled application mess," you should probably be prepared to join the unemployment line, regardless of the fact that you would be acting in the best interest of the organization and undertaking an effort that could result in millions of dollars of savings amortized over a number of years.

In conclusion, I would like to leave readers with something they can replace SOA with as they are getting called on the mat about their support:

1. SOA is a bad word because it doesn't tell us anything
2. Think about applying a pattern of organization to your information technology infrastructure that closely mimics your business' core focus, along the way reducing redundancy and building out a common reliable business service infrastructure
3. As a result of developing out the business service infrastructure, you will need to respond to practicalities associated with security, reliability and change management
4. Extra credit: take the opportunity to build out a strong software development life cycle methodology and develop out metrics and expected ROI