Jack Vaughan, Editor
Sometimes it seems application integration and SOA are either mortal enemies or birds of a feather – there seldom seems to be much of a middle ground there. The dichotomy is often on display on such worthy channels as the Service Orientated Architecture discussion forum. Someone there recently posted a job description for a SOA enterprise architect, and estimable forum members quickly chimed in, insisting the posting described an Integration Specialist rather than a SOAist.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
SearchSOA.com has generally looked at SOA as how you do things, and application integration as what you mostly do. We found out that ”them’s fighting words,” if you will, back in 2009 when we quoted Gartner’s Yefim Natis saying ”SOA is integration.” This didn’t sit right with some people who thought it was, at best, a return to some naive notions from the early days of EAI.
Gartner actually distinguishes application integration from SOA, in a way. That is, it breaks out market Magic Quadrants separately for “Application Infrastructure for New Systematic SOA Application Projects” and ”Application Infrastructure for Systematic Application Integration Projects.” Late in 2010, contributor Colleen Frye spoke with Gartner’s Massimo Pezzini about some of these distinctions.
Again the dichotomy came up in a story last week on a book on so-called ”Lean Integration.” The story discusses what business-side people see as ‘gold-plating”- the feeling a simple near-term software project is made to meet long-term services criteria. They feel their project is being made to carry the burden of others. Lean Integration’s authors have a humorous metaphor to describe this. It is, ”the first person on the bus pays for the bus.”
Integration and SOA – if it was truly bloody simple to balance the two, well, SOA would be a no-brainer anyone could do. As Yefim Natis told us long ago, “The difficulty in SOA-oriented development is that it must achieve real short-term business goals while setting the stage for far-reaching architectural objectives.” On a bad day that can turn into a dilemma, a quandary or a hairball, take your pick. Let us know what you think.