Part 1: Introduction to IDIOM
In practice, the business object definition (which is described in the form of an XML Schema) that is imported into the IDIOM Decision Suite provides the definition of the term, fact and some action assertion categories of business rules, while the IDIOM decisions provide the dynamic business rules.
This distinction separates the rules into those that are static and those that are dynamic; more or less into those that are the day to day concern of IT and those that are the concern of the business. IDIOM is specifically designed to allow the business to control the second category of rules directly, without recourse to the traditional Systems Development Life Cycle.
The lack of inductive inference derivation imposes the only restriction on the type of problem domains that IDIOM is suitable for. Specifically, IDIOM is not suitable for the types of problem that require artificial intelligence or inductive reasoning to solve, nor highly recursive problems (for instance `the salesman’s journey’ problem). This is consistent with IDIOM’s stated objective of ‘managing and deploying the decisions that you know how to make’. This focus on managing the business’s declared knowledge allows IDIOM to provide significant performance and testability benefits when compared with AI systems.
IDIOM is ideally suited to the following categories of problem:
- Definition and automation of contracts such as insurance and funding contracts, financial instruments, performance contracts, privacy etc.
- Context-aware and inter-field validation and transformation.
- Management of systems configurations and settings.
- Governance of business processes in an automated system.
- Replacing human decision makers in real-time transactions
The IDIOM Decision Cycle
The prime purpose of IDIOM is to enable a business to capture decision ‘formulas’ without error, and then to deploy them efficiently and at low cost into existing or new computer applications.
The IDIOM Decision Suite is a tool for capturing and deploying ‘the decisions that you3 know how to make’. It provides a desktop environment within which the user can define and capture the rules that support business decisions. These are accumulated into a repository, and then transformed into executable code for deployment into computer systems.
The starting point for using IDIOM is therefore a sound understanding of the decisions to be implemented4. Typically, IDIOM is driven by a Business Analyst or the business domain owners themselves - we see an even mix of these approaches. If an analyst is used, the analyst interacts directly with the business domain owner – that is, the expert who controls the decision making process. This interaction may be a simple discussion or it may be more formal. Armed with an understanding of the decision, the domain expert or analyst uses IDIOM to clarify and document the logic that describes the decision.
The specification of this logic is called a formula. IDIOM provides a flexible and structured tool that enables the formulas to be completely defined faster than documentation based alternatives. The emphasis on completely is deliberate. Most approaches for documenting business decision-making processes do not dictate completeness, resulting in unclear or ambiguous definitions. A common deficiency (in our experience) is the clarity with which decision variables (terms) are identified. IDIOM, by contrast, demands that all decision variables are explicitly identified as part of the formula definition process.
The approach to defining a formula can be compared to defining formulas in Excel. All steps are wizard-driven, and may be done in any order. At all times, unresolved arguments are tracked by the Formula Builder. When all arguments have been resolved, the formula is complete.
The analyst then prints the formula in ‘logical English’ and confirms it with the business process owner. Logical English (rather than colloquial English) uses logically structured but otherwise non-technical phrases, and is readable by a business audience. It requires no training, making it easy for the business owner to understand and verify the accuracy of the formula. This confirmation closes the construction loop. When all formulas are complete and ‘Quality Assured’, the Repository Document is released to production. Released formulas can then be changed by introducing a new effective dated version of the formula.
This process is encapsulated in the diagrams below (Fig 1a and 1b), which also contrasts the IDIOM approach with traditional techniques. Note that the entire knowledge definition cycle, from concept to deployment, is an efficient ‘closed loop’ that minimises cost and time, and reduces opportunities for error.
Figure 1a: The Old Way
Figure 1b: The IDIOM way