Mô hình dịch vụ ngân hàng của BIAN - Từ lý thuyết đến thực tiễn

Mô hình dịch vụ của BIAN giúp cụ thể hoá những vấn đề của kiến trúc doanh nghiệp trong ngành ngân hàng, đem tới một ngôn ngữ chung cho những người làm công nghệ và lãnh đạo nghiệp vụ. Việc sử dụng mô hình dịch vụ theo dạng chuỗi giá trị của BIAN cho phép tạo ra một “bản đồ nhiệt” để lãnh đạo ngân hàng nhìn rõ những vùng yếu kém hay gặp vấn đề về tuân thủ. Với cái nhìn tổng quan về ngân hàng chỉ trên một trang giấy, chúng ta có thể định hướng lại và xác định những mảng cần đầu tư thêm trong danh mục ứng dụng.

BIAN hiện có 74 thành viên, trong đó có 27 ngân hàng và tổ chức tài chính lớn (như SWIFT, ABN AMBRO, Commonwealth Bank, Credit Suisse, DBS, Deutsche Bank, ING, Nomura KWF, Rabobank, Societe Generale, Postbank, UBS, UniCredit Group, Bangkok Bank…), 43 nhà cung cấp giải pháp và dịch vụ phần mềm (IBM, Microsoft, SAP, Infosys, Sunguard, Temenos…) và 4 tổ chức giáo dục (Carnegie Mellon University, Singapore Management University, …). Các mô hình tiêu chuẩn của BIAN hình thành từ việc các ngân hàng lớn chia sẻ các yêu cầu của họ về dịch vụ ngân hàng, các nhà cung cấp giải pháp chia sẻ kinh nghiệm triển khai phần mềm và thông qua những hoạt động trao đổi, thảo luận thường xuyên. Tới quý III/2016, phiên bản 5.0 của BIAN Service Lanscape đã bao gồm gần 300 dịch vụ cùng hơn 1000 sự kiện và kịch bản kinh doanh liên quan.

Mô hình dịch vụ của BIAN

Bao gồm 3 cấp:

Cấp 1: Các lĩnh vực kinh doanh (BusinessArea) là cấp cao nhất, mỗi lĩnh vực kinh doanh bao gồm một tập lớn các khả năng kinh doanh, những khía cạnh của hoạt động kinh doanh có các ứng dụng hỗ trợ và nhu cầu thông tin tương đồng.

Cấp 2: Các phân vùng kinh doanh (Business Domain) bao gồm các khả năng kinh doanh liên quan đến các kỹ năng và kiến thức nhất định được nhìn nhận trong lĩnh vực ngân hàng.

Cấp 3: Các phân vùng dịch vụ (Service Domain) là cấp chi tiết nhất, dùng để phân định các tính năng duy nhất, riêng biệt.

Trong phiên bản 5.0 (phiên bản mới nhất) của mô hình dịch vụ BIAN có các lĩnh vực kinh doanh sau:

• Dữ liệu tham chiếu (ReferenceData): Bao gồm các phân vùng kinh doanh (và phân vùng dịch vụ con) đảm nhận việc truy cập tới thông tin nội bộ cũng như thông tin bên ngoài.

• Bán hàng và dịch vụ (Sales&Service): Bao gồm các phân vùng kinh doanh hỗ trợ việc giao tiếp với khách hàng của ngân hàng qua tất cả các kênh để bán hàng và phục vụ các sản phẩm dịch vụ của ngân hàng.

• Vận hành (Operations&Execution): Là một mảng lớn bao gồm tất cả các khía cạnh của việc xử lý giao dịch, gồm cả những hoạt động liên quan đến các sản phẩm cụ thể như tiền gửi, tiền vay, thẻ, tài trợ thương mại…

• Vận hành sản phẩm chéo (Cross Product Operations): Bao gồm các hoạt động xung quanh, liên quan đến sản phẩm như thanh toán, quản lý tài khoản, quản lý tài sản bảo đảm, các dịch vụ chung cho hoạt động vận hành.

