How SAP's Reference Architecture Fits Into TOGAF

Sit in an enterprise architecture governance review long enough, and someone will say “we’re in ADM phase B, business architecture” and look at you expectantly. If your entire SAP career has lived in PFCG roles and Fiori launchpads, not TOGAF phase gates, that sentence lands like a foreign language.

The confusion is not because SAP has no answer here. It has had one since 2023: its own TOGAF-aligned Enterprise Architecture Framework, with reference content, tooling and a methodology of its own. Almost nobody explains it in plain terms, or shows how it maps onto the TOGAF concepts an enterprise architect already knows.

This post draws that map. What SAP’s Enterprise Architecture Framework actually is, how it sits inside TOGAF rather than replacing it, and where a solution architect — not an EA specialist — actually needs to care.

🔗 Foundation for this post

What Does an SAP Solution Architect Actually Do? covers the SA-versus-EA boundary this post assumes, and S/4HANA Architecture Decisions Every Solution Architect Needs covers the technology-domain decisions that plug into the structure described here.

The one-sentence version

SAP has its own TOGAF-aligned Enterprise Architecture Framework. It is not a competing standard — it is TOGAF tailored with SAP-specific reference content, so architects are not rebuilding the same business-to-IT mappings from scratch on every project.

📌 Key takeaway

If you remember one thing from this post, make it this: SAP EAF does not replace TOGAF. It runs on top of it.

Why SAP built its own framework instead of just using TOGAF

TOGAF is deliberately generic. It gives you four architecture domains and a method — the Architecture Development Method, or ADM — for developing and governing architecture, but no content specific to any vendor’s products. That is the point. TOGAF has to work for any enterprise, running any technology, in any industry.

That generality leaves a real gap for an SAP-heavy landscape. TOGAF’s ADM tells you to define a target application architecture, but not which SAP module or BTP service actually satisfies a given business capability. Every architect working on SAP independently reconstructs that mapping from scratch, project after project.

SAP’s Enterprise Architecture Framework exists to close exactly that gap: TOGAF’s method, plus pre-built reference content mapping business capabilities directly to actual SAP solutions.

💡 Practical tip

If someone frames SAP EAF as “SAP’s alternative to TOGAF,” correct them. It only exists because TOGAF deliberately stays silent on vendor specifics — and that silence is a feature of TOGAF, not a gap SAP is trying to replace.

The five parts of the SAP Enterprise Architecture Framework

SAP structures its framework around five parts, and it helps to know what each one actually is before wading into any project that uses it.

Part	What it actually is
Methodology	A TOGAF-aligned method, tailored with SAP-specific artifacts and phase guidance
Reference Architecture content	Pre-built business and solution architecture content mapped to real SAP products
Tooling	SAP LeanIX, SAP Signavio and SAP Cloud ALM, supporting each stage of the method
Practice	How the framework gets embedded inside an organisation — governance, roles, change management
Services	Standardised EA services from SAP or partners, applying methodology, content and tooling together

⚠️ Warning

A common mistake is buying the tooling before agreeing on the methodology. A LeanIX licence without a shared method behind it just becomes an expensive diagramming tool. Get the methodology and governance agreed first — the tooling should support a practice that already exists, not create one by accident.

Where TOGAF’s ADM and SAP’s methodology actually map

TOGAF organises architecture into four domains — business, data, application and technology — developed iteratively through the ADM’s phases, from the initial architecture vision through business architecture, information systems architecture, technology architecture, and on into implementation and governance.

SAP structures its own Reference Architecture content around views that map onto those same domains, just pre-populated. Where TOGAF’s business architecture phase asks you to define target business capabilities from a blank page, SAP’s Reference Business Architecture already has a capability map built out for common industries, connected straight through to which SAP solution covers each one.

TOGAF ADM phase	SAP equivalent content
Phase B — Business Architecture	SAP Reference Business Architecture — pre-built capability and process maps
Phase C — Information Systems Architecture	SAP Reference Solution Architecture — capabilities mapped to actual SAP products and modules
Phase D — Technology Architecture	SAP-specific technology content — deployment options, BTP services and platform choices

📝 Note

