Hiện đại hóa hệ thống COBOL: chuyển đổi sang Java mà vẫn bảo toàn logic nghiệp vụ

Hệ thống vẫn chạy đúng mỗi ngày. Vấn đề là số người có thể giải thích tại sao nó chạy như vậy đang ít dần.

Các nghiệp vụ lõi — quản lý đơn hàng, sản xuất, tồn kho, xuất hàng, hạch toán — vẫn được xử lý chính xác trên những chương trình viết cách đây hai, ba chục năm. Nghĩa là chất lượng xử lý không phải điều đáng lo. Điều đáng lo là tốc độ thay đổi và số lựa chọn còn lại. Muốn mở thêm kênh bán hàng, muốn kết nối API với đối tác, muốn gom dữ liệu để phân tích hoặc ứng dụng AI — lần nào cũng vấp phải cùng một câu hỏi: “hệ thống lõi có sửa được không?”. Và dần dần, kế hoạch kinh doanh tự thu hẹp lại cho vừa với những gì hệ thống chịu được.

Đó mới là lý do thật sự khiến các doanh nghiệp bắt đầu tính đến việc hiện đại hóa hệ thống COBOL — không phải vì ngôn ngữ cũ, mà vì không gian lựa chọn quanh nó đang hẹp lại. Bài viết này dành cho CIO, giám đốc công nghệ, trưởng bộ phận CNTT và người phụ trách chuyển đổi số, tập trung vào: phân biệt migration với modernization, cách chọn giữa replatform – refactor – reimagine, vai trò thực tế của AI, và quy trình chuyển đổi COBOL sang Java theo năm giai đoạn.

Vì sao hiện đại hóa hệ thống COBOL trở thành ưu tiên

COBOL không phải ngôn ngữ đã biến mất. Nó vẫn đang xử lý giao dịch lõi trong ngân hàng, bảo hiểm, sản xuất và phân phối. Nhưng “hệ thống chạy tốt” và “hệ thống bảo trì được” là hai chuyện khác nhau. Tạp chí Ngân hàng (Ngân hàng Nhà nước Việt Nam) khi phân tích rào cản của hệ thống ngân hàng lõi kế thừa trong chuyển đổi số và tích hợp AI cũng chỉ ra đúng nhóm vấn đề này: thiếu hụt chuyên gia COBOL, dữ liệu bị cô lập, xử lý theo lô không đáp ứng thời gian thực, và thuật toán “hộp đen” khó giải thích.

Trong thực tế triển khai, tám nhóm rủi ro sau thường là thứ đẩy việc hiện đại hóa từ “để sau” thành “năm nay phải làm”.

1. Rủi ro nhân lực và tình trạng phụ thuộc cá nhân

Tài liệu thiết kế không được cập nhật, hoặc không còn. Hệ quả là logic nghiệp vụ chỉ nằm trong đầu vài kỹ sư gắn bó lâu năm. Khi họ nghỉ hưu hoặc chuyển việc, doanh nghiệp không chỉ mất nhân sự mà mất luôn khả năng thay đổi hệ thống. Nguồn kỹ sư COBOL trên thị trường ngày càng hiếm, nên phương án “tuyển người thay thế” mỗi năm một khó.

2. Chi phí vận hành tăng dần

Chi phí bảo trì phần cứng và phần mềm là phần nhìn thấy được. Phần lớn hơn nằm ở kiểm thử: khi không ai dự đoán được phạm vi ảnh hưởng của một thay đổi, mọi thay đổi đều phải kiểm thử hồi quy trên diện rộng. Sửa một dòng mà mất ba tháng mới phát hành được là chi phí thật, dù nó không xuất hiện trên hóa đơn hạ tầng nào.

3. Khả năng bảo trì suy giảm

Sau vài chục năm chỉnh sửa, các nhánh điều kiện chồng lên nhau khiến chương trình trở thành “hộp đen”. Thời gian dành cho việc xác định có được sửa hay không nhiều hơn thời gian sửa.

4. Nền tảng và middleware hết hỗ trợ

Vòng đời của mainframe, hệ điều hành và middleware do nhà cung cấp quyết định, không phụ thuộc kế hoạch của doanh nghiệp. Khi mốc kết thúc hỗ trợ đã được công bố, cửa sổ ra quyết định thu hẹp lại — và càng bắt đầu muộn thì càng dễ bị dồn vào phương án nhanh nhất thay vì phương án đúng nhất.

5. Bảo mật và tuân thủ

Trên nền tảng hết hỗ trợ, việc vá lỗ hổng, nâng cấp thuật toán mã hóa hay tích hợp cơ chế xác thực hiện đại đều khó. Với các ngành chịu quản lý chặt như tài chính – ngân hàng, số hạng mục phải trả lời “kiến trúc hiện tại không đáp ứng được” sẽ tăng dần theo thời gian.

6. Khả năng tích hợp và khai thác dữ liệu

Khi dữ liệu lõi bị khóa bên trong hệ thống cũ, mọi sáng kiến về data platform, BI hay AI đều dở dang. Cách xử lý quen thuộc — thêm một luồng batch kết nối điểm-điểm mỗi khi cần — chính là thứ tạo ra thế hệ legacy tiếp theo.

7. Tốc độ đưa sản phẩm ra thị trường

Có làm agile ở lớp front-end đến đâu, nếu lead time của hệ thống lõi không đổi thì tốc độ tổng thể vẫn không đổi. Tốc độ chung luôn bị quyết định bởi lớp chậm nhất.

8. Tính liên tục của hoạt động kinh doanh

Business continuity không phải là “từ trước tới nay chưa từng dừng”, mà là “có ai và có quy trình nào khôi phục được”. Một hệ thống lõi chỉ ba người hiểu là rủi ro liên tục, bất kể chỉ số uptime đẹp đến đâu.

Migration không đồng nghĩa với modernization

Đây là điểm dễ nhầm nhất ở giai đoạn đầu, và nó quyết định ngân sách. Chuyển môi trường vận hành (migration) và tái cấu trúc để hệ thống dễ bảo trì, dễ mở rộng (modernization) là hai quyết định đầu tư khác nhau. Trong thực tế, các chương trình lớn áp dụng ba hướng dưới đây cho từng vùng nghiệp vụ khác nhau.

Với một hệ thống lõi quy mô lớn, câu hỏi hữu ích không phải “chọn phương án nào” mà là “phương án nào cho vùng nào”. Các xử lý batch ổn định có thể chỉ cần replatform để gỡ rủi ro nền tảng; vùng đơn hàng – tồn kho thay đổi thường xuyên thì refactor để lấy lại khả năng bảo trì; chỉ một số chức năng cần tích hợp ra ngoài mới đáng reimagine. Độ chính xác của việc phân bổ này ảnh hưởng đến hiệu quả đầu tư nhiều hơn bất kỳ lựa chọn công cụ nào.

AI hỗ trợ hiện đại hóa: giao đến đâu và dừng ở đâu

AI đã thay đổi đáng kể chi phí của giai đoạn khảo sát và lập tài liệu — vốn từng chiếm phần lớn công sức. Những ứng dụng đã chứng minh được hiệu quả gồm:

• Phân loại mã nguồn và kiểm kê tài sản (đang dùng / không dùng / trùng lặp)
• Application discovery và lập bản đồ phụ thuộc (dependency mapping)
• Sinh tài liệu kỹ thuật cho những phần không còn hồ sơ
• Trích xuất và tóm tắt logic nghiệp vụ
• Hỗ trợ chuyển đổi mã nguồn
• Sinh test case
• Hỗ trợ lập kế hoạch migration wave (chia đợt chuyển đổi)
• Tự động hóa kiểm thử

Ngược lại, giả định rằng AI có thể tự hoàn tất cả dự án là chưa đúng ở thời điểm hiện tại. Lý do rất rõ: thứ nằm trong mã nguồn cũ không chỉ là logic, mà còn là các ngoại lệ nghiệp vụ và bối cảnh lịch sử. “Nhánh điều kiện này chỉ áp dụng cho một khách hàng cụ thể”, “quy tắc làm tròn này xuất phát từ chính sách kế toán”, “kiểm tra ngày này viết theo một quy định đã được sửa” — phân tích tĩnh cho ra đoạn mã, chứ không cho ra ý định đằng sau nó.

Vì vậy mô hình BAP áp dụng là AI-assisted, expert-led — có con người trong vòng lặp kiểm chứng. AI đảm nhận tốc độ phân tích và sinh nội dung; chuyên gia hệ thống legacy, kỹ sư Java/cloud, đội QA và người dùng nghiệp vụ chịu trách nhiệm kiểm chứng kết quả. Sự tham gia của bộ phận nghiệp vụ không phải hình thức — đó là căn cứ cuối cùng để kết luận hệ thống mới tương đương về chức năng.

AI là công cụ nén khối lượng khảo sát và sinh mã, không phải chủ thể chịu trách nhiệm cho quyết định nghiệp vụ. Dự án nào để ranh giới này mờ đi thì sẽ trả giá ở giai đoạn kiểm thử.

Quy trình chuyển đổi COBOL sang Java: năm giai đoạn

Giai đoạn 1 — Khảo sát ứng dụng và lập bản đồ phụ thuộc

Kiểm kê chương trình, job, shell script, màn hình, báo cáo và đối tượng cơ sở dữ liệu; sau đó dựng sơ đồ quan hệ gọi và luồng dữ liệu. Kết quả có giá trị nhất ở giai đoạn này là xác định được phần tài sản thực tế không còn được sử dụng — quy mô dự án thường giảm đáng kể sau bước loại trừ này. Song song đó là phỏng vấn bộ phận nghiệp vụ để khôi phục những quy tắc chưa từng được ghi thành tài liệu.

Giai đoạn 2 — PoC và lập kế hoạch chia đợt chuyển đổi

Không triển khai toàn bộ ngay từ đầu. Chọn một nghiệp vụ có độ khó đại diện, rồi chứng minh trọn vẹn phương án chuyển đổi, kiến trúc đích và cách kiểm thử. Mục tiêu của PoC không phải là “có làm được không”, mà là đưa dự án về trạng thái ước lượng được khối lượng, chất lượng và rủi ro khi mở rộng ra quy mô thật. Từ kết quả đó mới chia migration wave theo nghiệp vụ và theo dữ liệu, đồng thời quyết định cách cắt chuyển cho từng đợt, kể cả việc có cần chạy song song hay không.

Giai đoạn 3 — Chuyển đổi mã nguồn, giao diện, dữ liệu và nền tảng

Song song với chuyển đổi mã nguồn là việc đưa màn hình online lên nền web, dựng lại hệ thống báo cáo, di chuyển dữ liệu (xử lý rõ khác biệt về bảng mã và kiểu dữ liệu), chuyển middleware và lịch chạy job. Toàn bộ quá trình cần giữ được khả năng truy vết: bất kỳ lúc nào cũng phải trả lời được chương trình COBOL nào tương ứng với thành phần Java nào.

Giai đoạn 4 — Kiểm thử tương đương chức năng và bảo đảm chất lượng

Chất lượng của cả dự án được quyết định ở giai đoạn này. Nếu cam kết không thay đổi quy trình nghiệp vụ, doanh nghiệp phải chứng minh được bằng bằng chứng cụ thể rằng với cùng đầu vào, hệ thống mới trả về cùng kết quả như hệ thống cũ. Các loại kiểm thử chính:

• Unit test (kiểm thử đơn vị)
• Component test
• Đối chiếu kết quả batch giữa hệ cũ và hệ mới
• Integration test (kiểm thử tích hợp)
• Data reconciliation (đối soát toàn vẹn dữ liệu)
• System test
• Performance test — đặc biệt là hoàn tất batch trong cửa sổ thời gian cho phép
• Kiểm tra bảo mật
• Regression test (kiểm thử hồi quy)
• User acceptance testing (nghiệm thu người dùng)

Giai đoạn 5 — Cutover, ổn định vận hành và cải tiến liên tục

