Product lifecycle management

ks during transitions (e.g., block GA transition if security scan fails). 4. Observability Layer: Emits events for state changes, enabling downstream automation (notifications, billing adjustments).

Technical Implementation (TypeScript)

The following implementation defines a type-safe PLM engine. It includes a state machine, policy validation, and an asset registry interface.

1. Domain Definitions

// types.ts

export type LifecycleState = 
  | 'DRAFT' 
  | 'ALPHA' 
  | 'BETA' 
  | 'GA' 
  | 'MAINTENANCE' 
  | 'SUNSET';

export type Transition = {
  from: LifecycleState;
  to: LifecycleState;
  requiredPolicies: string[];
};

export interface LifecyclePolicy {
  name: string;
  validate(assetId: string, context: Record<string, any>): Promise<boolean>;
}

export interface DigitalAsset {
  id: string;
  type: string; // e.g., 'API', 'SCHEMA', 'CONFIG'
  currentState: LifecycleState;
  metadata: Record<string, any>;
  transitions: Array<{
    timestamp: string;
    from: LifecycleState;
    to: LifecycleState;
    actor: string;
    reason: string;
  }>;
}

2. State Machine and Engine

// engine.ts

import { LifecycleState, Transition, LifecyclePolicy, DigitalAsset } from './types';

export class PLMEngine {
  private transitions: Transition[];
  private policies: Map<string, LifecyclePolicy>;
  private registry: Map<string, DigitalAsset>;

  constructor() {
    this.transitions = [
      { from: 'DRAFT', to: 'ALPHA', requiredPolicies: ['security-scan'] },
      { from: 'ALPHA', to: 'BETA', requiredPolicies: ['test-coverage'] },
      { from: 'BETA', to: 'GA', requiredPolicies: ['security-scan', 'performance-baseline'] },
      { from: 'GA', to: 'MAINTENANCE', requiredPolicies: [] },
      { from: 'MAINTENANCE', to: 'SUNSET', requiredPolicies: ['dependency-check'] },
      // Allow rollback in specific cases
      { from: 'BETA', to: 'ALPHA', requiredPolicies: [] },
    ];
    this.policies = new Map();
    this.registry = new Map();
  }

  registerPolicy(policy: LifecyclePolicy): void {
    this.policies.set(policy.name, policy);
  }

  registerAsset(asset: DigitalAsset): void {
    this.registry.set(asset.id, asset);
  }

  async executeTransition(
    assetId: string, 
    targetState: LifecycleState, 
    actor: string, 
    reason: string,
    context: Record<string, any>
  ): Promise<DigitalAsset> {
    const asset = this.registry.get(assetId);
    if (!asset) throw new Error(`Asset ${assetId} not found`);

    const transition = this.transitions.find(
      t => t.from === asset.currentState && t.to === targetState
    );

    if (!transition) {
      throw new Error(`Invalid transition from ${asset.currentState} to ${targetState}`);
    }

    // Validate Policies
    for (const policyName of transition.requiredPolicies) {
      const policy = this.policies.get(policyName);
      if (!policy) throw new Error(`Policy ${policyName} not implemented`);
      
      const isValid = await policy.validate(assetId, context);
      if (!isValid) {
        throw new Error(`Policy validation failed: ${policyName}`);
      }
    }

    // Execute Transition
    const previousState = asset.currentState;
    asset.currentState = targetState;
    asset.transitions.push({
      timestamp: new Date().toISOString(),
      from: previousState,
      to: targetState,
      actor,
      reason,
    });

    // Emit Event (Mock)
    console.log(`[PLM] Event: Asset ${assetId} moved ${previousState} -> ${targetState}`);
    
    return asset;
  }

  getAssetsByState(state: LifecycleState): DigitalAsset[] {
    return Array.from(this.registry.values()).filter(a => a.currentState === state);
  }
}

3. Policy Implementation Example

// policies.ts

import { LifecyclePolicy } from './types';

export class SecurityScanPolicy implements LifecyclePolicy {
  name = 'security-scan';

  async validate(assetId: string, context: Record<string, any>): Promise<boolean> {
    // Integrate with actual security tooling (e.g., Snyk, Trivy, OWASP)
    const scanResult = context.securityScanResult;
    return scanResult?.status === 'PASS' && scanResult.criticalVulns === 0;
  }
}

4. Usage Example

// main.ts

import { PLMEngine } from './engine';
import { SecurityScanPolicy } from './policies';

async function bootstrap() {
  const engine = new PLMEngine();
  engine.registerPolicy(new SecurityScanPolicy());

  // Register a new API asset
  engine.registerAsset({
    id: 'api-payment-v1',
    type: 'API',
    currentState: 'DRAFT',
    metadata: { owner: 'payments-team', repo: 'github/org/repo' },
    transitions: [],
  });

  // Promote to Alpha
  const updatedAsset = await engine.executeTransition(
    'api-payment-v1',
    'ALPHA',
    'dev-lead',
    'Ready for internal testing',
    { securityScanResult: { status: 'PASS', criticalVulns: 0 } }
  );

  console.log(`Asset state: ${updatedAsset.currentState}`);
}

bootstrap();

Architecture Rationale

• Decoupled State: Lifecycle state is managed independently of Git branches or deployment tags. This allows an asset to be deployed in production but marked SUNSET to block new integrations.
• Policy Hooks: Transitions are gated by policies. This enforces quality and compliance automatically. You cannot reach GA without passing security and performance checks.
• Immutable Audit Trail: The transitions array in the asset object provides a tamper-evident log of lifecycle changes, essential for compliance and debugging.
• Type Safety: TypeScript interfaces ensure that state transitions and policy contracts are validated at compile time, reducing runtime errors.

Pitfall Guide

1. Treating PLM as Metadata Only

Mistake: Storing lifecycle status in a README or Jira ticket without enforcement. Consequence: State becomes stale and untrusted. Developers ignore the metadata because it doesn't block actions. Best Practice: Bind lifecycle state to execution gates. CI/CD pipelines should query the PLM engine and fail builds if an asset is in a prohibited state (e.g., deploying SUNSET assets).

2. Ignoring the Sunset Phase

Mistake: Defining states up to GA but neglecting MAINTENANCE and SUNSET. Consequence: Technical debt accumulates. Deprecated assets remain active, consuming resources and increasing attack surface. Best Practice: Define sunset policies explicitly. Implement automated dependency checks that warn consumers when an asset approaches sunset. Automate the retirement workflow to decommission resources.

3. Over-Complicating the State Machine

Mistake: Creating dozens of states and complex cross-branching transitions. Consequence: The system becomes rigid and hard to maintain. Policy logic becomes tangled. Best Practice: Keep the state machine minimal. Use DRAFT, ALPHA, BETA, GA, MAINTENANCE, SUNSET. Handle variations via metadata and policies, not state proliferation.

4. Coupling Lifecycle to Git Commits

Mistake: Using git tags or branch names to infer lifecycle state. Consequence: Semantic loss. A tag v1.0 doesn't indicate if the asset is supported. Rollbacks become ambiguous. Best Practice: Map git references to lifecycle states via the registry. The PLM engine is the source of truth; git is the artifact store.

5. Lack of Observability

Mistake: No metrics or alerts on lifecycle events. Consequence: Blind spots. Teams don't know when assets are stuck in ALPHA for months or when transitions fail. Best Practice: Emit structured events for all transitions. Dashboard metrics like "Time to GA," "Orphaned Asset Count," and "Transition Failure Rate."

6. Manual Transitions in High-Volume Environments

Mistake: Requiring manual approval for every state change in large teams. Consequence: Bottlenecks. Velocity decreases as teams wait for lifecycle updates. Best Practice: Automate transitions where possible. Use policies to auto-promote assets that meet criteria (e.g., auto-promote to GA after 30 days of stability in BETA). Reserve manual approval for high-risk transitions like SUNSET.

7. Ignoring Dependency Matrices

Mistake: Managing asset lifecycle in isolation without tracking dependencies. Consequence: Breaking changes. Sunsetting an asset breaks downstream consumers. Best Practice: Implement a dependency graph. The dependency-check policy should analyze the digital asset matrix to identify consumers before allowing SUNSET. Notify and coordinate with downstream teams.