The generic ADM phases do not disappear just because SAP has pre-built content for them. You still run the method. SAP’s content just gives you a faster, more concrete starting point than a blank page.

Reference Architecture vs Reference Solution Architecture — the terms people mix up

Reference Business Architecture is capability and process-level content. It describes what the business needs to do, independent of any specific software — the same kind of content a pure TOGAF business architecture phase would produce, just pre-built for common industries.

Reference Solution Architecture is the next layer down: it maps those same capabilities to actual SAP products and modules. It answers the question the business architecture deliberately leaves open — which specific SAP solution actually does this.

The practical distinction matters in the room, not just on paper. A business architecture conversation is a conversation with the business about what needs to happen. A solution architecture conversation is a conversation with IT and vendors about what actually delivers it. Mixing the two up in a governance meeting means debating specific transaction codes when the room was meant to agree on business capabilities — or the reverse, agreeing on vague capability language when what the room actually needed was a concrete product decision.

Where ISA-M fits — a narrower, complementary framework

ISA-M, the Integration Solution Advisory Methodology, is not a rival to SAP’s Enterprise Architecture Framework. It is a narrower, integration-specific methodology SAP has used since 2014, built to help architects assess integration styles — process, data, user and IoT integration — and design a hybrid integration platform across SAP and non-SAP landscapes.

If the Enterprise Architecture Framework is the whole map, ISA-M is the detailed street-level guide for one specific district: integration architecture. You reach for it once you are specifically designing how systems talk to each other, not for the broader business-to-IT alignment question the wider EA framework answers.

✅ Best practice

Do not reach for ISA-M as your first framework on a project. Start with the broader EA methodology to establish the target architecture, then bring ISA-M in specifically once you are at the integration design stage.

Where this actually matters for a solution architect

This connects straight back to the SA-versus-EA boundary from earlier in this series. Smaller organisations often do not have a dedicated enterprise architect, which means the solution architect ends up applying pieces of this framework by default, whether or not anyone in the room calls it that.

Knowing the mapping is what lets you speak the same language as an enterprise architect in a governance conversation, instead of nodding along at “ADM phase B” without understanding what is actually being asked of you.

📌 Key takeaway

You do not need to become a TOGAF-certified enterprise architect to get value from this. You need to recognise the handful of terms that keep recurring in governance conversations, and know roughly which SAP artifact answers each one. That covers most of the practical value.

At a glance — the mental model

Concept	One-line summary
TOGAF	The vendor-neutral enterprise architecture standard and ADM method that SAP EAF is built on top of, not a replacement for
SAP Enterprise Architecture Framework (EAF)	TOGAF tailored with SAP-specific reference content, so architects are not rebuilding business-to-IT mappings from scratch
The five EAF parts	Methodology, Reference Architecture content, Tooling, Practice, Services
Reference Business Architecture	Capability and process-level content describing what the business needs, independent of specific software
Reference Solution Architecture	Maps those same capabilities to actual SAP products and modules
ISA-M	A narrower, complementary methodology specifically for integration architecture decisions, in use since 2014
Why it matters for an SA	Lets you speak the same language as an enterprise architect in governance conversations, even without EA specialist training

What to take away

SAP’s framework is not a competing standard. It is a shortcut inside an existing one — TOGAF’s method, with the vendor-specific content TOGAF deliberately leaves out already filled in for you.

Knowing that distinction saves you from relitigating “why aren’t we just using TOGAF” in every governance meeting. It is the difference between being the person in the room who nods along at “ADM phase B” and being the person who knows exactly which SAP artifact that phase maps to.

You do not need a TOGAF certification to use any of this well. You need to recognise the handful of terms that keep recurring, and know roughly where they sit in the structure. That is the whole bridge this post set out to build.

🔗 Related reading — the rest of this series

What Does an SAP Solution Architect Actually Do? — the SA-versus-EA boundary this post assumes and builds on directly.

SAP LeanIX — Enterprise Architecture Management — a closer look at the tooling pillar of the framework described in this post.

Published on rakeshnarayan.com — Articles

URL: https://rakeshnarayan.com/articles/how-saps-reference-architecture-fits-into-togaf/