SOA Algebra 2

Following my earlier post on SOA Algebra, Andrew Johnston argues that SOA doesn't need a new algebra. He claims "it just requires the right application of techniques we should already understand".

But I never said SOA needed a new algebra. I said it needed an algebra. I expect (indeed hope) that some (perhaps even all) of the elements of this algebra are already known (somewhere). I agree that most (perhaps even all) of the problems are older than SOA.

But the reason I use the word algebra is because I want a systematic and coherent approach (not just a random collection of techniques) to address a set of problems (composition and decomposition) that are currently handled very badly. Most of the people in the SOA world seem to be ignoring or fudging these problems. And there is very little work being done in this area.

Andrew mentions some techniques for calculating reliability (based on probability maths and statistics), and recommends a simple Fault Tree notation (for which he sells a Visio plug-in called RelQuest). He suggests that "service design tools ought to be able to generate the Fault Tree model directly from a graphical service composition". It would also be useful to integrate the Fault Tree model with something that can calculate or simulate the probabilities.

But of course reliability is only one of the things we need to think algebraically about. There are many aspects of service engineering where we need to reason from structure (for example a specific decomposition or collaboration pattern) to quantity (for example, a specific cost/performance envelope). If the structures are simple enough, we may be able to calculate the quantities using simple arithmetic (addition and multiplication), but as soon as the structures get interesting we need to have a more sophisticated algebra.