Chủ Nhật, 16 tháng 8, 2026

[Infographic] Quy hoạch hệ thống theo TMForum, eTOM, TAM, SID, ODA

Trong bài viết này chúng ta sẽ tìm hiểu về chuẩn xây dựng hạ tầng kỹ thuật theo TM Forum, trong đó tập trung vào eTOM, SID, Functional Framework, ODA Components/Canvas và Open APIs. Cần chú ý rằng là:

Không nên chọn giữa eTOM, TAM, SID và ODA. Chúng nằm ở các lớp kiến trúc khác nhau và bổ sung cho nhau.
Với quy hoạch hệ thống của các doanh nghiệp Viễn thông, tôi khuyến nghị ODA làm kiến trúc đích, eTOM cho nghiệp vụ, Functional Framework thay TAM cho kiến trúc chức năng mới, SID làm ngôn ngữ dữ liệu, TMF Open API/Event cho tích hợp, và ODA Canvas/Cloud Native cho runtime.

Đặc biệt, việc gọi mô hình hiện tại là “7 lớp TM Forum” cần chỉnh lại về thuật ngữ.

1. Trước hết: TM Forum không phải là một “mô hình kiến trúc”

TM Forum là liên minh ngành viễn thông toàn cầu xây dựng các framework, standard, API, data model và kiến trúc tham chiếu.

Trong lịch sử chúng ta thường gặp:


                     TM FORUM
                         │
          ┌──────────────┼───────────────┐
          │              │               │
        eTOM            SID             TAM
     Process Model   Data Model    Application Map
          │              │               │
          └──────────────┼───────────────┘
                       Frameworx
                           │
                           ↓
                Open Digital Architecture
                         ODA
                           │
        ┌──────────────────┼─────────────────┐
        │                  │                 │
 Functional Framework   Components       Open APIs
        │                  │                 │
        └──────────────────┼─────────────────┘
                           ↓
                      ODA Canvas

TM Forum hiện đã có eTOM v26.0, SID v26.0, Functional Framework v26.0 và ODA Components Map v26.0, phát hành năm 2026.

2. Phân biệt 5 khái niệm bằng một câu hỏi

Khái niệm	Câu hỏi nó trả lời	Ví dụ Telco (Mobi,Viettel,Vina)
TM Forum	Chuẩn/ngôn ngữ chung của ngành viễn thông là gì?	eTOM, SID, ODA, Open API
eTOM	Doanh nghiệp làm nghiệp vụ gì?	Order-to-Activate, Billing, Assurance, Customer Care
TAM	Cần những nhóm ứng dụng nào?	CRM, Product Mgmt, Order Mgmt, Billing...
SID	Các hệ thống đang nói về dữ liệu gì?	Party, Customer, Product, Service, Resource
ODA	Các capability đó phải được xây thành component, kết nối và chạy thế nào?	Component + Open API + cloud-native + Canvas

Đây là chìa khóa để không trộn các khái niệm.

3. eTOM: mô hình nghiệp vụ, không phải kiến trúc hệ thống

eTOM = Enhanced Telecom Operations Map, tên hiện tại là Business Process Framework.

TM Forum định nghĩa nó là hệ thống phân loại phân cấp các business processes cần thiết để vận hành một service provider.

Ví dụ một hành trình:


Khách hàng mua gói 5G
        │
        ↓
Order Capture
        │
        ↓
Order Validation
        │
        ↓
Service Order
        │
        ↓
Service Provisioning
        │
        ↓
Resource Activation
        │
        ↓
Billing / Charging

eTOM giúp trả lời:

Ai làm gì?
Process nào?
Input/output là gì?
Đơn vị nào chịu trách nhiệm?

Nhưng eTOM không nói rằng:


Order Management dùng Oracle hay PostgreSQL?
Chạy VM hay Kubernetes?
Có bao nhiêu microservice?
REST hay Kafka?

Do đó:

eTOM = Business Process Architecture.

4. SID: mô hình thông tin chứ không phải một database

SID = Shared Information/Data Model, hiện gọi là Information Framework.

TM Forum mô tả SID là information/data reference model và common vocabulary độc lập với platform, language và protocol; đồng thời là nền tảng cho function, application, component và API development.

Ví dụ:


PARTY
 │
 ├── Individual
 └── Organization
       │
       ↓
    CUSTOMER
       │
       ↓
   AGREEMENT
       │
       ↓
    PRODUCT
       │
       ↓
    SERVICE
       │
       ↓
   RESOURCE

Điểm này đặc biệt quan trọng với hiện trạng của các doanh nghiệp Telco.

Hiện có thể tồn tại:


TC&QLKH.Customer
mSale.Customer
MyMobiFone.Customer
BigData.Customer
CRM.Customer
ERP.Customer

và mỗi nơi hiểu Customer hơi khác nhau.

SID giúp thiết lập:


             ENTERPRISE SEMANTIC MODEL

Party ─ Customer ─ Account ─ Product
                       │
                       ↓
                     Service
                       │
                       ↓
                     Resource

Nhưng không có nghĩa:

“Phải tạo một SID database rồi tất cả hệ thống truy cập.”

Không nên làm như vậy.

SID chủ yếu giúp chuẩn hóa:

semantic model;
entity;
relationship;
API contract;
event contract;
canonical terminology.

5. TAM: rất tốt cho As-Is, nhưng không còn nên là kiến trúc đích

TAM = Telecom Application Map / Application Framework.

Nó phân loại application functionality của telco. TM Forum vẫn công bố Application Framework/TAM và mô tả nó như framework dùng để phân loại, rationalize application portfolio.

Ví dụ TAM-style:


CUSTOMER
├─ Customer Management
├─ Customer Order Management
├─ Customer Problem Management
└─ Customer Interaction Management

PRODUCT
├─ Product Catalog
├─ Product Lifecycle
└─ Product Performance

SERVICE
├─ Service Management
├─ Service Inventory
└─ Service Order

RESOURCE
├─ Resource Inventory
├─ Resource Order
└─ Resource Management

Đây chính là lý do TAM rất thích hợp để rà soát:


106 hệ thống
    ↓
Hệ thống nào trùng chức năng?
    ↓
Hệ thống nào thiếu?
    ↓
Keep / Merge / Replace / Retire

Và điều này phù hợp với bài toán gom gộp hiện tại: ví dụ bạn đang có 106 → 77 → 52 hệ thống, trong đó riêng CCBS (Quản lý khách hàng tập trung) mới dự kiến gom nhiều hệ thống hiện hữu.

Nhưng có một điểm rất quan trọng:

Giảm 106 xuống 52 hệ thống chưa có nghĩa là đã chuyển sang ODA.

52 monolith lớn vẫn có thể tệ hơn 106 application nhỏ.

6. Functional Framework là bước tiến hóa hiện đại của TAM

Khi “Thay thế TAM bởi Functional Framework và ODA Component.”, TM Forum hiện cũng mô tả Functional Framework là sự tiến hóa từ Application Framework, bằng cách loại bỏ application context và chia nhỏ các hoạt động thành các function cơ bản.

Do đó tôi đề xuất:


TAM
 ↓
Dùng chủ yếu cho
AS-IS APPLICATION MAPPING

Functional Framework
 ↓
Dùng cho
TARGET FUNCTIONAL ARCHITECTURE

ODA Components
 ↓
Dùng cho
TARGET APPLICATION ARCHITECTURE

Không cần “vứt TAM”.

TAM là cầu nối migrate legacy → ODA.

7. ODA là kiến trúc đích

ODA = Open Digital Architecture.

TM Forum hiện định nghĩa ODA là blueprint xây dựng các hệ thống telecom/enterprise IT linh hoạt, cloud-based; các thành phần được tổ chức modular và cung cấp business services qua standardized Open APIs dựa trên common data model.

Trung tâm ODA là:


           ODA COMPONENT
                 │
        ┌────────┴────────┐
        │                 │
   Business API        Events
        │                 │
        └────────┬────────┘
                 │
           SID semantics
                 │
          Cloud Native
                 │
          ODA Canvas

TM Forum mô tả ODA Components là các reusable, plug-and-play software building blocks cung cấp chức năng qua Open APIs.

ODA Canvas là runtime/deployment environment dành cho các component đó.

8. Như vậy toàn bộ TM Forum hiện đại nên được hiểu như sau

