Rules Based Applications

Mark Norton  28 April 2014 05:15:28 PM

Most people think of ‘business rules’ as a modest amount of precisely targeted business logic (implicitly Boolean in nature) that is injected into an application. This is a narrow view of rules that can be very limiting in terms of the value that can be harvested from implementing a rules approach.

While we can agree that this view does define rules as practiced by many – in fact it is the essence of the Business Rules Manifesto – the concept of rules can be productively expanded to obtain much more value from any effort being invested into business rules. In fact, we can extend the scope of ‘rules’ to embrace the entire business policy that defines how the business responds to events throughout the life cycle of its core transaction entities, regardless of the domain. In doing so we redefine the boundary between applications and rules, with significant benefits to both.

If we start with the limited scope of rules as implied in the preamble, the first and obvious extension that can help us to obtain more value is to expand the definition of rules beyond the boolean ‘constraints’ view espoused by the Manifesto, and embrace all forms of business defined derived-data, especially numbers, dates, and text. Examples of these additional business owned and defined values include costs, prices, and other values; trigger dates and related meta-data for workflow management; and dynamically compiled text and other messages for communication and agreement. The people who are targeted for the limited scope business rules as described in the preamble above are almost certainly the same people who ‘own’ these other values – any separation between these classes of ‘rules’ would be artificial in their eyes.

A second scope extension is perhaps less obvious, but every bit as important. Business rules are usually defined in an idiom (Defn: “A specialized vocabulary used by a group of people; jargon; a style or manner of expression peculiar to a given people.”). The language that forms the basis of the idiom is essentially proprietary because the behavior of the organisation is proprietary. However, the raw data in any domain typically describes the domain’s real-world entities in real world terms (by definition – the entities exist irrespective of the organisation that records them). There is almost always a language gap between the language of the ‘real world’ data and the idiomatic language of the business rules, and this gap must be addressed before the rules can be applied. This requires a step to validate the real world data as collected by the business, and to then transform it to align with the idiomatic phrasing used by the rules. Only then can the rules be applied and the business respond appropriately to the events described by the data. The idiom is the language used by the business to define its strategies, its policies, and lowest in this hierarchy, the rules, which ultimately govern its behavior (for those seeking more background on this topic, please see ‘Decisioning – the next generation of business rules’ as recently published in both the Business Rules Journal and Modern Analyst).

The ‘rules’ are the ‘sharp end’ of applied business strategy – they are the means by which business policies actually get applied to real-world entities and their events. These rules are applied within discrete, atomic units that we refer to as ‘decisions’. A decision in this context is a unique, business defined outcome that is derived by a specific set of rules (all of which must be applied as a single unit-of-work). We can draw an analogy with molecules and atoms – a decision is like a molecule; the smallest tangible outcome from a rules process that can exist in its own right. Whereas the rule is like an atom – essential as part of a decision, but cannot be used in isolation to achieve any particular purpose.

In order to apply the policy defined business rules we need to bridge the gap between the raw data and the business idiom. Ergo, an effective rules engine must also be a data validation and transformation engine. In fact, our experience suggests that the vast majority of rules development effort is in the validation and transformation area. But unless this transformation is fully and completely achieved, the policy defined business rules cannot be applied.

Again, the validation and transformation rules are business defined (by definition) and belong in the same scope as the core business rules we started with – they are co-dependent, so that one cannot be useful without the other. There is no useful boundary between a business rule that derives an intermediate value from one which derives the ultimate business outcome – they are all just rules aggregated into decisions and ultimately into complete sets of decisions – a.k.a. ‘Decision Model’ in IDIOM parlance.

This is a useful point to recap – the above discussion has (re)defined the business rules scope as including everything involved in the transition of the raw business data describing an entity in one state, through to its return in a new (and valid) state. This is an important observation – it means that we can define all of the bespoke business elements of an application within the ‘business rules’ concept.

