What Does an SAP Solution Architect Actually Do?

Ask five people on an SAP project what the solution architect actually does, and you will get five different answers. One says they draw diagrams. Another says they are the person everyone escalates to when two functional leads disagree. A third genuinely does not know — they just know the SA has the final say on anything that touches more than one module.

This is not because the role is badly defined somewhere out there. It is because SAP consulting has four overlapping titles — functional consultant, technical architect, solution architect, enterprise architect — and every company draws the lines between them slightly differently. Job descriptions copy from each other. Titles get inflated for pay bands. Nobody sits down and writes out where one role’s accountability actually ends and the next one’s begins.

I am going to draw those lines properly in this post. Not the generic version from a recruiter’s template, but the version that matters on the day something breaks in production and someone has to explain, in a room full of people, why it happened on their watch.

🔗 Foundation for this post

This post assumes you already know the platform landscape a solution architect works across. If S/4HANA vs ECC — The Real Difference and SAP BTP — The Platform Explained are unfamiliar territory, start there — the rest of this post will make a lot more sense.

The one-sentence version

A solution architect owns the end-to-end shape of a solution — how the modules, integrations, custom builds and platform choices fit together to solve a business problem. Not any single piece of it.

They usually do not own FI configuration. They do not own ABAP code. They own the decision that FI, MM and a BTP extension need to talk to each other in a specific way — and they are accountable when that decision turns out to be wrong.

📌 Key takeaway

If you can point to one system or module and say “that’s mine”, you are probably not the solution architect on the project. The SA’s ownership is the connective tissue between systems, not any single system.

Solution Architect vs Functional Consultant

A functional consultant lives deep inside one line of business — finance, materials management, sales and distribution, whichever module they own. They configure that module to match how the business actually operates, write functional specifications when a developer is needed, and run workshops within their area.

A solution architect, in most SAP setups, does not configure anything themselves. Their job is deciding how each functional consultant’s module-level design fits with every other module and system around it.

A concrete example. The FI consultant designs the chart of accounts and the posting logic for a new subsidiary. The solution architect decides whether that subsidiary’s intercompany transactions run through native S/4HANA intercompany functionality, or through a middleware-based integration because the subsidiary runs a non-SAP system. That decision has an FI component, but its consequences reach well outside FI — into integration cost, data latency and who owns the reconciliation when something does not match.

Aspect	Functional Consultant	Solution Architect
Primary scope	One module or line of business (FI, MM, SD, HR, etc.)	The whole solution — how every module and system connects
Typical deliverable	Functional specification, configuration, process design	Architecture design, integration approach, technology decisions
Decision authority	How the process works inside their module	How modules and systems fit together across the project
Escalates to	Solution architect, when a decision crosses module boundaries	Enterprise architect or programme steering, on landscape-wide decisions

⚠️ Warning

A common mistake — organisations without a dedicated SA quietly hand the role to the most senior functional consultant. It works fine until the project has more than two or three modules talking to each other. After that, decisions start getting made without anyone owning the whole picture, and integration gaps surface in UAT, not before, when fixing them costs far more.

Solution Architect vs Technical Architect

The solution architect decides what gets built and why. The technical architect decides how it gets built well.

Take a clean core scenario: SAP’s guidance to keep custom code out of the core S/4HANA system and push extensions onto BTP instead. The solution architect decides that a specific business capability genuinely needs a custom side-by-side extension because standard S/4HANA does not cover it. The technical architect then decides whether that extension is built with SAP’s Cloud Application Programming Model or ABAP Cloud, how it scales, what the deployment pipeline looks like, and what performance and availability targets it needs to hit.

Aspect	Solution Architect	Technical Architect
Primary question	What should we build, and why does the business need it?	How do we build it so it performs, scales and stays supportable?
Owns	End-to-end solution design, integration approach, build vs buy decisions	Platform architecture, non-functional requirements, technical standards
Does not own	Deep platform internals, infrastructure configuration	Business process design, module-level configuration
Works closely with	Functional leads, business stakeholders, technical architect	Developers, Basis/platform team, solution architect

💡 Practical tip

On smaller projects, one person often does both jobs. A dedicated technical architect role is usually only justified on programmes with heavy custom development or a genuinely complex integration landscape — do not assume every project needs both as separate people.

Solution Architect vs Enterprise Architect

This is a different altitude entirely. The enterprise architect is not attached to one project. They own the standards, roadmap and technology choices across the organisation’s whole IT landscape — SAP and non-SAP together. The solution architect applies those standards to one specific project or programme.

