E02 - Understanding the Architecture

I intend to skip the history of versions and some technical notations so as not to add to my confusion ??.

SAP (System Analysis Program Development, you might find Systems, Applications and Products more often) is wide and it is easy to get lost and confused. Read a brief history and overview here.

The first focus for me, after the whole history and understanding of an ERP (Enterprise Resource Planning software), of course, was to create a simple structure of the system's architecture for myself. I found out that there can be a couple of ways to view the architecture.

1. From the software design point of view
2. From the functional setup point of view

Functional Setup

I'll speak to this first because that's what resonates more with being a functional expert in SAP.

The ERP serves as the Giant Robot of different parts, parts being different functions of a typical business; Sales, Procurement, Inventory Management, Logistics, Human Resource Management, Finance, etc.

SAP has a module (part) for the different business functions. I came across terms like SD (Sales and Distribution), PP (Production Planning), FI (Financial Accounting), CO (Controlling), MM (Materials Management), etc, each referring to the functional module as applicable. This Learning Journey by SAP proved helpful.

Finance is at the heart of a business, therefore its module(s) are designed to integrate with other modules. In the design of the Finance modules, there are key terms that describe the sub-modules within:

• FI module is subdivided into:

1. GL: General Ledger Accounting
2. AR: Accounts Receivable
3. AP: Accounts Payable
4. AA: Asset Accounting; and then you have

• CO: Controlling, which handles cost controlling and setups.

In the FI module, the GL reports the summary of what happens in other sub-modules. AR deals with Customers, AP with Vendors, and AA with Assets, all of which have what is called Master Data and Transaction Data. In fact, all modules have Master Data and Transaction Data (I'll have to talk about the difference between these later, though this thread can help).

Modules kind of hand over to each other after processing in their respective domains. For example, when a customer-related transaction is performed in the AR module, that transaction is registered into the customer records, then reported to the GL module under the certain ledger mapped to the customer transactions. I got a hint that each module would store transactions within them via document numbers. So one transaction in real life can have different document numbers, but a singular document number in every module that it has to pass through. This is one of the goodness of ERPs, you do not have to wait for updates from the other departments to continue processing, as long as the modules speak to each other, one move made by another department has chain effects in others, according to relevance.

You can refer to this LinkedIn Course, it was quite helpful.

Software Design

As an aspiring FICO consultant, understanding the underlying architecture of SAP is essential. I will mention the key components as much as I can and maybe to the limits of one who is more interested in FICO modules.

1. Client-Server Architecture: SAP follows a client-server architecture, where multiple clients (such as desktop applications, web browsers, or mobile devices) interact with a central server. The server, known as the SAP Application Server, manages the processing of business transactions and data storage. This distributed approach allows for scalability, security, and efficient utilization of resources.
2. Three-Tier Architecture: SAP architecture follows a three-tier model, the presentation tier, application tier, and database tier. Each tier has specific functions and responsibilities:

• Presentation Tier: This is the user interface layer, where users interact with SAP through various interfaces like SAP GUI (Graphical User Interface) or web-based portals. It provides access to SAP functionalities and allows users to input and retrieve data.
• Application Tier: Also known as the application server layer, it processes business logic and executes transactions. The application server hosts the SAP Business Application Programming Interface (BAPI) and implements the core SAP modules, including FICO. It handles the processing requests from the presentation tier and communicates with the database tier.
• Database Tier: This layer stores the vast amount of data generated and maintained within SAP. It uses a robust database management system, such as SAP HANA, to ensure data integrity, security, and efficient retrieval. The database tier stores both application data (transactional data) and configuration data (system settings and parameters).

3. SAP Instance and System Landscape: In SAP, an instance refers to a runtime environment of SAP applications running on an application server. Multiple instances can exist on a single server or across multiple servers to handle different tasks and workload distribution. An SAP system landscape is a collection of interconnected SAP instances, facilitating system administration, development, and testing activities.

Common types of SAP landscapes include:

a) Development System: Used for creating, modifying, and testing SAP applications and configurations.

b) Quality Assurance (QA) System: A replica of the production system, used for rigorous testing and quality control before deploying changes to the live environment.

c) Production System: The live system where actual business operations and transactions occur.

Phew! If I didn't jot it here, I personally wouldn't believe I can cough out this much about Architecture! See you in the next episode!