Hệ thống cũ (legacy system) là phần mềm vẫn đang chạy nghiệp vụ quan trọng nhưng đã khó bảo trì, khó tích hợp và phụ thuộc vào công nghệ hoặc con người đang mất dần. Hiện đại hoá có bốn hướng chính: giữ và bọc API bên ngoài, thay bằng gói phần mềm thương mại, viết lại toàn bộ, hoặc thay thế dần từng phần theo mẫu "bóp nghẹt" (strangler fig). Hướng cuối thường an toàn nhất với hệ thống lớn.
Lựa chọn sai phổ biến nhất là viết lại toàn bộ từ đầu với niềm tin rằng lần này sẽ làm đúng. Hệ thống cũ chứa hàng chục năm quy tắc nghiệp vụ tích luỹ, nhiều quy tắc không ai còn nhớ lý do; viết lại nghĩa là phải khám phá lại tất cả, trong khi hệ thống cũ vẫn phải được bảo trì song song. Bài này giúp đánh giá hệ thống hiện có và chọn chiến lược theo rủi ro.
"Cũ" không đồng nghĩa với "hỏng"
Một hệ thống viết bằng ngôn ngữ lập trình thế hệ trước, chạy trên máy chủ tại chỗ, giao diện thô, nhưng xử lý chính xác hàng triệu giao dịch mỗi năm không phải là vấn đề cần giải quyết chỉ vì nó cũ. Nhiều ngân hàng và hãng bảo hiểm trên thế giới vẫn chạy nghiệp vụ lõi trên các hệ thống viết từ nhiều thập kỷ trước vì chúng ổn định và đã được kiểm chứng qua mọi tình huống.
Hệ thống trở thành vấn đề khi xuất hiện một trong các rủi ro cụ thể: rủi ro con người — chỉ còn một hai người hiểu mã nguồn, và họ sắp nghỉ hưu hoặc nghỉ việc; rủi ro công nghệ — hệ điều hành, cơ sở dữ liệu hoặc phần cứng hết hỗ trợ, không còn bản vá bảo mật; rủi ro nghiệp vụ — mỗi thay đổi nhỏ mất hàng tháng, không kết nối được với kênh bán mới, đối tác mới; rủi ro tuân thủ — không đáp ứng được yêu cầu pháp lý mới về dữ liệu, hoá đơn, báo cáo.
Ở Việt Nam, kịch bản quen thuộc là phần mềm quản lý do một lập trình viên hoặc công ty nhỏ viết riêng cho doanh nghiệp từ mười lăm, hai mươi năm trước, chạy trên một máy chủ đặt tại văn phòng, mã nguồn không có tài liệu, và người viết đã chuyển nghề. Phần mềm vẫn chạy tốt cho đến ngày cần kết nối với sàn thương mại điện tử, hoặc máy chủ hỏng mà không ai cài lại được.
Bốn chiến lược hiện đại hoá
Các khung phân loại của hãng tư vấn có nhiều biến thể với năm, sáu hay bảy lựa chọn; bốn hướng dưới đây là phần cốt lõi mà các khung đều có.
| Chiến lược | Cách làm | Phù hợp khi | Rủi ro chính |
|---|---|---|---|
| Giữ và bọc API | Giữ nguyên hệ thống, xây lớp API hoặc lớp tích hợp phía trước để các hệ thống mới giao tiếp | Lõi ổn định, vấn đề chủ yếu là kết nối; cần kết quả nhanh | Không giải quyết rủi ro con người và công nghệ; nợ kỹ thuật vẫn còn |
| Thay bằng gói phần mềm | Chuyển sang ERP hoặc phần mềm thương mại, chấp nhận điều chỉnh quy trình | Nghiệp vụ không đặc thù, thị trường có sản phẩm trưởng thành | Mất quy tắc đặc thù có giá trị; chi phí chuyển đổi dữ liệu và đào tạo |
| Viết lại toàn bộ | Xây hệ thống mới từ đầu, chuyển một lần | Hệ thống nhỏ, quy tắc nghiệp vụ được hiểu rõ và có tài liệu | Kéo dài, đội ngũ phải duy trì hai hệ thống, dễ đuổi theo mục tiêu di động |
| Thay thế dần (strangler fig) | Xây chức năng mới bên cạnh, chuyển dần từng phần, hệ thống cũ thu hẹp tới khi tắt hẳn | Hệ thống lớn, không chấp nhận được rủi ro chuyển một lần | Thời gian tổng dài; cần lớp định tuyến và đồng bộ dữ liệu tạm thời |
Các chiến lược không loại trừ nhau. Một lộ trình thường gặp là bọc API trước để giải quyết nhu cầu tích hợp cấp bách, đồng thời dùng chính lớp API đó làm điểm chuyển hướng cho chiến lược thay thế dần.
Vì sao viết lại toàn bộ hay thất bại
Năm 2000, Joel Spolsky viết bài "Things You Should Never Do, Part I", lấy ví dụ quyết định viết lại trình duyệt Netscape từ đầu, khiến công ty không phát hành được phiên bản lớn nào trong khoảng ba năm trong khi đối thủ chiếm thị trường. Lập luận của ông: mã nguồn cũ trông xấu nhưng chứa vô số bản sửa lỗi cho những tình huống thực tế đã gặp; vứt bỏ nó là vứt bỏ tri thức tích luỹ. Bài viết có phần cường điệu và đã bị phản biện, nhưng cơ chế ông mô tả lặp lại ở rất nhiều dự án.
Cơ chế thứ hai là mục tiêu di động. Trong lúc đội mới viết lại, nghiệp vụ vẫn thay đổi và hệ thống cũ vẫn phải được cập nhật. Mỗi thay đổi phải làm hai lần, hoặc hệ thống mới tụt lại phía sau. Dự án kéo dài, ngân sách vượt, áp lực buộc phải chuyển sang hệ thống mới khi nó chưa đủ chức năng.
Cơ chế thứ ba là quy tắc ẩn. Hệ thống cũ làm những việc mà không ai ghi lại: làm tròn theo một cách đặc biệt mà đối tác lớn đã quen, bỏ qua một loại giao dịch vào ngày cuối tháng, tự động gộp hai mã khách hàng có lịch sử đặc biệt. Hệ thống mới viết theo yêu cầu "như đã hiểu" sẽ bỏ sót, và sai lệch chỉ lộ ra sau khi chạy thật. Viết lại chỉ hợp lý khi hệ thống đủ nhỏ để kiểm chứng toàn bộ hành vi, hoặc có bộ kiểm thử bao phủ tốt.
Mẫu strangler fig từng bước
Martin Fowler đặt tên mẫu này năm 2004, lấy hình ảnh cây đa bóp cổ (strangler fig) mọc quanh cây chủ cho tới khi thay thế hoàn toàn. Trình tự triển khai điển hình như sau.
- Đặt lớp định tuyến phía trước: mọi yêu cầu từ người dùng và hệ thống khác đi qua một lớp trung gian, ban đầu chuyển hết về hệ thống cũ.
- Chọn lát cắt đầu tiên: một chức năng có ranh giới rõ, giá trị cao, rủi ro vừa phải — ví dụ tra cứu đơn hàng, cổng cho đại lý — thay vì lõi kế toán.
- Xây chức năng mới trên nền tảng mới, đọc dữ liệu từ hệ thống cũ qua API hoặc bản sao đồng bộ.
- Chuyển hướng dần: lớp định tuyến đưa một phần người dùng sang chức năng mới, theo dõi, rồi tăng dần tới toàn bộ.
- Chuyển quyền làm chủ dữ liệu của lát cắt đó sang hệ thống mới khi đã ổn định; hệ thống cũ chuyển sang đọc hoặc ngừng dùng phần đó.
- Lặp lại với lát cắt tiếp theo, ưu tiên theo giá trị và rủi ro.
- Tắt hệ thống cũ khi phần còn lại đủ nhỏ, sau khi lưu trữ dữ liệu lịch sử theo yêu cầu.
Ưu điểm lớn nhất là mỗi bước mang lại giá trị dùng được và có thể dừng lại bất cứ lúc nào mà không mất trắng đầu tư. Nhược điểm là giai đoạn hai hệ thống cùng tồn tại kéo dài, đòi hỏi kỷ luật đồng bộ dữ liệu và một danh mục rõ ràng chức năng nào đang nằm ở đâu.
Đánh giá hệ thống cũ trước khi quyết định
Trước khi chọn chiến lược, cần một bản đánh giá trung thực. Các câu hỏi dưới đây nên được trả lời bằng văn bản, có bằng chứng.
- Có bao nhiêu người hiểu đủ mã nguồn để sửa lỗi nghiêm trọng, và họ còn gắn bó với doanh nghiệp trong bao lâu?
- Mã nguồn có đầy đủ, có quản lý phiên bản, có quyền sở hữu hợp pháp của doanh nghiệp không? Hợp đồng cũ có điều khoản nào hạn chế?
- Hệ điều hành, cơ sở dữ liệu, ngôn ngữ lập trình còn được nhà sản xuất hỗ trợ và vá lỗi bảo mật không?
- Thời gian trung bình để thực hiện một thay đổi nghiệp vụ nhỏ là bao lâu, và xu hướng đang tăng hay giảm?
- Những tích hợp nào doanh nghiệp đang cần mà hệ thống không đáp ứng được?
- Quy tắc nghiệp vụ nào là đặc thù có giá trị cạnh tranh, quy tắc nào chỉ là thói quen?
- Có bản sao lưu và quy trình khôi phục đã được thử thật gần đây không?
Câu hỏi cuối thường lộ ra rủi ro cấp bách nhất. Một hệ thống cũ chưa từng được thử khôi phục từ bản sao lưu là rủi ro liên tục kinh doanh cần xử lý ngay, trước cả khi bàn đến chiến lược hiện đại hoá.
Giảm rủi ro con người ngay cả khi chưa hiện đại hoá
Nhiều doanh nghiệp chưa có ngân sách hoặc chưa sẵn sàng thay hệ thống, nhưng rủi ro phụ thuộc vào một người có thể giảm ngay với chi phí thấp. Bước đầu tiên là đưa mã nguồn vào hệ thống quản lý phiên bản thuộc quyền doanh nghiệp, kèm hướng dẫn dựng lại môi trường chạy từ đầu trên một máy mới. Nếu chỉ người viết mới cài lại được, đó là rủi ro số một.
Bước thứ hai là khai quật quy tắc nghiệp vụ: ghi lại những tính toán quan trọng — giá vốn, chiết khấu, lương, hoa hồng — bằng ngôn ngữ nghiệp vụ, đối chiếu với kết quả thực tế của hệ thống. Tài liệu này có giá trị bất kể sau này chọn chiến lược nào, vì nó là yêu cầu đầu vào cho hệ thống thay thế và là tài liệu kiểm thử.
Bước thứ ba là xây bộ kiểm thử hành vi ở mức đầu vào–đầu ra: với một tập dữ liệu mẫu, hệ thống cho ra kết quả gì. Bộ kiểm thử này cho phép sửa hệ thống cũ an toàn hơn và sau này so sánh hệ thống mới với hệ thống cũ một cách khách quan. Michael Feathers, trong cuốn Working Effectively with Legacy Code năm 2004, định nghĩa mã kế thừa đơn giản là mã không có kiểm thử — một định nghĩa gợi ý rằng việc đầu tiên không phải là viết lại mà là làm cho mã kiểm chứng được.
Câu hỏi thường gặp
Bao lâu thì một phần mềm được coi là hệ thống cũ?
Không phụ thuộc tuổi mà phụ thuộc khả năng thay đổi. Một phần mềm năm năm tuổi nhưng không có tài liệu, không có kiểm thử và chỉ một người hiểu đã mang đủ đặc điểm của hệ thống cũ. Ngược lại, hệ thống hai mươi năm được bảo trì tốt có thể chưa cần thay.
Đưa hệ thống cũ lên đám mây có phải là hiện đại hoá không?
Chuyển nguyên trạng lên máy chủ đám mây giải quyết rủi ro phần cứng và có thể giảm chi phí vận hành, nhưng không giải quyết vấn đề mã nguồn khó sửa hay khó tích hợp. Đây thường là bước đầu hợp lý, không phải đích đến.
Có nên dùng AI để chuyển mã nguồn cũ sang ngôn ngữ mới không?
Công cụ hỗ trợ bằng AI có thể giúp đọc hiểu, tạo tài liệu và chuyển đổi từng phần mã, nhưng mã sinh ra vẫn cần người kiểm tra và bộ kiểm thử hành vi để xác nhận kết quả giống hệ thống cũ. Không nên coi chuyển đổi tự động là thay thế cho việc hiểu quy tắc nghiệp vụ.
Làm sao thuyết phục lãnh đạo đầu tư hiện đại hoá khi hệ thống vẫn chạy?
Trình bày bằng rủi ro và chi phí cơ hội cụ thể: thời gian thay đổi nghiệp vụ, cơ hội kinh doanh bị bỏ lỡ do không tích hợp được, chi phí ước tính nếu người duy nhất hiểu hệ thống nghỉ việc, và kết quả thử khôi phục sao lưu. Con số thật thuyết phục hơn mô tả công nghệ.
Nhà thầu cũ không bàn giao mã nguồn thì làm thế nào?
Trước hết rà soát hợp đồng về quyền sở hữu mã nguồn và nghĩa vụ bàn giao, nhờ tư vấn pháp lý nếu cần. Nếu không lấy được, hướng khả thi là bọc API quanh dữ liệu nếu truy cập được cơ sở dữ liệu, và lên kế hoạch thay thế bằng gói phần mềm hoặc thay thế dần.
Chiến lược bóp nghẹt dần có áp dụng cho phần mềm kế toán không?
Khó hơn với các hệ thống có tính toàn vẹn sổ sách cao, vì không nên để hai hệ thống cùng ghi sổ một kỳ. Với kế toán, thường thay một lần vào đầu kỳ, còn chiến lược thay dần phù hợp hơn cho các phân hệ vệ tinh như bán hàng, kho, cổng khách hàng.