Rules & Architecture

Rules can be seen as both the essence and the glue of models:

  • Essence: while entwined in requirements rules embody the combined static and dynamic complexity of actual domains and symbolic representations.
  • Glue: once explicitly delineated in models rules bind the semantics of whatever is set in their footprint.
How to outline the architectural footprint of rules (John Devlin)

Considering that requirements are not supposed to be delivered with categories fully and consistently defined upfront, the way rules are expressed is at the core of requirements analysis.

It ensues that between jumbled requirements and well-formed logic rules can take a variety of shapes, which raises two questions: (1) how are those shapes to affect architectures capabilities and, (2) how to pick the good ones.

PRIMARY TAXONOMY

As far as enterprise architecture is concerned, rules can be about:

  • Business and regulatory environments.
  • Enterprise objectives and organization.
  • Business processes and supporting systems.

That classification can be mapped to a logical one:

  • Rules set in business or regulatory environments are said to be deontic as they are to be met independently of enterprise governance. They must be enforced by symbolic representations if enterprise systems are to be aligned with environments.
  • Rules associated with objectives, organization, processes or systems are said to be alethic (aka modal) as they refer to possible, necessary or contingent conditions as defined by enterprise governance. They are to be directly applied to symbolic representations.

Whereas both are to be supported by systems, the loci will differ: system boundaries for deontic rules (coupling between environment and systems), system components for alethic ones (continuity and consistency of symbolic representations). Given the architectural consequences, rules should be organized depending on triggering (actual or symbolic) and scope (environment or enterprise):

  • Actual deontic rules are triggered by actual external events that must be processed synchronously.
  • Symbolic deontic rules are triggered by external events that may be processed asynchronously.
  • Actual alethic rules are triggered by business processes and must be processed synchronously.
  • Symbolic alethic rules are triggered by business processes and can be processed asynchronously.
Rules should be classified upfront with regard to triggering (actual or symbolic) and scope (environment or enterprise)

Footprint

The footprint of a rule is made of the categories of facts to be considered (aka rule domain), and categories of facts possibly affected (aka rule co-domain).

As far as systems are concerned, the first thing to do is to distinguish between actual contexts and symbolic representations. A naive understanding would assume rules to belong to either actual or symbolic realms. Given that the objective of modeling is to decide how the former should be represented by the latter, some grey imprints are to be expected and dealt with:

  • Rules targeting actual contexts. They can be checked through sensors or applied by actuators. Since rules enforcement cannot be guaranteed on non symbolic artifacts, some rules will have to monitor infringements and proscribed configurations. Example: “Cars should be checked on return from each rental, and on transfer between branches.”
  • Rules targeting symbolic representations. Their enforcement is supposedly under the full control of system components. Example: “A car with accumulated mileage greater than 5000 since its last service must be scheduled for service.”
  • Rules defining how changes in actual contexts should impact symbolic representations: what is to be considered, where it should be observed, when it should be recorded, how it should be processed, who is to be authorized. Example: ” Customers’ requests at branches for cars of particular models should be consolidated every day.”
RulesCapabs
Rules & Capabilities

That analysis should be carried out as soon as possible because rules set on the divide will determine the impact of requirements on architecture capabilities.

Semantics and Syntax

Rules footprints are charted by domains (what is to be considered) and co-domains (what is to be affected). Since footprints are defined by requirements semantics the outcome shouldn’t be contingent on formats.

From an architecture perspective the critical distinction is between homogeneous and heterogeneous rules, the former with footprint on the same side of the actual/symbolic divide, the latter with a footprint set across.

RulesCapabsH
Homogeneous vs Heterogeneous footprints

Contrary to footprints, the shape given to rules (aka format, aka syntax,) is to affect their execution. Assuming homogeneous footprints, four basic blueprints are available depending on the way domains (categories of instances to be valued) and co-domains (categories of instances possibly affected) are combined:

  • Partitions are expressions used to classify facts of a given category.
  • Constraints (backward rules) are conditions to be checked on facts: [domain].
  • Pull rules (static forward) are expressions used to modify facts: co-domain =  [domain].
  • Push rules (dynamic forward) are expressions used to trigger the modification of facts: [domain]  > co-domain.
Pull vs Push Rule Management

Stereotyped blueprints can then be defined for homogeneous rules:

  • Symbolic objects: integrity constraints, derivation rules, inference or cascading updates.
  • Activities: static conditions, conditions on data flows, functions, sequencing of operations.
  • Processes: synchronization constraints, derived states, stimulus or triggering of transitions.
  • Actors: categories, constraints, specialization, delegation.
  • Physical objects: monitoring, computation rules, events triggering rules.
RulesForms
Stereotyped blueprints for homogeneous rules

Assuming circumscribed and homogeneous footprints, the next step is to refine the attachments.

Anchors & Granularity

In principle, rules targeting different categories of facts are nothing more than well-formed expressions combining homogeneous ones. In practice, because they mix different kinds of artifacts, the way they are built is bound to significantly bear on architecture capabilities.