Production Bundle

Action Checklist

• Define Lifecycle Schema: Establish the canonical set of states and transitions for your product domain.
• Implement PLM Engine: Deploy the state machine and registry using the provided TypeScript template.
• Configure Policies: Implement policy checks for security, testing, and compliance relevant to your transitions.
• Integrate CI/CD: Hook pipelines to the PLM engine to validate state before deployment and trigger transitions on success.
• Audit Existing Assets: Run a discovery scan to register all current digital assets and assign initial states.
• Enable Observability: Set up dashboards and alerts for lifecycle metrics and transition events.
• Document Sunset Procedures: Create runbooks for the SUNSET phase, including consumer notification and resource decommissioning.
• Review Quarterly: Schedule regular reviews of the lifecycle policy effectiveness and state machine adjustments.

Decision Matrix

Scenario	Recommended Approach	Why	Cost Impact
Small Team / MVP	Lightweight PLM with JSON Registry	Low overhead, quick setup. Use simple scripts for transitions.	Low dev time, minimal infra cost.
Enterprise / Compliance	Programmatic PLM with Policy Hooks	Enforces audit trails, automated gates, and dependency checks.	Higher initial dev cost, reduces audit/compliance costs significantly.
High Churn / Rapid Iteration	Automated Transitions with Auto-Promotion	Reduces bottlenecks; policies drive state changes based on metrics.	Increases velocity; reduces manual toil.
Legacy Asset Migration	Read-Only Registry + Gradual Onboarding	Avoids disrupting legacy systems; map assets over time.	Low risk; incremental cost for migration tooling.

Configuration Template

Use this YAML configuration to define lifecycle policies and transitions for infrastructure-as-code integration.

plm:
  version: "1.0"
  states:
    - DRAFT
    - ALPHA
    - BETA
    - GA
    - MAINTENANCE
    - SUNSET
  
  transitions:
    - from: DRAFT
      to: ALPHA
      policies:
        - name: security-scan
          config:
            tool: trivy
            severity: HIGH
        - name: unit-test
          config:
            coverage: 80

    - from: BETA
      to: GA
      policies:
        - name: security-scan
        - name: performance-baseline
          config:
            p99_latency_ms: 200
        - name: compliance-check
          config:
            standard: SOC2

    - from: GA
      to: SUNSET
      policies:
        - name: dependency-check
          config:
            action: notify_consumers
            grace_period_days: 90

  assets:
    - id: api-user-service
      type: API
      initial_state: GA
      metadata:
        owner: identity-team
        repo: github/org/user-service
    
    - id: schema-order-v2
      type: SCHEMA
      initial_state: BETA
      metadata:
        owner: commerce-team

Quick Start Guide

1. Initialize Registry: Create a new repository for your PLM configuration. Add the TypeScript engine code and the types.ts definitions.

   mkdir plm-engine && cd plm-engine
   npm init -y
   npm install typescript @types/node
   tsc --init
   

2. Define First Asset: Create a configuration file (e.g., assets.json) and register your first digital asset with an initial state.

   [
     {
       "id": "svc-core-v1",
       "type": "SERVICE",
       "currentState": "DRAFT",
       "metadata": { "owner": "platform", "repo": "github/org/core" },
       "transitions": []
     }
   ]
   

3. Run Transition Script: Execute a script to promote the asset. This validates policies and updates the registry.

   node dist/main.js promote svc-core-v1 ALPHA --actor dev-ops --reason "Ready for staging"
   

4. Verify State: Query the registry to confirm the state change and audit trail.

   node dist/main.js status svc-core-v1
   # Output: State: ALPHA | Last Transition: 2023-10-27T10:00:00Z by dev-ops
   

5. Hook to Pipeline: Add a step in your CI pipeline to call the PLM engine before deployment. Fail the build if the asset is not in a deployable state.

   # .github/workflows/deploy.yml
   - name: Check PLM State
     run: |
       STATE=$(plm-cli get-state svc-core-v1)
       if [ "$STATE" != "GA" ] && [ "$STATE" != "MAINTENANCE" ]; then
         echo "Asset not in deployable state: $STATE"
         exit 1
       fi