One of the fascinating things about rules is just what you can do with them once there is a convenient way of making them work automatically. That means rules engines and, while it may be easy to assume that automated rules processing and management is of necessity still quite simple, there is a subtlety growing in that business which is showing all the signs of moving beyond the ability to run just a process, and onto the ability to genuinely manage complex issues.

Take, as an example, some recently undertaken work by rules engine vendor, inRule, on behalf of an outsourcing and remote hosting service provider. It is easy to imagine where a rules engine would fit into that environment. It would be monitoring such areas as the capacity and predicted loading on available resources, for example, so that the system kept running as well as possible. It would be comparing contracted service levels against current and predicted levels given the overall upstream workload and capacity available.

The objective here would be, not unreasonably, the protection of the business of the outsource/hosting company – make sure the systems do not: a) dig a hole into which the business falls and, b) do not continue digging furiously if a hole ever gets started.

What this can mean, of course, is that when such a hole is spotted, the system will self-protect in the following order: itself; those priority customers with the most stringent Service Level Agreements and/or most punitive penalty clauses; the rest.

This is not a criticism, it is a fact of life and, in practice, it will often be the case that such a hole appears and grows at a rate which does not allow a company to do anything to civilised – like give `the rest’ a reasonable level of advance warning.

But what if it could? What if it was able to warn customers of an impending problem? It could even set up a situation where those customers could themselves take actions that reduce the possibility of such a hole getting deeper. This is the area inRule has addressed. In effect, the rules that manage the internal operations of the outsourcer feed results to additional rules engines that work out what status advice should then be given to customers. Such advice will obviously be driven by the resource utilisation demands and SLAs contracted with individual customers, but even for the lowliest of them the impact can be useful – in both directions.

For example if a lowly customer, with the worst SLA terms, still gets a warning that its service may go AWOL in three minutes it has time to make a decision – risk running an upcoming large process or defer it? OK, late running could upset its own customers but that would be better than dropping them down a hole not of their making. And the act of deferment could be just what is needed to reduce the demand on resources and keep everything operational.

It seems that there is considerable scope for infrastructure management to move to the next stage – the ability to manage automatically the ebbs and flows of workload through a growing complex of nested rules, each one feeding the next in the chain, both down it and up.

Somewhere, I suppose, such an environment will ultimately end up with a Tolkien-esque world where there is One Rule To Bind Them.