The Business Rules Manifesto and Ampersand

Ampersand lets you use business rules as intended in the Business Rules Manifesto (by the Business Rules Group, 2003). This chapter quotes each article from the manifesto verbatim. Besides, it describes how Ampersand implements it,

1. Primary Requirements, Not Secondary

1.1.	Rules are a first-class citizen of the requirements world.
Ampersand says:	Agreed! First-class means that every requirement is a rule and every rule is a requirement. An Ampersand-engineer makes a requirement concrete by specifying a constraint. At design time, these constraints must be consistent and Ampersand's type system helps out by signalling those inconsistencies. At runtime violations of constraints are signalled the moment they occur.
1.2.	Rules are essential for, and a discrete part of, business models and technology models.
Ampersand says:	Agreed! Business models and technical models in Ampersand consist of rules.

2. Separate From Processes, Not Contained In Them

2.1.	Rules are explicit constraints on behavior and/or provide support to behavior.
Ampersand says:	Agreed! Each rule in Ampersand is a constraint, the violations of which are computed (in real time) and signalled to the appropriate stakeholder. The signal triggers behavior of the individual who is assignd to make that violation go away. Support is provided by different types of enforcement.
2.2.	Rules are not process and not procedure. They should not be contained in either of these.
Ampersand says:	Agreed! An Ampersand-engineer defines rules, not processes and not procedures.
2.3.	Rules apply across processes and procedures. There should be one cohesive body of rules, enforced consistently across all relevant areas of business activity.
Ampersand says:	Agreed! A rule applies throughout its context. If several processes and procedures are valid in a particular context, all rules of that context apply to all of them.

3. Deliberate Knowledge, Not A By-Product

3.1.	Rules build on facts, and facts build on concepts as expressed by terms.
Ampersand says:	Agreed! Facts are true statements. Assuming that the data entered in an information system represent facts, Ampersand preserves their truth with mathematical rigor. If false data (i.e. non-facts) are entered into an information system built by Ampersand, the software will detect every inconsistency caused by that falsehood. Facts in Ampersand constitute the population of relations. Relations exist between concepts. Rules are expressed by terms in which operators link relations into meaningful terms.
3.2.	Terms express business concepts; facts make assertions about these concepts; rules constrain and support these facts.
Ampersand says:	Agreed! If the Ampersand-engineer works on a business problem, she uses the concepts of the business as concepts in Ampersand.
3.3.	Rules must be explicit. No rule is ever assumed about any concept or fact.
Ampersand says:	Agreed! Every rule in Ampersand is explicit and has a well defined meaning that a computer can calculate. An Ampersand-engineer can formulate that rule explicitly in natural language too.
3.4.	Rules are basic to what the business knows about itself — that is, to basic business knowledge.
Ampersand says:	Agreed! Rules are the mortar that unite individuals to form an organisation or to realise a business process. Together with the definitions of concepts and relations, rules form the ontology of the business.
3.5.	Rules need to be nurtured, protected, and managed.
Ampersand says:	Agreed! Rules need to be managed in a rule repository such as RAP.

4. Declarative, Not Procedural

4.1.	Rules should be expressed declaratively in natural-language sentences for the business audience.
Ampersand says:	Agreed! Ampersand rules are constraints, and therefore declarative. A rule has no procedural interpretation.
4.2.	If something cannot be expressed, then it is not a rule.
Ampersand says:	Only formal rules are expressed in Ampersand, which is necessary for generating software. Informal rules cannot be expressed in Ampersand. However formal rules are accompanied by their formulation in natural language.
4.3.	A set of statements is declarative only if the set has no implicit sequencing.
Ampersand says:	Agreed! Statements in Ampersand are order independent. There is no implicit sequencing. Changing places does not change meaning, just like rules in natural language do.
4.4.	Any statements of rules that require constructs other than terms and facts imply assumptions about a system implementation.
Ampersand says:	Agreed! Ampersand defines rules exclusively by terms and facts and makes no assumptions about a system implementation.
4.5.	A rule is distinct from any enforcement defined for it. A rule and its enforcement are separate concerns.
Ampersand says:	Agreed! Rules and enforcements of rules are separated in Ampersand. Ampersand supports 4 ways of enforcing rules: invariance (a rule must remain satisfied at all times), process (a rule must be satisfied eventually by a designated role who reacts on violations), automated (a rule wil remain satified because a computer reacts on violations), and none (the rule will remain satisfied without any enforcement. Axioms are such rules.)
4.6.	Rules should be defined independently of responsibility for the who, where, when, or how of their enforcement.
Ampersand says:	Agreed! responsibility is specified separate from rules in Ampersand.
4.7.	Exceptions to rules are expressed by other rules.
Ampersand says:	Agreed! Ampersand contains no exception mechanism for precisely this reason. Every exception is expressed as a proper rule.

5. Well-Formed Term, Not Ad Hoc

5.1.	Business rules should be expressed in such a way that they can be validated for correctness by business people.
Ampersand says:	Agreed! Business rules are formulated (by an Ampersand-engineer) both in natural language and in formal language. The natural language representation is used in discussions with business people. The formal language is used by computers. The correspondence between the two can be verified by peer-reviewing.
5.2.	Business rules should be expressed in such a way that they can be verified against each other for consistency.
Ampersand says:	Agreed! Consistency of rules is first checked in a type checker. Rules that fail this test have no semantics and are rejected as a consequence. The remaining rules have an interpretation, which is used by a computer to signal data that violates the rule. In case of an inconsistency, violations won't go away. The only way to resolve that situation is to change one or more rules to form a consistent set.
5.3.	Formal logics, such as predicate logic, are fundamental to well-formed term of rules in business terms, as well as to the technologies that implement business rules.
Ampersand says:	Agreed! Ampersand use mathematical logic on terms in relation algebra.

