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

Phân biệt TMForum, TAM, ODA

1. TAM và ODA khác nhau thế nào?

TAM trả lời: “Doanh nghiệp viễn thông cần những nhóm chức năng/ứng dụng CNTT nào?”
ODA trả lời: “Trong kiến trúc số thế hệ mới, những chức năng đó nên được tổ chức thành các component thế nào, giao tiếp thế nào, triển khai và vận hành thế nào để có thể thay thế/lắp ghép linh hoạt?”

Có thể hình dung:


                  TM FORUM FRAMEWORK

 Business
 ┌─────────────────────────────────────────────┐
 │ eTOM       → Do WHAT? Business process      │
 │              Làm nghiệp vụ gì?              │
 └─────────────────────────────────────────────┘

 Information
 ┌─────────────────────────────────────────────┐
 │ SID        → WHAT DATA?                     │
 │              Customer/Product/Service/...   │
 └─────────────────────────────────────────────┘

 Application / Function
 ┌─────────────────────────────────────────────┐
 │ TAM        → WHAT APPLICATION FUNCTIONS?    │
 │              Cần các nhóm ứng dụng nào?     │
 └─────────────────────────────────────────────┘

 Target Digital Architecture
 ┌─────────────────────────────────────────────┐
 │ ODA        → HOW TO ARCHITECT & IMPLEMENT?  │
 │ Components + Open APIs + Cloud-native       │
 │ + Canvas + governance + common data model   │
 └─────────────────────────────────────────────┘

TM Forum hiện mô tả ODA là kiến trúc modular/component-based, trong đó các software component có khả năng tương tác, cung cấp business services thông qua Open APIs và dựa trên common data model.

2. TAM thực chất là gì?

TAM = Telecom Application Map, hiện thường được gọi là Application Framework, trước đây gắn với tài liệu GB929.

Mục tiêu của TAM không phải thiết kế Kubernetes, microservices hay API. Nó là một bản đồ chức năng ứng dụng chuẩn cho doanh nghiệp viễn thông, cho phép CIO/Enterprise Architect trả lời:

“Hiện tôi đang có những application nào, application đó đang thực hiện chức năng nào, chức năng nào bị trùng, chức năng nào còn thiếu?”

TM Forum mô tả Application Framework/TAM là framework tạo ngôn ngữ chung cho buyer/vendor và dùng để map applications, rationalize application portfolio.

Ví dụ một nhà mạng có:


CRM
Billing
Charging
Order Management
Product Catalog
Inventory
Fault Management
Performance Management
Workforce Management
ERP
HRM
Financial Management
Fraud Management
Data Management
API Management
...

TAM giúp đặt chúng vào đúng các domain/function.

Một nhầm lẫn rất phổ biến

TAM không đồng nghĩa với BSS.

Trong chính tài liệu anh gửi, Functional/Application Map bao gồm:


Market/Sales
Customer
Product
Service
Resource
Partner
Enterprise
Integration

Và đặc biệt Enterprise Domain có:

Revenue Assurance
HR Management
Financial Management
Asset Management
Security Management
Knowledge Management
Fraud Management
Regulatory & Compliance
Administrative Services
Supply Chain Management
Data Management

Integration Domain còn có:

Enterprise Application Integration
BPM/Workflow
API Management.

Đây chính là lý do trước đây anh thấy ERP, HRM xuất hiện trong bản đồ TM Forum: không có gì sai cả.

Sai chỉ xảy ra nếu chúng ta diễn giải:

“ERP và HRM là BSS.”

Không phải.

Đúng phải là:

“ERP và HRM thuộc phạm vi application landscape của enterprise telco, nằm trong Enterprise Domain của Application/Functional Framework.”

3. ODA là gì?

ODA = Open Digital Architecture.

ODA rộng hơn TAM rất nhiều.

TM Forum định nghĩa ODA như một blueprint cho kiến trúc số modular, cloud-based, composable. Các component được loosely coupled và cung cấp capability thông qua standardized Open APIs/common data model.

Whitepaper anh gửi tóm tắt ODA dựa trên các tư tưởng:

modularity;
microservices;
normalized/Open APIs;
cloud/cloud-native;
common data;
real-time integration;
security by design;
privacy by design;
elastic scaling;
continuous delivery;
multi-vendor;
legacy integration.

Và mục tiêu cuối cùng là:

independent scalability;
faster time-to-market;
flexibility;
security;
future proofing;
sản phẩm/business model mới;
giảm chi phí;
tăng tốc độ;
cải thiện customer experience.

4. Đây là điểm khác nhau quan trọng nhất