Systems are tied to environments by anchors, i.e objects and processes whose identity and consistency must be maintained during their life-cycle. Rules should therefore be attached to anchors’ facets as to obtain as fine-grained footprints as possible:

OKBI_Camco
Architecture Anchors & their facets
  • Features: domain and co-domain are limited to attributes or operations.
  • Object footprint: domain and co-domain are set within the limit of a uniquely identified instance (#), including composites and aggregates.
  • Connections: domain and co-domain are set by the connections between instances identified independently.
  • Collections: domain and co-domain are set between sets of instances and individuals ones, including subsets defined by partitions.
  • Containers: domain and co-domain are set for whole systems.

While minimizing the scope of simple (homogeneous) rules is arguably a straightforward routine, alternative options may have to be considered for the transformation of joint (heterogeneous) statements, e.g when rules about functional dependencies may be attached either to (1) persistent representation of objects and associations or, (2) business applications.

Heterogeneous (joint) Footprints

Footprints set across different categories will usually leave room for alternative modeling options affecting the way rules will be executed, and therefore bearing differently on architecture capabilities.

Basic alternatives can be defined according to requirements taxonomy:

  • Business requirements: rules set at enterprise level that can be managed independently of the architecture.
  • System functionalities: rules set at system level whose support depends on architecture capabilities.
  • Quality of service: rules set at system level whose support depends on functional and technical architectures.
  • Operational constraints: rules set at platform level whose support depends on technical capabilities.
Rules do not necessarily fit into clear requirements taxonomy

While that classification may work fine for homogeneous rules (a), it may fall short for mixed ones, functional (b) or not (c). For instance:

  • “Gold Customers with requests for cars of particular models should be given an immediate answer.”
  • “Technical problems affecting security on checked cars must be notified immediately.”

As requirements go, rules interweaving business, functional, and non functional requirements are routine and their transformation should reflect how priorities are to be sorted out.

Moreover, if rule refactoring is to be carried out, there will be more than syntax and semantics to consider because almost every requirement can be expressed as a rule, often with alternative options. As a corollary, the modeling policies governing the making of rules should be set explicitly.

Sorting Out Mixed Rules

Taking into account that functional requirements describe how systems are meant to support  business processes, some rules are bound to mix functional and business concerns. When that’s the case, preferences will have to be set with regard to:

  • Events vs Data: should system behavior be driven by changes in business context (as signaled by events from users, devices, or other systems), or by changes in symbolic representations.
  • Activities vs Data: should system behavior be governed by planned activities, or by the states of business objects.
  • Activities vs Events: should system behavior be governed by planned activities, or driven by changes in business context.

Taking the Gold Customer example, a logical rule (right) is not meant to affect the architecture, but expressed at control level (left) it points to communication capabilities.

RulesBuFu1
How to express Gold customers’ rule may or may not point to communication capabilities.

The same questions arise for rules mixing functional requirements, quality of service, and operational constraints, e.g:

  • How to apportion response time constraints between endpoints, communication architecture, and applications.
  • How to apportion reliability constraints between application software and resources at location .
  • How to apportion confidentiality constraints between entry points, communication architecture, and locations.

Those questions often arise with non functional requirements and entail broader architectural issues and the divide between enterprise wide and domain specific capabilities.

Decision Points, Architecture, and the Making of Rules

Beyond requirements specifics, rules should befit organizational and architectural options set at enterprise level. That should be the aim of requirements analysis and rules transformation.

While rules description combines syntactic constructs (constraints, computation, triggers, etc) and semantics (objects, events, activities, role, etc), their transformation should be governed by the pragmatics associated to the architecture framework. For instance, rules aiming at a Model/View/Controller framework would be organized along three layers:

  • Model:  constraints, derivations, inferences and cascading updates that can be applied on shared and persistent instances independently of applications.
  • Views: constraints and processing rules that can be applied on non shared and transient instances executed at entry points.
  • Controller: processing and control rules that can be applied on shared and transient instances independently of entry points.

Obviously, pragmatics can go further than simple MVC layers and take into account application life-cycle (e.g along MDA’s CIMs, PIMs, and PSMs), and collaboration mechanisms (e.g activity- vs event-driven). For that purpose the making of rules should follow three guidelines:

  1. Partitions and constraints should be used to anchor rules to decision points clearly set with regard to architecture (e.g MVC) and model layers (e.g MDA). For instance: the decision point for the type of reservation belongs to computation independent business logic, and classifications of customers and cars belong to computation Independent business domains.
  2. Backward constructs should be used for rules pertaining to business logic independently of processes execution. For instance: how to process a reservation (a).
  3. Forward constructs should be used to compare alternative execution models. For instance: activity driven through control flows (b), or event-driven through event notification (c).
“Gold Customers with requests for cars of particular models should be given an immediate answer.”

Not by chance, applying those guidelines will neatly map rules to standard diagrams: class diagrams (partitions and integrity constraints), use cases (extension points), activity diagrams (backward rules for branches and functions), business processes (backward rules for gateways) and state charts (forward rules for transitions).

Further Reading

%d bloggers like this: