SAP dưới góc nhìn kỹ thuật: Kiến trúc hệ thống ERP tích hợp và cách nó vận hành ở quy mô doanh nghiệp
SAP giải quyết bài toán gì ở level hệ thống?
Nếu bỏ toàn bộ lớp “ERP marketing”, SAP thực chất giải quyết một bài toán rất cụ thể:
Làm sao để nhiều domain (finance, sales, inventory, HR…) cùng thao tác trên một state mà không bị lệch dữ liệu
Trong system design hiện đại, đây chính là bài toán:
- Distributed data consistency
- Cross-domain transaction
- Single source of truth
Cách phổ biến hiện nay:
- Microservices + eventual consistency
- Event bus + message queue
- Saga pattern
Cách SAP làm:
- Centralized data model
- Synchronous transaction
- Strong consistency mặc định
Đây là khác biệt cốt lõi.
SAP hoạt động như một “transaction engine” chứ không phải app
Trong SAP, mọi thứ xoay quanh transaction.
Ví dụ một flow: Create Sales Order
Ở level system, nó không phải 1 action đơn giản, mà là:
- Insert vào bảng sales (SD)
- Update tồn kho (MM)
- Ghi nhận accounting entry (FI)
- Trigger workflow khác nếu cần
Tất cả nằm trong một LUW (Logical Unit of Work)
Tức là:
- Either commit tất cả
- Hoặc rollback toàn bộ
Không có chuyện:
- Sales thành công nhưng accounting fail
- Inventory chưa sync
=> Đây là ACID xuyên domain, thứ mà microservices rất khó làm.
Kiến trúc: Domain modular nhưng data không bị tách
SAP chia hệ thống thành các module:
- FI (Finance)
- MM (Material)
- SD (Sales)
- PP (Production)
Nhưng quan trọng:
- Không có database riêng cho từng module
- Không có service boundary rõ như microservices
Thay vào đó:
- Tất cả share chung một schema lớn
- Quan hệ table chồng chéo mạnh
=> Đây là shared database architecture
Ưu điểm:
- Không cần sync
- Không có eventual consistency
Nhược điểm:
- Coupling cực cao
- Scale theo kiểu vertical là chính
SAP HANA thay đổi execution model như thế nào?
SAP HANA không chỉ là database, mà thay đổi luôn cách code chạy.
Trước HANA:
- App server xử lý logic
- DB chỉ lưu trữ
- Batch job để aggregate Sau HANA:
- Logic được đẩy xuống DB
- Query chạy trực tiếp trên RAM
- Aggregation realtime
Ví dụ:
Thay vì:
SELECT data -> load lên app -> xử lý -> trả về
Chuyển thành:
DB tự xử lý logic -> trả về kết quả cuối
=> Gọi là code push-down
Điều này khiến:
- SQL trở thành nơi xử lý chính
- App layer mỏng đi
S/4HANA: Loại bỏ data duplication để giảm complexity
SAP S/4HANA giải quyết vấn đề lớn của SAP cũ: Data redundancy
Trước đây:
- Có nhiều bảng aggregate
- Có bảng tổng hợp riêng cho reporting
Sau S/4HANA:
- Giữ 1 bảng chính
- Query trực tiếp
Điều này dẫn tới:
- Không cần ETL
- Không cần sync BI
- Report realtime
So sánh nhanh với microservices
| Tiêu chí | SAP | Microservices |
|---|---|---|
| Data | Centralized | Distributed |
| Consistency | Strong (ACID) | Eventual |
| Transaction | Cross-module | Saga |
| Coupling | High | Low |
| Scaling | Vertical | Horizontal |
| Debug | Khó (vì lớn) | Khó (vì phân tán) |
Điểm thú vị:
- SAP chọn consistency → chấp nhận coupling
- Microservices chọn scale → chấp nhận inconsistency
Vì sao SAP vẫn sống khỏe dù “không modern”?
Lý do không nằm ở công nghệ, mà ở bài toán:
SAP tối ưu cho:
- Enterprise lớn
- Quy trình phức tạp
- Sai lệch dữ liệu = rủi ro lớn
Trong các hệ này:
- Consistency quan trọng hơn scale
- Correctness quan trọng hơn speed
=> Kiến trúc SAP phù hợp hơn microservices trong nhiều case
Những điểm dev sẽ “vỡ đầu” khi làm SAP
8.1. Data model cực lớn
- Hàng nghìn table
- Quan hệ phức tạp
- Không có document rõ như REST API
8.2. ABAP không giống ecosystem phổ biến
- Không phải OOP thuần
- Syntax riêng
- Debug kiểu riêng
8.3. Không có boundary rõ
Trong microservices: Service A không biết DB service B
Trong SAP: Module A có thể query thẳng data module B
=> Debug khó hơn nhiều
8.4. Custom = technical debt
- Custom nhiều → upgrade khó
- Nhưng không custom → business không fit
Kết luận
Nếu nhìn SAP như một công cụ, sẽ rất khó hiểu vì sao nó lại phức tạp và tốn kém đến vậy. Nhưng khi nhìn nó như một “hệ điều hành cho doanh nghiệp”, mọi thứ trở nên hợp lý hơn.
SAP được thiết kế để giải quyết bài toán mà nhiều hệ thống khác gặp phải: làm sao để toàn bộ dữ liệu và quy trình trong một tổ chức lớn có thể vận hành thống nhất, không bị rời rạc.
Đó cũng chính là lý do SAP không phù hợp với mọi doanh nghiệp, nhưng lại trở thành lựa chọn gần như bắt buộc khi hệ thống đạt đến một mức độ phức tạp nhất định.
=> Tham khảo: https://bizflycloud.vn/tin-tuc/sap-la-gi-20181113115730288.htm
All rights reserved