So what is left of the traditional application? At least a platform infrastructure that includes resource management, authentication and authorization, etc.; and a series of generic, event driven features and functions like searching, selecting, opening, and saving entities; applying business rules; and receiving and sending messages to other devices or locations (e.g. printers, webservices, queues, legacy systems etc.). The latter generic capabilities can be controlled by meta-data that is defined by the real-world capability of the feature or function itself – their meta-data is externally and statically defined, just like the real-world business data. And like that real-world business data, we can use rules to derive the system meta-data and so explicitly control the system’s features and functions – rules become the business owners ‘remote control’ for the system.

The above now implicitly defines a generic application that can service virtually any commercial need provided that the appropriate rules are supplied to define and apply the relevant business policies, and to then drive the supporting application features and functions (via their respective meta-data).

Such an application is not hypothetical! IDIOM has now built many such applications for organisations large and small, all very similar in concept and architecture to the application described in our paper Architecture for Agile Provisioning of Financial Products and Services.

Most of these applications have used a common underlying pattern, which includes the following generic concepts:

·        Business policy is developed, defined, and implemented using a mix of rules and configuration documents, all of which are stored in the database, and which are themselves controlled by rules.

·        The context data (meaning the entity and all of its related transaction and event data) that describes the current state of the entity in its entirety is stored extant as XML in an XML column in the database. The context data can be large and complex – often hundreds of thousands of nodes with many nested levels of hierarchy – and only needs to be understood by the rules that govern it.

·        Most other traditional database column values are generated by the rules, and only exist to provide database indexes or for the special needs of other (less agile) applications.

·        Rules generated messages are used to align any and all other systems including legacy and accounting systems, with the latest entity state. This data is extracted automatically when saving, and then routed to meta-data defined end-points.

·        Workflow is fully managed by rules that create forward looking actions and events – for instance ‘Bring-Ups’ (automated future events) and ‘Actions’ (future events for manual resolution). These Workflow triggers are declared in the database for each entity, and are fully replaced for the entity every time the rules are run, so that the entire life cycle of the entity is inherently managed.

By building an application using the above design pattern, development time, cost and risk can be reduced by an order-of-magnitude. And the business will love you for an application that empowers them while still hiding the technical complexities.

For those familiar with data design, the following sample database schema provides some insight into the underlying architecture of the design pattern:

In the above diagram, we can see the context data (the transaction XML document) stored as ‘ContextDataXML’ in the Core Business Entity table [blue]. For commercial domains of even modest complexity, this simple design concept can save us from having to build and provide application support for perhaps hundreds of database tables; nor are we constrained by the incredible development inertia that is implied by large fully normalized database designs. As a bonus, query performance against this structure can be better than with standard normalized database schemas because joins are rarely required. Also, full text search on the XML column can provide instant Google like search over the full extent of the database.

The rules for managing the full, business policy defined life-cycle of the ContextDataXML can be found in the ‘DecisionModelBinary’ column of the Decision Model table [green]; IDIOM now routinely class-loads the decision model dlls or JARs directly from the database (at least in those environments capable of it). Various business policy configuration parameters that relate to the particular type of entity that is in focus are in the EntityConfigXML in the Entity Class table [green], and are automatically delivered to the rules each time they execute.

The Financial Entry, Bring-Up, and Action table rows are generated by the rules within the ContextDataXML and are automatically stripped off by the database handler when it is saved.

The following two diagrams provide a high level view of the overall IDIOM approach, centered on business policy development and testing using the IDIOM Decision Manager in the first diagram. The second diagram outlines how the business policy is deployed and eventually executed using the Decision Engine (and a sample set of decision models by way of example only). The green arrow linking the diagrams is used to indicate the flow of decision models, which are exported in a manifest that includes generated source code for each model (a JAR or dotNET assembly). This code is compiled and executed behind the ‘Decision Engine’ interface, which is also provided in source code form (Java and/or C#) for complete peace of mind.

Diagram 1:

Diagram 2:

Finis

• Comments [0]