In a traditional business application, you implement the business rules by analysing the requirements and then developing lines of program code. Erudine’s Behaviour Engine (“EBE”), a Java-based package that runs on Windows, Solaris or Linux takes a different approach: it still implements the logic of your business rules, but the majority of the design and construction work is handled graphically.

Of course, there are plenty of packages on the market that use GUIs to make the development process easier and faster, but EBE turns the whole development process on its head. In a traditional model you work out what the business rules are, then you write the code, then you work through a cycle of testing and refining/correcting the code until the output is correct. With EBE you work out what the inputs are and what the outputs should be, and then you work backwards from the differences it discovers between the “correct” answer and the answer it’s worked out, to “explain” to EBE why a particular input gives a particular output.

An EBE application starts with a model of the data you’re using, with relationships defined between the various entities. Imagine for a moment that you’re in the travel industry (where I spend most of my time) building a system for taking holday villa bookings. You’d have concepts such as customers, hotels, rooms, bookings and so on, and just as you’d define these as objects in, say, a Java application, you do the same in EBE – albeit via the Java-based GUI. You’ll also define the relationships between the objects (so a customer object would have an address objects, perhaps). Obviously you’ll need the system to communicate with your existing systems and those that they’re integrated with. EBE has a variety of interfaces to messaging mechanisms such JMS and IBM MQ, and can interface to databases including Oracle, SQL Server and MySQL. If you have something wackily proprietary, you’ll therefore have to do a little bit of work building some “glue” programs to bridge the gap between what you happen to have and one of the interfaces EBE provides.

Once you’ve defined the entities in the system, you can have a first go at the business logic. In the first instance you’ll do this rather as you would in the traditional programming model, by working with those who understand the business rules (the "domain experts", as Erudine terms them) and deducing the fundamental rules of how to work out prices and such like. Once you have your basic logic set, you can set about adding them to EBE via the GUI. The graphical model is pretty flexible, and it lets you define the rulesets in the natural way you’d think about them: by abstracting the functionality into high-level modules and then drilling into each module to add more detail. With a complicated system the view of boxes and links can start to look a little spaghetti-like, but the ability to split things into layers and drill in and out does a decent job of preserving comprehensibility. The GUI itself takes a little bit of getting to grips with, but this isn’t in itself a problem because your first project will generally involve Erudine’s staff working with you to guide you through the process; the idea is that over time their involvement will decrease as your staff’s understanding and abilities increase.

If you’re thinking that this all sounds just like what you’re doing already in Java or .NET, you’re not far wrong. But once you’ve got the basic model defined, the clever bit is just around the corner. You’ll obviously want to test the system by giving it input data and checking that it produces the right output. The easiest way to do this in EBE is to provide it with a set of test input data and a corresponding set of expected output data. It’ll then rattle through the data and flag the items where the calculated output doesn’t match what you told it to expect. You can then refine the logic in the system to deal with these anomalies.

Let’s go back to our holiday villa example, and imagine that our initial logic came up with the price of £1000, instead of the expected £750, for a particular villa in Portugal. We’d go back to the domain expert and say: “Why is this one only £750? The system’s correctly priced 5,000 of the 5,100 datasets, so we can be reasonably sure the basic logic is sound – are we missing an exceptional case?” The answer might be: “Ah, yes, we give a 25 percent discount on villas sleeping eight or more if the party size is fewer than six people”. So you return to your logic GUI and add an extra calculation to reflect this new-found fact, and let the system recalculate the anomalies. After a while spent refining the logic and adding rules, you’ll be down to an empty anomaly list.

You’re probably thinking at this point that what you have by now is not necessarily a correct set of business logic – it’s merely a set of rules that transform an arbitrary set of test data into an arbitrary set of expected output – and it takes no account of cases that we simply didn’t think of when writing the test data. And you’d be right. Where EBE actually comes into its own is when you want to replace the legacy application that you’ve had since the year dot, and which runs on a server with a big handle on the side that someone has to wind up every morning. The older an application, the more comprehensive the set of test data – and expected output – you have available. If you work through an EBE development with several million historic input/output sets, and you eradicate all the anomalies, you can be reasonably confident that you’ve covered all the bases. An example I’ve seen is the redevelopment of a payroll system for a public-sector industry; the development process resulted in around 1,600 rules in the EBE, but as the system had a vast amount of historical data to compare with its own output, they can be confident that the system is producing data that’s at least as correct as the legacy application it’s replacing.

With vast sets of rules in the system, performance is of course a potential concern. Erudine is understandably reticent when it comes to describing precisely how the core of the system works. As you’d expect with this type of package they’ve designed and written it to scale sensibly in a multi-processor setup, either SMP or MPP. The bit they’re not telling is how it recalculates the execution plan for the various rules in the system – ie how it spots that, say, a particular clump of rules is extraneous and that not bothering with them has no effect on the output.

There’s a problem with putting your system together with this process of working backwards from the data – namely that many organisations, particularly the larger ones, have process methodologies that require the production of documentation describing the business logic. The answer is simple: once you’ve built your system graphically, you have the option of asking EBE to produce a human-readable version of the decision collection you’ve defined. Now, I can’t claim that the prose reads as fluently as a Mills and Boon paperback, but it is understandable and it should address many of the documentation requirements of the project process.

Although EBE is marketed as both a legacy replacement tool and a system for developing new business systems, it really comes into its own in the legacy context, because this is the realm in which you’re most likely to have wads of legacy data to exploit in the development process. Incidentally, although EBE will undoubtedly chop a significant amount of time off your development cycle, don’t expect miracles: you’ll still have to spend time with those who know the business processes in order to investigate and deal with the various discrepancies the system identifies for you. Additionally, it’s not a small business toy: the benefits of this type of system are to be had in more complex projects, and a typical starting point for the cost of rolling it out is of the order of £50k+.

In short, then, EBE is unusual and very clever. The vendor has taken a refreshingly new look at how to engineer business systems, and the resulting product is intriguing and well worth a look, particularly if you’re faced with the task of re-engineering or replacing one or more legacy systems.


The first project will usually be a joint effort between Erudine and you, though once you understand the system there’s no reason why you can’t handle future projects on your own.