Business rules are forking

Another good post from @tetradian on business rules in response to James Taylor’s recent piece reporting Gartner's view that "Business rules are king".

Tom agrees with James Taylor about the importance of discipline around business rules, but objects to an interpretation of business rules that goes back to Taylor's namesake Frederick Winslow Taylor.

Tom distinguishes between decision-support (where the decision is made by a collaboration between an automated system and human judgement) and automated decision-making.(where there is no space for human judgement). This distinction is not always clear-cut - if the human actants within a complex business process lack the information, intelligence, attention or confidence to overrule the computer's suggested answer, then a decision-support system becomes defacto a decision-making system.

We should also distinguish between simple rules (binary logic) and more complex rules (modal logic, probabilistic logic). As Tom points out, much of the rule industry appears to assume simple composition of simple binary rules, which are inadequate for most interesting business problems (three quarters of his "context space mapping framework).

Tom makes three important points

• We should not assume that the business rules are sufficient, invariant, accurate and complete, especially if they are derived from the people who run the existing processes. Therefore the identification and codification of business-rules generally leaves something to be desired. (One way of putting this is that the Real resists symbolization.)

• There needs to be a very strong emphasis on rule-maintenance, otherwise placing all the business-rules into an automated system will lead to a ‘fit and forget’ attitude. (One way of putting this is a demand for double-loop or deutero-learning.)

• The viability of using automation for decision-making is dependent on the context.

---

In his new book Obliquity, John Kay discusses the example of waiting for a bus. According to the timetable, a bus should come every ten minutes. There are two rules that should help you decide whether to wait for the bus or walk - except that these two rules contradict each other.

Rule One says the longer you wait for the bus, the more likely it is to arrive soon. So if you have waited for nine minutes, it is practically certain to arrive in the next minute.

Rule Two says that the longer you wait for the bus, the more likely it is that Rule One is incorrect. So if you have waited more than nine minutes for the bus, it is starting to look as if the bus will never come at all.

If you have waited more than half-an-hour for the bus, then common sense suggests that Rule Two is in force. But as Kay points out, many people (including those who drove banks into bankruptcy) appear incapable of shifting from Rule One to Rule Two.

In  real business situations, there is always a balance between following a rule and questioning the rule. It is not just automated systems that may fail to strike this balance; many people with significant business responsibility lack common sense. This is an important aspect of the context for decision-making.

A business case for collaborative action

#SOA #insurance #govit @mcgoverntheory asked if anyone was interested in learning how insurance carriers partnered with state GOV to stand up SOA for online coverage verification?

Where is the business case for this initiative? There is certainly a demand, going back to this 2001 article on the Growing DMV Reporting Headache, and James points to a March 2004 document on the IICMVA website called Online Insurance Verification Using Web services to verify auto insurance coverage (pdf).

The IICMVA document outlines the problem - costs incurred by uninsured motorists, complicated and varied procedures for verifying insurance between different states - and so it makes clear that a web service solution might be a good idea. But a business case has to go further than this.

Firstly it must show that the benefits outweigh the costs (and risks). In a collaborative scheme, it isn't always obvious who is going to pay for the scheme, so there may be alternative options for funding the development followed by some kind of charge-back during operations. Each party that is investing in the scheme will presumably need a business case to justify its own investment. But if there aren't sufficient benefits to cover everyone's costs, then the scheme just isn't viable at all.

Searching the internet, I found a presentation by Loren McGlade and Jon Neiditz from the ACORD/LOMA Insurance Systems Forum (May 2009) mcglade_neiditz.pdf; mcglade_neiditz.mov; mcglade_neiditz.mp3. This presentation contains a lot more than the March 2004 document in terms of quantifying the potential benefits and cost-savings of the scheme.

And secondly, in a collaborative scheme like this, the viability depends on the number of people who join. In this case, how many insurance companies and how many states have to participate, in order for the scheme to deliver the benefits. Given that the benefits are largely dealing with the complication caused by the differences in regulation between states, this only makes sense if multiple states are involved. But how many?

I've done a number of business cases of this kind, where the viability of a multi-agent scheme depends critically on the rate of adoption, so I'd be very interested to see how this aspect of the business case for the IICMVA scheme is worked out.

More generally, there is a widespread belief in the potential benefits and cost savings of shared service provision, especially in the public sector. However, there is often a lack of realism in how these shared services are to be implemented. If the shared services are too inflexible, then people won't use them without some degree of coercion; thus the costs and risks are higher than expected, and the benefits lower. I'm looking at a number of situations in the UK where public sector agencies are being encouraged to use nationally provided services, and it's an extremely complex task to work out how these services can be fitted asymmetrically into a joined-up solution that delivers the best outcomes. (Please contact me if you are facing this kind of task.)

What's Wrong with the Single Version of Truth

As @tonyrcollins reports, a confidential report currently in preparation on the NHS Summary Care Records (SCR) database will reveal serious flaws in a massively expensive database (Computer Weekly, March 2010). Well knock me down with a superbug, whoever would have guessed this might happen?

"The final report may conclude that the success of SCRs will depend on whether the NHS, Connecting for Health and the Department of Health can bridge the deep cultural and institutional divides that have so far characterised the NPfIT. It may also ask whether the government founded the SCR on an unrealistic assumption: that the centralised database could ever be a single source of truth."

There are several reasons to be ambivalent about the twin principles Single Version of Truth (SVOT) and Single Source of Truth (SSOT), and this kind of massive failure must worry even the most fervent advocates of these principles.

Don't get me wrong, I have served my time in countless projects trying to reduce the proliferation and fragmentation of data and information in large organizations, and I am well aware of the technical costs and business risks associated with data duplication. However, I have some serious concerns about the dogmatic way these principles are often interpreted and implemented, especially when this dogmatism results (as seems to be the case here) in a costly and embarrassing failure.

The first problem is that Single-Truth only works if you have absolute confidence in the quality of the data. In the SCR example, there is evidence that doctors simply don't trust the new system - and with good reason. There are errors and omissions in the summary records, and doctors prefer to double-check details of medications and allergies, rather than take the risk of relying on a single source.

The technical answer to this data quality problem is to implement rigorous data validation and cleansing routines, to make sure that the records are complete and accurate. But this would create more work for the GP practices uploading the data. Officials at the Department of Health fear that setting the standards of data quality too high would kill the scheme altogether. (And even the most rigorous quality standards would only reduce the number of errors, could never eliminate them altogether.)

There is a fundamental conflict of interest here between the providers of data and the consumers - even though these may be the same people - and between quality and quantity. If you measure the success of the scheme in terms of the number of records uploaded, then you are obviously going to get quantity at the expense of quality.

So the pusillanimous way out is to build a database with imperfect data, and defer the quality problem until later. That's what people have always done, and will continue to do, and the poor quality data will never ever get fixed.

The second problem is that even if perfectly complete and accurate data are possible, the validation and data cleansing step generally introduces some latency into the process, especially if you are operating a post-before-processing system (particularly relevant to environments such as military and healthcare where, for some strange reason, matters of life-and-death seem to take precedence over getting the paperwork right). So there is a design trade-off between two dimensions of quality - timeliness and accuracy. See my post on Joined-Up Healthcare.

The third problem is complexity. Data cleansing generally works by comparing each record with a fixed schema, which defines the expected structure and rules (metadata) to which each record must conform, so that any information that doesn't fit into this fixed schema will be barred or adjusted. Thus the richness of information will be attenuated, and useful and meaningful information may be filtered out. (See Jon Udell's piece on Object Data and the Procrustean Bed from March 2000. See also my presentation on SOA for Data Management.)

The final problem is that a single source of information represents a single source of failure. If something is really important, it is better to have two independent sources of information or intelligence, as I pointed out in my piece on Information Algebra. This follows Bateson's slogan that "two descriptions are better than one". Doctors using the SCR database appear to understand this aspect of real-world information better than the database designers.

It may be a very good idea to build an information service that provides improved access to patient information, for those who need this information. But if this information service is designed and implemented according to some simplistic dogma, then it isn't going to work properly.

Multiple styles of EA

@tetradian has an interesting post on Big EA, Little EA and Personal EA., based loosely on Patti Ancram's classification of knowledge management.

• Big KM is about top-down, structured and organizationally distinct “knowledge management”
• Little KM is about safe-fail experiments embedded in the organizational structure
• Personal KM is about access to tools and methods to ensure that knowledge, context, bits, fragments, thoughts, ideas are harvestable

---

As I see it, this classification identifies different styles that may possibly coexist, or perhaps different kinds of knowledge claim that may interact in interesting ways. (I don't like the word "layers" for this kind of classification, because it implies a particular structural pattern, which isn't appropriate here.)

I've used a slightly different division in the trust sphere, which might make sense here as well.

• Authority EA - this is a kind of top-down command-and-control EA, representing the will-to-power of the enterprise as a whole, and ultimately answerable to the CEO. This is what Tom calls Big EA.

