Introduction and manifesto for business rules analysis

This booklet is published under the terms of the licence summarized in footnote 1.

The Rules and Patterns (RAP) group was established in 1995 to explore ways to specify the structure and behaviour of a data processing system. The RAP Group was an informal and sometimes international discussion group - a forum to share ideas about how systems analysts should specify entities, events and business rules.

These on-line booklets contain RAP Group papers written over a 5 year period. However, I still edit the papers today. For example, I have added notes drawn from Object Management Group (OMG) discussions of business rules analysis and specification, and added some definitions of terms from the ISEB reference model for Enterprise and Solution Architecture.

Most RAP group members were and are people interested in business or systems analysis who take it for granted that they can:

• Encapsulate a system: define the inputs it consumes and outputs it produces
• List stated requirements in a catalogue
• Define the processes and/or use cases that a system’s user follow to do their business
• Define the structure of any data stored within a system using a data model.

Analysts are usually trained in drawing business process models, documenting use cases and building data models. However, analysts lack good enough techniques for analysing and documenting business rules in a systematic way. How best to analyse and specify exactly what an enterprise application does for users by way of evaluating and enforcing business rules?

At occasional meetings in London, I and other speakers have explored questions such as:

• What kind of language for specifying business rules will work for both systems analysts and software developers?
• Not just how should results be documented, but also how should analysis proceed?
• What patterns can we detect in models of system structure and behaviour?
• Given alternative patterns, why and when should one pattern be transformed into another?
• How best to produce specifications that programmers will find helpful, without directing the programmer in any aspect of software design?

After these meetings, I wrote up papers which are now collected and edited into these booklets (published at ref. 1).

Meanwhile, the Object Management Group, leaning much on work done by the Business Rules Group, published their Business Motivation Model. That is fine in its own way, but the RAP group papers provide a different view point that is valuable, and pose some questions that business rules gurus find awkward to answer.

Service-oriented rule definition

The quality and integrity of business data is vital to business processes. The information supplied to business people must accurately reflect the state of world the enterprise operates in. The enterprise’s stored business data should be consistent with all business rules.

The principle of service-orientation leads designers to encapsulate business data behind a façade of automated services.

Principle	Service-orientation
Statement	Define a system is primarily by the external services it offers (and only secondarily by its internal components). Define each service by a contract including its signature, semantics (or rules) and non-functional requirements.
Rationale	Interoperability, portability and reuse are increased when analysts specify required services in a service catalogue, builders define provided services in a service directory, and efforts are made to match required services to provided services.
Implications	The enterprise must follow a consistent approach to system specification and implementation, centered on the governance of a service catalogue.

Further, the principle of “defensive design” - the norm in enterprise application software – leads designers to code business rules in automated services.

Principle	Defensive design
Statement	An automated service must test all its preconditions before updating stored data according to other defined business rules.
Rationale	Prevent the corruption of data by clients who do not know the preconditions.
Implications	All the necessary rules are declared an event/service catalogue.

So, many rules are naturally specified in an event/service catalogue. (The same rules may be executed at user interfaces, for usability and performance reasons, but that is not where they should be specified.)

It not uncommon to specify the data store and automated services of an enterprise application using some kind of entity model and/or event model. Yet knowledge of how to build these models to capture business rules and ensure data integrity is thinly distributed. These booklets should be of interest and perhaps immediate help to anybody who analyses and specifies business rules in an SOA environment.

Some principles of business rule analysis and specification

The principles in this table may not make sense to you immediately; they are distilled from explanations given in later booklets.

