In a recent meeting, the customer brought up a valid question: “How do I know if a problem/system is a good candidate for using SOA (vs. using old but trusted techniques).  I put this checklist together.  If you can answer yes to 2 or more of these, it might well be a good candidate.  This is V1, and I will likely update it over time.  Comments (that are not spam or sales pitches) appreciated.

Part of the conversation was also around the fact that SOA has two faces to it; one is around the obvious reuse possibilities. The other, that often gets forgotten, is that SOA provides goodness in terms of simplifying integration even where opportunities to reuse those integrations are small; at least the integrations are standards-based and more flexible.  I did not write a lot of verbiage about each of them, for example “Business Process” implies that there is a set of step-wise actions that need to take place in a coordinated fashion that include integrating with systems (and sometimes people for approvals and other human-only actions) in the process.