I recall jumping on to the SOA Yahoo group months ago, hoping to more fully understand the prevailing definition and practice of what is referred to as SOA. I came to the conclusion that SOA as stand-alone entity never existed. Oh, there was SOA this and SOA that (and a parody titled exactly that featuring Greg the Architect) but fundamentally, architecture is architecture, whatever the guiding principles may be.
Service orientation is just one way of creating an enterprise architecture (or an application architecture or an integration architecture or ....).
To say SOA is folding into EA is amiss in my opinion. It was never its own thing to begin with.
Is it time to fold SOA into Enterprise Architecture (EA)? Is there even really any fundamental difference between SOA, EA, and for that matter, BPM (business process management)?
That’s the question Kyle Gabhart asks in his latest post. (Dave Linthicum also predicted last year that SOA would eventually fold into EA).
At the end of the day, SOA, EA, BPM (and let me add Enterprise 2.0 and enterprise data management) call for similar methodologies, and address the same problems. Are they essentially the same thing? 
Kyle notes that at a governance panel at last week’s Open Group conference, members of the audience asked panelists to delineate between governing SOA and governing EA. This proved to be somewhat difficult, as “the line between these disciplines is quickly blurring within many enterprises,” he said.
“We need to look past the labels that are applied and take a more business-focused and goal-oriented approach to education, mentoring, and ultimately solution development. We need to probe more intently with our clients to discover their strategic direction, business drivers, and objectives for one-year, two-year, and five-year timeframes. We may have the perfect service offering for them, but because it is labeled as SOA, BPM, or EA, it may not jive.”
Agreed. Business leaders don’t care if a project is called “SOA,” or “EA,” or “DOA.” They want an initiative that achieves faster time to market, streamlines an outmoded process, or improves front office productivity. Period.
Kyle backs up his assertions with some examples. For example, at one workshop he conducted for the Department of Defense, participants observed that the discussion on SOA principals, methodologies, and best practices “all flowed very nicely” into a broader scope of EA. “The ‘SOA’ label that we had begun with was immaterial to the objective — better governance of enterprise assets and business processes.”
He also observes that his company’s clients often associate SOA very closely with BPM, and visa versa. “It was the same standards, same tools, and the training was about 90% the same,” he said. “The difference was found in the labels attached and the emphasis upon certain key concepts.”
At this point, BPM and EA seem to be in separate camps within organizations, and, significantly, the BPM and EA folks, by heritage, may have tighter relationships with the business, versus the IT-centric heritage of SOA. This may be the main divide at this time. But as Kyle points out, it makes a lot of sense to bring these all together in pursuit of better business performance.
. There is a definite synergy betn BPM and SOA .. and organizations are now realizing it. 