Đây là mô hình tôi đề xuất sử dụng thống nhất từ nay:


                  BUSINESS STRATEGY
                         │
                         ↓
            VALUE STREAM / CAPABILITY
                         │
                         ↓
                ┌────────────────┐
                │      eTOM      │
                │ Business Process│
                └───────┬────────┘
                        │
                        ↓
           ┌────────────────────────┐
           │  FUNCTIONAL FRAMEWORK  │
           │ System Functions       │
           └───────────┬────────────┘
                       │
             ┌─────────┴─────────┐
             ↓                   ↓
       ┌───────────┐       ┌───────────┐
       │    SID    │       │    ODA    │
       │Information│←────→ │Components │
       └───────────┘       └─────┬─────┘
                                 │
                         TMF Open APIs
                           + Events
                                 │
                                 ↓
                          ODA CANVAS
                                 │
                                 ↓
                  Kubernetes / OpenShift
                   Private/Public Cloud
                                 │
                                 ↓
                  Compute/Storage/Network

TAM đứng bên cạnh mô hình trên để mapping các application legacy.

9. Phản biện quy hoạch Telco hiện tại

Tôi đánh giá quy hoạch hiện nay đúng hướng khoảng 70–75%, nhưng đang ở giai đoạn “TM Forum-aligned” chứ chưa phải ODA thực sự.

Điểm tốt thứ nhất: đã nhận ra đúng vấn đề legacy

Quy hoạch trước kia đã nhận diện khá chính xác:

nhiều hệ thống độc lập;
chức năng chồng chéo;
tốn nguồn lực vận hành;
dữ liệu không nhất quán;
nhiều hệ thống chưa có DR.

Đây chính xác là nhóm vấn đề ODA muốn xử lý.

10. Điểm tốt thứ hai: đã đi đúng sang Cloud Native

Bản hiệu chỉnh mới đã nêu:

Container;
Microservices;
DevOps;
CI/CD;
Open API;
automation;
security.

Đây là nền tảng kỹ thuật rất phù hợp ODA.

Nhưng:

Cloud Native ≠ ODA.

Một monolith chạy Docker/Kubernetes vẫn là monolith.

11. Điểm tốt thứ ba: đã hình thành đúng các capability lớn

Tài liệu đã định hướng:


Channel
Customer
Product
Order
Billing
Charging
Payment
Partner
Provisioning
Data
OSS
Enterprise

và các hệ thống mục tiêu như:


CBS
OCS
SmartSales Pro
Portal/MyMobi
OmniChannel
Master Product Catalog
OpenGW
API Gateway
Mediation
PaymentGW
...

Đây là nền tốt để map sang ODA.

12. Nhưng tôi không khuyến nghị gọi mô hình hiện tại là “7 lớp TM Forum”

Nếu đang gọi:

“Kiến trúc theo mô hình TM-Forum (7 lớp chức năng)”

với Channel / Analytics / BSS / OSS / Enterprise / Network / Integration...

Tôi đề nghị đổi tên thành:

“Telco Functional Landscape – TM Forum aligned”

hoặc:

“Kiến trúc chức năng CNTT Telco tham chiếu TM Forum.”

Bởi vì TM Forum không có một normative standard gọi chính thức là:

“Kiến trúc TM Forum 7 lớp”

theo đúng cấu trúc đó.

Đây là mô hình nội bộ/tư vấn rất hữu ích, nhưng không nên gắn nhãn thành chuẩn TM Forum.

13. Tương tự, mô hình 3 lớp hiện nay phải giữ nhưng đặt đúng vị trí

Quy hoạch hiện tại có:


LỚP ỨNG DỤNG
      ↓
LỚP TÀI NGUYÊN HỆ THỐNG
      ↓
LỚP HẠ TẦNG

với Cloud, Storage, Network, DC...

Hoặc:


SaaS
PaaS
IaaS

Cái này hoàn toàn có giá trị.

Nhưng nó là:

Technology/Deployment Architecture

chứ không phải:

TM Forum Business/Functional Architecture.

Hai bản đồ phải tồn tại song song.

14. Khoảng trống lớn nhất hiện nay: “gom hệ thống” đang được coi gần như đồng nghĩa “hiện đại hóa”

Đây là điểm tôi phản biện mạnh nhất.

Ví dụ:


             16 hệ thống
                  │
                  ↓
                QLKH

Về vận hành:

tốt — giảm server, DB, interface, nguồn lực.

Nhưng về kiến trúc:


16 monolith nhỏ
        ↓
  1 SUPER MONOLITH

có thể tạo ra một single point of complexity cực lớn.

Do đó mục tiêu không nên chỉ là:

106 → 77 → 52.

Mà phải thêm:


Application count ↓
Coupling ↓↓↓
DB dependency ↓↓↓
Point-to-point ↓↓↓

Reusable components ↑
Open APIs ↑
Independent deployment ↑
Observability ↑
Resilience ↑

15. QLKH/CBS nên được nhìn như tập ODA Component, không phải một application khổng lồ

Ví dụ thay vì:


                  CBS
                   │
     ┌─────────────┼──────────────┐
     │             │              │
 Customer       Product         Billing
 Order          Payment         Partner
 ...

tôi đề xuất logic target:


                DIGITAL BSS

          Party Management
                  │
          Customer Management
                  │
             Agreement
                  │
                  ↓
      ┌──── Product Catalog ────┐
      │                         │
      ↓                         ↓
Product Order              Customer Care
      │
      ↓
Service Order
      │
      ↓
Service Inventory
      │
      ↓
Resource Order
      │
      ↓
Resource Inventory


       Billing Account
             │
       Customer Bill
             │
          Payment


OCS / Charging
      │
      └──── API/Event ─────→ các component

TM Forum hiện có ODA Components riêng cho những capability như Service Order Management và Resource Order Management.

16. Master Product Catalog nên là một trong các dự án đầu tiên

Quy hoạch hiện tại đã hướng tới Master Product Catalog, đây là lựa chọn đúng.

Tôi sẽ đưa nó lên mức P0/P1.

Target:


                 MASTER PRODUCT CATALOG
                         │
       ┌─────────────────┼──────────────────┐
       ↓                 ↓                  ↓
      OCS               CBS             SmartSales
       │                 │                  │
       ├────────────── API/Event ───────────┤
       │                                    │
     MyMobi                          OmniChannel
       │
       ↓
Partner / Marketplace

Không nên để:


OCS Catalog
QLKH Catalog
mSale Catalog
MyMB Catalog
VAS Catalog
Partner Catalog

tiếp tục tồn tại độc lập.

17. SID nên giải bài toán Customer360/MDM đang tồn tại

Hiện tại đã nhận ra:

Customer360;
Big Data;
dữ liệu tập trung;
MDM;
Single Source of Truth;
làm sạch và chia sẻ dữ liệu.

Hướng này đúng.

Nhưng tôi đề xuất thêm SID Semantic Layer:


                    SID SEMANTIC MODEL

 Party
   │
Customer
   │
Account
   │
Product ─── Product Offering
   │
Service
   │
Resource
   │
Usage
   │
Bill / Payment

Sau đó mỗi hệ thống phải khai báo:


System Data Model
       ↕ mapping
Enterprise SID Model
       ↕
Open API / Event

18. OpenGW không nên trở thành “ESB phiên bản mới”

Quy hoạch hiện tại đang thay ESB bằng OpenGW.

Nhưng target không nên là:


App
 ↓
OpenGW
 ↓
App

cho mọi giao tiếp.

Nên phân ra:


                    INTEGRATION

North-South
Internet / Partner
        │
     API GW
        │
        ↓

Internal synchronous API
        │
 OpenGW / API Management
        │

East-West microservices
        │
 Service Mesh
        │

Asynchronous Integration
        │
 Kafka / Event Streaming
        │

Bulk Data
        │
 Data Pipeline / CDC

Và nguyên tắc rất quan trọng:


New integration:

DB Link       ✗
Shared Table  ✗
Direct DB     ✗
FTP           △

API           ✓
Event         ✓
CDC           ✓

19. Mô hình kiến trúc Telco 2030 tôi đề xuất

Không dùng một “7-layer diagram” để giải quyết tất cả.

Tôi đề xuất 7 architecture views:


