Making enterprise (and other) applications more configurable has been one of the pursuits in many of my past projects. The extra effort to open up enterprise applications for enhanced adaptability surely pays back the extra investment. Of course, one may go to the other extreme and end up in over-engineering. So the challenge is somewhere in between hard-coding and decoupling what’s in code and what needs to go via configuration. One aspect is about having an idea or even a vision of what can and might change in the future. Yet, even if we have a good idea of what might change in the future it’s in many cases not trivial to make things configurable, simply because configurations don’t always fit in basic parameter settings.
The use of arithmetic or logical expressions, also called formulas, is an interesting way to push the adaptability of a business application beyond simple parameter configurations.
Business logic as found in complex enterprise applications is a typical aspect of application architecture that demands for a configurable setup but is not trivial to handle thoroughly. Before thinking about configurable business logic. Let’s first consider the software architecture, where the best practice is to layer or isolate the business logic from the rest of the system, like the presentation layer and data layer. Books have been written with advice on how to create such layering in software design. One of these excellent books is “Patterns of Enterprise Application Architecture” from Martin Fowler et al. Let me cite from this book’s introduction:
<< Then there’s the matter of what comes under the term “business logic.” I find this a curious term because there are few things that are less logical than business logic. When you build an operating system you strive to keep the whole thing logical. But business rules are just given to you, and without major political effort there’s nothing you can do to change them. You have to deal with a haphazard array of strange conditions that often interact with each other in surprising ways. Of course, they got that way for a reason: Some salesman negotiated to have a certain yearly payment two days later than usual because that fit with his customer’s accounting cycle and thus won a couple of million dollars in business. A few thousand of these one-off special cases is what leads to the complex business “illogic” that makes business software so difficult. In this situation you have to organize the business logic as effectively as you can, because the only certain thing is that the logic will change over time. >>
Even it’s certainly an important improvement to isolate business logic in a dedicated layer, yet having it configurable without code changes is also important. Isolating business logic in a well-crafted layer, makes the practice of development easier, more qualitative and so on. Still changes in business logic do require code changes. Getting software changes integrated in live production systems takes time and effort even if the most agile development methodologies are applied.
A serious attempt to improve this is to ‘program’ the business logic in a dedicated domain language, a so-called domain specific language (DSL) . A well-designed DSL that is expressive enough to describe the logic of a given domain and yet sufficiently high-level and easy to use so that there’s a significant advantage over programming in the system’s language (java, C++, Ruby, Groovy and the other new kids on the block…). These DSL can be very beneficial, still it’s difficult to call this configurable business logic, since this typically requires programming skills to implement such business logic.
The goal is to obtain a business application that is generic enough to represent most business models in configuration or even a run-time context. This is the case with most (but not all) software products. Office applications like a document editor (like MS Word, Apple Pages, Open Office Writer, …) or spreadsheet applications (like MS Excel, Apple Numbers, Open Office Calc, …), drawing programs, and other are all examples that in most situations don’t use much custom programming to be used effectively in a certain domain. Business software products try to achieve the same with different means from simple parametric configuration to more advanced custom or generic programming languages. Both In my opinion, the interesting ones are within, with a good balance between simplicity and power.
The use of logical expressions, like formulas in Excel, is one technique that is situated between simple parameteric setups and full-blown program scripts to customize. Like program constructs, expressions are formal notations to allow to specify conditions in an unambigious way. The fact that no special programming skills or knowledge of specific language paradigms are needed to create and edit logical expressions is certainly very attractive. Of course, some knowledge and awareness of syntax is required and it doesn’t read as plain text. Not that it’s as trivial as setting a parameter value such as a price or description, but many people are pretty familiar with logical expressions. The concept of formulas is often used in math, physics, economy and other courses; so most people are pretty familiar with these. Also most product managers, marketeers, engineers and of course software developers know how to deal with formulas. This allows for a much broader target group to do configurations, non-programmers, including business analists, marketeers, etc. to customize applications.
Not only in my past projects, we could apply expressions with good results, but I see other applications applying this approach to do validations, personalization, product selection, dimension calculations (in CAD) etc.
Given the above reflections, the idea grew to elaborate this topic of logical expressions with regard to business logic somewhat further. In a next post, I might evaluate this a bit further.
Tags: business logic, configurable, expressions, formulas, linkedin, Software