Tôi sẽ dùng chính một ví dụ rất gần với hệ thống viễn thông.

Giả sử có Product Catalog.

TAM nhìn Product Catalog như sau


PRODUCT DOMAIN
       │
       ├── Product Lifecycle Management
       ├── Product Strategy
       ├── Product Catalog Management
       └── Product Performance Management

TAM nói:

“Enterprise cần capability Product Catalog Management.”

Nhưng TAM chưa buộc anh phải triển khai nó bằng:


Monolith?
Microservice?
Oracle?
PostgreSQL?
Kubernetes?
REST?
Kafka?
Active-Active?

ODA nhìn vấn đề sâu hơn

ODA hướng tới:


                  Product Catalog Component
                           │
                   ┌───────┴────────┐
                   │ Business APIs  │
                   │ TMF Open APIs  │
                   └───────┬────────┘
                           │
                   Standard data model
                           │
              ┌────────────┼─────────────┐
              ↓            ↓             ↓
         Ordering       Billing       Channels

Component phải:

có boundary rõ;
API rõ;
lifecycle độc lập;
có thể deploy/scale độc lập;
hạn chế dependency trực tiếp;
có common information/data semantics;
có khả năng thay vendor/component;
chạy trong môi trường ODA Canvas/cloud-native phù hợp.

Đây chính là sự khác biệt giữa:

Application Map

và

Composable Architecture.

5. Bảng phân biệt TAM – ODA

Tiêu chí	TAM / Application Framework	ODA
Bản chất	Bản đồ chức năng ứng dụng	Kiến trúc số tổng thể
Câu hỏi chính	Cần những application/function nào?	Thiết kế và kết nối chúng thế nào?
Góc nhìn	Application/functional landscape	Business → information → component → runtime
Đối tượng	Application/function	ODA Component
API	Không phải trọng tâm chính	Rất quan trọng
Open API	Không bắt buộc	Thành phần cốt lõi
Microservices	Không quy định	Khuyến khích componentization/cloud-native
Cloud-native	Không	Là một hướng triển khai quan trọng
Common data model	Không phải mục tiêu chính	SID/common information model rất quan trọng
Runtime	Không mô tả	Có Canvas/deployment/runtime
Vendor independence	Giúp chuẩn hóa procurement	Hướng đến component plug-and-play
Legacy	Rất hữu ích để map As-Is	Hướng tới To-Be và migration
Rationalization	Rất mạnh	Có nhưng không phải mục đích duy nhất
Kiến trúc mục tiêu	Không đủ	Có
Phạm vi	Application portfolio	Digital enterprise architecture

TM Forum từng thể hiện rất trực quan TAM như một công cụ cho “As-is OSS/BSS Application Map”, trong khi ODA là kiến trúc đích rộng hơn gồm frameworks, APIs, components, deployment/runtime và transformation.

6. Vì sao rất dễ nhầm TAM với ODA?

Đây là điểm tôi muốn phản biện tài liệu này.

Trang 5–8 của whitepaper dùng tiêu đề:

Open Digital Architecture – Functional Architecture Mapping

Sau đó liệt kê:


Common Domain
Market Sales Domain
Customer Domain
Product Domain
Service Domain
Resource Domain
Business Partner Domain
Enterprise Domain
Integration Domain

Điều này nhìn rất giống TAM/Application Framework.

Thực tế, ODA có Functional Framework/Functional Architecture, và nó sử dụng các function map để mô tả hoạt động của tổ chức từ góc nhìn hệ thống. TM Forum hiện mô tả Functional Framework là một common map và terminology về các hoạt động/functions của tổ chức.

Vì vậy có một chuỗi tiến hóa/quan hệ:


             APPLICATION FRAMEWORK / TAM
                       │
                       │ Functional decomposition
                       ↓
              FUNCTIONAL FRAMEWORK
                       │
                       │ group / organize
                       ↓
             ODA FUNCTIONAL ARCHITECTURE
                       │
                       │ realization
                       ↓
                  ODA COMPONENTS
                       │
              ┌────────┼────────┐
              ↓        ↓        ↓
           Open API   SID      Events
                       │
                       ↓
                  ODA Canvas

Nói đơn giản:

TAM/Functional Framework nói về “function”.
ODA Component nói về “đơn vị kiến trúc triển khai capability đó”.

Không được coi hai cái là một.

7. Một ví dụ nữa: Customer Order Management

TAM có thể cho chúng ta:


Customer Domain
       ↓
Customer Order Management

Nhưng một hệ thống legacy có thể triển khai:


