SAF and DevOps
Nature and status of the approach
DevOps is not one standard or a formal metamodel, but a family of cultural and engineering principles and practices that bring development, delivery, and operations closer together. This page uses the common ground in public DORA/Google Cloud, Microsoft, AWS, and ISACA materials as of August 3, 2026. No source is treated as the sole canon.
Purpose and audience
The common intent of DevOps is to deliver changes faster and more reliably, remove organizational gaps, develop shared responsibility, and shorten feedback from users to teams. Its audience includes product, development, platform, security, quality, and operations teams and their leaders.
Management scope and unit
DevOps manages the flow of change for a digital product or service: from an idea and code through build, testing, and deployment to operations and learning. Practices include version control, CI/CD, test and deployment automation, infrastructure as code, observability, small batches, and continual improvement. The particular set depends on the organization.
Concepts and SAF mappings
| DevOps | Nearest concept in SAF | Type / confidence | Boundary |
|---|---|---|---|
| Product/service ownership | Service, product grouping, and owner Actor | Composite / medium | Product and team topology remain external. |
| Cross-functional team | Actors with roles and a grouping | Partial / medium | Team is not a separate core type. |
| Value stream / delivery flow | Processes, Capabilities, and object states | Composite / medium | A work flow is not one Process. |
| Loosely coupled architecture | Systems, Components, Interfaces, and Integrations | Partial / high | SAF shows structure; DevOps evaluates whether its parts can change independently. |
| Deployment pipeline | External process and tools that create a SAF Deployment | Composite / high | A pipeline and deployment record are not the Deployment object. |
| Infrastructure as code | Representation of Deployment, Compute Resource, and Network Segment configuration | Partial / high | Code is a source of facts, not a substitute for SAF's business meaning. |
| Telemetry and feedback | External measures and operational records | Not applicable / high | Raw data is not stored in SAF. |
Relationships
A change affects code, configuration, and the supported service; a pipeline creates an artifact and delivery record; an actual Deployment realizes a Component; observability produces feedback; an incident or user signal initiates improvement. SAF connects the persistent points in this chain but does not replace a build graph or a delivery-platform workflow.
Lifecycle and organization of work
The common denominator across sources is small changes, automated checks and delivery, observation of outcomes, learning, and shared responsibility. DORA studies capabilities and measures of high-performing delivery, but it does not define every DevOps implementation. SAF records architectural dependencies that matter for delivery independence and impact analysis.
Roles and governance
DevOps seeks to reduce handoffs between isolated functions. This does not eliminate governance, segregation of duties, or ownership. In SAF, an object owner remains explicit; approval rules, policy as code, access, and team accountability belong to external management systems.
Measures, maturity, and adaptation
Public sources measure flow speed, stability, recovery, reliability, quality, and organizational outcomes. These measures depend on context and cannot be converted into SAF maturity. The architecture model helps explain which dependencies constrain flow and where a measure aggregates incomparable systems.
Using the approaches together
Pipelines and IaC should publish links to component_id, deployment_id, environment, and version instead of creating a parallel catalog. SAF provides a blast-radius map and business context; DevOps tools return actual state, change frequency, and operational signals. A mismatch becomes verifiable drift rather than a manual dispute between catalogs.
Mapping limitations
Public DevOps definitions vary and are often associated with vendor products. This page uses only recurring themes; source-specific recommendations are identified as such. DORA provides research support for particular capabilities but is not treated as a DevOps or SAF metamodel.