DecisionCAMP 2018

DecisionCAMP is a major annual conference on Decision Management, with a strong focus on the DMN standard and practical implememntation issues.  This year DecisionCAMP 2018 will be held in the University of Luxembourg on September 17-19, and co-located with Logic for AI Summit.  It's the friendliest AI/DM conference in the schedule, with plenty of opportunities to talk to important people in the field.

I am pleased to be on the organizing committee, together with:

• Dr. Jacob Feldman, OpenRules, USA (Chair)
• James Taylor, Decision Management Solutions, USA
• Prof. Jan Vanthienen, KU Leuven, Belgium
• Mark Proctor, Red Hat, UK
• Carole-Ann Berlioz, Sparkling Logic, USA. 

I hope to meet you there!

And the call for presentations closes on March 25, so if you have something interesting to say, let us know.

Modern fears: Can intuitive artificial intelligence be ethical?

Steven Hawking has recently warned that “the development of full artificial intelligence could spell the end of the human race”, because “it would take off on its own, and re-design itself at an ever increasing rate”.    It is interesting to compare this very 21^st century fear with earlier ones.

Progress in Decision Modelling

I created this blog in 2009, with a very specific purpose:  to share the initial concepts of Decision Requirements Analysis and get some feedback prior to writing a book on the subject.  It served its purpose;  it forced me to formalize the central ideas, and I had some very useful input from a number of people.  Knowledge Automation was eventually published in 2012.  I now have enormous respect for authors; if I had known how much work was involved in producing even that slim volume I might never have started.  If you are one of the select few who have actually purchased a copy, many thanks.

In Knowledge Automation I introduced a new type of diagram – the Decision Requirements Diagram (DRD) – which models a domain of decision-making by decomposing it into a network of interdependent decisions, supported by areas of business knowledge and data.  I showed that such models can support an efficient methodology for scoping and implementing decision automation projects.  

A simple DRD as proposed in Knowledge Automation

I thought you might like to know where these concepts have gone.

DRA in Design

Design tends to be the prerogative of techies – and is therefore elegant from the bottom up:  it uses the computational resources very efficiently.  Good design should also be elegant from the top down:  the structure of the solution should be parsimonious and reflect the structure of the decisioning.  Bottom-up design is very specific to the platform, so it is not possible to discuss it in this platform-neutral forum anyway.  Top-down design, however, can be purely functional.  This posting suggests how the decisioning structure exposed in the DRD can be used as the basis for designing a decision flow and an object model.

Rules Discovery

The key to successful rules discovery is that all rules must be contextualized in specific business decisions.  This statement may be seen as heretical by those who have signed up to the Business Rules Manifesto, but my concern here is with the practicalities of delivering decision services to a tight budget and timescale, not with the quixotic task of modelling the behaviour of an entire organization.  So my advice is this:  do not try to define universal rules which apply across all business processes and activities; establish only the specific rules required to make each decision which is in scope.

DRA in Project Management

In the good old, bad old days of Knowledge Engineering, the “iterative approach" often meant in practice "keep adding rules until the client runs out of money".  This mindset persisted as our field came to be called Business Rules, when there was a common assumption that one could simply gather whatever rules the "experts" considered pertinent, arrange them into groups, and deploy them as rule services.  Now Decision Management (DM) has turned this deeply misguided idea on its head by stressing that one must first define the business decisions to be automated, before harvesting the specific rules to implement them (see for example James Taylor on "Using Decision Management to improve Requirements”).

Decision Requirements Analysis (DRA) formalises this top-down process, allowing a rigorous specification of the decisioning requirements at the outset of a rules project.  The main benefit is improved project management:  DRA results in better plans, less risk, and tighter control on scope.

DRAW

DRAW (Decision Requirements Analysis Workshop) is a structured workshop technique for defining the decisioning requirements for a rules project, using the DRD described in my last posting.  There are two typical contexts for DRAW:

• It can be carried out as a self-contained activity, to establish the resources required for a potential rules project (e.g. to establish feasibility, to prioritise alternative projects or to produce a road-map for multiple deliveries)
• It can be carried out in the first few days of a rules development project, to define the decisioning requirements (as a Requirements task in waterfall, or an Inception task in RUP).