CRM MONOLITH

Customer
Order
Product
Campaign
Complaint
Payment
Workflow
...
       │
       └── Oracle DB

Về TAM:

✔ Có Customer Order Management.

Nhưng về ODA:

❌ Chưa chắc tốt.

Vì application này có thể:


Tight coupling
Shared DB
Point-to-point integration
Vendor proprietary API
Không independent scaling
Release chung
Không componentized

Chuyển theo ODA

Ta có thể hướng tới:


                 DIGITAL CHANNELS
                       │
                  API Gateway
                       │
        ┌──────────────┼─────────────┐
        ↓              ↓             ↓
     Party          Product       Customer
   Management       Catalog       Management
        │              │             │
        └──────────────┼─────────────┘
                       ↓
                Order Management
                       │
                Service Ordering
                       │
              Service Orchestration
                       │
                Resource / Network

Các boundary giao tiếp thông qua standardized APIs/events thay vì:


App A → DB của App B
App C → Stored procedure App A
App D → file FTP
App E → bảng DB_LINK

Đó mới chính là sự chuyển đổi kiến trúc mà ODA nhắm tới. Whitepaper cũng nhấn mạnh componentization để hỗ trợ môi trường multi-vendor và legacy integration, đồng thời dùng microservices để cô lập thay đổi và rút ngắn continuous delivery/time-to-market.

8. ODA không phải chỉ là “microservices”

Đây cũng là một hiểu nhầm phổ biến:


ODA ≠ Microservices
ODA ≠ Kubernetes
ODA ≠ Open API
ODA ≠ eTOM
ODA ≠ TAM
ODA ≠ SID

Mà gần đúng hơn:


                        ODA
                         │
       ┌─────────────────┼──────────────────┐
       │                 │                  │
 Business            Information        Implementation
 Architecture        Systems            / Runtime
       │                 │                  │
       │                 │                  │
    eTOM            Functions           Components
 Capabilities          SID              Open APIs
                    TAM/FF             Canvas
                                      Cloud-native
                                      DevSecOps

ODA tập hợp những tài sản TM Forum có từ trước — eTOM, SID, APIs, business architecture — rồi bổ sung componentization, technical architecture, deployment/runtime, Canvas và governance để tạo ra kiến trúc chuyển đổi end-to-end.

9. TAM rất hữu ích khi anh đang có hàng chục/hàng trăm hệ thống

Đây là điểm tôi cho rằng TAM đặc biệt phù hợp với bài toán quản trị hệ thống CNTT hiện nay.

Giả sử hiện có:


CRM
TC&QLKH
Billing
mSale
mSale Pro
MyMobiFone
MobiGold
Loyalty
Payment
Portal
eKYC
DWH
Big Data
API Gateway
ERP
HRM
...

Đừng bắt đầu bằng:

“Hệ thống này dùng Oracle hay PostgreSQL?”

Hoặc:

“Hệ thống này K8s hay VM?”

Nên bắt đầu:


STEP 1
Inventory hệ thống
       ↓
STEP 2
Map vào TAM / Functional Framework
       ↓
STEP 3
Xác định capability overlap
       ↓
STEP 4
Identify:
Keep / Merge / Retire / Replace
       ↓
STEP 5
Thiết kế target ODA
       ↓
STEP 6
Tách component/API/data
       ↓
STEP 7
Modernization
Legacy → API-enable → Container → Cloud-native

TM Forum cũng nêu TAM/Application Framework như công cụ để rationalize application inventory và streamline procurement.

10. Tôi đề xuất không dùng “7 lớp TM Forum” theo cách cứng nhắc

Một điểm liên quan trực tiếp đến cách phân loại hệ thống mà chúng ta từng trao đổi: không nên biến các domain TM Forum thành kiểu:


L1 = Channel
L2 = BSS
L3 = OSS
L4 = Data
L5 = Middleware
L6 = Infrastructure
...

rồi gọi đó là “7 lớp chuẩn TM Forum”.

Cách đó có thể là enterprise architecture model nội bộ, nhưng không nên gán trực tiếp là cấu trúc chính thức của TM Forum.

TM Forum có nhiều view/framework khác nhau:


Business Capability
       ↓
eTOM Process
       ↓
Functional Framework
       ↓
Application Framework/TAM
       ↓
SID
       ↓
ODA Components
       ↓
Open APIs
       ↓
Deployment / Canvas

Mỗi cái trả lời một câu hỏi kiến trúc khác nhau.

11. Áp dụng vào kiến trúc CNTT thực tế

Thay vì chỉ một sơ đồ, tôi sẽ duy trì 4 bản đồ song song:


