In my last blog, I commented about the difficulty of a church writing its own software. In my humble opinion, an even worst business practice than a church writing its own software is modifying a software package that was designed to support another industry or feature set. This is just a bad idea, period. I remember trying to do that as a consultant with a major management consulting firm in the 1990’s. In the end, we were wasting the clients’ money. By the time we were ready to deploy, the vendor was out with a set of modifications that was needed to fix major issues with their code or the upgrade was required in order to be eligible for support.
So what are the real problems with this approach?
1) If you are building upon an already mature product, how long will it be before the vendor is required to upgrade the technology platform in order to support its core business? One of the truisms about technology is that it is constantly changing. Whether you believe that to be a problem or an opportunity, either way, it is a fact. Are you prepared to keep changing (time, dollars and fortitude) as the vendor changes the underlying plumbing? If the vendor chooses not to improve the technology, than you have limited the life of your investment from the outset.
2) If you are building upon an immature product set, it is like building on quicksand. The underlying structure is going to be changing all the time, causing an emotional pain that borders on insanity. The feeling of redoing the same changes over and over will drive your team crazy or fuel the business of an outside organization for as long as your pocketbook can sustain it.
The only viable way to modify vendor software is to really not modify it at all. Instead, design and code to the vendor’s API (Application Programming Interface) which is designed specifically for extending its application. Even when the underlying architecture then changes, should the vendor decide that such a change is necessary, the modifications to the API can be backward compatible based on a version control method that should be part of the vendor’s API framework.
Fellowship One offers Data Exchange, an XML API that allows our customers to integrate and extend the Fellowship One application.
Grace to you,
jhook