What does an SAP solution architect do?

An SAP solution architect owns the design of one SAP solution end to end: which processes run in standard, what gets extended, where the data lives, and how the parts integrate into something a business can actually run. The role is accountable for the coherence of that design across every stream of a programme, rather than for depth in a single area.

Where a functional consultant goes deep in one business area, the architect holds the whole picture — and answers, long after the workshops, why the solution looks the way it does.

What an architect decides

The decisions arrive as questions from delivery teams, and each answer closes a door for everyone downstream.

Standard, configuration or extension: Whether a requirement is met by the process as delivered, by configuration, or by a build — and when it is a build, whether it belongs in the core or as a side-by-side extension on BTP. Clean-core discipline is mostly this one call, repeated.
Where the data lives: Which system is the master for a given object, what is replicated, and what is only read (master data ownership settled late is expensive rework).
Integration topology: Which interfaces exist at all, whether each is synchronous, event-driven or batch, and what happens when one fails — designed with the integration people, owned by the architect.
Non-functional shape: Volumes, peak load, availability windows, archiving, and the authorization concept the design implies.
Sequence of delivery: What has to be live before what — the reason design and the plan argue early rather than during cutover.

The artefacts that carry the decisions

An architect's output is documents other people build from: the solution design, a decision log naming the alternatives rejected and why, a target landscape picture, an interface inventory, and the review gates where specs, configuration and code get read before they ship.

Is a solution architect the same as an enterprise architect?

No — the scope differs. An enterprise architect works above single programmes, on the application portfolio and roadmap of a whole company; a solution architect is accountable for one solution being designed and delivered. Between them sit narrower specialisms: integration architects, and the technical architect side, which usually grows out of Basis. The project manager is a different axis again: plan, budget and people, against the architect's design.

Where the design goes wrong

Corridor decisions. Agreed in a hallway, never written down; the same debate reopens with no record of the trade-off.
Designs nobody can build. Coherent on a slide, unconfigurable in practice, or unsupportable once it reaches AMS.
Local optimization. Each stream optimizes its own area until a sales design quietly breaks revenue recognition — the cross-area seams are what an architect is there to watch (which SAP areas sit next to each other).
Happy-path interfaces. Designed for the message that arrives correctly, so the first failed one becomes a production incident.
Drift. An architecture eroded by changes approved without it, until the live system and its documents describe different solutions.

How people end up with the title

Most solution architects come up through delivery — functional or technical — taking the cross-stream questions nobody else owns until answering them is the whole job; the other common way in is the customer side, out of internal IT or enterprise architecture. Breadth across more than one SAP area, real integration awareness and the patience to document are the ingredients; the title follows the behaviour, usually after a programme where you were already doing the job under another label.

Interviews test it through a design you owned, not vocabulary: what you chose, what you rejected, and what it cost when an assumption turned out to be wrong (what interviews test). The move on is wider programme scope, then enterprise architecture, further up the role ladder.