┌─────────────────────────────────────────────────────┐
│ 1. BUSINESS / eTOM                                  │
│    Doanh nghiệp đang làm nghiệp vụ gì?              │
└─────────────────────────────────────────────────────┘
                         ↓

┌─────────────────────────────────────────────────────┐
│ 2. FUNCTION / TAM                                   │
│    Cần những capability/application function nào?   │
└─────────────────────────────────────────────────────┘
                         ↓

┌─────────────────────────────────────────────────────┐
│ 3. APPLICATION LANDSCAPE                            │
│    CRM / Billing / TCQLKH / mSale / MyMobiFone...   │
│                                                     │
│    → Mapping application ↔ TAM                      │
└─────────────────────────────────────────────────────┘
                         ↓

┌─────────────────────────────────────────────────────┐
│ 4. TARGET ODA                                       │
│                                                     │
│ Components                                          │
│       ↓                                             │
│ Open APIs / Event                                   │
│       ↓                                             │
│ Data                                                │
│       ↓                                             │
│ Canvas / K8s / Cloud                                │
└─────────────────────────────────────────────────────┘

Đây là cách rất tốt để tránh việc trộn business architecture, application architecture và technology architecture vào một slide.

12. Tóm tắt

Tài liệu muốn truyền tải rằng:

Legacy BSS/OSS ngày càng không phù hợp với yêu cầu CSP trở thành digital service provider.
ODA cung cấp một blueprint chung cho business và technology.
Kiến trúc cần modular/componentized, thay vì monolithic.
Các component cần giao tiếp bằng API chuẩn, giảm point-to-point.
Microservices giúp independent deployment/scaling.
Cloud/cloud-native giúp tăng elasticity và giảm time-to-market.
Data phải có khả năng chia sẻ xuyên kiến trúc để hình thành single customer view.
Security, privacy và governance phải được thiết kế xuyên suốt.
Legacy không thể thay ngay; kiến trúc mới cần coexist/integrate trong nhiều năm.
Netadmin dùng Functional Architecture Map để tự đánh giá từng capability là Full / Partial / Limited or no support — đây là ví dụ rất hay về cách dùng TM Forum framework để đánh giá một sản phẩm/vendor, nhưng không phải toàn bộ bản thân ODA.

13. Công thức dễ nhớ nhất

Tôi đề xuất anh nhớ TM Forum theo công thức này:


eTOM
"Chúng ta LÀM GÌ?"
      ↓
SID
"Chúng ta dùng THÔNG TIN GÌ?"
      ↓
TAM / Functional Framework
"ỨNG DỤNG cần có CHỨC NĂNG GÌ?"
      ↓
ODA
"CHIA chúng thành COMPONENT thế nào?"
      ↓
Open API
"CÁC COMPONENT NÓI CHUYỆN thế nào?"
      ↓
ODA Canvas / Cloud-native
"DEPLOY + RUN chúng thế nào?"

Và nếu phải phân biệt TAM – ODA chỉ bằng hai hình:


TAM
────────────────────────────
           BẢN ĐỒ
        🗺 APPLICATION

       "CẦN CÓ GÌ?"
────────────────────────────

so với:


ODA
────────────────────────────
       BẢN THIẾT KẾ
       🏗 ARCHITECTURE

     "XÂY NÓ THẾ NÀO?"
────────────────────────────

TAM không cạnh tranh với ODA. TAM là một trong những công cụ đầu vào cực kỳ hữu ích để hiểu/rationalize application landscape; ODA là kiến trúc đích giúp chuyển landscape đó sang mô hình modular, composable, API-driven và cloud-native. TM Forum hiện vẫn phát triển ODA theo hướng Components & Canvas, với Component Directory và cơ chế conformance/certification — tức ODA đã đi xa hơn rất nhiều so với một “application map”.

Nếu áp dụng vào bài toán kiến trúc tổng thể cho Telco, tôi khuyên xây một mô hình 5 tầng liên kết: eTOM → TAM/Functional Framework → hệ thống thực tế → ODA Component → IaaS/PaaS/Cloud. Mô hình này sẽ giải quyết rất rõ câu hỏi đang gây tranh luận như CRM/Billing/QLKH thuộc đâu, ERP/HRM thuộc đâu, Data/DWH thuộc đâu, và cái nào nên gom/gộp/tách component đến 2030.

THAM KHẢO:

https://2948626.fs1.hubspotusercontent-na1.net/hubfs/2948626/documents/TM-Forum-Whitepaper.pdf

Website TMForum

=============================
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