S/4HANA Architecture and Landscape Interview Questions for SAP

SAP HANA is SAP's in-memory, column-oriented relational database. It keeps data mainly in RAM and stores it by column, which makes aggregation and analytics very fast and allows one system to handle both transactions and reporting (OLTP and OLAP). It also offers compression, calculation views, text search, spatial and predictive functions. S/4HANA runs only on HANA, which allowed SAP to remove aggregate tables and simplify the data model.

A row store keeps all fields of a record together, which suits reading or writing whole records. A column store keeps each column's values together, which compresses well and makes scanning, filtering and aggregating a few columns across millions of rows very fast. Most S/4HANA application tables are column tables. Row tables are used only for some small, frequently updated technical tables.

An SAP system has a presentation layer (SAP GUI, browser with Fiori), an application layer (one or more ABAP application servers running work processes that execute business logic), and a database layer (SAP HANA in S/4HANA). Users connect to the application server, which reads and writes the database. This separation lets companies scale by adding application servers and keeps the database central.

A landscape is the set of systems used to develop, test and run SAP. A typical three-system landscape has Development (DEV) for configuration and code, Quality (QAS) for testing, and Production (PRD) for live business. Changes move from DEV to QAS to PRD through transports. Larger landscapes add sandbox, pre-production, training and separate systems such as SAP BW or SAP Gateway.

A client is an independent business unit inside one SAP system, identified by a three-digit number such as 100 or 200. Each client has its own master data, transaction data and users, while repository objects such as programs and tables are shared across all clients. Configuration can be client-specific or cross-client. A development system often has a configuration client, a unit test client and a sandbox client.

A transport request is a container that records changes made in development, such as configuration or ABAP objects, so they can be moved to quality and production in a controlled way. Workbench requests carry repository objects that are cross-client, and customizing requests carry client-specific configuration. Requests are released in DEV and imported by Basis or a tool such as SAP Cloud ALM or ChaRM. Transaction SE09 or SE10 manages them.

In SAP GUI, go to System then Status, which shows the client, user, transaction, program and database, and the component information button shows software components with release and support package levels, such as S4CORE. In the Fiori launchpad, the About option in the user menu shows the frontend version. Transaction SPAM also lists installed support packages. Knowing the release helps when reading SAP Notes.

The Universal Journal is table ACDOCA, which stores all actual line items from Finance, Controlling, Asset Accounting and Material Ledger in one place. In ECC these were spread across many tables such as BSEG, COEP, FAGLFLEXA and ANEP with totals tables. With one table, FI and CO are reconciled by design, reporting reads line items directly, and month-end reconciliation work is greatly reduced.

Main simplifications are: no aggregate and index tables in many areas, the Universal Journal for finance, Business Partner as the single master for customers and vendors, a simplified inventory table MATDOC, a longer 40-character material number option, new credit management, output management based on BRF+, and Fiori as the main user experience. SAP lists all these changes in the Simplification List for each release.

Work processes are the operating system processes that execute user and system requests. Dialog processes handle interactive steps, update processes write database changes asynchronously (V1 and V2), background processes run batch jobs, enqueue manages locks, and spool handles printing. The dispatcher assigns requests to free work processes. Basis checks them in SM50 or SM66, and long-running dialog steps often point to performance problems.

SAP Gateway exposes SAP data and logic as OData services over HTTP. Fiori apps and external systems call these services to read and change business data. In S/4HANA, Gateway can run embedded in the same system or as a separate hub. Modern apps use OData V2 or V4 services generated from CDS views and the RAP framework, and services are activated in transaction /IWFND/MAINT_SERVICE.

The Simplification List documents every functional and technical change in an S/4HANA release, such as removed transactions, changed tables and mandatory replacements. The SAP Readiness Check is a tool that analyses an existing ECC system and reports which simplification items apply, custom code impact, add-on compatibility, data volume and sizing. Together they help a team estimate the effort and plan a conversion project.

SUM (Software Update Manager) is the Basis tool used to update SAP systems and to convert ECC to S/4HANA. DMO (Database Migration Option) is a SUM feature that combines the database migration to HANA and the software update in one run, so a customer on Oracle or DB2 can move to S/4HANA on HANA in a single downtime. Basis teams run test conversions several times before the production run.

