Disruptive technology and business outcomes

Every so often, you come across what seems like a genuinely disruptive (in the sense that it makes you rethink what is “good practice”) technology and Erudine’s “behaviour engine” may be a case in point. In essence, it turns the conventional approach to development on its head: instead of working out what the product should do (in conjunction with end users, if you’re lucky), designing test cases for these “requirements” and then building and testing the system, with Erudine you look at the existing business system, whether manual or automated, and collect its inputs and the business outcomes corresponding to them. The Erudine engine then assures you that these inputs will always result in these outcomes and, after a confidence-building period of parallel running, you can cut over to the Erudine engine for production.

So far so good. You have an executable model of the status quo—where’s the business return in that? Well, automating a manual system (or developing a new one) brings obvious efficiency benefits if you’ve got the requirements right. And the Erudine engine runs on modern hardware platforms and this may let you retire a legacy platform. However the main return comes from the fact that the Erudine “behaviour engine” model is easily maintainable, whereas your status quo probably isn’t (and Erudine would claim its models are generally more maintainable than alternative technologies). If you don’t like behaviour in your current model—perhaps it tells you to politely refuse a customer with a poor credit rating, when you’d like it to initiate a call to the local police station—you simply tell it about this new behaviour and explain why it should now be invoked. For example, something like: “…IF bad customer (IF customer is also carrying a weapon THEN call police ELSE turn away nicely) THEN reject loan…”. This new behaviour may well be incompatible with other behaviours, of course—in which case, the contradictions will be brought up and you will explain which behaviour is “correct” in each case and which factors drive this decision. You can take a legacy system with implicit and/or embedded, undocumented, domain knowledge that makes it largely unmaintainable and transform it into a system that behaves in the same way but with a behaviour that can easily be changed with the application of current domain knowledge at the point of change.

And this doesn’t just apply to legacy modernisation. If you want to build a “requirements model” for behaviours you don’t have yet, Erudine can implement its behaviour and, if you think about the description above, it is easy to implement the most common behaviours first, so confidence in the model rises rapidly. And your new system will be maintainable, because the Behaviour Engine is, in effect, a complete set of regression tests for the “status quo” system behaviour. If the behaviour changes, this will be because you’ve told it to and added the factors driving the new behaviour.

The devil is in the detail, of course, and there is a sophisticated underlying mathematical model of behaviour and the automatic consistency checking based on “knowledge management” with “conceptual graphs”. Erudine keeps this mathematical underpinning largely private; it’s the company’s prime intellectual property. If you want to learn more, Erudine can supply (no prescription needed) a trial ‘headache cure’, a package containing a USB software capsule containing a demo version of the Behaviour Engine, various white papers and training documents and even a full version of the Engine. It would be unfair to say that this pill guarantees you a good night’s sleep—but it does contain plenty of serious reading.

Erudine’s secretiveness about the mathematics behind its engine was a stumbling block in its early days and most of its first customers came to it in acute pain—with a legacy system, typically, that they could neither maintain, nor emulate, nor replace. This overcame any risk associated with adopting a solution from a comparatively unknown company and Erudine demonstrated on several occasions that it could turn failure into success. It could also demonstrate that even if the internal workings of the Engine itself weren’t accessible, the end result documented the behaviour of the customer’s organisation very clearly and transparently This was when we first met Erudine and you can see our initial thoughts here.

The company is now entering stage two of its evolution. It has documented collateral showing that it works, reasonable capital investment and a strong partnership with EADS, delivering decision support systems in the defence and security space. It’s no longer just replacing legacy but increasingly being used as an innovative way of developing and maintaining new systems. However, it still has a consultancy arm, actually developing Erudine solutions for its customers—Erudine is new technology and its customers don’t feel entirely happy taking it in house (or, perhaps it is thinking of behaviours and knowledge that worries them).

Stage three of the evolution will come when customers feel comfortable taking the Behaviour Engine entirely in-house and working with the concept of behaviour for themselves. Erudine will then be where it wants to be—developing the Behaviour Engine as a routine development tool. But will the Erudine Behaviour Engine become the status quo for software development? Experience suggests, probably not, as new technologies have seldom entirely replaced old ones in IT so far. Possibly only the most mature companies, capable of managing risk and organisational behaviours, will take it up, although if you add in companies with real pain, that’s a potentially large market. There may also be an opportunity in emerging economies which have to catch up with the developed economies quickly; and where managers probably have less intellectual ‘baggage’ holding them back and making them risk-averse.

Nevertheless, remember that this isn’t a formal evaluation of the Erudine Behaviour Engine; it’s a ‘heads up’ for an interesting new technology that is maturing nicely. However, we are writing about it now, because it seems to fit well with another disruptive influence that we find interesting currently, ITIL v3, which talks about “integrating IT with the business” and focuses on “business outcomes” instead of requirements. This fits well with the way you develop with Erudine, as the model’s behaviour is driven by domain experts in the business and “behaviour” maps more immediately onto “business outcome” than the average IT requirements document ever does.

The degree of integration of IT into the business Erudine may catalyse was really brought home to us in a conversation with Phil Rice (CTO at Erudine) about the ethics of decision support in a life threatening situation—does the Behaviour Engine embody the ethics of the organisation or does the person at the sharp end make their own ethical decisions? And if they do, should this (or if the decision was bad, with hindsight, its opposite) be fed back into the Behaviour Engine? People often make the wrong decisions in the stress of the moment and, as the world seems to be becoming a more dangerous place, perhaps Erudine will find itself the right technology in the right place over the next few years.