1. BUSINESS ARCHITECTURE
   Strategy
   Capability
   Value Stream
   eTOM

                 ↓

2. FUNCTIONAL ARCHITECTURE
   TM Forum Functional Framework

                 ↓

3. INFORMATION ARCHITECTURE
   SID
   MDM
   Data Governance
   Data Product

                 ↓

4. APPLICATION ARCHITECTURE
   ODA Components
   Legacy Applications

                 ↓

5. INTEGRATION ARCHITECTURE
   Open API
   Event
   API Gateway
   Service Mesh

                 ↓

6. TECHNOLOGY ARCHITECTURE
   Kubernetes/OpenShift
   PaaS
   Database
   Private/Public Cloud
   DC

                 ↓

7. CROSS-CUTTING
   Security
   Observability
   HA/DR
   DevSecOps
   AIOps

Đây mới là Enterprise Architecture hoàn chỉnh.

20. Và mapping sang các chuẩn TM Forum cực kỳ rõ


BUSINESS
────────────────────────────
Capability / Value Stream
          ↓
        eTOM


FUNCTION
────────────────────────────
Functional Framework


INFORMATION
────────────────────────────
SID


APPLICATION
────────────────────────────
ODA Components


INTEGRATION
────────────────────────────
TMF Open APIs
Events


RUNTIME
────────────────────────────
ODA Canvas
Cloud Native


INFRASTRUCTURE
────────────────────────────
Kubernetes
VM
Cloud
Compute
Storage
Network
DC

Đây là mô hình tôi khuyên đưa vào Quy hoạch CNTT giai đoạn đến 2030.

21. Plan triển khai cụ thể từ hiện tại đến 2030

Với thời điểm hiện tại là 2026, tôi không đề xuất “big bang ODA”. Nên triển khai theo Strangler Pattern.

Giai đoạn 1 — H2/2026: Chuẩn hóa kiến trúc

Mục tiêu chưa phải thay hệ thống.

Mục tiêu là tạo bộ luật kiến trúc.

Thực hiện:

thành lập Architecture Board / ODA CoE;
xây Enterprise Capability Map;
map eTOM L1-L3;
map toàn bộ hệ thống → Functional Framework;
map data → SID;
map ứng dụng → ODA Component;
lập API Catalog;
lập Data Catalog;
xác định system-of-record.

Sản phẩm bắt buộc:


SYSTEM → eTOM → FUNCTION → SID → ODA COMPONENT → API → DATA OWNER

22. Giai đoạn 2 — 2027: dựng ODA Foundation

Tôi ưu tiên 8 nền tảng:


API Management
Event Streaming
IAM/SSO
Service Mesh
CI/CD
Observability
Secrets Management
Container Platform

Song song xây:


SID Enterprise Model
MDM
Data Catalog
API Catalog
Event Catalog

Và ban hành nguyên tắc:

Không phát triển DB Link mới.

Đây sẽ là một KPI kiến trúc rất đáng giá.

23. Giai đoạn 3 — 2027–2028: bóc dần QLKH/CBS

Không viết lại toàn bộ.

Ưu tiên tách lần lượt:


1 Product Catalog
        ↓
2 Party / Customer
        ↓
3 Customer Account
        ↓
4 Product Order
        ↓
5 Payment
        ↓
6 Billing
        ↓
7 Partner

Mỗi lần tách:


Legacy
 │
 ├── API Adapter
 │
 └── Event
       ↓
New ODA Component

Sau đó traffic dịch chuyển dần.

24. Giai đoạn 4 — 2028–2029: Product → Service → Resource

Đây là phần rất quan trọng đối với 5G/FWA/IoT/MVNO.

Xây chuỗi:


Product Order
      ↓
Service Order
      ↓
Service Inventory
      ↓
Resource Order
      ↓
Resource Inventory
      ↓
Provisioning
      ↓
5G / FWA / IoT / FTTH / MVNO

Như vậy business không còn phải hiểu:


HLR
HSS
UDM
PCRF
PCF
OLT
ONT
...

BSS chỉ nhìn:

Product → Service.

OSS chịu trách nhiệm:

Service → Resource.

Đây mới là decoupling đúng.

25. Giai đoạn 5 — 2029–2030: ODA thực sự

Lúc này mục tiêu mới là:


