Vì sao bề mặt tích hợp, chứ không phải ứng dụng, quyết định một dự án ngân hàng có vượt qua bản phát hành đầu tiên, và cần chốt gì trước khi cutover.
Chỉ là thông tin chung, cập nhật tại thời điểm đăng bài, không phải tư vấn pháp lý hay quy định. Ghi chú đầy đủ ở cuối bài.
Phần mềm ngân hàng hiếm khi được xây dựng một cách biệt lập. Một dịch vụ mới phải kết nối với hệ thống lõi, danh tính, hạ tầng thanh toán, nền tảng dữ liệu, các kiểm soát rủi ro và quy trình vận hành vốn đang gánh những khối lượng công việc trọng yếu, theo lịch phát hành được thiết lập từ rất lâu trước khi dự án ra đời.
Đó là lý do bản thân ứng dụng hiếm khi là phần khó. Bề mặt tích hợp mới chính là dự án: một đội ngũ có thể xây xong tính năng trong sáu tuần rồi mất sáu tháng để khám phá xem nó chạm vào những gì, và con số thứ hai mới quyết định bản phát hành có hạ cánh an toàn hay không. Bốn câu hỏi sẽ cho bạn biết sớm mình đang đối mặt với con số nào. Về phía thương mại, gồm phạm vi, mô hình hợp tác và các dịch vụ, xem trang Finance & Banking engineering của chúng tôi.
Một kế hoạch tích hợp đáng tin cậy bắt đầu từ khám phá (discovery), không phải từ kiến trúc đích. Ai đề xuất trạng thái đích ngay trong buổi họp đầu tiên là đang đưa bạn một mẫu có sẵn gắn logo của bạn, vì những ràng buộc thực sự sẽ định hình thiết kế còn chưa được xem xét.
Đáng đánh giá discovery qua những gì nó tạo ra, không phải qua thời gian nó kéo dài. Một bộ đầu ra hợp lý gồm:
Mô hình ngữ cảnh hệ thống (system context model) thể hiện ranh giới của thay đổi;
Bản đồ phụ thuộc phân tách các lời gọi đồng bộ với xử lý batch;
Yêu cầu phi chức năng có con số cụ thể, không phải tính từ;
Sơ đồ luồng dữ liệu với một người sở hữu gắn cho từng nguồn;
Sổ đăng ký rủi ro tiếp tục sống trong giai đoạn triển khai thay vì khép lại cùng discovery; và
Kế hoạch chuyển đổi bao gồm cutover, rollback và hỗ trợ.
Dòng về batch đáng được chú ý đặc biệt trong công việc core banking. Một nền tảng lõi có cửa sổ xử lý qua đêm hoạt động hoàn toàn khác với một API có thể gọi bất cứ lúc nào, và một thiết kế giả định tính sẵn sàng thời gian thực trên một hệ thống ràng buộc bởi batch sẽ hỏng theo cách chỉ lộ ra vào cuối tháng. Các đội đã làm việc bên trong nền tảng core banking và các lớp open banking API đều hỏi về cửa sổ batch từ sớm, vì họ đã từng vấp phải nó.
Tuân thủ không thể nằm trong một tài liệu riêng chỉ được xem xét gần cuối. Mô hình triển khai cần cho thấy con đường của một yêu cầu: từ một tuyên bố chính sách, đến một quyết định kiến trúc, đến một hạng mục backlog có tiêu chí nghiệm thu, đến một bài kiểm thử, rồi đến một bằng chứng phát hành, truy vết được theo cả hai chiều khi sau này có người hỏi vì sao một kiểm soát tồn tại.
Trên thực tế, điều này có nghĩa là các chủ sở hữu về Công nghệ, Rủi ro, An ninh và Tuân thủ của tổ chức tham gia vào các quyết định thiết kế và phát hành liên quan đến họ, thay vì chỉ rà soát kết quả sau đó. Chúng tôi mô tả đây là một mẫu quản trị đáng khuyến nghị, không phải khẳng định mọi dự án đều chạy cùng một quy trình phê duyệt; cấu trúc đúng là cấu trúc phù hợp với khung quản lý thay đổi của chính ngân hàng. Cùng bài toán bằng chứng này, áp dụng cho các workflow có AI hỗ trợ, là chủ đề của bài RegTech và AI thực sự giao thoa ở đâu.
Kỳ vọng về khả năng chống chịu vận hành (operational resilience) tại Hồng Kông, được nêu trong tài liệu giám sát của HKMA, xoay quanh khả năng tiếp tục cung cấp các hoạt động trọng yếu xuyên suốt gián đoạn. Với một dự án tích hợp, điều đó quy về năm điểm cụ thể, và cả năm đều là câu hỏi về diễn tập chứ không phải về tài liệu:
Phương án dự phòng (fallback) là gì khi thành phần mới không khả dụng;
Rollback được thực hiện thử ra sao, chứ không chỉ được viết ra;
Có những khả năng quan sát (observability) nào trên thành phần mới và trên các thành phần nó chạm tới;
Ai chịu trách nhiệm sự cố, theo ca trực nào; và
Lần gần nhất khôi phục được kiểm thử đầu cuối là khi nào.
Câu hỏi hé lộ nhiều nhất để hỏi bất kỳ đội ngũ nào, nội bộ hay bên ngoài, là họ sẽ chạy cutover hai lần như thế nào: một lần như buổi diễn tập có thực hiện rollback thật, và một lần chạy thật. Những đội đã từng làm sẽ trả lời ngay và chi tiết, thường kèm câu chuyện về lần diễn tập đã cứu họ. Những đội chưa làm sẽ nói về kế hoạch.