One of the great things about working at a university is that you often have the option of creating something from nothing. Over my more than forty years at Columbia, I have written or managed the writing of many different programs and systems. I am fairly certain that one of the attractions of working at a university is the ability to be creative as opposed to being just a systems administrator installing or managing commercial products.
Back in “the old days,” you often did not have a choice: if you wanted a piece of software, you had to either write it or do the work by hand. This fit in well with the culture and no one thought worse of you when your answer for software vendor was homegrown. One of the big advantages of using custom software is the end product actually matched your business processes.
Fast forward to “The Cloud Age” and it appears that the pressure is on to do everything in the cloud. I, for one, sit squarely on the fence about this. I see the merits of using cloud software when the product does exactly what you need, fits into your budget allocated for the task and can securely interface with the systems that you already have in place (a topic I explored in more detail here).
This does not mean that I have completely jumped the homegrown fence and given up on my open-source, freeware, build-it-yourself heritage. My policy of one-size-does-not-fit-all extends to my acquisition of software. I believe that the solution needs to fit the problem. You do not have to compromise the processes that are in place to make them fit into the trendy product being advertised in the pages of the airline magazines, or being pushed by a fast-talking sales person. We (Columbia) use various homegrown systems to protect our enterprise.
Another aspect of the build-or-buy dilemma will surface in any organization that exists long enough for a system to need upgrading or replacement. Over 25 years ago, Columbia decided it was time to move from a manual accounting system to a computerized one. At the time, computers took up a room, were batch-oriented and ran on punch cards. Needless to say, buying an off-the-shelf accounting system to run a university the size of Columbia did not exist, so we wrote one. (You can read a History of Administrative Data Processing at Columbia, which was written for the 25th anniversary in 1988). One of the decisions made at that time was to use nine-digit account numbers. This turned out to be the downfall of the system. Around 15 years ago, we started running out of account numbers and a decision was made that we needed to replace or update our homegrown system. After much discussion and many meetings, we decided that we would go with a commercial product to replace our current system. After many millions of dollars and several years of work, the new system went live about three years ago. It is now three years since the new system went into production and, for the most part, it is working.
The benefits of moving to a commercial or open-source product revolve around support and feature updates. Homegrown systems require commitment on the part of the organization to keep supporting and improving the application. This often means that you may need to have dedicated programmers that, over time, may leave or move on to other projects. As holes in your support network develop, you may be placed in a position where you will need to replace your application, or end up with a broken system and no way to get it fixed.
The downside to using a general-purpose program is that you will always need to adapt your business to the model that was used to create the application. This may be fine if you did not have a custom system in place, but be prepared for a lot of push back from staff when you move from something that fits like a glove to an “it sort of works” product.
I am certain that making the best choice between homegrown and commercial software (cloud or locally run) is a very complicated and possibly game-changing decision. You will need to completely understand the business process that is being controlled by the system in question, as well as: the people who will be using the new system, the data being processed, and the security needed to protect that data. Once all of these and other factors have been analyzed, the decision should come down to a matter of usability, support and the ability of the new system to get the job done, with room for expansion.
Please do not make the decision based on money—you will be greatly disappointed, and usually in the end, spend a lot more money to get the functionality you thought you were going to get.
You Might Also Like
