I was having a discussion the other day about the reasons for using SOA. If the liklihood of defects in a system are logarithmically proportional to the complexity of the system, I noted, then SOA is useful because you can create a collaboration of interacting systems, where each system is as simple as possible, and some logic moves to the collaboration or orchestration between them.
To which my friend replied: so if a team has 10 members, and one is not functional, the rest of the team can adapt, but if a team has 10 members, but communication is screwed up, then the team itself is dysfunctional. That’s worse. So, can SOA create dysfunctional collaborations? Can we create a “team” of systems that hate each other?
What if one system is best served by mistakes that show up in another? Can that system engage in passive-agressive behavior with another system? What about codependency? Can two systems behave in a manner that is counterproductive to both, but makes both of them look effective from the outside?
Do our test plans need to start including common team dysfunctional behaviors as test scenarios?
Something like this is certainly possible at the business level. Badly designed service-oriented relationships can produce frustration, anger and alienation, both for customers and for employees. For example, see my SOA blog
http://www.veryard.com/so/2005/06/emergent-dysfunction.htm
cheers, Richard