Book Pick: Rules & Architecture

Symbolic & Actual Rules’ Footprint

Excerpt from Enterprise Architecture Fundamentals:


Rules’ Footprints

The architectural footprint of rules can be defined by their triggering conditions, what is evaluated (rule’s domain), and what is affected (rule’s co-domain). On that basis, a distinction can be made between:

• Homogeneous rules: triggered, evaluated, and executed on the same side of the environment/EA divide

• Heterogeneous rules: set astride EA edges, with a possible mix of business complexity and architecture capabilities

Homogeneous rules, which are evaluated and executed on the same side of the divide, should not affect the tie-up (or coupling) between systems and their environment; for example (figure 12-5):

  • Data analytics: for rules used to build business (or symbolic) views of environments (e.g., market demographics) without a direct impact on systems’ representations (figure 12-5a)
  • Regulations: for rules governing business environments (e.g., food labeling); possibly used by business intelligence (figure 12-5b)
  • Business logic and computation rules: meant to be applied to enterprises’ symbolic representations without affecting them (e.g., audit rules) (figure 12-5c)

Figure 12-5. Rules’ Footprint

By contrast, the footprint of heterogeneous rules straddles the fences between enterprises and environments:

  • Input/Output rules: to log external events (figure 12-5e) or to notify internal ones (figure 12-5d)
  • Application rules: combine the complexity of business domains with the constraints of systems functional architecture (figure 12-5f )
  • Technical rules: combine functional complexity with the constraints of QoS (figure 12-5g)

Refactoring rules with regard to their footprint on the environment/architecture divide helps to map requirements to EA capabilities.


(From Chapter 12)
%d bloggers like this: