Software Product Line and Variability

This chapter addresses scale. Once enterprise architecture becomes semantic, decision-aware, and tied to execution, the next problem is how to produce many related solutions without recreating the same architecture effort each time. That is the practical territory of software product lines.

Product line discipline gives enterprise architecture a productive form under conditions of repetition and controlled variation, generalizing the SAP-specific pattern of Post 5 to the full enterprise portfolio.

What the chapter covers

9 sections, in order.

9.1 Family-based architecture in an enterprise setting
9.2 Why traditional enterprise architecture struggles with commonality and variability
9.3 What working systems already demonstrate
9.4 Designing a family architecture instead of a static reference
9.5 ACME Pharma: controlled variability for a regulated digital-study platform
9.6 What software product lines change for architects
9.7 Costs, limits, and trade-offs
9.8 Conclusion
9.9 Sources

Figures, tables and listings

3 code listings

Reproduced in full, in the order they appear in the published chapter. The reasoning that connects them is in the book.

apiVersion: ea.codex/v1
kind: ProductLineSpecification
metadata:
  id: PLS-CIP-001
  name: customer-identity-platform
  status: approved
  version: "1.0"
spec:
  intent:
    statement: >
      Provide a governed identity and consent capability for regulated customer journeys
      across multiple regions and assurance levels.
  scope:
    capabilities:
      - customer-identity
      - consent-management
      - audit-traceability
      - customer-notification
    inScopeProducts:
      - retail-onboarding
      - partner-onboarding
      - service-account-registration
  commonality:
    canonicalObjects:
      - Customer
      - IdentityCredential
      - ConsentRecord
      - AuditEvent
    coreServices:
      - identity-core
      - consent-core
      - audit-service
      - notification-core
    mandatoryControls:
      - separation-of-duties
      - immutable-audit-log
      - retention-baseline
  variationPoints:
    region_pack:
      type: alternative
      values: [EU, US, APAC]
      bindingTime: deployment
    assurance_level:
      type: alternative
      values: [standard, strong, qualified]
      bindingTime: design
    channel_adapter:
      type: multiple
      values: [web, mobile, contact-center, partner-api]
      bindingTime: build
    deployment_mode:
      type: alternative
      values: [shared, dedicated]
      bindingTime: decision
  rules:
    - when: region_pack == "EU"
      require: [gdpr_pack, eu_data_residency]
    - when: assurance_level == "qualified"
      require: [hardware_key_protection, four-eyes-approval]
    - when: deployment_mode == "shared"
      forbid: [qualified]
  decisions:
    - id: DD-ID-012
      statement: dedicated deployment is reserved for qualified assurance contexts
      variationPoint: deployment_mode
    - id: DD-ID-019
      statement: partner-api requires explicit contract versioning
      variationPoint: channel_adapter
  derivationInputs:
    - selected-region-pack
    - selected-assurance-level
    - selected-channel-adapters
    - applicable-policies
  derivationOutputs:
    - target-architecture-spec
    - control-profile
    - deployment-template

Figure 9.1: Architecture contract for the customer-identity-platform family.

apiVersion: ea.codex/v1
kind: ProductLineSpecification
metadata:
  id: PLS-ACME-DSP-001
  name: acme-digital-study-platform
  status: approved
  version: "1.0"
spec:
  intent:
    statement: >
      Deliver a governed family of digital-study solutions with reusable controls,
      bounded regional variation, and validated integration into the ACME Pharma trial estate.
  scope:
    capabilities:
      - study-setup
      - investigator-collaboration
      - participant-consent-traceability
      - regulated-document-exchange
      - study-notifications
      - evidence-and-audit
  commonality:
    coreServices:
      - identity-and-access
      - workflow-engine
      - document-service
      - audit-event-store
      - notification-service
      - integration-gateway
      - observability-stack
    canonicalObjects:
      - Study
      - Site
      - Investigator
      - ParticipantConsent
      - StudyDocument
      - AuditEvidence
    mandatoryControls:
      - immutable-audit-log
      - validated-release-pipeline
      - segregation-of-duties
      - evidence-retention
  variationPoints:
    region:
      type: alternative
      values: [EU, US, Global]
      bindingTime: deployment
    study_mode:
      type: alternative
      values: [interventional, observational]
      bindingTime: design
    hosting_model:
      type: alternative
      values: [validated-shared, dedicated]
      bindingTime: decision
    ai_assistance:
      type: alternative
      values: [disabled, retrieval-only, constrained-workflow]
      bindingTime: design
    external_partner_portal:
      type: optional
      values: [enabled]
      bindingTime: build
  rules:
    - when: region == "EU"
      require:
        - eu-data-residency
        - gdpr-consent-pack
        - eu-vendor-assurance
    - when: study_mode == "interventional"
      require:
        - adverse-event-workflow
        - investigational-product-integration
    - when: ai_assistance == "constrained-workflow"
      require:
        - model-risk-assessment
        - prompt-and-response-logging
        - human-review-step
        - approved-action-boundaries
    - when: hosting_model == "validated-shared"
      forbid:
        - study_mode == "interventional"
  decisions:
    - id: DD-ACME-041
      statement: >
        Interventional studies require dedicated hosting because validation and
        operational segregation obligations exceed the validated-shared baseline.
    - id: DD-ACME-052
      statement: >
        AI assistance is limited to retrieval-only or constrained workflow patterns
        and cannot issue autonomous study-state changes.
  derivationOutputs:
    - target-architecture-spec
    - control-profile
    - deployment-blueprint
    - validation-scenario-pack

Figure 9.2: Product-line specification for the ACME Pharma digital-study platform family.

package acme.studyplatform
deny[msg] {
  input.study_mode == "interventional"
  input.hosting_model != "dedicated"
  msg := "Interventional studies must use dedicated hosting."
}
deny[msg] {
  input.region == "EU"
  not input.controls.eu_data_residency
  msg := "EU deployments require EU data residency controls."
}
deny[msg] {
  input.ai_assistance == "constrained-workflow"
  not input.controls.human_review_step
  msg := "Constrained workflow AI requires a human review step."
}

Figure 9.3: Rego policy enforcing the interventional-study hosting rule.

The rest of this chapter

The published chapter runs the argument through all 9 sections above. This page reproduces its structure and every exhibit; the analysis is in the book.