I see so much about how much SOA can do for organizations, I've become a bit obsessed with the question of when organizations should not use SOA. As I've written before, someone will occasionally throw out the obligatory, "Of course, SOA isn't right for everyone," but that's seldom explained.
David Linthicum tackled this topic in November, naming three situations when you wouldn't benefit from SOA:
- Your organization doesn't change that much.
- The architecture is homogeneous.
- The value of change is low.
A recent paper published this month in BP Trends expounds on this list of situations where SOA might be inadvisable -- or, at least, overkill. "SOA : To Do or Not to Do," written by Gopala Krishna Behara and K.T.R.B Sarma, adds the following factors:
- You don't need standards-based integration. In some cases, the paper points out, simple data exchange will do the job and there's no need for complexities such as choreography, BPEL engines and orchestration.
- You can't afford it. I've seen arguments that SOA is cost-neutral. That's great if you have the experience to do it in-house, a la Microsoft, but, for the rest of us, SOA will probably mean incurring costs, such as hiring outside help or buying some solutions -- an application server, BPEL engine, or process server are specifically mentioned in the paper.
- You need really fast response times. I've never seen this mentioned before, but this paper notes that loosely coupled architecture is not the best solution if response times are a critical issue. For instance, SOA would not be a good idea in companies that handle "extremely high-volume, synchronous, real-time transactions," according to the paper.
- If it works, you don't need SOA to fix it. That's my short-hand for several of the other items mentioned in the article. For instance, your legacy systems may work fine and you don't need to change them. In this case, SOA would be overkill. Or you may not need to change the data flow, processes or business logic. Honestly, this is an extension of Linthicum's point, "The value of change is low."
- A small percentage of your IT budget is spent on integration activities. Since integration is a key value for SOA, if you're not spending a ton of time or money on integration, you may want to skip SOA.
But here's my favorite:
When a clear business case or opportunity has not been identified that would benefit from the IT capabilities offered by SOA.
Preach it, BP Trends.
The article also outlines when you should adopt SOA. If you're new to SOA, there's even a short, but excellent, explanation of SOA and how it differs from traditional development. Overall, the article is a great resource for beginners or those on the fence about SOA.
While you're downloading that paper, check out Jim Sinur's column, "The Seven Deadly Beliefs That Could Hurt SOA Efforts."
Sinur is a chief strategist, so he's identifying the cultural issues and flat-out SOA myths that could thwart building a business case for SOA and achieving the promised results. It's a quick read that manages to avoid the obvious and point out real stumbling blocks.