Legacy System

Trong mọi dự án bạn sẽ gặp một cái tên được nhắc kèm tiếng thở dài. Một phần mềm viết từ 2009, chạy trên máy chủ đặt ở tầng hầm, người viết nó nghỉ hưu năm 2016, tài liệu là một file Word thiếu ba chương. Nó xấu, nó chậm, và nó đang giữ toàn bộ dữ liệu hợp đồng của công ty.

Hệ thống cũ tồn tại được lâu như vậy vì nó vẫn đang chạy đúng. Đó là lý do khiến việc thay thế nó khó hơn viết mới rất nhiều.

Vì sao không bỏ đi cho xong

• Nghiệp vụ nằm trong code chứ không nằm trong tài liệu. Hai mươi năm ngoại lệ, quy định thay đổi, mẹo vặt của người dùng đều đã bị lập trình vào đó.
• Rủi ro không cân xứng. Thay hệ thống sổ cái mà sai một tuần là hậu quả lớn hơn nhiều so với cái lợi của giao diện đẹp.
• Ràng buộc pháp lý về lưu trữ dữ liệu nhiều năm.
• Không ai muốn ký tên vào quyết định tắt nó.

Vì vậy chuyện thường thấy là hệ thống mới mọc bao quanh hệ thống cũ, gặm dần từng phần nghiệp vụ. Cách làm này có tên là strangler pattern, và nó thực tế hơn nhiều so với phương án thay một phát ăn ngay.

Ràng buộc thật khi tích hợp

Đây là phần BA cần biết trước khi hứa hẹn gì với khách:

• Không có API. Cách trao đổi khả dĩ là xuất file. File văn bản cố định độ dài, không có dấu phân cách, mỗi trường chiếm đúng bao nhiêu ký tự thì phải tra tài liệu. Đẩy qua SFTP hoặc thư mục dùng chung.
• Chỉ chạy theo lô ban đêm. Hệ thống có cửa sổ khoá sổ cuối ngày, ví dụ 22h tới 1h sáng, trong khoảng đó không truy vấn được. Mọi yêu cầu kiểu dữ liệu cập nhật tức thì phải bị từ chối ngay từ giai đoạn phân tích.
• Tiếng Việt lưu theo bảng mã đời cũ, không phải Unicode. Chuyển đổi sai là tên khách hàng thành một dãy ký tự lạ, và lỗi này thường chỉ lộ ra ở những cái tên có dấu nặng.
• Môi trường test giống thật thì gần như không có. Có thì cũng là bản sao từ năm ngoái, thiếu dữ liệu.
• Truy vấn nặng vào giờ hành chính làm chậm nghiệp vụ quầy, nên đội vận hành sẽ yêu cầu chạy ngoài giờ.
• Người hiểu hệ thống chỉ còn đúng một người. Thường sắp nghỉ hưu, và rất bận.
• Đổi một dòng cấu hình cũng phải xin lịch, và lịch gần nhất là sau kỳ khoá sổ quý.

Ví dụ thực tế

"Cho khách xem dư nợ theo thời gian thực." Yêu cầu từ phía kinh doanh của một công ty tài chính tiêu dùng gọn đúng một dòng như vậy, cho một app tra cứu khoản vay. Hệ thống lõi thì là phần mềm chạy trên nền tảng cũ, mỗi đêm chốt số và xuất ra file văn bản đặt vào thư mục SFTP lúc khoảng 2h sáng.

Kết quả sau khi phân tích: app hiển thị dư nợ tính tới cuối ngày hôm trước, kèm dòng chữ ghi rõ mốc thời gian, và các khoản vừa thanh toán trong ngày được ghi nhận riêng ở một mục chờ cập nhật. Phía kinh doanh ban đầu không hài lòng. Nhưng khi BA đưa ra con số — muốn thời gian thực thì phải mở API trên hệ thống lõi, ước tính hơn 6 tháng và một khoản ngân sách riêng — thì mọi người đồng ý với phương án hiện tại và đưa việc mở API vào kế hoạch năm sau.

Mẹo khi đi làm

Khi hệ thống cũ không có tài liệu, ba nguồn thông tin đáng tin theo thứ tự: dữ liệu thật trong database, người dùng lâu năm, và cuối cùng mới tới tài liệu còn sót lại. Xin quyền đọc một bản sao dữ liệu và tự đi tìm câu trả lời — một buổi chiều ngồi với dữ liệu thật hơn mười buổi phỏng vấn.

Và ghi rõ ngày với nguồn của từng thông tin bạn moi được, kể cả khi nguồn là "anh Tuấn bảo thế". Người hỏi lại bạn sau này thường chính là bạn, và lúc đó bạn sẽ không nhớ nổi mình nghe từ đâu.