Business System Design:
Why We Do Custom
Ease of Use
Rule 1: Software should be judged by those who use it.
Users have the best ideas about how business systems should work, they're strongly motivated to improve efficiency because it makes their lives easier.
If users don't like a system, this judgment is almost certainly based in a lack of efficiency that has a direct, negative bottom line impact.
Rule 2: Gathering requirements is not complete until users have been given time to compile a list of everything that's missing... from a live system.
Planning tries to define all requirements up front, but people think completely differently when you put a working system in front of them. No system's requirements list is complete until users have actually used it to do real work. This is a fundamental truth of all the tools we use, not just applications.
Experienced developers are well aware of this and deploy working systems early, deliver in increments, and solicit feedback throughout the process. Modern development calls this "agile", but it's simply common sense.
Ease of Change
Rule 3: A business system's databases design must always be a direct embodiment of the processes it supports.
Databases with designs that do not faithfully reflect the actual meaning of the data they contain, or can't change with changing requirements, create a technical dissonance that leads directly to the primary failure mode of all business applications.
Ease of updating, especially ease of updating database design, is by far the strongest indicator of the quality of a business system's technical execution. This is achieved through simplicity in application architecture, appropriate use of automated tests, and avoiding excessive abstraction.
The Benefit of Legacy Systems
Replacing a legacy system isn't "throwing away" work: when designing new systems, having a legacy system for reference saves a substantial amount of effort, because development is able to start with very well-defined, well-understood requirements - even if they're known only in contrast to what's currently in place.
Legacy systems can communicate valuable institutional knowledge in a precise way that even good documentation can fail to match. Even a bad legacy system is not a failure, it is an advantage.
Custom is King
Reusable systems work for some functions such as accounting, but for most, no one application can encompass all the variation encountered from business to business.
This is a big problem for COTS because customization tends to fail: shared systems must contain generalizations that strongly constrain design. Configurable is complex, and complex is not flexible.