I also conceed your point about abstraction vs. performance being a factor.

I specificly choose “uncooporative” rather than “obsolete / legacy” systems as the target of this piece because I think the challenge presented by them differ. If the system you were replacing was simple an old system then adapters and a little bit of hard work during the migration would likely be more cost effective, however an “uncooperative” system, in my mind at least, is a system where the design has become practically untenable and potentially the relationship with the company that produces the system has soured.

I view this as the “hostile takeover” methodology of system migration as opposed to the retirement of a dear friend.

The cost / benift for one of these cases would likely be negligible in the sense that if you were driven to a drastic replacement, it could well be the difference between continuing to operate as a business or having to sustain serious losses due to an untennable environment.

As a footnote, I think that the encapsulated system would be best accessed using adapters to prevent this situation reemerging in the future but I’d almost expect that as a part of good software design. I think that ideology and fit-for-purpose software design should go hand in hand, otherwise whatever your design looks like, it’s not ideal.

With any integration of separate or third party systems there is always a risk that it will need to change. Surly the best approach is to always provide Adapters (Providers) to these systems so when they do change they are easily replaceable?

I don’t think any architecture will reach entirely a state of perfection. This in mind i think it is important to learn to accept that not every system will reach our own idealistic standards and sometimes we have to learn to let small unavoidable smells go and abstract them best as possible with the above approach. The question i suppose boils down to “Would the cost of leaving the inconvenience in place outweigh the cost of implementing a new provider?”

Which leads me nicely onto the fact i’ve been going through this recently and i don’t think it is always a simple case of “hiding” an uncooperative system behind a idealistic interface either. Let me give you an example, to make my uncooperative system perform i either needed to create an API that slightly coupled it to the underlying component or provide over ten times the infrastructure to support it. So we have a choice either Abstraction or Performance which do you choose?

I suppose my goal here is to point out there is a difference between ideology and fit-for-purpose which sometimes we as developers get caught up in. And also that while we should strive for perfection we sometimes have to accept imperfections.

Best Regards
Offshore Software Development
http://www.softwebsolutions.com