Would you knowingly and willingly spend $20 million for a few integration projects?
Burton Group analyst Anne Thomas Manes is quoted in a recent SearchCIO.com article as saying this is what companies are doing, in effect, when they don't focus on the business value of service-oriented architecture:
"All this money is going into ESBs [enterprise service buses] and Web services, and they get a dozen or two integration projects going, but are they getting any business value out of that? I don't see it ... I don't think a bunch of integration projects are worth $20 million."
It may be her most succinct argument to date against using SOA only for integration-a practice she calls "service-oriented integration."
The TechTarget article further explores something uncovered by a March TechTarget reader survey: The idea that BPM (business process management) can support SOA by giving it a more strategic bent.
Joe McKendrick pointed out that the article offers specific examples of how SOA can transform the business, giving this nice summary:
"A new article by Christina Torode lends credence to the higher-purpose side of SOA, noting that spending millions of dollars on SOA simply to achieve application integration is overkill. Rather, SOA efforts should be linked to wider-reaching business process management (BPM) initiatives."
But as Joe's readers point out, it doesn't have to be an either/or situation. A commenter signed "jshah0209" wrote:
"Companies are finding value in BPM+SOA. But the end result of a such an approach is systems working together or 'integrating' in the context of a process! Debating integration vs SOA makes little sense. They are not mutually exclusive."
"To some it is simply moving data back and forth which is the simplest form of low level integration(really data synch it is). ... To others integration is much more than data movement. ... I think the reality is in a SOA style of architecture if your 'Services' don't integrate then they are pretty useless."
Griffin went on to say that he thinks it's useless to distinguish between SOA and service-oriented integration-a term Manes used to describe SOA projects that relied on Web services and focused only on integration from broader, more substantial SOA implementations.
That debate's pretty long standing, and I just don't have the energy for it today. I will point out, however, that this isn't the first time I've seen the definition of integration disputed.
Anyway, that's not really the point. I think the real takeaway here is that you can achieve more good with SOA if you're focused on BPM. Integration is great as far as it goes, but it's not the end-all and be-all for SOA.
In a similar vein, another popular reason for adopting SOA is integrating and extend legacy applications. If that appeals to you, then you should definitely read ZapThink's most recent ZapFlash on the topic, "Legacy: Can't Live With It, Can't Live Without It." In that piece, Jason Bloomberg explains that companies often want SOA to either replace or rejuvenate legacy systems when, in fact, the better approach is to let it do both.