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?

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

One thought on “Does SOA create a new class of defect: passive-agressive behavior?”

Leave a Reply

Your email address will not be published. Required fields are marked *

19 − 15 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.