Software: Packaged or Build
- Buy Packaged Software? Or "Roll Your Own?"
- When Packages Make Sense
- Evaluating Packages
- Selection Process
- Living with Packages
- Harris Kern's Enterprise Computing Institute
The mission of IT is to produce useful business applications by all means necessary. There are many tools and flexible software architectures that will make the job easier, make the software more bug-free, and make your programmers more productive. More IT managers have gone on the rocks by failing to bring internal development programs to completion on time and on budget than by any other cause. I hope to give you some tips that will help you avoid being one of the casualties.
Buy Packaged Software? Or "Roll Your Own"?
For many years following the introduction of computers to business in the 1950s, corporate IT departments assumed that they would write most of their business software. Larger corporations would hire staff programmers to write corporate information systems, and smaller companies that couldn't afford their own staff would use consultants to create data systems. Gradually packaged software emerged, at first to perform standard corporate functions such as accounting and payroll, and later to do other standardized functions such as purchasing, human resources tasks, and manufacturing. As technology has improved, packages have become more flexible so that they can be adapted to individual businesses, and packaged software is assumed to be suitable for most core business functions.
With the arrival of integrated enterprise data systems such as SAP, many IT managers assume that their data architecture can be built entirely around off-the-shelf software, and in-house capabilities can be abandoned or outsourced. Before you drop your IT capabilities, however, consider some of the issues in the use of purchased software and the implications for your business. Otherwise you may discover after you've let your programming team go that the package doesn't meet your needs and you need to "roll your own."