SOA and business rules management

Businesses continue to strive for shorter time to market and to lower the cost of developing and maintaining computer applications to support their operations. Business rules management technologies can play an important role in this.

Well, if you believe that, you'll believe anything. You are already thinking 'Another silver bullet!' But stay with me for at least another few paragraphs, whilst I try to convince you that it may actually be worthwhile to read further. When I started writing this book, this chapter had the provisional title of 'Why Business Rules?' or some such. As I started laying out the reasons, it became clear that I was ducking the main issues facing the world of IT (information technology) by thus restricting my focus. So I asked myself 'Why are we doing all this?'

According to Standish (1995; 2004), around 66% of large US projects fail, either through cancellation, overrunning their budgets or delivering software that is never put into production. Outright project failures account for 15% of all projects, a vast improvement over the 31% failure rate reported in the first survey in 1994, but still a scandal. On top of this, projects that are over time, over budget or lacking critical features and requirements total 51% of all projects in the 2004 survey. It is not incredible to extrapolate these – frankly scandalous – figures to other parts of the world. What is harder to believe is that our industry, and the people in it, can tolerate such a situation. Clearly we should be doing something differently. The Standish surveys also looked into the reasons why people involved in the sample projects thought such projects fail. The reasons given – in descending order of importance – were:

• lack of user involvement;
• no clear statement of requirements;
• no project ownership;
• no clear vision and objectives; and
• lack of planning.

Furthermore, the level of abstraction at which we work is far too low. IT departments are often culturally and technically miles away from the concerns and thought processes of the customers they serve. The problem is, thus, far broader than the need for business rules management; the real problem we have to solve is how to align IT practice with business need.

To believe that adopting a business rules management system on its own will solve this problem is nothing short of na¨ıve. Business rules management is only a part of the solution. To align IT with business we must also consider innovative approaches to requirements engineering and service oriented architecture. Whilst its focus remains on business rules, this book is about all these issues.

Briefly – because the next chapter will be devoted to a detailed discussion – service oriented architecture (SOA) is an architectural concept in software design that emphasizes the use of combined services to support business requirements directly. In SOA, resources are made available to service consumers in the network as independent artifacts that are accessed in a standardized way. SOA is precisely about raising the level of abstraction so that business processes can be discussed in a language understood by business people as well as IT folk. Business rules are about aligning IT with the business too. It is to them we now turn.

In this chapter, after a short look at the history of the idea and technology of business rules management systems (BRMS), we examine the features and responsibilities of a BRMS, and then the benefits of and business drivers for adoption of the technology. We list typical applications and indicators of the need for a BRMS.

In subsequent chapters we will relate business rules to the concept of service oriented architecture, look at different approaches to and philosophies of business rules management, cover the key technical features of a BRMS (including inter alia knowledge representation and inference techniques) and discuss requirements engineering, appropriate development methods and processes. Next we try to distil this knowledge into a prototype pattern language.

1.1 Historical Background

The first talk of business rules management emerged from discussions in the database community as long ago as the late 1980s, notably in a journal called The Database Newsletter – although the term was used as early as 1984 in an article in Datamation.

However, there is an older tradition in the artificial intelligence (AI) community going back, arguably, to EMYCIN, the first so-called expert system shell. MYCIN (Shortliffe, 1976) was an expert system that could diagnose infectious diseases of the blood – with some success too. MYCIN was not, in any sense, a business rules management system; its rules were pretty much hard coded and concerned a fairly esoteric domain: medicine. EMYCIN (Melle et al., 1981) was 'empty' MYCIN: MYCIN with the rules taken out and two significant mechanisms. First, rules on any suitable domain (including business domains) could be typed in and run under the control of the same logic used by MYCIN. Secondly, an EMYCIN application could be asked to explain its conclusions when asked 'How?' or 'Why?' I will explain how all this works in a later chapter. For now, notice only that EMYCIN separated business rules from both data and the control logic that enabled conclusions to be reached, and this is a key principle of modern business rules management systems. Furthermore, the rules were entirely declarative (unconnected statements rather than the interdependent lines of a computer program); another key principle of the business rules approach.

