Rules Based Applications

Transcription

1 White Paper April 2014

2 RULES BASED APPLICATIONS Rules and Applications where is the separation and does it matter? Most people think of business rules as a modest amount of precisely targeted business logic 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 view can be productively extended to obtain much more value from any effort being invested into business rules. This effort is mostly expended in detaching the business rules from the underlying application, and then making them available for development and maintenance outside of that application s SDLC. Ideally, when we have extracted these rules we would hand them over 100% to their respective business owners; however this is a goal that still eludes many. Perhaps if there was more value to be harvested, more effort would be invested in this worthwhile goal. The first and obvious scope extension that can help us to obtain more value from rules 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, including values, dates, and text. For instance, deriving costs and prices, setting trigger dates, and compiling printable text are all things that are often business defined. The people who are targeted for the more traditional business rules as described above are almost certainly the same people who own these other values the separation between these classes of rules is 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. 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 a language gap between the language of the real world data and the idiomatic language of the business rules that must be addressed. 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, policies, and (lowest in this hierarchy) the rules which ultimately govern its behavior. For those seeking more background on this discussion, please read Decisioning the next generation of business rules (recently published on both the Business Rules Journal and Modern Analyst). The rules in this case 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 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. Copyright IDIOM Limited 2014 April 2014 Page 2 of 8

3 In order to apply the higher order, policy defined business rules (always in the form of decisions), 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 effort is made, the higher order policy defined business rules are unable to function. 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. 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. the Decision Model in IDIOM parlance. This is a useful point to recap we have now (re)defined the business rules scope as being everything involved in the transition of the raw business data describing an entity in one state to its return in a new state. This is an important observation it means that we can define all of the bespoke elements of an application within the business rules concept. So what is left in the traditional application? A series of generic event driven features and functions like searching, selecting and saving entities, applying business rules, and receiving and sending messages to other devices or locations (e.g. printers, webservices, queues, legacy systems etc.). These 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 static and externally defined, just like the realworld business data. And like that real-world business data, we can use rules to derive the system meta-data and explicitly control the system s features and functions rules are now 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, 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 use a variation of a common underlying architecture, which includes the following generic concepts: Business policy is defined and implemented by 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 (i.e. the transaction and all of its related entity and event data) is stored extant as XML in an XML column in the database. The context data can be large and complex hundreds of thousands of nodes with many nested levels of hierarchy and they only need to be understood by the rules that govern them. 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 data is also used to align any and all other systems, including legacy and accounting systems, with the latest transaction state. This data is extracted automatically by rote when saving, and then routed to meta-data defined end-points. Copyright IDIOM Limited 2014 April 2014 Page 3 of 8

4 Forward looking actions and events are created by rules as Bring-Ups (automated future events) and Actions (targeted events for human users). By building an application using the above design approach, 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 approach: In the above diagram, we can see the context data (the transaction XML document) stored as SoldProductXML in the Sold Product Instance table [blue]. Note that 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 this transaction XML can be found in the DecisionModelBinary column of the Decision Model table; IDIOM now routinely loads the decision model dll or JAR directly from the database (at least in those environments capable of it). The policy configuration parameters are in the ProductConfigXML in the Product table [green], and are delivered to the rules each time they execute. Copyright IDIOM Limited 2014 April 2014 Page 4 of 8

5 The Financial Entry, Bring-Up, and Action table rows are generated by the rules within the SoldProductXML and are automatically stripped off by the database handler when saving the SoldProductXML. The following two diagrams provide a high level view of the overall IDIOM approach, centered on the IDIOM Decision Manager in the first diagram. The second diagram highlights the Decision Engine and a sample set of decision models. 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. This code is compiled and executed behind the Decision Engine interface, all of which are provided in source code form (Java and/or C#) for peace of mind. Copyright IDIOM Limited 2014 April 2014 Page 5 of 8

6

7

8 Finis Established in 2001, IDIOM Limited is a private company based in Auckland, New Zealand. IDIOM develops and licenses decision-making software that automates business policy on a large scale, making systems more transparent and agile, while reducing development cost, risk, and time. IDIOM s innovative business oriented software is used by business users to graphically define, document, and verify corporate decision-making and related business rules; it then auto-generates these into small footprint, non-intrusive software components for use in systems of any type or scale. IDIOM is a pioneer in the development and use of decision oriented concepts, and has applied these concepts in the development of intelligent processes for customers around the world in local / state / central government, insurance /superannuation / finance, health admin / clinical health, telecoms, logistics, and utilities. IDIOM automated business policy and decision making extends far beyond mere business rules, so that ownership and control of larger and more complex decision making can be fully delegated to business experts. IDIOM enabled development and management of policy based decision making by policy owners creates a propitious business policy life-cycle that significantly improves business agility and transparency. IDIOM develops and licenses the IDIOM Decision Manager, IDIOM Forms, IDIOM Decision Tracker and the IDIOM Decision Manager Workbench. IDIOM Contact Details Mark Norton Director Idiom Limited Office Mob After Hrs Aust. Free Call Dominion Rd. Mt Eden Auckland 1024 PO Box Titirangi Auckland 0642 New Zealand mark.norton@idiomsoftware.com Skype Mark.Norton