Business logic in information systems

There are a number of things you can use to get an interesting (and sometimes heated) discussion going amongst technical professionals. One of them is the issue of where to store business logic in an information system.

Some advocate for storing business logic is in the database. The argument is that business logic is enforced without regard to, and independently of the front-end application used to interact with the data. The opposing argument wants to place business logic solely in the application code. The argument here is that more complex business logic can be implemented in program code, and that program code is more easily maintained than database structures, relationships and constraints.

The best discussions on this topic recognize two important and overriding facts. First is that the answer to this question (as is the case for most technical and business questions) is "it depends". The second fact is that for better or worse, some business logic is stored in a database, even if it's only the association of business concepts by placing columns to represent them into a common table.

Many business and technical decisions represent trade-offs of risks/costs and benefits, and this issue is no exception. Relying primarily (or in some extreme cases almost exclusively) on program code to enforce business logic places a much greater burden on development resources. In addition, this burden increases over time as the system becomes more complex in response to user or client demands and changing business requirements. The result is increased development costs, longer timeframes to implement changes and enhancements, longer testing cycles and increased error rates.

Placing more logic into the database requires more time and effort to create a database that accurately reflects the business processes being modeled. Such a database is capable of accomodating the continual change that most informations systems endure. This requires more resources to collect requirements and do proper data modeling, as well as more time to bring the initial release of the system on-line.

Clearly the two approaches differ qualitatively in terms of their costs and benefits. However, in the business context the long-term benefits of placing more logic into the database are realized in the ability of the company to maintain a competitive advantage through reduced maintenance costs and the ability to quickly respond to changing client/customer/user requirements and changing business conditions and processes.

The business decision should come down on the side of a greater investment up-front in the system - particularly in the data modeling - to avoid eventual vulnerability to competitors who don't have the accumulated issues that arise from relying solely on program code and programming resources to keep up with business requirements.