It wasn't well-received on the SOA Yahoo Group, where SOA experts debate the nuances of service-oriented architecture.
"What can we do to slow down spreading such Integration SOA madness?" asked Enterprise Solutions Architect Michael Poulin.
If you haven't been keeping tabs, this is a hot-button issue for SOA. The argument is that SOA is an architecture and about so much more than tying things together. Anne Thomas Manes of the Burton Group explained it this way in her post to the Yahoo Group:
"Many organizations mistakenly perceive SOA as an integration strategy. But it is not. SOA is about architecture. To achieve SOA, you must rearchitect your systems. You must remove the deadwood. Every organization has too much stuff -- too many redundant applications and data sources. SOA is about cleaning house. You will not simplify your environment, reduce costs, and gain agility until you reduce that redundancy."
But the facts are these: Most companies aren't getting into SOA for a complete rebuild. Most companies deploy SOA because it's so darn helpful with simplifying integration, as another Gartner analyst, Andrew White, recently learned while interviewing clients about SOA use.
Or, to continue the house metaphor, companies don't want Extreme Makeover. They're looking for a slight update, something that ties the room together, as interior designers like to say.
And here's another hard truth: Although David Linthicum and others believe that agility is the ROI for SOA, many companies are realizing SOA ROI through integration.
I understand that the experts want to fight the perception that SOA is only a method to do integration-that it's just Enterprise Application Integration 2.0, as some have suggested.
But I also think a lot of SOA people do themselves and SOA a disservice by disavowing integration as a real reason for SOA. Hey, SOA works for integration. Why not embrace that? Particularly given SOA's recent fall from grace.
As Yahoo Group poster Rob Eamon
"While I wouldn't say 'SOA is integration' per se, I'd say that integration is one of the core values of the SO approach. Services have 1 or more interfaces. Interaction with services is via those (and only those) interfaces. Services (and other components such as service clients) exist in independent ownership domains. Those characteristics are the heart of integration. SO demands that one consider integration up front rather than as an afterthought. IMO, integration strategy is a side-effect of applying SO principles at the enterprise level."
Fortunately, there is a middle ground here, and that's seeing integration as a first step for SOA. White described the connection between SOA and integration:
"Given my background in Supply Chain, I would argue that there is potentially far greater value to the business from SOA at the strategic level, that is, in the rapid orchestration, and re-orchestration, of business applications supporting new, evolving business processes. The baby steps of 'simpler integration' are fine, but SOA needs to be more relevant to business if IT is to leverage the approach and support the business."
So, maybe instead of saying, "No, SOA is not integration," and then advocating a complete overhaul, maybe SOA experts could try this: "Sure, great! Deploy SOA for integration-then come back to me in six months so we can talk about what else you can accomplish using this approach."
I think SOA advocates could use a lesson from my great-grandmother. My father tells a story about her - a pretty tough old lady who loved to fish. One time, my father was trying to rush me out the door, but like any four-year-old, I wanted to play and was easily distracted. I was struggling to get my coat on. He became particularly impatient and snapped at me to hurry.
My great-grandmother intervened. "Give her time, Larry. Give her time," she admonished.
Eventually, I figured it out.
So will the companies using SOA for integration. You've just got to give them time.