Kế hoạch cắt chuyển chỉ hoàn chỉnh khi đi kèm điều kiện rollback được viết rõ. Ngay sau cutover, cần tăng cường giám sát và đội trực tuyến đầu; xác nhận hệ thống chạy ổn định rồi mới bàn giao sang bảo trì thường quy. Và hiện đại hóa không kết thúc ở cutover: khi đã có một hệ thống dễ bảo trì, việc mở API và đưa dịch vụ cloud vào theo từng bước mới là lúc phần lớn giá trị đầu tư được thu hồi.

Giá trị kinh doanh có thể đạt được

• Giảm rủi ro vận hành — thoát khỏi nền tảng hết hỗ trợ, mở rộng số người có thể xử lý sự cố.
• Giảm phụ thuộc nhân lực COBOL — chuyển sang công nghệ có nguồn tuyển dụng lớn giúp doanh nghiệp có thể tái lập đội ngũ.
• Nâng cao khả năng bảo trì — cấu trúc và tài liệu rõ ràng làm giảm công sức khảo sát cho mỗi lần thay đổi.
• Rút ngắn chu kỳ phát hành — khi phạm vi ảnh hưởng dự đoán được, phạm vi kiểm thử có thể thu hẹp một cách hợp lý.
• Tăng khả năng tích hợp — có điểm kết nối thật cho API, cloud, nền tảng dữ liệu và AI.
• Bảo toàn logic nghiệp vụ — những quy tắc đã được kiểm chứng qua nhiều năm được chuyển tiếp ở dạng giải thích được.
• Cải thiện trải nghiệm người dùng — đưa màn hình lên web giúp gỡ bỏ ràng buộc về thiết bị đầu cuối và cải thiện thao tác.
• Nền tảng cho chuyển đổi số dài hạn — các sáng kiến sau đó không còn phải bắt đầu bằng việc “đi khảo cổ” hệ thống lõi.

Tỷ lệ tiết kiệm hay thời gian hoàn vốn phụ thuộc hoàn toàn vào quy mô, cấu trúc và yêu cầu nghiệp vụ của từng hệ thống. Các con số mục tiêu nên được đặt ra dựa trên kết quả khảo sát hiện trạng, không nên lấy từ một mức trung bình chung.

Dự án BAP đã tham gia: đổi nền tảng mà không đổi quy trình nghiệp vụ

BAP đã tham gia dự án chuyển các nghiệp vụ quản lý đơn hàng, sản xuất, tồn kho và xuất hàng từ hệ thống cũ sang nền tảng mới, với ràng buộc rõ ràng: không làm thay đổi quy trình nghiệp vụ hiện tại.

Phạm vi dự án gồm khoảng:

• 90 màn hình người dùng
• 300 chương trình ứng dụng
• 85 shell script cho batch processing và vận hành
• 65 bảng cơ sở dữ liệu

BAP thực hiện xác nhận yêu cầu và phân tích hệ thống tại chỗ, đề xuất giải pháp migration, hỗ trợ phát triển, đồng thời thực hiện component test, system test và user acceptance testing.

Ràng buộc “không thay đổi quy trình nghiệp vụ” đáng được nhấn mạnh, vì nó xác định nơi dự án thành hay bại: nếu quy trình phải giữ nguyên thì việc chứng minh tương đương chức năng không còn là hoạt động cuối kỳ, mà trở thành hạng mục bàn giao trung tâm — và thiết kế kiểm thử phải được đưa vào ngay từ giai đoạn khảo sát.

Năng lực BAP trong dự án hiện đại hóa COBOL

BAP có khoảng 500 nhân sự kỹ thuật, với các trung tâm phát triển tại Việt Nam (Hà Nội, Đà Nẵng, TP. Hồ Chí Minh, Huế) và văn phòng tại Nhật Bản, Hàn Quốc, Australia và Hoa Kỳ. Phần lớn kinh nghiệm triển khai của BAP đến từ các dự án cho doanh nghiệp Nhật Bản — môi trường đặt yêu cầu rất cao về tài liệu, tương đương chức năng và ổn định vận hành. Đây cũng chính là ba tiêu chí quyết định trong một dự án chuyển đổi hệ thống lõi.

Câu hỏi thường gặp

Chuyển COBOL sang Java là đã hoàn tất hiện đại hóa?

Chưa. Nếu chỉ ánh xạ cấu trúc điều khiển của COBOL sang Java, kết quả là “COBOL viết bằng Java”: công nghệ mới nhưng công sức khảo sát cho mỗi lần sửa gần như không đổi. Chuyển đổi phải đi kèm việc định nghĩa lại cấu trúc package, cách truy cập dữ liệu và cơ chế xử lý ngoại lệ thì mới cải thiện được khả năng bảo trì.

Doanh nghiệp gần như không còn tài liệu thiết kế, có chuyển đổi được không?

Được, và đây là tình trạng phổ biến chứ không phải ngoại lệ. Đặc tả được dựng lại từ mã nguồn, định nghĩa job và hành vi dữ liệu thực tế, sau đó xác nhận lại với bộ phận nghiệp vụ. Phân tích và sinh tài liệu bằng AI phát huy hiệu quả rõ nhất ở giai đoạn này, nhưng khâu xác nhận vẫn thuộc về con người.

Nên chuyển đổi một lần hay chia nhiều đợt?

Tùy vào mức độ chấp nhận gián đoạn nghiệp vụ và quy mô tài sản. Chuyển một lần thì không phải gánh chi phí chạy song song, nhưng rollback khó hơn nhiều. Chuyển từng đợt giảm rủi ro mỗi lần, đổi lại phát sinh bài toán thiết kế thật sự: đồng bộ dữ liệu giữa hệ cũ và hệ mới trong suốt giai đoạn chuyển tiếp. Nên quyết định dựa trên kết quả PoC thay vì theo nguyên tắc chung.

Làm sao bảo đảm nghiệp vụ không bị thay đổi sau khi chuyển?

Bằng kiểm thử tương đương chức năng. Đối chiếu đầu ra của hệ cũ và hệ mới; mỗi khác biệt đều phải truy nguyên nhân và xác định cùng bộ phận nghiệp vụ đó là lỗi hay là thay đổi đặc tả có chủ đích. Không có cách nào đi tắt qua bước này.

Nền tảng còn được hỗ trợ vài năm nữa, có cần bắt đầu ngay không?

Riêng việc khảo sát tài sản và chốt phương án đã mất khá nhiều thời gian, sau đó còn chuyển đổi, kiểm thử và ổn định vận hành. Bắt đầu muộn thường khiến lựa chọn bị thu hẹp về replatform. Nên làm khảo sát hiện trạng trước để có đủ dữ kiện ra quyết định — bước này chi phí không lớn.

Nên bắt đầu từ đâu?

Từ kiểm kê tài sản và lập bản đồ phụ thuộc. Chỉ khi nhìn rõ quy mô và cấu trúc thì mới bàn được tỷ lệ phân bổ giữa replatform, refactor và reimagine. Ở bước này chưa cần quyết định đầu tư lớn.

Trao đổi với BAP về hệ thống COBOL của bạn

BAP đồng hành với doanh nghiệp ở mọi giai đoạn của quyết định này, kể cả giai đoạn sớm nhất:

• Đánh giá hiện trạng hệ thống COBOL — kiểm kê tài sản và lập bản đồ phụ thuộc
• Trao đổi về hệ thống hiện tại — rà soát rủi ro nhân lực, tải bảo trì và mốc hết hỗ trợ của nền tảng
• Xây dựng modernization roadmap — phân bổ phương án theo từng vùng nghiệp vụ và thiết kế các đợt chuyển đổi
• Thực hiện PoC — kiểm chứng phương án và độ chính xác của ước lượng trước khi đầu tư quy mô lớn

Nếu nội bộ vẫn chưa thống nhất phương hướng thì đó cũng là một điểm khởi đầu hợp lý. Hãy chia sẻ tình trạng hệ thống hiện tại, chúng tôi sẽ đề xuất những câu hỏi cần trả lời trước và cách triển khai phù hợp.