Imagine the following scenario, a basic business rule (read logical) change in an enterprise (read complex) application which could and should be tested in under a second, takes an hour to test. Now imagine repeating this process countless times over years with hundreds to thousands of business rules – at vendor software development rates you’ve got millions of dollars wasted.
How on earth could one have such a scenario? Surely its madness to waste ridiculous amounts of money on highly inefficient processes. But its not, it happens time and time again. The harshness of these words however have no place in the field of software engineering and software architecture – we must look at the engineering tradeoffs involved when including a rules engine and perform a quality attribute analysis. While we will not look at the enterprise rule engine in terms of a quality attribute analysis (this should be in the SAD of a given enterprise system which will have its own enterprise context), its worth looking at opinion pieces that in effect do point out certain quality attributes of enterprise rules engines. One such piece is the article Soft Coding by Alex Padadimoulis. Soft Coding is broadly defined, by Mr. Padadimoulis as
the practice of removing “things that should be in source code” from source code and placing them in some external resource
Mr. Padadimoulis goes on to say
The reason we find ourselves Soft Coding is because we fear change. Not the normal Fear of Change, but the fear that the code we write will have to be changed as a result of a business rule change. It’s a pretty silly fear to have. The whole point of software (hence, the “soft”) is that it can change that it will change. The only way to insulate your software from business rule changes is to build a completely generic program that’s devoid of all business rules yet can implement any rule. Oh, and they’ve already built that tool. It’s called C++. And Java. And C#. And Basic.
In my experience, some of the reasons why an enterprise rules engine (which may manifest itself in many forms, including Excel or even a vendor GUI of some sorts), may be used, rather than say a regular programming language, include the following:
- Insufficient time spent on design and the financial implications of design. Particularly relevant quality attributes that get neglected include modularity, testability and maintainability.
- The desire to include non-technical (non-programmers) in logic specification.
- No experience with continuous integration or continuous delivery. It may be that just about everyone concerned has been burned by non-delivery, for whatever reason.
- Insufficient time spent considering the implications and effects of product vendor lock-in.
- Consulting software vendor interests not sufficiently aligned with the clients interests. For example, including an enterprise rules engine may lead to more business (hours sold).
It may be that its possible to include an enterprise rules engine in an efficient, streamlined delivery cycle. Regretfully I have not seen this happen.