Thứ Bảy, 15 tháng 8, 2026

Phân biệt ODA và TAM của TMForum

I.TỔNG QUAN
Trong hệ thống tiêu chuẩn của TM Forum, TAM (Telecom Application Map / Application Framework) là bản đồ ứng dụng truyền thống phân loại các chức năng phần mềm OSS/BSS, trong khi ODA (Open Digital Architecture)kiến trúc số mở hiện đại, hướng mây (cloud-native) và tích hợp AI nhằm thay thế các hệ thống nguyên khối cũ bằng các thành phần phần mềm có thể lắp ghép (plug-and-play) giao tiếp qua Open APIs. Về mặt tiến hóa, TAM chính là tiền thân khái niệm của Functional Framework trong ODA, chuyển dịch từ góc nhìn "ứng dụng phần mềm" sang góc nhìn "khối chức năng hệ thống độc lập". [1, 2, 3, 4, 5, 6]
Tiêu chí so sánh chi tiết
Tiêu chíTAM (Application Framework)ODA (Open Digital Architecture)
Bản chấtBản đồ phân loại ứng dụng (Application Classification Map).Khung kiến trúc và vận hành dạng mô-đun (Modular Component-based Architecture).
Mục tiêu cốt lõiXác định ứng dụng nào quản lý quy trình và dữ liệu nào trong OSS/BSS.Chuẩn hóa các khối phần mềm (ODA Components) và Open APIs để tích hợp plug-and-play.
Môi trường triển khaiPhù hợp với kiến trúc phần mềm nguyên khối hoặc phân lớp truyền thống.Thiết kế tối ưu cho môi trường điện toán đám mây (Cloud-native) và hỗ trợ AI-native.
Mối quan hệ cấu trúcThuộc thế hệ khung cũ (Frameworx).Tiến hóa từ TAM, thay thế góc nhìn ứng dụng bằng Functional FrameworkODA Components.
Các điểm khác biệt cốt lõi
  • Góc nhìn tiếp cận (Application vs. Function): TAM tập trung định nghĩa các lớp ứng dụng (ví dụ: hệ thốngBilling nào làm gì). ODA loại bỏ bối cảnh phụ thuộc vào nhà cung cấp ứng dụng cụ thể thông qua Functional Framework, nguyên tử hóa các hoạt động thành các ODA Components nhỏ gọn, không phụ thuộc công nghệ. [1, 2]
  • Khả năng tương tác (Integration): TAM dựa vào các chuẩn tích hợp cũ, phức tạp. ODA bắt buộc sử dụng các Open APIs dựa trên REST và vận hành trên môi trường quản lý vòng đời chuẩn gọi là ODA Canvas. [1, 2, 3]
  • Định hướng tương lai (AI & Autonomous): ODA mở rộng vượt ra ngoài ranh giới của TAM bằng cách tích hợp lớp thực thi hướng AI (AI-native ODA), cho phép các tác nhân AI và tự động hóa mạng lưới hoạt động xuyên suốt các miền. [1, 2]

(Khung kiến trúc CNTT theo TAM của TMForum)

II.GIẢI THÍCH DỄ HIỂU
Để bạn dễ hình dung, hãy tưởng tượng hệ thống phần mềm của một nhà mạng viễn thông (gọi là OSS/BSS) giống như nhà bếp của một nhà hàng lớn.
1. Ví dụ dân dã: Nhà bếp "Kiểu cũ" (TAM) vs. Nhà bếp "Hiện đại" (ODA)
Giai đoạn TAM: Nhà bếp phân chia theo "Thiết bị đóng gói"
  • Cách hiểu: TAM giống như việc bạn đi mua những chiếc máy làm bếp công nghiệp đa năng được đóng gói sẵn từ các hãng khác nhau. Ví dụ: Bạn mua Máy làm bánh mì hãng A (trong đó tích hợp sẵn cả khay trộn bột, lò nướng, ngăn ủ) và Máy làm mỳ Ý hãng B (tích hợp sẵn trục cán, nồi luộc).
  • Vấn đề gặp phải: Khi bạn muốn đổi sang một loại lò nướng tiết kiệm điện hơn, bạn không thể bóc tách riêng cái lò ra được, vì nó đúc liền khối trong Máy hãng A. Muốn đổi là phải bỏ cả cái máy lớn. Ngoài ra, máy hãng A và máy hãng B dùng đầu cắm điện và ống nước khác nhau, khiến việc kết nối rất lộn xộn.
  • Liên hệ thực tế: Trong viễn thông, TAM là sơ đồ phân loại các "cục" phần mềm đóng gói (Applications). Ví dụ: Bạn mua nguyên một hệ thống tính cước (Billing) của hãng X hay hệ thống quản lý khách hàng (CRM) của hãng Y. Chúng hoạt động độc lập và rất khó tùy biến sâu.
Giai đoạn ODA: Nhà bếp "Lắp ghép mô-đun" (Plug-and-Play)
  • Cách hiểu: ODA dẹp bỏ các máy nguyên khối. Thay vào đó, toàn bộ nhà bếp được quy chuẩn hóa thành các Mô-đun chức năng độc lập (ODA Components). Bạn sẽ có: 1 mô-đun chuyên Trộn bột, 1 mô-đun chuyên Nướng, 1 mô-đun chuyên Luộc.
  • Ưu điểm vượt trội: Các mô-đun này kết nối với nhau qua một chuẩn jack cắm duy nhất (Open APIs) và đặt trên một mặt bàn thông minh cung cấp sẵn điện, nước (ODA Canvas). Nếu lò nướng bị hỏng hoặc lỗi thời, bạn chỉ việc rút phích cắm, vứt cái lò cũ đi và cắm một cái lò nướng siêu tốc của hãng khác vào là xong.
  • Liên hệ thực tế: ODA chia nhỏ hệ thống thành các dịch vụ siêu nhỏ (Microservices/Components). Chức năng "Tính tiền" tách rời khỏi chức năng "Quản lý tài khoản". Nhà mạng có thể tự do thay thế hoặc nâng cấp từng phần nhỏ mà không làm sập cả hệ thống lớn.

2. Mô hình trực quan so sánh kiến trúc
Để trực quan hóa sự khác biệt về cấu trúc hạ tầng, hãy xem mô hình so sánh dưới đây:
Graph image
Giải thích mô hình trực quan:
  • Bên kiến trúc TAM: Các khối ứng dụng lớn (như CRM, Billing, Inventory) đứng độc lập như những "ốc đảo". Khi chúng muốn nói chuyện với nhau, kỹ sư phải tự viết các đường ống kết nối riêng biệt (Point-to-Point). Kết quả là tạo ra một "mạng nhện" dây cáp cực kỳ phức tạp và dễ lỗi khi có một khối thay đổi.
  • Bên kiến trúc ODA: Mọi thứ gọn gàng hơn nhờ 3 lớp chuẩn hóa:
    1. ODA Components (Mô-đun chức năng): Các hạt nhân phần mềm nhỏ, thực hiện một nhiệm vụ duy nhất (ví dụ: chỉ quản lý Giỏ hàng, hoặc chỉ quản lý Địa chỉ khách hàng).
    2. Open APIs (Cổng kết nối chuẩn): Tất cả các mô-đun đều nói chung một ngôn ngữ. Muốn lấy dữ liệu? Cứ cắm vào cổng API chuẩn là xong, không cần biết mô-đun bên trong do hãng nào viết.
    3. ODA Canvas (Nền tảng quản trị): Giống như hệ điều hành (hoặc mặt bàn bếp thông minh), tự động cấp phát tài nguyên, bảo mật và vận hành các mô-đun này trên môi trường Điện toán đám mây (Cloud-native).

III. Ví dụ thực tế khi nhà mạng triển khai gói cước 5G mới

  • Nếu dùng TAM (Kiểu cũ): Nhà mạng phải cấu hình lại hệ thống CRM để hiện nút bấm gói cước, sửa đổi hệ thống Billing để nhận diện công thức tính tiền mới, cấu hình hệ thống Provisioning để mở mạng 5G. Do các hệ thống này là các "cục" lớn của các hãng khác nhau, việc kiểm thử và tích hợp có thể mất 3 đến 6 tháng.
  • Nếu dùng ODA (Kiểu mới): Nhà mạng chỉ cần gọi đến Mô-đun Quản lý Sản phẩm (Product Catalog Component) để thêm gói cước mới. Mô-đun này sẽ tự động bắn tín hiệu qua Open API đến Mô-đun Tính cước (Charging Component)Mô-đun Kích hoạt mạng (Activation Component). Quá trình này diễn ra tự động và có thể hoàn thành trong vài giờ.
Để hiểu cách ODA Components đập tan và thay thế các hệ thống TAM truyền thống, chúng ta hãy lấy ví dụ thực tế về thực thể quan trọng nhất của mọi nhà mạng: Khách hàng (trong TM Forum gọi chung là Party - bao gồm cá nhân, doanh nghiệp, đối tác).
(1) Góc nhìn TAM cũ: Hệ thống CRM là một "Gã khổng lồ" ôm đồm
Trong bản đồ ứng dụng TAM, thông tin khách hàng nằm trọn trong một cục phần mềm lớn gọi là CRM (Customer Relationship Management).
  • Cách hoạt động: Khi bạn mua một bộ phần mềm CRM của một hãng lớn, phần mềm này sẽ ôm đồm rất nhiều tính năng: lưu tên tuổi khách hàng, quản lý lịch sử cuộc gọi, tạo đơn hàng mới, xử lý khiếu nại, gửi email khuyến mãi...
  • Điểm yếu chết người:
    • Nếu hệ thống Billing (Tính cước) hoặc Website bán hàng muốn kiểm tra xem khách hàng này là VIP hay Thường để áp mã giảm giá, chúng bắt buộc phải chọc xuyên qua lớp bảo mật để đi vào sâu trong "bụng" của hệ thống CRM để lấy dữ liệu.
    • Khi nhà mạng muốn nâng cấp tính năng "Xử lý khiếu nại" lên phiên bản mới bằng công nghệ AI, họ không thể tự sửa riêng phần đó được. Họ phải nâng cấp toàn bộ hệ thống CRM, kéo theo rủi ro làm gián đoạn luôn cả tính năng lưu tên tuổi khách hàng.

(2) Góc nhìn ODA mới: Rã nhỏ CRM thành các mô-đun siêu chuyên hóa
Kiến trúc ODA không công nhận một khái niệm chung chung, to lớn mang tên "CRM" nữa. ODA thực hiện một cuộc "phẫu thuật", chia nhỏ CRM thành các ODA Components độc lập.
Đối với mảng khách hàng, ODA chia thành các hạt nhân cốt lõi sau:
  1. Party Management Component: Chỉ làm đúng một nhiệm vụ duy nhất là lưu trữ thông tin định danh (Tên, tuổi, CCCD, địa chỉ, mã số thuế của khách hàng/đối tác).
  2. Customer Bill Management Component: Chuyên quản lý các thông tin liên quan đến hóa đơn của khách hàng.
  3. Customer Interaction Management Component: Chuyên ghi lại nhật ký tất cả các lần khách hàng gọi điện lên tổng đài, nhắn tin qua chatbot hoặc ra cửa hàng.

(3) Mô hình so sánh dòng chảy dữ liệu
Hãy xem cách hai kiến trúc này xử lý một yêu cầu đơn giản: "Khách hàng VIP gọi điện lên tổng đài để đổi địa chỉ nhận hóa đơn".
KIẾN TRÚC TAM (Cũ):
[Nhân viên Tổng đài] 
        │
        ▼ (Mở ứng dụng CRM tổng thể)
   ┌─────────── Hệ thống CRM Nguyên Khối ───────────┐
   │ 1. Tra cứu thông tin (Bên trong CRM)           │
   │ 2. Xem lịch sử cuộc gọi (Bên trong CRM)        │
   │ 3. Sửa địa chỉ hóa đơn (Bên trong CRM)         │
   └────────────────────────────────────────────────┘
        │ 
        ▼ (Viết code kết nối riêng biệt - Point-to-Point)
   [Hệ thống Billing] (Để Billing cập nhật thông tin in hóa đơn mới)


KIẾN TRÚC ODA (Mới):
[Nhân viên Tổng đài] 
        │
        ▼ (Giao diện tổng đài gọi đồng thời các Open API chuẩn)
   ├─► [Customer Interaction Component] ──► (Ghi nhận nhật ký cuộc gọi)
   ├─► [Party Management Component]      ──► (Cập nhật lại Địa chỉ mới)
   └─► [Customer Bill Component]         ──► (Cập nhật địa chỉ nhận hóa đơn)

(4) Lợi ích thực tế khi rã nhỏ thành ODA Component
Nhờ việc tách riêng thành các cấu phần độc lập kết nối qua cổng chuẩn (Open API), nhà mạng sẽ có các lợi thế cực lớn:
  • Thay thế "ruột" cực dễ (Plug-and-Play): Nếu hệ thống lưu lịch sử cuộc gọi cũ quá chậm, nhà mạng có thể rút bỏ Customer Interaction Component cũ ra, mua một giải pháp lưu trữ dữ liệu lớn (Big Data) của một startup công nghệ khác lắp vào. Miễn là cấu phần mới đáp ứng đúng chuẩn TM Forum Open API (TMF667), toàn bộ hệ thống còn lại (như cấu phần lưu Tên/Tuổi) vẫn hoạt động bình thường, không hề bị ảnh hưởng.
  • Tối ưu hóa hạ tầng đám mây (Cloud-native Scaling): Vào ngày cuối tháng, lượng khách hàng tra cứu hóa đơn tăng vọt gấp 100 lần, nhưng lượng khách hàng sửa đổi thông tin cá nhân (Tên, tuổi) vẫn giữ nguyên.
    • Với TAM: Nhà mạng phải tăng cường máy chủ cho cả cục CRM lớn, cực kỳ lãng phí.
    • Với ODA: Hệ thống tự động nhân bản (scale-out) riêng lẻ cấu phần Customer Bill Management lên 100 lần trên đám mây để gánh tải, còn cấu phần Party Management vẫn giữ nguyên tài nguyên thấp để tiết kiệm chi phí.
Bây giờ bạn đã thấy rõ cách ODA chia nhỏ một hệ thống cũ như thế nào.
=============================
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

ĐỌC NHIỀU

Trần Văn Bình - Oracle Database Master