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.
***