The first implementations of business rules in databases were more limited in several ways, the first being that rules were usually implemented as stored procedures written in procedural and proprietary extensions of declarative SQL. Other rules, notably those for referential integrity, were implemented in the database system itself, but nothing more complex was to succumb to this approach. The next step forward took some time. Active databases incorporated triggers: if/then rules that caused updates dependent on the values entered into the database. But even triggers did not offer the flexibility of EMYCIN's general if/then rules.

As an example of the gulf between the two traditions, I recall attending the British launch of Sapiens (still a major player in the BRMS marketplace today) in around 1989. I have a fairly low tolerance for sales pitches, but I was aroused from my slumbers when told that the product (basically a database and 4GL) was object-oriented and rule-based. As the technical presentation wore on, it became clear that the 'objects' were merely relational tables; by the end nothing much had been said about rules.

'Can you give me an example of a rule?' I asked.
'Of course. All employees must be over 16.'
'No, I mean a proper rule with an ''if'' and a ''then''.'
The speaker paused for a second. 'OK, then. If you are to be an employee then your age must be greater than or equal to 16.'
I decided to hold my peace, and went away rather unimpressed.

The point here is not just that salesmen can sometimes be rather uneconomical with buzzwords, but that there is a misunderstanding about what constitutes a rule (and, indeed, an object in this particular case). I regarded the example given as a range constraint on an attribute, rather than a rule. What is evinced is a lack of common terminology among the two camps.

Consider the following (very slightly edited) dialogue between MYCIN and a human physician.

>Is the patient's illness with ORGANISM-1 a hospital acquired infection?

>WHY?
[i.e. Why is it important to determine whether or not the infection with ORGANISM-1 was acquired while the patient was hospitalized?]

This will aid in determining the category of ORGANISM-1. It has already been established that

[1.1]the gram stain of ORGANISM-1 is gramneg, and
[1.2]the morphology of ORGANISM-1 is rod, and
[1.3]the aerobicity of ORGANISM-1 is facultative

Therefore, if

[1.4]the infection with ORGANISM-1 was not acquired while the patient was hospitalized

then

There is strongly suggestive evidence (.8) that the category of ORGANISM-1 is enterobacteriaceae

ALSO:

There is weakly suggestive evidence (.1) that the identity of ORGANISM-1 is pseudomonas-aeruginosa

Even ignoring the specialized terminology, it should be clear that the implied rule is far more complex than a constraint saying that staff entered in the database must be over 16. We will see many examples of similarly complex rules in more familiar domains as we proceed. Furthermore, we will encounter more complex constraints that involve more than one attribute, object or database table.

The first step towards a reconciliation between these two camps came with Ron Ross's (1994) Business Rule Book, to be followed by his several subsequent publications that show that he is aware of both traditions, though mainly rooted, originally, in the database world. Ross founded Business Rule Solutions in 1997 to focus on applied business aligned models (strategy, process, vocabulary, rules, etc.) that would be completely independent of any IT tradition.

In 1995, a group of IT practitioners produced the GUIDE Business Rules Project Report, which also clarified the territory, though remaining database centred. The manifesto of the (now better informed) database-centred approach was finally published by Chris Date (2000). In the same year, the Business Rules Group published the first version of the Business Rules Manifesto, which established the ground rules for what constitutes a BRMS and the principles of the business rules approach. By 2002, Barbara von Halle, another database guru, had published the first comprehensive method for applying the approach and Tony Morgan became the first AI expert to publish a book on the subject.

In the interim, products evolved. Some of them were extensions of database or repository products, others evolved from expert systems shells. We will look at some of them later.

As I write, it seems to me that there is now enough maturity in both theory and practice for commercial organizations to apply the business rules approach, along with mature object-oriented modelling techniques, better requirements engineering and the philosophy of service oriented architecture, to the critical problem of aligning IT with business goals and practices.

• Continue reading Chapter 1: SOA and business rules management.
• Read Chapter 2: SOA and decentralizeed IT systems.
• For more data management-related books, see our Chapter Download Library.