• Rủi ro và tuân thủ (Risk & Compliance): Bao gồm các phân tích kinh doanh và phân tích khách hàng, đánh giá hiệu quả kinh doanh và các loại rủi ro (rủi ro tín dụng, thị trường, tác nghiệp và tuân thủ).

• Hỗ trợ kinh doanh (Business Support): bao gồm các hoạt động quản lý và hỗ trợ thường có trong phần lớn các doanh nghiệp như quản trị, tài chính, nhân sự, hệ thống và hạ tầng

Để thuận tiện cho việc sử dụng, mô hình dịch vụ của BIAN có thể được sắp xếp lại theo chuỗi giá trị của ngân hàng (phân thành các công đoạn phát triển sản phẩm, quản lý nguồn lực, vận hành, cung cấp sản phẩm cho khách hàng, …) (hình dưới).

Chúng ta có thể xem xét từng ứng dụng hiện có, ánh xạ nó với các vùng dịch vụ tương ứng của BIAN (các chức năng kinh doanh cụ thể) trong công cụ quản lý kiến trúc doanh nghiệp. Điều này cho chúng ta một cái nhìn rõ ràng về các hệ thống đang cung cấp những tính năng tương tự hoặc chồng lấn lên nhau, có thể được tối ưu hoá, đồng thời đem lại khả năng đánh giá các giải pháp mới một cách nhất quán.

Với mục đích tối ưu hoá các hệ thống lõi hay hệ thống do lịch sử để lại, các phân vùng dịch vụ được dùng như một khung ổn định xác định các chức năng không chồng lấn để ánh xạ tới từng ứng dụng, từ đó chỉ ra những bất cập. Phần lớn các ứng dụng legacy bao gồm nhiều phân vùng dịch vụ khác nhau, vì thế không thể so sánh các ứng dụng đó với nhau. Do các phân vùng dịch vụ theo định nghĩa của BIAN không chồng lấn nên khi ánh xạ với chúng, có thể so sánh chức năng của các ứng dụng và tổng hợp thông tin về phạm vi của các ứng dụng để xác định vai trò của chúng trong dài hạn. Kết quả phân tích có thể cho thấy 3 vấn đề sau:

- Trùng lắp: Vấn đề dễ thấy nhất là hai hay nhiều ứng dụng thực hiện cùng một chức năng của cùng một phân vùng dịch vụ. Đây là dấu hiệu cho thấy có thể có ứng dụng dư thừa.

- Thiếu hụt: Danh mục phân vùng dịch vụ có thể bao gồm những tính năng mà không có ứng dụng hiện có nào hỗ trợ và điều đó sẽ thể hiện trên bản đồ ánh xạ. Có thể thấy cả những ứng dụng nào là ứng viên tốt nhất có thể mở rộng để đáp ứng các nhu cầu chưa được hỗ trợ.

- Định hướng sai lệch: Vấn đề thường gặp của các ứng dụng vượt mong đợi. Được phát triển để hỗ trợ một chức năng nào đó nhưng lại được mở rộng sang các lĩnh vực khác mà nó có thể cung cấp giải pháp đơn giản, chi phí thấp. Tuy nhiên, một ứng dụng được thiết kế để hỗ trợ một chức năng có thể gặp vấn đề khi cố hỗ trợ các chức năng khác và có thể xung đột với các yêu cầu vận hành.

Ánh xạ danh mục ứng dụng có thể cung cấp hiểu biết sâu sắc về sự trùng lắp hay thiếu hụt của danh mục. Phần lớn các ngân hàng có sự dư thừa đáng kể ứng dụng do quá trình triển khai các hệ thống rời rạc hay sáp nhập các ngân hàng (khi các hệ thống không được thay thế hoàn toàn mà vẫn còn tiếp tục hoạt động đồng thời). Sự dư thừa này cần được đánh giá chi tiết hơn để xác định mức độ trùng lắp chức năng và thông tin ảnh hưởng thế nào tới việc đồng bộ hệ thống hay làm phát sinh chi phí không cần thiết:

+ Trùng lắp logic ứng dụng là việc hai hay nhiều ứng dụng thực hiện cùng một chức năng bằng các logic khác nhau và có thể dẫn đến sự không nhất quán trong vận hành hệ thống. Ảnh hưởng có thể nhỏ hay có thể khiến ngân hàng phát sinh chi phí đáng kể, làm giảm lợi nhuận và tạo ra rủi ro.

+ Trùng lắp dữ liệu kinh doanh là khi hai hay nhiều ứng dụng cùng duy trì cái nhìn độc lập về cùng một thông tin kinh doanh và cần đồng bộ. Các thay đổi thông tin ở nơi này có thể không được phản ánh ở những chỗ khác và dẫn đến lỗi. Các cập nhật có thể bị mất (hay bị ghi đè) và khả năng tổng hợp, phân tích và phản ứng với thông tin cũng bị ảnh hưởng.

Đôi khi hai ứng dụng cùng liên quan tới một phân vùng dịch vụ nhưng khi phân tích kỹ thì thấy chúng không trùng lắp vì liên quan tới những logic hay thông tin khác nhau trong phân vùng dịch vụ đó. Nhưng trong phần lớn các trường hợp , mức độ trùng lắp giữa các ứng dụng có thể làm phát sinh chi phí đồng bộ lớn hơn nhiều so với dự kiến. Phần lớn các ngân hàng biết rõ họ có thể có những ứng dụng trùng lắp nhưng thường cho rằng những hệ thống đó đáp ứng những nhu cầu khác nhau trong cùng một phân vùng dịch vụ. Chẳng hạn như hai hệ thống quản lý thông tin tham chiếu khách hàng có thể quản lý những phân khúc khách hàng khác nhau, các hệ thống tính hoa hồng cho những bộ phận nhân lực khác nhau. Trong trường hợp đó việc tối ưu hóa các ứng dụng chồng chéo sẽ không đem lại nhiều lợi ích.

Mô hình dịch vụ của BIAN không chỉ dừng lại ở mức khái quát mà còn được phát triển chi tiết thành các dịch vụ nhỏ, có thể hỗ trợ việc định nghĩa API. Nhiều ngân hàng đã triển khai các công nghệ để tạo ra những dịch vụ kết nối tới những hệ thống do lịch sử để lại, chẳng hạn như trục tích hợp (ESB). Tuy nhiên, nếu không có thiết kế kiến trúc tốt, rất dễ xây dựng những dịch vụ chi tiết, cung cấp khả năng truy cập các hàm và các tập dữ liệu khá nhỏ. Những dịch vụ đó giúp nâng cao khả năng phát triển ứng dụng mới bằng cách cung cấp các tiện ích có thể dùng lại. Tuy nhiên cách làm đó có một số hạn chế như sau:

- Việc tái sử dụng phần mềm không phải lúc nào cũng đồng nghĩa với tối ưu hóa và sử dụng lại các tính năng kinh doanh;

- Các thư viện dịch vụ phức tạp và không có cấu trúc: Các dịch vụ được chia nhỏ có thể hình thành nên các bộ sưu tập các dịch vụ chồng chéo, khó phân loại, duy trì và tham chiếu;

- Các dịch vụ riêng biệt: Các dịch vụ được định nghĩa thường bao gồm những tính năng cụ thể, riêng có của các hệ thống cũ, gây khó khăn cho việc ghép nối để tạo ứng dụng mới bằng những dịch vụ từ các ứng dụng khác nhau;

- Khó theo dõi, đánh giá các chức năng và dữ liệu: Cũng giống như vấn đề tối ưu hoá danh mục ứng dụng đã nêu ở trên, nếu chỉ đơn giản tạo ra dịch vụ để các ứng dụng khác có thể truy cập chức năng của những hệ thống cũ mà không có thiết kế phù hợp thì rất dễ xảy ra tình trạng trùng lắp, xung đột giữa các hệ thống dịch vụ đó.

Việc sử dụng các phân vùng dịch vụ của BIAN như một bộ khung để phát hiện những trùng lắp và các vấn đề về đồng bộ với các ứng dụng chồng chéo có thể mở rộng, phân tích sâu tới mức các dịch vụ dùng chung. Các phân vùng dịch vụ xác định những vùng chức năng không chồng lấn trong hoạt động kinh doanh. Tương ứng với chúng, các hoạt động dịch vụ liên kết định ra những hoạt động dịch vụ không chồng lấn. Vì vậy, chúng ta có thể sử dụng khung dịch vụ của BIAN để phân tích và dần chuyển đổi các hệ thống cũ thành các hệ thống cấu phần hóa, thực hiện việc chuyển đổi dần toàn bộ hệ thống theo các bước hợp lý, phù hợp với chiến lược kinh doanh tổng thể.

Việc định nghĩa các chức năng công nghệ tương ứng với từng phân vùng dịch vụ trong hoạt động kinh doanh cũng giúp các ngân hàng chuẩn bị cho những sáng tạo trong tương lai. Sự xuất hiện của các công ty Fintech đang tạo ra những kỳ vọng mới cho khách hàng, hình thành nên những mô hình kinh doanh mới có thể cạnh tranh trực tiếp với ngân hàng. Các ngân hàng không thể không thay đổi để nắm bắt những cơ hội mới, đáp ứng nhu cầu của khách hàng. Việc hợp tác với bên ngoài, hình thành nên các hệ sinh thái mới trong kỷ nguyên ngân hàng số không chỉ đòi hỏi thay thế cách tiếp cận của các ứng dụng nguyên khối mà còn cần hướng tới mô hình API mở. Khung dịch vụ của BIAN có thể đóng vai trò định hướng, kết hợp với các tiêu chuẩn trên thị trường để tạo nên kiến trúc doanh nghiệp tiên tiến, đáp ứng nhu cầu của thị trường và những xu hướng kỹ thuật mới.

Ứng dụng tại ngân hàng

PNC Financial Corp, một trong 10 ngân hàng hàng đầu của Mỹ là ngân hàng đầu tiên báo cáo về tiến độ triển khai ứng dụng các mô hình BIAN. Ứng dụng đầu tiên của họ là sử dụng khung tiêu chuẩn của BIAN để đổi mới hệ thống ngân hàng lõi. Với các ngân hàng lớn, để bắt đầu công cuộc chuyển đổi cần phải biết rõ lộ trình, phân tích môi trường, đưa tất cả mọi người vào cùng một hiểu biết chung. Theo ông Steve Van Wyk, phụ trách công nghệ và vận hành của PNC, BIAN đang giúp ngân hàng với tổng tài sản 320 triệu đô la như PNC cung cấp một ngôn ngữ chung và từ vựng chung cho toàn ngân hàng và cả các đối tác (nghiệp vụ cũng như công nghệ). Cũng giống như hầu hết các ngân hàng lớn, các vụ sáp nhập trong nhiều năm đã để lại cho PNC một “mạng nhện” các hệ thống ngân hàng lõi khác nhau, trong đó có Hogan – một sản phẩm đang sắp hết thời. Các hệ thống do lịch sử để lại đã được tuỳ biến trong nhiều năm và trở nên rất tốn kém để duy trì. Ông Van Wyk nói rằng khung BIAN sẽ giúp họ bắt đầu công cuộc “tiến hóa” các hệ thống ngân hàng lõi mà không cần phải thay đổi lớn. Chuyển đổi các hệ thống lõi thành các khung cấu phần hoá như mô hình của BIAN cho phép ngân hàng thay đổi dần dần, theo các bước logic, phù hợp với chiến lược kinh doanh chung. Và khi nhiều ứng dụng cùng thực hiện một việc giống nhau, khung BIAN giúp PNC loại bớt những ứng dụng dư thừa, không còn phù hợp.

BIAN cũng giúp PNC và các ngân hàng khác trong việc lựa chọn nhà cung cấp. Khi PNC chuẩn bị thay thế engine thanh toán, họ bắt đầu với việc viết ra tất cả các yêu cầu và họ thấy có hàng trăm yêu cầu khác nhau. Trong nhiều năm engine thanh toán đã mở rộng và đảm nhiệm cả những hoạt động ngoài phạm vi của nó. Vì thế, PNC nhận thấy việc so sánh các giải pháp trở thành một “điệp vụ bất khả thi”. Nhóm BIAN phân tích ứng dụng thanh toán và xác định tất cả các tính năng kinh doanh BIAN trong yêu cầu ban đầu và họ thấy có khoảng 50 tính năng. Sau đó họ thảo luận với các bộ phận nghiệp vụ xem trong số các tính năng đó, những tính năng nào thực sự là tính năng thanh toán. Kết quả là họ rút gọn số yêu cầu cho engine thanh toán xuống con số 10, những tính năng còn lại cần nằm ở các hệ thống khác. Điều đó đã giúp PNC lựa chọn nhà cung cấp một cách dễ dàng hơn.

Hơn thế, kiến trúc hướng dịch vụ theo định nghĩa của BIAN còn giúp PNC thay đổi nhanh chóng. Ông Van Wyk nói rằng “Nếu bạn xem xét các giải pháp lớn cho doanh nghiệp, bạn biết chi phí tích hợp tốn kém như thế nào và bạn sẽ bị khoá cứng vào một giải pháp”. Ông nói khung BIAN có thể làm thay đổi thị trường giải pháp cho doanh nghiệp và “Tôi thấy sẽ tới thời điểm các dịch vụ BIAN có thể được mua từ bất kỳ ai có thể làm được sản phẩm tốt nhất và đó có thể không phải là SAP, Oracle hay bất kỳ nhà cung cấp hiện tại nào. Đó có thể là một nhà cung cấp rất sáng tạo, có cái nhìn khác biệt hoàn toàn. Khi đó tôi có thể mua sản phẩm và đặt nó vào môi trường của tôi vì nó tương thích với khung BIAN”. Đó không phải là một mong ước hão huyền trong lý tưởng của một vài người. SAP là một trong những nhà cung cấp đang làm cho các sản phẩm của họ tương thích với BIAN. Vì khung dịch vụ của BIAN xác định cách các dịch vụ làm việc với nhau nên các dịch vụ tương thích với BIAN có thể cùng tồn tại mà không mất nhiều công sức để tích hợp. Trong môi trường CNTT hoàn toàn tương thích với khung BIAN, ngân hàng có thể dễ dàng loại bỏ các dịch vụ cũ để thay thế bằng dịch vụ mới.

Ngoài việc chuẩn hoá hệ thống hiện có, PNC còn tích cực tham gia các hoạt động nghiên cứu, đổi mới công nghệ bằng các chuẩn của BIAN. API mở là xu thế quan trọng trong ngành ngân hàng nhưng việc chuẩn hoá API là một thách thức lớn. Nếu mỗi ngân hàng và nhà cung cấp đều có chuẩn API riêng của mình thì các đơn vị không thể hợp tác thành công. Những lập trình viên không thể xây dựng các giao tiếp khác nhau cho từng ngân hàng. Mô hình dịch vụ của BIAN là một cơ sở tốt để hình thành các API chuẩn. Tháng 5/2017, dự án hợp tác giữa trường Heinz College của đại học Carnegie Mellon với PNC Bank, BIAN và IFX (International Financial eXchange) đã hoàn thành nhiệm vụ xây dựng một bản thử nghiệm về API mở trong ngân hàng, tương thích với quy định PSD2 của EC.

Ứng dụng các mô hình của BIAN trong đào tạo

Đại học Quản lý Singapore (SMU) là thành viên của BIAN và rất tích cực trong việc sử dụng mô hình dịch vụ BIAN trong công tác đào tạo, nghiên cứu. SMU đã triển khai một chương trình dài hạn với tên gọi “SMU Bank for Financial Services Education” (Ngân hàng SMU cho đào tạo dịch vụ tài chính), hay còn gọi là “SMU Teaching Bank” (hay “SMU tBank”).

tBank của SMU được xây dựng từ con số không, dựa trên các thông lệ thực hành tốt nhất về kiến trúc ngân hàng, trong đó có mô hình dịch vụ của BIAN. tBank được lắp ghép bằng các phần mềm do chính sinh viên của SMU xây dựng với sản phẩm của các hãng công nghệ khác nhau để minh hoạ những tình huống thực tế trên thị trường tài chính ngân hàng, chẳng hạn như: thay thế hệ thống core banking, sáp nhập các ngân hàng (khi các sản phẩm cùng loại và khác loại của các nhà cung cấp khác nhau cùng tồn tại). Ngoài ra, tBank cũng là nền tảng phục vụ việc hợp tác với các ngân hàng và các nhà cung cấp giải pháp để nuôi dưỡng các sáng kiến, phát minh mới. Cơ cấu phát triển của tBank khá vững chắc nhưng vẫn đảm bảo sự hài hoà và linh hoạt, trong đó nhà trường xây dựng một khung tiến trình hợp nhất để định hướng cho tất cả các ứng dụng, thiết kế các dịch vụ ngân hàng được hình thành dựa trên các định nghĩa dịch vụ của BIAN, các dự án đỉnh cao của học viên sau đại học góp phần xác định kiến trúc giải pháp cho các kênh dịch vụ, các dự án của sinh viên đại học cung cấp phần mềm cho các kênh giao dịch được hình thành dựa trên kiến trúc giải pháp đã được xây dựng. Các phần mềm giao dịch do sinh viên đại học phát triển được tích hợp với kiến trúc của tBank và được sử dụng để phục vụ nhu cầu thực hành trong các khoá học của cả sinh viên đại học và sau đại học. Sinh viên dùng tBank để học về các quy trình giao dịch ngân hàng như mở tài khoản, đánh giá tín dụng, trả nợ vay, chuyển khoản, mua bán ngoại tệ, thanh toán qua điện thoại di động, xác thực hai yếu tố, quản lý mạng lưới ATM, đưa ra các khuyến mại thời gian thực cho khách hàng cụ thể. Các câu hỏi trong ngân hàng thực hành giúp đánh giá hiểu biết của sinh viên về các quy trình giao dịch ngân hàng cũng như hạch toán kế toán. Về công nghệ, sinh viên có thể sử dụng tBank để học về các kỹ thuật tích hợp như kiến trúc hướng dịch vụ (ServiceOrientedArchitecture), các phần mềm lớp giữa. Các bài tập thực hành công nghệ bao gồm xây dựng các cấp phần tích hợp để cho phép các ứng dụng khác nhau trong ngân hàng trao đổi, minh họa những gì thực sự diễn ra ở lớp tích hợp khi một giao dịch như chuyển khoản được thực hiện. Hơn thế, sinh viên có thể dùng phiên bản thu gọn của tBank được cài đặt trên máy tính xách tay để thể hiện hiểu biết của họ về 3 nguyên lý kiến trúc chính: khả năng chịu lỗi (chuyển hoạt động sang hệ thống dự phòng), xử lý đồng thời (xử lý yêu cầu của số lớn người dùng) và hiệu năng (thời gian phản hồi nhanh). Hệ thống cũng đóng vai trò quan trọng trong các công tác nghiên cứu chuyên sâu như kiến trúc doanh nghiệp (Enterprise Architecture), các khả năng ứng dụng thực tế của các lưới dữ liệu trong bộ nhớ (in-memory data grid). Kế hoạch dài hạn của SMU là triển khai tBank lên đám mây và mở hệ thống để các trường đại học khác có thể tham gia sử dụng. Tháng 10/2014 đã có đối tác đầu tiên ngoài SMU tham gia sử dụng tBank là Trường đại học công nghệ Ngee Ann.

Tuy mô hình dịch vụ của BIAN vẫn cần bổ sung, chỉnh sửa thêm nhưng những kết quả ứng dụng ban đầu cho thấy một tương lai hứa hẹn. Những kết quả phân tích không chỉ dừng lại ở mức lý thuyết mà đã thực sự đi vào cuộc sống, góp phần đắc lực cho quá trình hiện đại hóa hệ thống công nghệ ở ngân hàng PNC, cho phép trường đại học SMU tự dựng lên một hệ thống giao dịch ngân hàng hoàn chỉnh. Cùng với các thông tin khích lệ đó, việc Mạng lưới Kiến trúc ngành Ngân hàng cung cấp miễn phí mô hình dịch vụ là một điểm cộng hấp dẫn các ngân hàng, công ty công nghệ và tổ chức nghiên cứu tại Việt Nam tìm hiểu, ứng dụng những tri thức quý báu của BIAN.