The traditional information engineering approach advocates the placement of as much business logic as possible inside the database management system (DBMS). More recently, under the umbrella of service-oriented architecture (SOA), folks are arguing for placement of that business logic in a layer of code outside the DBMS. Occasionally, those who favor locating business logic outside the DBMS have even gone so far as to say that this logic “naturally” belongs in a non-DBMS-supported layer. Apparently, to these individuals, triggers, functions, and so forth are viewed as unnatural objects.
Beyond these obvious pieces of code that can reside within a DBMS, many would argue that foreign keys, data types, and data population optionality also qualify as business rules. Unfortunately, those in favor of leaving business logic outside the DBMS often ignore these various details and will not acknowledge any problem whatsoever with foreign keys, data types, and optionality. Certainly, if one has multiple business functions accessing the same data, having logic loaded and reused inside the DBMS does suggest the most simple and direct approach, doesn’t it?
Data access for reporting and analytics functions is accomplished via all sorts of tools distinct from the SOA’s business logic layer. The reporting and analytics functions often appear as a world unto itself, with different rules from the operational side of the house. Justifications for this non-SOA approach frequently cite the fact that these functions use a separate copy of the data, and that these functions are mostly performing read-only operations.
However, any assumptions about a separate but equal “operational versus analytics” environment don’t necessarily hold true. With CRM and other analytical-slanted processing, real-time data values are being created, which scores customers for one thing or another. Analytics processes now create new data content, the same as an SOA function, and the results from those functions are often used operationally. Possibly worse, it is not unusual for a prototype or proof of concept to become a final solution, regardless of tools used or the ways those processes may or may not fit into a defined “business logic layer.”
Repeatedly, the confusing nature of these arguments and counter-arguments may result from a deeper misperception over the distinction between logical and physical ideas. A logical business logic layer might not preclude a physical implementation of business logic from including the DBMS via triggers, functions, and more. Potentially, the distinction might be nothing but perspective. Business logic implemented in triggers, in some distinctly DBMS layer, or through the use of an otherwise isolated analytics engine might still be considered part of a clear and separate “business logic layer,” as long as it is plainly documented. Maybe some term other than “business logic layer” would fit this situation better—something that might make it easier to observe the dividing line between purposes more clearly but still prevent the need to ignore foreign keys and data types serving as business rules. How shall we choose to define and sculpt our architectures logically?
Consider that the issue may be much larger than mere business logic. We may yet be in the infancy of coherent programming/computing/analytical thought. Do we desire a clear, solid, and justifiable logical approach that will serve as a theory of everything? Instead, today we are routinely bombarded with physical implementations that are surrounded by never-ending sales pitches which claim logical gravitas for a product’s physical variations. Are there infinite arrays of possible logical solutions if we simply grab them for the taking, allowing us to avoid having vendors or pundits sell us a given category of a solution as a single approach? Clear advantages exist in exploring possibilities, because possibilities may be all we have to work with and our choices may define a new best practice.