Putting SOA Back on Track with Enterprise Architecture

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

There's a lot of buzz about enterprise architecture right now. I'll occasionally see blog posts or what-not questioning whether enterprise architecture is a "replacement" for service-oriented architecture. It's not-in fact, it may very well be that your enterprise architecture will include SOA in its toolbox.


The confusion, I'm sure, comes from IT's abuse of the word "architecture." I really wish the term "architecture" hadn't made its way into IT. I think it does nothing to clarify the huge language gap between technologists and the business. It's a confusing term because you automatically want to turn it into a metaphor, but, in fact, what IT means by architecture extends beyond that.


If it helps, I've created my own simple way of looking at it. I tend to think of enterprise architecture as the planning and zoning of the enterprise. Enterprise architects deal with technicalities such as standards, true-but their decisions must also take into account where the business is going, much the way planning and zoning boards have to take into account a county or city's 10-year master plan for growth and development.


But the issue is confusing, even among architects who wonder how efforts at SOA fit in with EA and vice versa. Author and former Blue Cross/Blue Shield Massachusetts chief architect Rick Sweeney is tackling this issue head-on in a recent two-part interview published on TechTarget and in his new book, "Achieving Service-Oriented Architecture: Applying an Enterprise Architecture Approach," available for preview on Google Books.


One of the important points he makes in this interview is that SOA is actually being held back by the fact that most companies are implementing it without any big-picture architecture plan. You've heard it before-it's an architecture, not a technology-but I think he does a good job of explaining the costs of focusing on technology:

If vendors want to sell you an ESB, are they going to tell you that's low-hanging fruit, that the reality is it's a short-term deliverable with short-term value? They won't tell you to establish an architectural practice and build competencies, because that's a much longer delivery cycle. Technology is the least of your issues; the technologies are there but they're just a tool. First you need the architecture, then apply the tools; that's really the disconnect.

He also talks about how IT culture needs to change to adapt to the demands of SOA, including the need to move out of the inherent silos of being project-oriented. That's going to be hard for IT, which really pioneered the discipline of project management in enterprises, but there are real benefits to taking his advice-especially when you look at integration issues. Writes Sweeney:

[Organizationally] the project manager, instead of overseeing one project, now it may be a matrix, so all the integration capability is delivered on time, all channel enhancements, etc. A project is comprised of different components, and the SDLC (software development life cycle) process needs to change in the way requirements are gathered, how coding is done, and organizationally the resources/skills/roles will change.

I appreciate that he also explains what is meant by "business architecture" and "reference architecture."


The first part of the interview is a bit tricky to read, especially if you're new to the "architecture" discussion, but it does discuss how organizations benefit from a "top-down" approach to SOA. The second part is easier, and focuses more on the organizational and cultural shifts needed to support SOA. Taken together, the Q&As go a long way toward clarifying the value of applying enterprise architecture to SOA.