I caught up with the wonderfully named Decisions recently. Back in the 90s the founders started OOP.com to separate what programmers did (build new components) from business users (who assembled and managed components) in complex decisions. This was sold to become the platform for a voice recognition product in the UK.
I caught up with the wonderfully named Decisions recently. Back in the 90s the founders started OOP.com to separate what programmers did (build new components) from business users (who assembled and managed components) in complex decisions. This was sold to become the platform for a voice recognition product in the UK. In 2004 they started Transparent Logic and this was sold a few years later to Symantec as the basis for their workflow/rules platform in Symantec ServiceDesk. Deployment was always an issue with these tools as that meant talking to IT every time something had to be updated for real. All this experience resulted in Decisions, founded in 2009.
Decisions was initially focused on providing an OEM engine for companies, especially in the healthcare space, in products like Central Logic Core, RCx Rules, CareFamily and Aviacode – everything from medical coding to claims pre-processing and more. More recently they have begun to sell to end user companies.
Decisions is very focused on making sure that business users can do things for themselves and that constrains and motivates everything in the platform, leading to a graphical environment that walks business users through every action. The platform has four elements:
Plus there are a set of custom components and a set of integrations with third party products. All the design elements are available within a portal and this environment can also be used to manage the resulting application. Decisions is available subscription-based in the cloud and as installed licenses with some customers moving from cloud to deployment in house as they grow their usage. The Decisions platform is Silverlight based with end user-facing components being moved to HTML 5.
The primary use case for most business users is to begin with a Flow. This uses a simple drag and drop editor that validates the flow as it is built, flagging incomplete items as the user works. Steps in the flow include Forms (which can be designed with the form editor), Rule Tasks, sub-Flows and branching. When Forms are designed the things added to the Form affect the Flow. For instance the options available on a Form determine what options exist in the Flow for leaving the Form step. The Flow can be executed, debugged, etc.
The Rule builder can be used to build either specific rules or tables of rules. The rule view is a point and click editor that walks a user through selecting through available data (passed in or available in the session), comparators, actions etc. A graphical view of the rule is also available and this is fully editable, allowing a business user to edit the rule in this graphical editor. A decision table or rule sheet table editor is also available. The editor first let’s a business user create or map information items into the editor and then builds a classic rulesheet layout with information items as columns and each rule as a row. The table can be first hit or all hit and can have a fall through rule for handling “otherwise.”
Test data for rules can be entered and saved into a test case framework (that also handles the flows and forms). The expected outcome can be documented for ongoing regression testing later. If Rules are added to a Flow they could just be invoked, adding the results to the available data, or they can be used to route in the Flow based on the value returned for instance. To make it easy to do the latter Rules can also specify Flows as actions.
Reporting is available too, also focused on business users. Columns from a source can be dropped on to a display, filters specified etc. Dashboards can include a report and then see actions for things in the report because all actions are linked to specifics in the back end not to the UI. This is a really nice feature, meaning that, for instance, a rule can be applied to data in a report. Reports can be built on data being manipulated by the system as well as on elements in the system like saves, versions, outcomes etc. This allows, for instance, Dashboards that display information about Rule execution. All the data is available externally also so customers can extend with their own data and reporting.
(image: dashboard / shutterstock)