Composable IT
API First
Event Driven
Cloud Native
Data Driven
AI Ready
Autonomous Operations

Các ODA Components được deploy trên runtime chuẩn hóa tương tự tư tưởng ODA Canvas. TM Forum xác định Canvas là môi trường runtime để tích hợp và triển khai ODA Components trên cloud.

Legacy lúc này:


Retain
Replace
Retire

chứ không migrate vô điều kiện.

26. KPI tôi đề xuất cho chương trình ODA

Đừng dùng KPI duy nhất:

“Còn bao nhiêu hệ thống?”

Nên dùng:

KPI 2030	Mục tiêu đề xuất
Critical business capability mapped TMF	100%
Hệ thống mới Cloud Native	>90%
Tích hợp mới dùng API/Event	100%
DB Link mới	0
API được catalog	100%
Critical APIs theo TMF Open API khi phù hợp	>80%
Master Data domain có owner	100%
Critical system có HA/DR	100%
Automated CI/CD	>90%
Observability end-to-end	>90%
Application có API lifecycle management	100%
Legacy interfaces loại bỏ	>80%

27. Thứ tự ưu tiên đầu tư mà tôi khuyến nghị

Từ hiện trạng thực tế, tôi sẽ không làm đồng thời tất cả.


P0
Architecture Governance
API/Event/Data Governance
        │
        ↓
P1
Master Product Catalog
Party / Customer Master
MDM / SID
        │
        ↓
P2
Order Management
Customer/Billing/Payment
        │
        ↓
P3
Service Order
Service Inventory
Resource Order
Resource Inventory
        │
        ↓
P4
Provisioning / Assurance
        │
        ↓
P5
AI / Closed-loop Automation
Autonomous Operations

28. Một thay đổi rất quan trọng trong tư duy quy hoạch

Quy hoạch cũ


Chúng ta cần những HỆ THỐNG nào?

Ví dụ:


CBS
QLKH
SmartSale
PayGW
OpenGW
...

Quy hoạch 2030 nên hỏi


BUSINESS CAPABILITY nào?
        ↓
PROCESS nào?
        ↓
FUNCTION nào?
        ↓
INFORMATION nào?
        ↓
ODA COMPONENT nào?
        ↓
API nào?
        ↓
TECHNOLOGY nào?

Đây là thay đổi từ:

System-centric architecture

sang:

Capability-driven + Component-based architecture.

29. Công thức tôi khuyên dùng chính thức

Nếu phải đưa vào Quy hoạch CNTT 2030 chỉ bằng một hình, tôi sẽ sử dụng:


                     TELCO STRATEGY
                           │
                           ▼
                  BUSINESS CAPABILITY
                           │
                           ▼
                         eTOM
                   Business Process
                           │
                           ▼
               FUNCTIONAL FRAMEWORK
                           │
          ┌────────────────┴────────────────┐
          ▼                                 ▼
         SID                         ODA COMPONENTS
    Information Model                      │
          │                                │
          └──────────────┬─────────────────┘
                         ▼
                  TMF OPEN APIs
                    + EVENTS
                         │
                         ▼
                     ODA CANVAS
                         │
                         ▼
            CLOUD-NATIVE PLATFORM
        Kubernetes / PaaS / DevSecOps
                         │
                         ▼
              PRIVATE / PUBLIC CLOUD
                         │
                         ▼
             DC / COMPUTE / STORAGE
                   / NETWORK

TAM nằm bên trái để mapping Legacy Applications → Functional Framework/ODA.

30. Kết luận

Nền tảng tốt: cloud hóa, gom gộp, OpenGW/API Gateway, Master Product Catalog, CBS, OCS, Big Data, Customer360, microservices và Cloud Native đều đang đúng hướng; tiếp tục theo hướng Cloud Native theo Containers + Microservices + DevOps + CI/CD + Open API.

Nhưng từ quy hoạch giai đoạn tới cần nâng một cấp:

Từ “Quy hoạch danh sách hệ thống” → “Enterprise Architecture theo TM Forum ODA”.

Và tôi đề xuất chuẩn hóa ngay cách gọi:


eTOM
= Business Process Architecture

Functional Framework
= Functional Architecture