• Commodity EA - this is where the EA is based on some kind of external product source - such as when the enterprise models are imported wholesale from IBM or SAP. This often resembles Big EA, but has some important differences.

• Network EA - this is where EA is based on informal and emergent collaboration between people and organizations. Tom calls it Little EA, but the collaborations can be very extended indeed - just think about some of the mashup ecosystems around Google or Twitter.

• Authentic EA - this is a personally engaged practice - what Tom calls Personal EA.

Once we have agreed that there are different styles, the really interesting question is not identifying and naming the styles, nor even saying that one style is somehow "better" than another style", but talking about how the different styles interact, and what are the implications for governance.

From Collaboration to Business Value?

#AIIM @noelrath @jmancini77 via @dhinchcliffe @skemsley .

Dion and Sandy retweeted a list of 8 Ways to Make Sure That Collaboration Adds Business Value on John Mancini's blog, possibly authored by Noel Rath of HP. I just wanted to add a few critical comments here.


1 -- Collaboration is part of a process.

One way of looking at this argument is to say that it is the business processes that deliver business value. Therefore the only way for collaboration to deliver business value is through the business processes - for example, helping people to communicate more efficiently and to make more effective decisions - or perhaps helping the supervisory level of management to control and audit what is going on.

But we can think of this in two ways. One is to think of "collaboration" as some stuff that gets plugged into an existing process, plus some additional control mechanisms to prevent people actually using this stuff in ways that might produce "adverse business consequences". This approach may well result in a more complicated and only slightly more effective process.

Alternatively, we can think of "collaborative" as a radically new way of architecting and regulating processes - based perhaps on a cybernetic paradigm (for example Stafford Beer's Viable Systems Model), with the potential to optimize the business value obtained from the transformation.


2 -- Control is essential. 
3 -- Records management is a discipline. 
8 -- Records management should be back-end driven. 

The article asserts that control of information processes is critical to reduce risk, and that it is the role of information specialists to ensure that collaborative technologies support the business and do not introduce unintended consequences. I suspect that this refers to a fairly narrow conception of risk, defined in terms of uncertainty of outcome, which is what people worry about in fairly simple business situations. For more complex situations, we also need to think about ambiguity (uncertainty of meaning) and ambivalence (uncertainty of intention). Collaborative intelligence can be extremely valuable in helping to address these higher uncertainties, but this kind of intelligence doesn't thrive in the wrong kind of control environment.

4 -- Consider content sources and types.
5 -- SharePoint collaboration.

These two points are more about technical design rather than business value, so I don't want to comment further.

6 -- Educate.
7 -- Consider the knowledge worker.

The article advocates "educating" the knowledge worker to get more productivity out of them, but doesn't want to overload the knowledge worker with the responsibility of deciding what is important for the business. Sounds like a Theory X management style to me.

---

Overall then, the article is mostly about records management. No doubt people who are scared by the idea of genuine collaboration and organizational intelligence will be attracted by this kind of half-hearted approach, but it doesn't have much to do with my notion of collaboration or my notion of business value.