IDIOM Decision Manager
For 20 years customers world-wide have been automating their business policies using the IDIOM Decision Manager. The result is improved business efficiency, agility, and auditability, with assured alignment between computer systems and business strategy, all at much lower cost and risk to develop and operate.
Business policies that govern decision making are captured in graphical form as 'decision models', tested, generated into Java or C# source code, and embedded into line-of-business systems all directly from the IDIOM Decision Manager.
Today, with billions of lines of code generated and in production, IDIOM continues to empower its many business users in insurance/finance, health, government, and logistics.
IDIOM Decision Manager
- IDIOM Decision Manager is a tool for graphically modeling, testing, and deploying business decision-making logic, algebra, and business rules – without programming!
- A tool for the policy maker, not the programmer.
- IDIOM automates complex decision-making at the enterprise level, deployable as industrial strength stand-alone components.
- In day-to-day practice it is used by SMEs, or analysts working closely with them.
- Together they model the business policies in terms of both data and decisions (see Decision Model top right) before moving on to define the underlying logic that binds them together (see Formula in blue, top right).
- The decision logic and data are usually modeled together in a single combined process of analysis and definition.
- The data model and the decision model share the same ‘context awareness’, with current-context and context boundaries visually highlighted at all times within the development palettes.
- Testing of the models is available at all times within the development palettes themselves; full regression testing (incl. ‘model answer’ differencing) is available in the on-board ‘Test Executive’.
- Deployment as 100% generated software components is fully automated and ‘without fingerprints’.
The ‘Decision Model’
- Example in the adjacent screenshots (below) is a small but real model drawn from a city council implementation of policy that calculates financial contributions to be paid by property developers.
- The problem domain is decomposed using a ‘mind mapping’ approach until we reach the atomic units that we call decisions (rounded boxes).
- This ‘decision model’ and the adjacent data model (top right) are demonstrably aligned and integrated through shared context – validating and strengthening both.
- The data model defines the entity at rest; the decision model defines the valid state transitions. Together they completely define the entity life-cycle and required business policy.
- The atomic ‘decisions’ provide an easy entry point for specification of the underlying rules details via the Formulas.
- The underlying rules details are easily captured using a ‘Lego like’ drag-and-drop approach that is ‘more fun than playing golf’ according to the CEO of one of our largest customers – there is no scripting or coding available or required to build formulas.
- The rules can be tested immediately within the IDIOM Decision Manager palettes.
- When finished, IDIOM Decision Manager generates computer source code (C# or Java) with a single button click, to be called by any application at run-time using any of a wide variety of supplied interfaces and wrappers (in-line, dll, JAR, web service, queue service, and many more).
- And at the same time, it generates the models into business readable PDF documentation.
Key Points of Difference:
- IDIOM’s decision models do for decisions what data models do for data – a powerful abstraction that makes the underlying complexity visible and manageable.
- The models allow data transformations and more traditional business rules to be intermingled. Business rules acting alone are severely limited in their ability to fully resolve complex commercial problems – invariably, in-line data transformations are necessary to facilitate the calculate/adjudicate/act behavior of business rules.
- Context is continuously displayed and actively managed.
- Decision models that incorporate both data and rules behavior enable a further critical capability that is unique to IDIOM Decision Manager – the models can be fully tested using real-world cases directly in the builder palettes. No external technology or application support is required to empirically prove the completeness, consistency, and correctness of the models.
Key Points of Innovation:
- Fundamental redesign of the traditional SDLC by fully separating the development and automation of business policy (deciding) from development of the system’s activities that support it (doing).
- Use of IDIOM is effective in spawning a ‘Business Policy Development Life Cycle’ that is managed independently of and alongside the traditional System Development Life Cycle.
As a consequence, we achieve the following key Value Propositions:
- 100% alignment of systems-based decision making with business policy, because the business owners have hands-on custody and control of the policy definitions actually used by the system.
- Increased agility with reduced business risk through business modeling and empirical testing of policy definitions prior to automated generation and implementation.
- Significant reduction in the business cost of developing and implementing automated business policy.
- Further reduction in software development cost, time, & risk through reduced system complexity, fewer moving parts, & clear separation of concerns.
- Full auditability of policy changes, and visibility of policy implementation through the graphical models and logical English PDF generation.
- Decision model artefacts can be traced to/from ‘sources of truth’ in underlying business policy documents (Word, Excel) using the IDIOM Tracker for requirements traceability.
- The IDIOM Decision Manager Workbench is available to experiment with and further develop policy independently of the underlying systems and of the SDLC.
- Automated, robust, industrial strength deployment on any scale that can be supported by the ‘host application’ and its underlying platform.
- Simple injection into legacy systems leading to eventual legacy replacement.