SID
= Information Architecture

TAM
= Legacy/Application Portfolio Reference

ODA Components
= Target Application Architecture

TMF Open API + Event
= Integration Architecture

ODA Canvas + Cloud Native
= Runtime Architecture

IaaS/PaaS/DC/Cloud
= Technology Infrastructure

Đặc biệt, “7 lớp TM Forum” hiện đang sử dụng nên đổi tên thành “Telco Functional Architecture – TM Forum aligned”. Còn kiến trúc đích 2030 nên lấy ODA + Functional Framework + SID + eTOM + Open APIs làm trục chính. Đây cũng phù hợp với Telco đã xác định hướng tới ODA, Functional Framework và cloud-native.

Nếu thực hiện đúng hướng này, bài toán không còn là bao nhiêu hệ thống, mà là: mỗi business capability có owner rõ ràng, mỗi dữ liệu có source of truth, mỗi capability được hiện thực bằng component độc lập, giao tiếp chuẩn API/event, không phụ thuộc DB của nhau và có thể nâng cấp/thay thế từng component mà không kéo sập cả hệ sinh thái. Đó mới là trạng thái kiến trúc ODA thực sự.

=============================
TƯ VẤN: Click Here hoặc Hotline/Zalo 090.29.12.888
=============================
Website không chứa bất kỳ quảng cáo nào, mọi đóng góp để duy trì phát triển cho website (donation) xin vui lòng gửi về STK 90.2142.8888 - Ngân hàng Vietcombank Thăng Long - TRAN VAN BINH
=============================
Nếu bạn không muốn bị AI thay thế và tiết kiệm 3-5 NĂM trên con đường trở thành DBA chuyên nghiệp hay làm chủ Database thì hãy đăng ký ngay KHOÁ HỌC ORACLE DATABASE A-Z ENTERPRISE, được Coaching trực tiếp từ tôi với toàn bộ bí kíp thực chiến, thủ tục, quy trình của gần 20 năm kinh nghiệm (mà bạn sẽ KHÔNG THỂ tìm kiếm trên Internet/Google) từ đó giúp bạn dễ dàng quản trị mọi hệ thống Core tại Việt Nam và trên thế giới, đỗ OCP.
- CÁCH ĐĂNG KÝ: Gõ (.) hoặc để lại số điện thoại hoặc inbox https://m.me/tranvanbinh.vn hoặc Hotline/Zalo 090.29.12.888
- Chi tiết tham khảo:
https://bit.ly/oaz_w
=============================
2 khóa học online qua video giúp bạn nhanh chóng có những kiến thức nền tảng về Linux, Oracle, học mọi nơi, chỉ cần có Internet/4G:
- Oracle cơ bản: https://bit.ly/admin_1200
- Linux: https://bit.ly/linux_1200
=============================
KẾT NỐI VỚI CHUYÊN GIA TRẦN VĂN BÌNH:
📧 Mail: binhoracle@gmail.com
☎️ Mobile/Zalo: 0902912888
👨 Facebook: https://www.facebook.com/BinhOracleMaster
👨 Inbox Messenger: https://m.me/101036604657441 (profile)
👨 Fanpage: https://www.facebook.com/tranvanbinh.vn
👨 Inbox Fanpage: https://m.me/tranvanbinh.vn
👨👩 Group FB: https://www.facebook.com/groups/DBAVietNam
👨 Website: https://www.tranvanbinh.vn
👨 Blogger: https://tranvanbinhmaster.blogspot.com
🎬 Youtube: https://www.youtube.com/@binhguru
👨 Tiktok: https://www.tiktok.com/@binhguru
👨 Linkin: https://www.linkedin.com/in/binhoracle
👨 Twitter: https://twitter.com/binhguru
👨 Podcast: https://www.podbean.com/pu/pbblog-eskre-5f82d6
👨 Địa chỉ: Tòa nhà Sun Square - 21 Lê Đức Thọ - Phường Mỹ Đình 1 - Quận Nam Từ Liêm - TP.Hà Nội