Think of the enterprise architect as the one who decides the company will standardise on BTP for all new extensions and sets the integration patterns every project must follow. The solution architect is the one who takes that standard and designs a single project’s landscape inside it.

📝 Note

Smaller organisations often do not have a dedicated enterprise architect. In that case the solution architect ends up making both kinds of decisions by default, whether or not anyone formally acknowledges it. That is worth naming out loud, because it changes who genuinely needs to be in the room for a big architecture decision.

Where accountability actually sits

This is the part job descriptions never touch. When something goes wrong — an integration breaks between two systems, month-end close fails because of a data flow gap, a Fiori app cannot retrieve data because nobody scoped an authorisation object — who is actually accountable?

If the failure sits inside one module’s configuration, that is the functional consultant’s design. But the solution architect is accountable for not catching the cross-module implication during design review. If it is a platform or performance issue, the technical architect owns the fix, but the SA is accountable for not scoping the non-functional requirement clearly enough upfront. If the entire technology choice was wrong for the requirement, that is an SA and EA accountability question together.

📌 Key takeaway

The solution architect is rarely the person who caused the specific bug. They are accountable for the fact that nobody upstream of the bug asked the right question before build started. That is a harder thing to be accountable for than a line of configuration — and it is why this role is genuinely difficult to do well.

A day in the life

Most days: reviewing functional designs across modules for cross-module conflicts, sitting in integration design workshops, writing or reviewing architecture decision records, and negotiating between competing priorities — finance wants strict data validation, sales wants speed at order capture, and someone has to find the trade-off. A fair amount of time also goes into presenting technical trade-offs to a steering committee that does not want the technical detail, just the risk and the recommendation.

What it usually is not: hands-on configuration most days, hands-on ABAP coding, or running end-user training. Those are real jobs on the project. They are just not this one.

✅ Best practice

Block dedicated time for cross-module design review before any build sprint starts. A conflict caught in review costs a conversation. The same conflict caught in UAT costs a rework cycle and a difficult conversation with the steering committee.

When you don’t need a dedicated solution architect

A single-module implementation, a small landscape, no complex integration — a senior functional consultant with architecture awareness can cover this without a dedicated SA. Forcing a separate role onto a small project usually just adds a layer of hand-off nobody needed.

A dedicated solution architect earns their keep once a project is coordinating three or more modules, multiple systems, several vendors, or a clean core extension strategy on BTP. Below that threshold, the accountability gap this post describes is small enough that one experienced person can hold it in their head. Above it, nobody can, and that is exactly when the role stops being optional.

At a glance — the mental model

Concept	One-line summary
Solution Architect	Owns the end-to-end shape of a solution — how everything fits together, not any one module or system
Functional Consultant	Owns configuration and process design within one module or line of business
Technical Architect	Owns how the solution gets built well — platform, performance, non-functional requirements
Enterprise Architect	Owns standards and roadmap across the whole organisation’s IT landscape, not one project
Accountability	The SA is accountable for the questions nobody asked before build started, not usually the specific bug
When you need one	Once a project coordinates 3+ modules, multiple systems, or a clean core BTP extension strategy
Day-to-day work	Design review, integration workshops, architecture decision records, stakeholder negotiation

What to take away

The solution architect is not the smartest person on the project, and they are rarely the one who writes the code that breaks. What they own is harder to see and harder to be accountable for: the questions nobody else was positioned to ask before the build started.

That is the real difference between this role and the others. A functional consultant is accountable for their module being right. A technical architect is accountable for the platform being built well. A solution architect is accountable for the fact that all of it still needs to work together eighteen months later, long after the person who made the original trade-off has moved to the next project.

Next time someone asks what a solution architect does, do not reach for the job description. Ask who gets called when two systems that were each built correctly still do not talk to each other properly. That is the job.

🔗 Related reading — the rest of this series

SAP S/4HANA Migration: Greenfield, Brownfield, Bluefield — choosing an implementation path is itself a solution architecture decision, and this post covers how to make it.

RISE with SAP — What’s Actually in the Bundle — knowing what is contractually included changes what a solution architect can actually design around.

GROW with SAP vs RISE with SAP — Which Is Right for You — the commercial model you choose shapes which architecture decisions are even on the table.

SAP LeanIX — Enterprise Architecture Management — where enterprise architecture tooling intersects with the SA/EA boundary drawn in this post.

Published on rakeshnarayan.com — Articles

URL: https://rakeshnarayan.com/articles/what-does-an-sap-solution-architect-actually-do/