Software Blog (beta)

The Long and Short of SOA

Good article here on the challenges and payoffs of implementing a SOA strategy. 

The article does a good job communicating how significant a change SOA is to a company.
"You need to “turn your organization on its side” and incorporate SOA into thinking enterprisewide, said Steve Wolf, Marriott’s senior enterprise architect. “What separates SOA from a minor technology change is the fact that this is a fundamental change in the way we do business,” he said during a session at The Open Group LLC’s Enterprise Architecture Practitioners Conference.

Implications:
A) This is a long sales cycle... and therefore expensive
B) Without significant internal evangelizing and championing, SOA projects will fail to meet expectations

In other words, this sounds like many other "revolutionary" three-letter-acronyms: ERP, CRM, SCM...  Lots of promise but not easy to attain.  So far SOA does not have the stain of overpromise/underdeliver that the other three do, but that could change if the tech media gets a hold of the "SOA is a failure" meme. 

The article also does a good job of illustrating the benefits of all the hard work to implement SOA:
Con-way Inc. has seen a substantial return on investment from an SOA approach it has been using since 1998...  The IT department can now change business processes as soon as an alteration is needed instead of having to rewrite code... In addition, the SOA supports the electronic transmission of data to customs officials in Canada. That has slashed the average time it takes for one of Con-way’s trucks to pass through customs gates to enter Canada from two to three hours to less than a minute... (emphasis mine)

BPM, BPEL, SOA... who's doing what now?

Nobody is immune to it.  Eventually you're in a conversation somewhere and the acronyms are flying and the jargon is charging.  You are following along, nodding perhaps, and then in a flash... you've lost the plot.  The person on the other end of the phone is going on and on about a solution that was really cool and it used BPM, SOA, and BPEL.

Wait, you think to yourself, BPM is "business process management" and that's when they design business processes... like using Visio... is it Visio?  Note to self, check on Visio... anyway, BPM is hot, right?  Isn't everyone touting it like mad?  Who exactly is doing this design?  I've never met a "business analyst," have I?  How many business analysts are out there and could they possibly justify all the product hype? 

Meanwhile, the conversation is still rolling on.  This time it's about SOA.  Whew, you think to yourself, this is familiar ground.  SOA.  SOA isn't ESB, but ESB can be a part of SOA, right?  Or do you even need an ESB?  Haven't we had SOA around for a while?  I thought web services were the visible manifestations of SOA, or are they the other side of the SOA coin? 

Anyway, BPEL.  Isn't that the language for designing business processes?  But BPM does that.  Maybe BPM uses BPEL.  Or maybe they compete.  Do I need BPEL?  Does the hypothetical business analyst need it? 

Of course, your mind isn't this scattered (or is it!).  Nevertheless, this article clarifies all.