SOA and EA: Get over It and Get Together

Share it on Twitter  
Share it on Facebook  
Share it on Linked in  

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.