Aligning architecture to business processes / taxonomies

[grovesy]

Feature Proposal

From an enterprise architecture and governance perspective, it is necessary to align system architectures, services, and interfaces with defined business taxonomies and business processes.

Target Project:

TBD

Description of Feature:

Introduce a business taxonomy decorator standard to enable consistent classification of CALM architecture elements (nodes, flows, controls, relationships) against a controlled business taxonomy (domains, capabilities, value streams, etc.).

This feature provides:

• A standardized, machine-readable way to associate architecture elements with business meaning
• A decoupled model where business taxonomy is managed independently of architecture structure
• The ability to query, aggregate, and reason over architecture by business capability rather than by system

User Stories:

• As an enterprise or business architect, I want to define arbitrary taxonomies so that architecture can be aligned to business intent
• As a solution architect, I want to tag services and flows with business taxonomies and processes so that I can demonstrate coverage and ownership
• As a business process owner, I want to query all systems supporting a capability so that I can assess business flows through system architecture.

Current Limitations:

• No standardized way to:
  • classify nodes by business function
  • associate flows with business processes
  • attach controls at a business level

Proposed Implementation:

Utilize CALM decorators with an associated schema to define arbitary business taxonomy and business process decorator standard.

Example taxonomy definition:

{
  "$schema": "https://calm.finos.org/standards/business/taxonomy.decorator.schema.json",
  "type": "business-taxonomy",
  "unique-id": "enterprise-taxonomy-v1",
  "data": {
    "taxonomies": [
      {
        "id": "trading",
        "name": "Trading",
        "kind": "domain"
      },
      {
        "id": "trading.execution",
        "name": "Execution",
        "kind": "capability",
        "parent": "trading"
      }
    ]
  }
}

Example classification decorator:

{
  "type": "business-classification",
  "unique-id": "classification-trading",
  "applies-to": ["execution-service", "risk-check-service"],
  "data": {
    "taxonomy-refs": [
      "trading.execution"
    ]
  }
}

Validation rules:

• taxonomy-refs must resolve to defined taxonomy nodes
• enforce allowed mappings:
  • nodes map to capabilities
  • flows map to processes or value streams
  • controls map to capabilities or classifications

Alternatives Considered:

Use metadata fields:

• hard to apply a meaningful schema which can be validated

Extend core CALM schema:

• introduces opinionated business model into core

External taxonomy system:

• no direct linkage to CALM artifacts
• requires custom integration
• weakens architecture-as-code approach

Naming conventions:

• not enforceable

Chosen approach:

• decorators provide standardized, extensible, non-breaking integration

Testing Strategy:

Unit tests:

• validate schema structure
• validate taxonomy reference resolution
• validate constraint rules

Integration tests:

• apply decorator to CALM models
• verify classification of nodes, flows, controls

Query tests:

• retrieve elements by taxonomy
• aggregate flows by capability
• list controls per capability

Negative tests:

• invalid references
• circular taxonomy definitions
• orphan taxonomy nodes

Documentation Requirements:

• business taxonomy decorator standard specification
• examples:
  • minimal taxonomy
  • enterprise taxonomy
  • multi-domain classification
• guidance:
  • taxonomy design principles
  • mapping rules for CALM elements
• integration guidance with flows and controls

Implementation Checklist:

• Design reviewed and approved
• Implementation completed
• Tests written and passing
• Documentation updated
• Relevant workflows updated (if needed)
• Performance impact assessed

Additional Context:

Key principle:

• keep business taxonomy decoupled but referentially linked to architecture