6. Rule-Based Architecture, Not Indirect Implementation

6.1.	A business rules application is intentionally built to accommodate continuous change in business rules. The platform on which the application runs should support such continuous change.
Ampersand says:	Agreed! The business rules application generated by Ampersand accommodates change in business rules by instant building of the application and by mutual independence of rules. Taking out or adding a rule does not affect other rules. The Ampersand compiler will generate the application also if the rules are not yet complete, which allows for incremental development of the 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.
Ampersand says:	Agreed! Rules in Ampersand are executed directly. All transformations needed are perfomed "under the hood" outside the view of engineers and users.
6.3.	A business rule system must always be able to explain the reasoning by which it arrives at conclusions or takes action.
Ampersand says:	Agreed! The system gives highly informative error messages that use the text of each rule to explain violations.
6.4.	Rules are based on truth values. How a rule's truth value is determined or maintained is hidden from users.
Ampersand says:	Agreed! The computation is hidden from users. All the user sees is a (database-like) application that signals violations when necessary.
6.5.	The relationship between events and rules is generally many-to-many.
Ampersand says:	Agreed! The Ampersand-system bears resemblance to reactive programming in this respect.

7. Rule-Guided Processes, Not Exception-Based Programming

7.1.	Rules define the boundary between acceptable and unacceptable business activity.
Ampersand says:	Agreed! A business that can clearly express what is acceptable/desirable and what is not (given its goals and culture) is supported by Ampersand's formal rules. When executed, violations will signal transgressions of the boundary. Ampersand will also tell which rule has been violated. Of course, a computer can never enforce ethical conduct. Neither can Ampersand.
7.2.	Rules often require special or selective handling of detected violations. Such rule violation activity is activity like any other activity.
Ampersand says:	Agreed! There are enforcement mechanisms to trigger corrective actions, either human action (process enforcement) or computer action (automated enforcement) or no action (invariance; the computer blocks and must roll back)
7.3.	To ensure maximum consistency and reusability, the handling of unacceptable business activity should be separable from the handling of acceptable business activity.
Ampersand says:	Agreed! Even though Ampersand has no specific construct for this, this principle is clearly applicable.

8. For the Sake of the Business, Not Technology

8.1.	Rules are about business practice and guidance; therefore, rules are motivated by business goals and objectives and are shaped by various influences.
Ampersand says:	Agreed! Ampersand stimulates to write a purpose with each rule. That is where motivations, business goals and objectives are linked to rules. In the Ampersand way of working, Ampersand-engineers are stimulated to identify stakeholders and discuss with them deeply.
8.2.	Rules always cost the business something.
Ampersand says:	Agreed! If the rule is not automated, people have to be educated to enforce them. That costs. Even if the rule is automated, there is a learning curve for people to comply with the rule correctly. That costs. If both cases it has to be documented and validated. That costs. The point is there are no free lunches. So you don't want more rules, you want fewer (good) rules. (… which is Principle 8.4.) (thanks to Ron Ross for this paragraph)
8.3.	The cost of rule enforcement must be balanced against business risks, and against business opportunities that might otherwise be lost.
Ampersand says:	Agreed! This goes without saying
8.4.	‘More rules’ is not better. Usually fewer ‘good rules’ is better.
Ampersand says:	Agreed! More rules restrict more, less rules restrict less. An Ampersand-engineer will happily remove a rule if it doesn't add value
8.5.	An effective system can be based on a small number of rules. Additional, more discriminating rules can be subsequently added, so that over time the system becomes smarter.
Ampersand says:	Agreed! Many Ampersand examples of less than 10 rules exist. A typical large system contains several hundreds of rules. Adding rules over time is easy, because rules have the property of compositionality.

9. Of, By, and For Business People, Not IT People

9.1.	Rules should arise from knowledgeable business people.
Ampersand says:	Agreed! The making of rules is a task for the wise, just as in the legislative process in civilized countries.
9.2.	Business people should have tools available to help them formulate, validate, and manage rules.
Ampersand says:	Agreed! Ampersand provides a method, a course, and tools for this purpose.
9.3.	Business people should have tools available to help them verify business rules against each other for consistency.
Ampersand says:	Agreed! Ampersand and RAP are such tools. Ampersand verifies rules for consistency and RAP is a repository in which those rules can be managed.

10. Managing Business Logic, Not Hardware/Software Platforms

10.1.	Business rules are a vital business asset.
Ampersand says:	Agreed! In principle, a business is a group of individuals who share purpose and are committed by a set of rules they try to follow. Without those rules, there is no business. So the business rules are a vital asset to the business.
10.2.	In the long run, rules are more important to the business than hardware/software platforms.
Ampersand says:	Agreed! A business without rules is merely a group of individuals, devoid of purpose. A business without hard/software platforms has been the norm for the many centuries before the information revolution starte. For this reason, Ampersand engineers focus on the business and let Ampersand do the technical work for them.
10.3.	Business rules should be organized and stored in such a way that they can be readily redeployed to new hardware/software platforms.
Ampersand says:	Agreed! The Ampersand compiler generates code that is typically deployed on a Docker platform. This means that deployment is instant, independent of hardware/software platforms, and headache free.
10.4.	Rules, and the ability to change them effectively, are fundamental to improving business adaptability.
Ampersand says:	Agreed! Adapting one rule has very often no consequence for other rules, because rules are mutually independent. That adaptation can be implemented in the software almost instantaneously.