=============================
cơ sở dữ liệu, cơ sở dữ liệu quốc gia, database, AI, trí tuệ nhân tạo, artificial intelligence, machine learning, deep learning, LLM, ChatGPT, DeepSeek, Grok, oracle tutorial, học oracle database, Tự học Oracle, Tài liệu Oracle 12c tiếng Việt, Hướng dẫn sử dụng Oracle Database, Oracle SQL cơ bản, Oracle SQL là gì, Khóa học Oracle Hà Nội, Học chứng chỉ Oracle ở đầu, Khóa học Oracle online,sql tutorial, khóa học pl/sql tutorial, học dba, học dba ở việt nam, khóa học dba, khóa học dba sql, tài liệu học dba oracle, Khóa học Oracle online, học oracle sql, học oracle ở đâu tphcm, học oracle bắt đầu từ đâu, học oracle ở hà nội, oracle database tutorial, oracle database 12c, oracle database là gì, oracle database 11g, oracle download, oracle database 19c/21c/23c/23ai, oracle dba tutorial, oracle tunning, sql tunning , oracle 12c, oracle multitenant, Container Databases (CDB), Pluggable Databases (PDB), oracle cloud, oracle security, oracle fga, audit_trail,oracle RAC, ASM, oracle dataguard, oracle goldengate, mview, oracle exadata, oracle oca, oracle ocp, oracle ocm , oracle weblogic, postgresql tutorial, mysql tutorial, mariadb tutorial, ms sql server tutorial, nosql, mongodb tutorial, oci, cloud, middleware tutorial, docker, k8s, micro service, hoc solaris tutorial, hoc linux tutorial, hoc aix tutorial, unix tutorial, securecrt, xshell, mobaxterm, putty

Chủ Nhật, 16 tháng 8, 2026

[Infographic] Quy hoạch hệ thống theo TMForum, eTOM, TAM, SID, ODA

1. Trước hết: TM Forum không phải là một “mô hình kiến trúc”

2. Phân biệt 5 khái niệm bằng một câu hỏi

3. eTOM: mô hình nghiệp vụ, không phải kiến trúc hệ thống

4. SID: mô hình thông tin chứ không phải một database

5. TAM: rất tốt cho As-Is, nhưng không còn nên là kiến trúc đích

6. Functional Framework là bước tiến hóa hiện đại của TAM

7. ODA là kiến trúc đích

8. Như vậy toàn bộ TM Forum hiện đại nên được hiểu như sau

9. Phản biện quy hoạch Telco hiện tại

Điểm tốt thứ nhất: đã nhận ra đúng vấn đề legacy

10. Điểm tốt thứ hai: đã đi đúng sang Cloud Native

11. Điểm tốt thứ ba: đã hình thành đúng các capability lớn

12. Nhưng tôi không khuyến nghị gọi mô hình hiện tại là “7 lớp TM Forum”

13. Tương tự, mô hình 3 lớp hiện nay phải giữ nhưng đặt đúng vị trí

14. Khoảng trống lớn nhất hiện nay: “gom hệ thống” đang được coi gần như đồng nghĩa “hiện đại hóa”

15. QLKH/CBS nên được nhìn như tập ODA Component, không phải một application khổng lồ

16. Master Product Catalog nên là một trong các dự án đầu tiên

17. SID nên giải bài toán Customer360/MDM đang tồn tại

18. OpenGW không nên trở thành “ESB phiên bản mới”

19. Mô hình kiến trúc Telco 2030 tôi đề xuất

20. Và mapping sang các chuẩn TM Forum cực kỳ rõ

21. Plan triển khai cụ thể từ hiện tại đến 2030

Giai đoạn 1 — H2/2026: Chuẩn hóa kiến trúc

22. Giai đoạn 2 — 2027: dựng ODA Foundation

23. Giai đoạn 3 — 2027–2028: bóc dần QLKH/CBS

24. Giai đoạn 4 — 2028–2029: Product → Service → Resource

25. Giai đoạn 5 — 2029–2030: ODA thực sự

26. KPI tôi đề xuất cho chương trình ODA

27. Thứ tự ưu tiên đầu tư mà tôi khuyến nghị

28. Một thay đổi rất quan trọng trong tư duy quy hoạch

Quy hoạch cũ

Quy hoạch 2030 nên hỏi

29. Công thức tôi khuyên dùng chính thức

30. Kết luận

ĐỌC NHIỀU