A software system principle	A software system can do nothing for a business but recognise and produce data flows; it validates input data events, stores the state of persistent data entities, and derives output from the input and state data.
The analysis principle 1	Analysts find things out, define activities in the business domain, distil a mess of data processing requirements into discrete elements, and define essential business rules in a semi-formal manner..
The analysis principle 2	Analysts do not write software – and do not complete all data and process models to the bottom level of detail and precision that would be required for code generation.
The PIM principle	Analysts produce a logical specification (a platform-independent model) that ignores the programming paradigm and technology, but does take account of some physical design constraints.
The distribution challenge	Analysts cannot reasonably assume that all applications will run on top of a single enterprise database – they must account for distribution of data storage.
The required process hierarchy	Analysts look to distinguish three levels of process specification: long-running business processes, shorter running use cases and atomic automated services (ideally transactions).
The refactoring principle	Analysts look for opportunities to factor out common (reused) processes, both between process levels and within a level.
The SOA principle	Analysts should match the required automated services (found by process analysis) with the provided automated services (found in a service catalogue).
The transaction principle	Analysts initially posit that an automated business service, triggered by a business event, can be rolled back automatically. This rule of thumb make specifications simpler and more consistent.
The data integrity concern	Analysts strive to maintain data integrity by defining rules that constrain all the users and clients that can update entity state data (which means, by the way, that they posit defensive design rather than design by contract).
The cache concern	Analysts regard caching business data outside the enterprise’s persistent data stores as a design optimisation technique and a design headache, not a primary design principle.
The data duplication concern	Analysts have to define workflows to synchronise copies or entity state that are duplicated beyond the bounds of automated transaction management.
The entity and event principle	Analysts treat entity-oriented and event-oriented views of a system as complementary and equally important, and unite them by specifying the effects of events on entities.
The event effect principle	Analysts specify the effect of a transient event on a persistent entity - not the operation(s) that implement that event effect.
The business rule principle	Analysts declare business rules as invariants of entity state, as preconditions and post conditions of event effects; and define volatile rules as user-updatable attribute values.
The here and now principle	Analysts define services and components to serve known clients, not imaginary ones, since generalization ahead of requirements hinders now and proves unwise later.
The class hierarchy concern	Analysts tend to eschew class hierarchies in business entity models, where the data entities represent numerous and long-lived real-world entities.
The denormalisation concern	Analysts tend to normalise the entities in data models; they treat denormalisation as a design optimisation decision for input, output and storage structures.

The need for human-friendly specification

Analysts and designers want to be agile. They don’t want complete every part of a model, or specify business rules with the precision and formality of a formal method. They want to specify the essential business rules for required processes without excessive formality. They want to specify business rules at level of abstraction above software (without knowing whether the code will be procedural or OO). They want to give software developers just enough information to build a required system. They do not want to design software.

Software developers also want this kind of specification. They don’t want to be given pseudo-code. They don’t want the analyst to prejudice design decisions about how to modularise the software.

The need for platform-independent analysis and specification

There is still no silver bullet (see ref. 2). Various technology-inspired movements have been found wanting. Programming languages once hyped as close to natural language have always been found wanting. COBOL was never written by business people. SQL is no longer considered an end-user language. Visual Basic did not deliver ”the end of programming” as once was promised. Java is if anything harder to read than COBOL. OOPLs may help programmers in some ways, but there is no evidence to suggest that OOPLs have advanced the state of the art in business database processing, or helped those involved in higher levels of systems analysis and design. SOA thinking has something to offer, once we abstract away from the common thinking that it means Web Services.

Systems analysis should be technology-independent - even in projects to roll out a pre-built package for (say) ERP, CRM or accounting. Understanding requirements is at least half the battle. Identifying requirements, communicating requirements to software specialists, and correcting errors in this process, takes as much or more effort than the end-less struggle to master technologies. We want to specify systems using a language that is entirely platform-independent, that is, independent of programming paradigm, development framework, database management system and any other specific computing technology.

Analysts want to produce specifications that both business people and programmers can understand, without directing choices of programming technology or program design. What systems analysts need, in the new millennium, are a few terms, concepts and principles for specifying the essence of a software system, while saying nothing about technology and making minimal use of a CASE tool.

But at the same time, it is important that systems analysts do not become entirely disconnected from programmers. Analysts do have to understand and consider some particular physical constraints on logical specification – notably the boundaries of data stores and of transactions.

References

Ref. 1: Booklets containing bundles of RAP group papers in the bottom-left of the Library at http://avancier.co.uk

Ref. 2: Fred Brooks, quoted in papers on scale and complexity in the Library at http://avancier.co.uk

Footnote 1: Creative Commons Attribution-No Derivative Works Licence 2.0

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this page, not derivative works based upon it.

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited: http://avancier.co.uk” before the start and include this footnote at the end.

For more information about the licence, see http://creativecommons.org