In response to our post “What to expect” our former cohort Chris from the old days at a giant semiconductor company posed the question:

“Any thoughts on communicating just exactly what SOA is to mixed audience of technical and non-technical folks, and how it will help them?”

Yes Chris, yes we do have quite a bit to say on the subject. In a previous post we talked about SOA being a means to a end which implies that SOA is an architectural response to a bigger need or problem. The worst thing you can do as an architect is to attempt to sell SOA as SOA. The equivalent mistake would be to try to sell Model/View/Controller (MVC) or Event-Driven architecture (EDA) to a business analyst or end-user. Either they will not get it or they will not care or both.

A better approach is to present the problem at hand, describe how the problem can be solved in conceptual terms, and then and only then illustrate how SOA (assuming it does) provides the design to solve the problem.

Having said that, this is part 1 of 4 posts on how to explain SOA to an organization.

Continue reading →

In “SOA is Like a Vacation” Brandon blogged on the notion that ESBs may, or may not, be part of an SOA which I agree with. In this blog I will go one step further and say that if I were you, I would question why implement SOA at all.

Continue reading →