Reduction in Dependency Complexity

[John Harby <jharby@gmail.com>]

This was something I once discussed with Frank McCabe and others in the SOA-RM, it's

probably more appropriate here. I had a client a couple years ago that is an insurance claims

processor, they service many large insurance companies. They found that every time they

added an insurance company, they had to rewrite their code that did the agent assignments,

estimating, etc. The codebase was a large fairly standard Object-Oriented approach. So, they

virtually had a 100,000 line codebase to provide assignments for insurance company A, 100,000 lines

for assignments for company B, etc.

 

The solution was to move to an "SOA" where we designed many services and used the orchestration

to handle their processes. What we were able to accomplish was reducing the number of significant

changes to changes in the orchestrations only. In other words, when some change was required

the services were usually unchanged, only new orchestrations were created when change was required .

This was a tremendous value add for the company.

 

IMHO, the idea here is to reduce the complexity of the overall dependency graph (using the principal

that multiple small forests easier to traverse than a single large forest). The best practice or pattern

here would be to recognize this benefit and utilize it in system design. Something Frank pointed out to me

was that SOA does not get you out of the forest, but my response is that it will simplify the journey.