SAF and TOGAF
This comparison uses the TOGAF® Standard, 10th Edition with Technical Corrigendum 1, as listed in The Open Group's official catalog. SAF is not presented as a TOGAF implementation and does not inherit its requirements.
Purpose and audience
SAF provides a small shared vocabulary and a path for gradually increasing the sophistication of a company model. TOGAF is primarily intended to organize an architecture practice: it helps determine how architecture is developed, decisions are made, outcomes are governed, and work is tailored to enterprise context. The Open Group describes the 10th Edition as a combination of fundamental content and Series Guides that configure the practice for different uses (TOGAF overview).
SAF therefore has a broader audience at early stages: technical leaders, product owners, and analysts can start with a catalog without a dedicated EA function. TOGAF is aimed more directly at architects, EA leaders, and architecture governance bodies, although organizations of different sizes can tailor it.
Architecture domains
Both approaches cover business, applications, data/information, and technology, but draw the boundaries differently:
- the SAF business layer contains actor, channel, service, process, capability, and information object;
- TOGAF organizes architecture work around Business, Data, Application, and Technology Architecture and connects them to vision, requirements, and implementation;
- the SAF infrastructure layer belongs to the domain model itself, whereas TOGAF places similar content in Technology Architecture and a tailored content model;
- SAF deliberately excludes goals, requirements, principles, projects, and roadmaps from its core; TOGAF uses such outputs throughout the architecture cycle.
The official explanation of using TOGAF and ArchiMate together likewise identifies business, information/data, application, and technology domains and relates them to ADM phases (The Open Group).
SAF concepts and mappings
| SAF object | Closest TOGAF content | Assessment |
|---|---|---|
| Actor | Actor, Role, Organization Unit, Stakeholder | Composite, high: SAF combines several organizational perspectives. |
| Channel | The interaction channel is expressed through service delivery, an interface, location, or a local extension | Composite, medium. |
| Service | Business Service | Direct, high, when the outcome boundary is aligned. |
| Process | Process and, where needed, Function | Direct/partial, high: SAF separates process from capability but has no business function type. |
| Capability | Business Capability | Direct, high. |
| Information object | Data Entity and business information content | Composite, high: SAF specializations require a rule for choosing logical and physical levels. |
| System | A set of Logical/Physical Application Components and their services | Composite, medium: a single SAF boundary need not match a building block. |
| Component | Logical or Physical Application Component | Partial, high. |
| Interface | Information System Service, contract, and access point to an Application Component | Composite, medium. |
| Integration | Interaction relationships, interface matrices, and data flows | Composite, high: a persistent SAF object usually becomes an architecture artifact or extension. |
| Deployment | A relationship between a Physical Application Component, Physical Technology Component, and environment | Composite, medium. |
| Compute resource | Physical Technology Component and Technology Service | Partial, high. |
| Network segment | Logical/Physical Technology Component, Location, and communications topology | Composite, medium. |
Matching terminology does not make identifiers interchangeable. Data exchange requires an explicit mapping profile that accounts for the enterprise metamodel configured by a particular TOGAF practice.
Relationships
SAF defines a small normative set of domain relationships: a service is realized by a process, a system supports a capability, a component exposes an interface, an integration transfers an information object, a deployment is hosted on a resource, and so forth.
TOGAF focuses more on traceability across architecture content through the metamodel, catalogs, matrices, and diagrams. Similar relationships can usually be found, but one SAF relationship may decompose into several relationships among building blocks, services, and requirement elements. This is especially visible for integration and deployment, which SAF treats as independent managed objects.
A practical rule for combined use is to keep SAF as the master model for the operational catalog while the TOGAF repository references the same stable identifier and adds architecture-work context. Equivalence must not be inferred automatically from names.
Views and artifacts
SAF prescribes no notation: a page, table, or diagram is a projection of one canonical model. TOGAF offers a much richer system of deliverables, artifacts, and building blocks; artifacts may be catalogs, matrices, or diagrams. This helps select a view for a stakeholder concern, but it does not mean that every TOGAF artifact belongs in SAF.
A combined practice only needs to:
- use the SAF catalog as source facts about the current state;
- derive TOGAF artifacts for a specific architecture task;
- return accepted changes to SAF while preserving identifiers;
- avoid moving temporary deliverables into the SAF core merely because one ADM iteration needs them.
Working method
TOGAF's principal addition to SAF is the Architecture Development Method (ADM): a repeatable cycle from preparation and vision through domain architectures, implementation options, migration planning, implementation governance, and change management. SAF describes evolutionary transitions in profile and maturity but does not define a complete architecture development project cycle.
Together they can work as follows: ADM frames the question, stakeholders, baseline, and target architecture; SAF supplies a minimal vocabulary of facts; specialized artifacts expose gaps and options; and the SAF catalog is updated after the decision as the durable model.
Governance
At the governed level, SAF requires owners, statuses, sources, validity periods, and relationship verification. TOGAF treats architecture capability more broadly through roles and governance bodies, principles, the repository, decision conformance, and requirements and change management. This is where TOGAF addresses SAF's most visible organizational gap.
These TOGAF mechanisms should not be placed in the minimal startup-profile core. They can be introduced as working practices when multiple teams, material investments, and cross-domain change coordination emerge.
Maturity and tailoring
The SAF levels “Catalog → Connected model → Governed model” measure the quality of a particular model, not the maturity of the whole EA function. TOGAF supports tailoring of method and content; Series Guides cover different ways of working, and the guidance catalog includes material on architecture capability and maturity models (TOGAF Series Guides).
A direct equivalence between the levels is therefore invalid. An organization may apply ADM rigorously while maintaining an incomplete SAF catalog, or maintain a high-quality connected model without a formal TOGAF practice.
Using TOGAF with SAF
- Startup: use selected ADM questions—purpose, stakeholders, constraints, and decision—without the full artifact set.
- Stable business: connect the SAF catalog to architecture initiatives, baseline and target architecture, principles, and decision reviews.
- Enterprise: use TOGAF for the EA operating model, governance, and transition portfolio, and SAF as a simplified shared core of objects and relationships for a broader audience.
The combination is particularly useful when moving to governed maturity, where object types alone are insufficient and a sustainable decision process is required.
Mapping limitations
TOGAF is a tailorable framework, so two organizations may use different content-metamodel extensions and artifact sets. These mappings describe the stable semantic core, not a universal import schema. The full standard is distributed under license; this page uses concise paraphrases of officially available information and does not copy tables or diagrams.