The SAP S/4HANA Migration Cockpit (transaction LTMC in older releases, now the Migrate Your Data Fiori app) is the standard tool to load master and open item data in greenfield projects. It uses predefined migration objects such as customers, suppliers, materials, open AR and AP items and fixed assets, with staging tables or file templates. It validates data, maps values and posts through standard APIs, replacing older LSMW for most loads.

I check the import log in STMS to confirm the request was imported without errors (return code 0 or 4). Then I confirm the change was saved in the right request and client, and whether it was client-specific customizing that needs a client copy or import into the specific QAS client. I also check for missing dependent transports, such as a new field or table that the configuration relies on, and object locks in another request.

I check what runs at that time: background jobs in SM37, active work processes in SM50 or SM66, and the workload monitor ST03N for response time breakdown between database, CPU and wait time. If heavy batch jobs overlap with peak dialog use, I reschedule them. If one report dominates, I trace it with ST12 or SQL trace ST05. I also check HANA memory and expensive statements with the DBA Cockpit or HANA cockpit.

For a repository object, open it in SE80 or SE11 and use Utilities then Versions to see version history with request numbers, or search the object in SE03 'Search for Objects in Requests'. For customizing, open the table or view in SM30, use Utilities then Change Logs if logging is active, or search the table key in SE03. Transport history in STMS shows when requests were imported into each system.

In SE09 or SE10, check the objects and documentation in the task and request, run consistency and ATC checks if required, release the task, then release the request. Basis or the change management tool imports it into quality following the transport route. After testing and approval, it is imported into production in the agreed window. I record the request number against the ticket or change document for traceability.

Open SM37, enter the job name, user and date range, and select Cancelled status. Select the job and open the job log, which shows messages and the point of failure. The spool list may show partial output. I then check the program variant, authorizations of the step user, locks, and short dumps in ST22 at that time. After fixing, the job can be rescheduled or repeated with the same variant.

Situation: a pricing configuration transport went to production without a dependent condition table. Task: restore order processing quickly. Action: I identified the missing object from the import log, raised an emergency change with approval, moved the dependent request, and verified with test orders. Result: orders were working within an hour. I then introduced a transport dependency checklist and peer review before production moves, and we had no repeat issues.

Because data is in memory and column-stored with high compression, HANA can aggregate millions of line items on the fly. So S/4HANA no longer needs precalculated totals tables or a separate data warehouse for operational reporting. CDS views define analytical models directly on transaction tables, and embedded analytics apps read them in real time. This removes data latency and duplicated storage, although enterprise-wide historical reporting may still use SAP Datasphere or BW.

When SAP removed tables such as BSIS, BSAS, BSID or the old MM stock tables, many custom programs still read them. S/4HANA provides compatibility views (often CDS based) with the old table names, which calculate the data from new tables like ACDOCA or MATDOC. Old SELECT statements keep working, but write access is not possible and performance can suffer, so custom code should be adapted to the new data model over time.

First I measure usage with ABAP Call Monitor (SCMON) or usage procedure logging to find dead code, which is often 40 to 60 percent and can be retired. Then I run the ABAP Test Cockpit with S/4HANA readiness checks to find code affected by simplifications. Remaining objects are fixed, replaced by standard functions, or redesigned as clean extensions. The custom code migration app helps track progress, and the plan is part of the conversion timeline.

I discuss downtime-optimized approaches in SUM such as downtime-optimized DMO and near-zero downtime technology, where most migration and data conversion run while the system is still live and only delta changes are processed during the final window. I also plan archiving to reduce data volume, several mock conversions to measure timing, a tested reconciliation of key financial and stock figures, and a rollback plan. The final choice balances cost against allowed downtime.

I would create a golden configuration client (for example 100) where all customizing is done and recorded in transports, a unit test client (for example 200) refreshed by client copy or transports for testing with data, and a sandbox client for experiments that never transports. Development of repository objects is cross-client. I would lock automatic recording rules in SCC4, define who can open clients, and document refresh schedules.

Situation: a conversion with four mock runs and many teams. Task: keep business and IT aligned. Action: I set a weekly steering update with simple status, risks and decisions needed, and daily stand-ups during mocks. I shared measured downtime and reconciliation results openly, including bad news early. Result: leadership approved an extra mock when timings were tight, and the final conversion finished within the planned weekend window.