SOA and EA: Get over It and Get Together

Loraine Lawson

Isn't it time SOA practioners asked enterprise architects to join them in implementation projects? And isn't it time that EA join them - even if they secretly disapprove and fear the unknown consequences of SOA?


Seriously, get over it, get together and let the problem work itself out on the drawing board now, before it's a major problem.


I ask this, because sometimes, I think I'm missing something. Yesterday, I wrote about the "conflict" between SOA and enterprise architecture. I say "conflict" with quotes, because this is more of a negotiation over how SOA fits into the EA landscape than an actual conflict. But you wouldn't know it by reading some of the articles and blog posts on the topic.


In reading about EA and SOA, I'm reminded of business units that sneak in technology under IT's radar, so IT has to play integration and security catch-up. Not very mature, people.


It seems obvious to me: SOA changes your application architecture and, possibly very soon, your IT infrastructure as well. It makes sense you would talk to your EA before you do something like that. And it seems like EA would want to be part of the discussion from the get-go, even if EA experts haven't worked out all the details about how SOA will fit in with EA practices.


But apparently not.


Witness this blog post on "SOA without executive support." Writer Nick Malik is discussing the merits of middle-out SOA implementation, as opposed to rigid top-down mandates and sprawling bottom-up projects that grow into SOA "organically."


He's not specifically addressing EA. And, to be fair, I'm not sure what his position on the EA/SOA issue is. But he states:

Middle out advocates suggest that a small group of people should get together and create a standard approach. ... They will pick patterns and naming conventions that allow flexibility later without sacrificing the ability to deliver now. They will name the services they need (without designing them). They will share this information with architects (emphasis added) and dev leads, and offer reviews and test harnesses to insure that services, once developed, will be enterprise ready.

He also adds:

The point is: middle out requires one thing: that you communicate with other architects before you build a bunch of services.

Of course, just by saying this, Malik is on the cutting edge of progressive thinking on this topic - at least from what I've read.


My point isn't to say Malik's wrong - I don't think he is - or even to say he's advocating against EA - because, clearly, he's not.


Maybe Malik worded it this way because he's advocating the middle-out approach and EA is inherently a top-down discipline. Maybe he assumes the SOA project people will have an EA background.


But reading what he wrote raised a few questions in my mind.


Why don't enterprise architects automatically have a seat at the table on SOA projects? Why just share information with architects? Why not have at least one architect involved in the first place?


Of course, we can't just blame those trying to implement SOA. As this piece from Computer Business Review Online points out, enterprise architects tend to be - I think this is the technical term - "freaked out" by SOA.


Perhaps if enterprise architects were involved from the get-go, they would start to see the merits of SOA and find ways to integrate it into the EA discipline.


Again - maybe I'm missing something. I am, after all, an industry observer, not an insider. But it seems to me a simple solution to the problem. And in the long run, both "sides" could avoid a lot of problems by at least having an enterprise architect involved in the first projects.

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.


Add Comment      Leave a comment on this blog post
Aug 2, 2007 8:52 AM Frank Millar Frank Millar  says:
Some interesting challenges: One of the premises here seems to be that we all understand the term "Enterprise Architect". My experience suggests that term is being defined differently in different enterprise circles. At the one extreme, there are those who view the role as purely a business function, chartered to translate strategic goals into proposals for org charts and track implementation results so that operations are optimized without immediate considerations of technology. Others feel that individuals who are successfully reducing costs and integrating and improving the efficiencies of disparate enterprise IT organizations and their respective resources should also be so tagged. Surely, these two roles as very different jobs.Then there are the challenges intrinsic to SOA: in my opinion and that of others, any substantial SOA deployment that is not part of an enterprise business processes management strategy is at risk of not providing sufficient return on investment and/or becoming a governance nightmare.In summary, however you define "EA", somewhere, somehow, someone needs to be leading a business case vision that's been developed in the context of organization's strategic goals. In that context, integrating resources to solve BPM issues via SOA could be an obvious conclusion, many times indisputable even under close scrutiny. Somewhat separate from enterprise initiatives is the reality observed above of disparate, sometimes independent enterprise organizations working "under the radar" regarding technology. Such efforts can indeed breed bickering and a host of other "larger-picture" issues, even while solving respective immediate problems. That said, I've come to believe that the most enlightened enterprise policies can have flexibility, actually foster such creativity, and yield net-advantages when cost-savings for both IT and operations are aggregated properly. At the core of such policies is considering them to be "phase one" rather than "rogue".Maybe we are learning that there is an emerging imperative to have an enterprise ***business*** architect driven by strategic goals who puts in place and propagates policies to connect-the-dots for the many stakeholders, encourages business-driven/prioritized solutions that include the use of technologies like SOA and Enterprise 2.0 based on corporate methods and standards, facilitates communications between IT and operations, and helps enterprises successfully leverage technology.Frank MillarExecutive DirectorMillar Consulants, LLChttp://www.millarconsultants.com Reply
Aug 2, 2007 7:48 PM Sarah Santorsiero Sarah Santorsiero  says:
Great article! I do think by having EA involved from the beginning on SOA initiatives provides an optimal solution for when they work together it promotes stellar reusable/enterprise services. Reply
Aug 6, 2007 2:00 PM S. Ramos S. Ramos  says:
In a well architected organization any IT projects must pass by the EA group. If you want to degenerated your organization's infrastructure, 'sneak' one or two projects under the EA radar and from then on, you'll have chaos, no butts about. While EA is top-down, middle out approach deals with applications which must be brought into the EA fold for visibility and fitting. Reply
Feb 23, 2010 2:39 PM Ashwin Sharma Ashwin Sharma  says: in response to S. Ramos

I think one of the challenges is that until very recently, the EA frameworks such as TOGAF and others did not give enough attention/discussion around SOA.   Therefore EAs who use these frameworks don't really understand where SOA sits in relation to frameworks such as TOGAF.

TOGAF 9, however, has discussed SOA in sufficient detail to put it into perspective for Enterprise Architects.   SOA is a special case of an Enterprise Architecture.  It is a subset.   I am hoping TOGAF 10 and future releases of other EA frameworks will discuss more of SOA and align it with the EA better.


Post a comment





(Maximum characters: 1200). You have 1200 characters left.




Subscribe Daily Edge Newsletters

Sign up now and get the best business technology insights direct to your inbox.

Subscribe Daily Edge Newsletters

Sign up now and get the best business technology insights direct to your inbox.