Soft Coding and The Enterprise Rules Engine – Millions of Dollars Worth of Waste

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:

  1. Insufficient time spent on design and the financial implications of design. Particularly relevant quality attributes that get neglected include modularity, testability and maintainability.
  2. The desire to include non-technical (non-programmers) in logic specification.
  3. 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.
  4. Insufficient time spent considering the implications and effects of product vendor lock-in.
  5. 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.

One Year To Get Productive On Codebase = You’ve got Architectural Problems

I recently met with an individual for a chat in my home town of Wellington, New Zealand who stated that it takes his engineers a year to get productive on their huge, monolithic Ruby on Rails codebase.

This in itself is astounding, as its an unusually long time-period. But it does make sense when one considers that no matter what framework or language you may be using, if you have not spent sufficient time on your architecture up front then you will pay for it at some time in the future.

Having dabbled with Rails, it is not surprising that a Rails application can morph, over years, into a large scale enterprise application that cannot easily be architecturally redesigned to enhance its modularity, testability and other quality attributes. But perhaps this does not matter so much if you are making tons of money.

MonolithLater and MonolithFirst Arguments

With microservices architectures being topical, its interesting to note that there are “Don’t start with a monolith” and “MonolithFirst” arguments out there with Martin Fowler falling into the latter camp. Mr. Fowler essentially argues that having architectural problems to solve is a better place to be with an exception to this rule of thumb being a system rewrite.

It may be hard to scale a poorly designed but successful software system, but that’s still a better place to be than its inverse.