
Use Agile for Areas Subject to Regulations?

“… to determine whether the designer, the programmer, the manufacturer or the operator is at fault if an autonomous drone strike goes wrong or a driverless car had an accident. In order to allocate responsibility, autonomous systems must keep detailed logs so that they can explain the reasoning behind their decisions when necessary.” [emphasis added]
That explanation better be in a form that humans (and lawyers too) can actually read. That means structured natural language. The article went on to make the following astute observation …“This has implications for system design: it may, for example, rule out the use of artificial neural networks … decision-making systems that learn from example rather than obeying predefined rules.”
Right! Where there is social liability, there will always be natural language. P.S. To vendors: If your meaning of ‘business rule’ doesn’t compel you toward this debate, then you’re simply not really doing ‘business rules’(!).6.2. Executing rules directly – for example in a rules engine – is a better implementation strategy than transcribing the rules into some procedural form.
With computing power so vastly improved, there is less and less reason every day to support business rules using procedural languages. Why are we still programming the evaluation of rules ourselves?! Just as a DBMS removes data management as an application concern, so too does a rule technology for the evaluation of rules. A related issue is compliance – not just regulatory compliance, but compliance with contractual obligations, deals, agreements, licenses, warranties, and so on. If you want to delight customers, keep your commitments. To do so you must be able to determine how your systems actually got the outcomes they did. That way, if there’s a mistake you can correct it. So the Manifesto says …6.3. A business rule system must always be able to explain the reasoning by which it arrives at conclusions or takes action.
Today, demonstrating compliance is a largely hit-or-miss affair, always after the fact. Does it have to be? No! A state-of-the-art enterprise architecture is one that logs the rules used to make evaluations and decisions just as a DBMS logs all transactions. Compliance based on rules can and should be built-in.“If you need to go beyond gathering [i.e., harvesting or mining] business rules to trying to understand “The Knowledge” [sic] that experts know, how experts think and decide, what the expert rules are, or what the higher-level heuristic rules are, then knowledge engineers … will keep using “knowledge acquisition” (KA), “knowledge representation” (KR), and “knowledge engineering” (KE). AI guys know that means.”
In other words, expert rules arise from an individual who is outstanding at his particular knowledge task. That’s very different. Expert Systems Wikipedia describes expert systems as follows:“software that uses a knowledge base of human expertise for problem solving, or to clarify uncertainties where normally one or more human experts would need to be consulted … a traditional application and/or subfield of artificial intelligence (AI)”
Bob Whyte, a practitioner for a major insurance company, makes the following observation about the difference between business rules and expert systems[1]:“What makes the real-world challenge of managing business rules so much more tractable than it appeared to academics and researchers in the1980s, the heyday of knowledge engineering and expert systems, is that in the day-to-day business world the institution plays role of ‘god’.
… for business rules the problem is not one of having to discover and define hidden, unknown or unexpressed rules, which takes you into byzantine solution spaces, but rather one of documenting known rules invented overtly and explicitly by actual historical person(s).
With business rules you are generally not discovering rules no one has ever consciously considered, but rather uncovering rules that some manager, lawyer or other expert decided on one day, but probably did not record simply for lack of an appropriate infrastructure for rulebook management.”
Excellent clarification!