OLB #06 — Kiến trúc ứng dụng ngân hàng: Từ năng lực nghiệp vụ đến hệ sinh thái công nghệ số

[GIẢ LẬP · PHỤC VỤ NGHIÊN CỨU & ĐÀO TẠO]

Kiến trúc ứng dụng ngân hàng: Từ năng lực nghiệp vụ đến hệ sinh thái công nghệ số

Trong hành trình xây dựng Odin Lab Bank (OLB), chúng ta đã lần lượt xác định tầm nhìn, chiến lược, kiến trúc doanh nghiệp, các năng lực nghiệp vụ, trách nhiệm quản trị và mô hình vận hành công nghệ. Nhưng một ngân hàng không tạo ra giá trị chỉ bằng những bản thiết kế tốt. Giá trị xuất hiện khi các năng lực được chuyển thành những dịch vụ mà khách hàng có thể sử dụng an toàn, ổn định mỗi ngày. Kiến trúc ứng dụng chính là một trong những cầu nối quan trọng của quá trình đó.

Một giao dịch chuyển tiền trên điện thoại tưởng như rất đơn giản, nhưng phía sau là nhiều ứng dụng phối hợp: kênh ngân hàng số tiếp nhận yêu cầu, dịch vụ xác thực kiểm tra danh tính, ứng dụng thanh toán xử lý giao dịch, hệ thống tài khoản ghi nhận biến động và những công cụ kiểm soát rủi ro, đối soát, thông báo hỗ trợ quá trình. Nếu thiếu quy hoạch tổng thể, ngân hàng dễ gặp tình trạng trùng lặp chức năng, dữ liệu phân tán, kết nối phức tạp và khó xác định nguyên nhân khi gián đoạn.

1. Bắt đầu từ năng lực nghiệp vụ

Trong OLB #03, bản đồ năng lực nghiệp vụ đã mô tả những việc ngân hàng phải có khả năng thực hiện, từ quản lý khách hàng, thanh toán, tiền gửi và tín dụng đến quản trị rủi ro. Một năng lực có thể được hỗ trợ bởi nhiều ứng dụng; ngược lại, một ứng dụng cũng có thể phục vụ nhiều năng lực. Vì thế, quyết định đầu tư không nên xuất phát đơn thuần từ việc công nghệ mới xuất hiện hay một đơn vị đề nghị mua thêm phần mềm.

OLB sử dụng chuỗi truy vết: Chiến lược → Năng lực nghiệp vụ → Dịch vụ ngân hàng → Ứng dụng → Dữ liệu và nền tảng công nghệ → Kiểm soát và khả năng phục hồi. Chuỗi này giúp nhận diện khoảng trống năng lực, ứng dụng trùng lặp và những khoản đầu tư chưa tạo ra giá trị tương xứng.

2. Sáu nhóm ứng dụng trong mô hình OLB

Để quản lý hệ sinh thái ứng dụng, OLB phân danh mục thành sáu nhóm chức năng. Đây là cấu trúc giả lập phục vụ nghiên cứu, không phải sơ đồ bắt buộc cho mọi ngân hàng.

Nhóm ứng dụng khách hàng và kênh số cung cấp điểm tiếp xúc qua điện thoại, website và các kênh phục vụ khác. Nhóm ứng dụng nghiệp vụ cốt lõi hỗ trợ quản lý tài khoản, tiền gửi, tín dụng, thanh toán và các giao dịch tài chính. Nhóm ứng dụng hỗ trợ nghiệp vụ kết nối hồ sơ, quy trình phê duyệt, chăm sóc khách hàng và hoạt động tác nghiệp.

Nhóm ứng dụng dữ liệu và phân tích tổ chức, khai thác thông tin phục vụ điều hành và quyết định. Nhóm ứng dụng rủi ro và kiểm soát hỗ trợ theo dõi rủi ro, tuân thủ, gian lận và bằng chứng. Cuối cùng, các dịch vụ ứng dụng dùng chung giúp kết nối, trao đổi dữ liệu và điều phối luồng xử lý giữa các hệ thống. Giá trị của mô hình không nằm ở số lượng nhóm, mà ở cách xác định ranh giới chức năng và quản lý quan hệ phụ thuộc giữa chúng.

3. Kết nối ứng dụng phải có nguyên tắc

Khi mỗi ứng dụng tự xây dựng kết nối riêng với tất cả ứng dụng còn lại, số lượng điểm tích hợp và chi phí thay đổi có thể tăng rất nhanh. OLB ưu tiên các giao diện được quản lý, giảm phụ thuộc trực tiếp và lựa chọn hình thức trao đổi thông tin theo đặc điểm nghiệp vụ.

Một giao dịch cần phản hồi tức thời có thể sử dụng kết nối đồng bộ. Những hoạt động như gửi thông báo hoặc cập nhật dữ liệu phân tích có thể dùng cơ chế xử lý bất đồng bộ. Không có phương thức nào phù hợp với mọi tình huống; thiết kế phải cân bằng tốc độ, tính nhất quán, bảo mật, khả năng xử lý lỗi và phục hồi. Mỗi kết nối cần xác định rõ ứng dụng cung cấp, ứng dụng sử dụng, chủ dữ liệu và người chịu trách nhiệm khi gián đoạn.

4. Hành trình một giao dịch thanh toán số

Trong tình huống giả lập của OLB, khách hàng khởi tạo giao dịch trên ứng dụng ngân hàng số. Yêu cầu được xác thực, kiểm tra điều kiện giao dịch và đánh giá các dấu hiệu rủi ro phù hợp. Ứng dụng thanh toán tiếp nhận và xử lý, phối hợp với hệ thống tài khoản cùng các hệ thống liên quan để ghi nhận kết quả. Thông báo sau đó được gửi tới khách hàng; dữ liệu cần thiết được cung cấp cho đối soát, giám sát và báo cáo.

Giao dịch thành công không chỉ phụ thuộc vào một ứng dụng thanh toán. Nó phụ thuộc vào toàn bộ chuỗi ứng dụng, dữ liệu và nền tảng hỗ trợ. Khi có sự cố, ngân hàng cần biết dịch vụ nào bị ảnh hưởng, điểm phụ thuộc nào đang gặp vấn đề, ai chịu trách nhiệm và phương án xử lý phù hợp. Bản đồ phụ thuộc ứng dụng vì thế không chỉ phục vụ thiết kế mà còn hỗ trợ quản lý thay đổi, sự cố và phục hồi.

5. Quản lý vòng đời để tránh tích lũy rủi ro

Một ứng dụng từng đáp ứng tốt nhu cầu có thể trở thành gánh nặng sau nhiều năm nếu thiếu kế hoạch duy trì. Công nghệ lạc hậu, chi phí bảo trì tăng, phụ thuộc nhà cung cấp, khó tích hợp và những điểm yếu chưa được xử lý đều có thể làm giảm giá trị theo thời gian.

OLB quản lý vòng đời từ xác định nhu cầu, thiết kế, xây dựng hoặc lựa chọn giải pháp, triển khai, vận hành đến đánh giá và hiện đại hóa. Mỗi ứng dụng cần được xem xét định kỳ về giá trị nghiệp vụ, chất lượng vận hành, chi phí, rủi ro, mức độ phù hợp kiến trúc và khả năng phát triển. Kết quả đánh giá là căn cứ để tiếp tục đầu tư, hợp nhất, nâng cấp, thay thế hoặc ngừng sử dụng.

6. An toàn và khả năng phục hồi ngay từ thiết kế

Một ứng dụng có thể hỗ trợ nhiều dịch vụ quan trọng; ngược lại, một dịch vụ có thể phụ thuộc vào nhiều ứng dụng ít được chú ý. Vì vậy, mức độ quan trọng của ứng dụng không thể chỉ dựa trên quy mô kỹ thuật. OLB liên kết ứng dụng với dịch vụ nghiệp vụ và đánh giá hậu quả khi từng thành phần bị gián đoạn.

Yêu cầu phân quyền, bảo vệ dữ liệu, ghi nhận sự kiện, kiểm soát thay đổi, xử lý lỗi và khả năng phục hồi cần được đưa vào ngay từ giai đoạn thiết kế. Các điểm phụ thuộc trọng yếu phải được nhận diện và kiểm thử phù hợp, tạo cơ sở cho ưu tiên đầu tư và quản trị khả năng liên tục hoạt động.

7. Kiến trúc phải được duy trì bằng dữ liệu và bằng chứng

Một sơ đồ kiến trúc đẹp sẽ nhanh chóng mất giá trị nếu không được cập nhật. OLB hướng tới kho thông tin kiến trúc có cấu trúc, trong đó ứng dụng được gắn với mã định danh, chức năng, năng lực nghiệp vụ, chủ sở hữu, dữ liệu, giao diện kết nối, dịch vụ phụ thuộc và yêu cầu kiểm soát.

Khi phát sinh nhu cầu mới, kho thông tin giúp xác định khả năng tái sử dụng ứng dụng hiện có. Khi thay đổi, nó hỗ trợ phân tích phạm vi ảnh hưởng. Khi xảy ra sự cố, nó giúp truy vết chuỗi dịch vụ. Hồ sơ kiến trúc, kết quả kiểm thử, đánh giá rủi ro, thông tin vòng đời và nhật ký quyết định trở thành bằng chứng phục vụ quản trị theo phương pháp Odin: Mục tiêu → Rủi ro → Kiểm soát → Bằng chứng → Trách nhiệm → Quyết định → Hành động.

8. Kiến trúc tốt giúp ngân hàng thay đổi dễ dàng hơn

Đích đến của kiến trúc ứng dụng không phải một bản vẽ chứa đủ mọi hệ thống. Kiến trúc tốt giúp phát triển dịch vụ mới mà không phải sửa đổi quá nhiều thành phần, mở rộng quy mô mà không mất kiểm soát độ phức tạp, thay thế công nghệ lạc hậu với chi phí hợp lý và duy trì dịch vụ khi một phần hệ thống gặp sự cố.

OLB ưu tiên các khối chức năng có ranh giới rõ, kết nối được quản lý, dữ liệu nhất quán và khả năng truy vết từ ứng dụng tới giá trị nghiệp vụ. Đây cũng là nền tảng cho những bài tiếp theo về dữ liệu và trí tuệ nhân tạo, hạ tầng, an toàn thông tin và khả năng phục hồi.

9. Tiếp nối hành trình Odin Lab Bank

OLB #06 kế thừa mô hình vận hành công nghệ ở OLB #05 và cụ thể hóa các năng lực nghiệp vụ từ OLB #03. Chuỗi bài hiện đi từ chiến lược, kiến trúc doanh nghiệp, năng lực nghiệp vụ, trách nhiệm quản trị và vận hành đến kiến trúc ứng dụng. Bài tiếp theo, OLB #07, sẽ nghiên cứu cách tổ chức dữ liệu thành tài sản chiến lược và ứng dụng trí tuệ nhân tạo có trách nhiệm.

Một ngân hàng không nhất thiết phải sở hữu công nghệ phức tạp nhất. Điều quan trọng là lựa chọn, kết nối và vận hành công nghệ phù hợp để tạo ra giá trị, kiểm soát rủi ro và thích ứng với thay đổi.

Đọc tiếp trong chuỗi OLB

OLB #01 — Chiến lược · OLB #02 — Kiến trúc doanh nghiệp · OLB #03 — Năng lực nghiệp vụ · OLB #04 — Tổ chức và quản trị · OLB #05 — Mô hình vận hành CNTT · Chỉ mục Odin Lab Bank

Tài liệu tham chiếu

TOGAF — The Open Group; BIAN Service Landscape; COBIT — ISACA; NIST Cybersecurity Framework 2.0; ISO/IEC/IEEE 42010 về mô tả kiến trúc. Các nguồn được tham khảo ở mức phương pháp; OLB không tuyên bố được chứng nhận hay tuân thủ đầy đủ.

ODIN LAB BANK · OLB #06 — APPLICATION ARCHITECTURE
Business Capability → Application → Data → Technology → Risk & Resilience
TURN RISK INTO VALUE

OLB là ngân hàng giả lập phục vụ nghiên cứu và đào tạo, không mô phỏng một tổ chức cụ thể. Tên hệ thống, tình huống và kiến trúc là mô hình tổng hợp, không phải dữ liệu triển khai thực tế. Các thương hiệu của bên thứ ba thuộc sở hữu của chủ thể tương ứng.