“Hệ thống vẫn chạy chính xác mỗi ngày — nhưng gần như không ai giải thích được vì sao nó chạy như vậy.” Đây là thực trạng của nhiều doanh nghiệp đang vận hành hệ thống lõi viết bằng COBOL.
Vấn đề không nằm ở chất lượng, mà ở tốc độ thay đổi và các lựa chọn ngày càng bị thu hẹp. Muốn mở thêm kênh bán hàng, kết nối dữ liệu với SaaS hay dùng AI dự báo nhu cầu — câu hỏi đầu tiên luôn là “có động vào hệ thống lõi được không?”. Và câu trả lời thường khiến chính sáng kiến đó bị thu nhỏ lại. Đó mới là lý do thực sự khiến doanh nghiệp tính đến hiện đại hóa.
Bạn sẽ nắm được sau bài viết (dành cho lãnh đạo IT, CIO, CTO)
- 8 áp lực khiến hiện đại hóa COBOL trở thành ưu tiên
- Khác biệt giữa migration và modernization, cách chọn giữa Replatform, Refactor và Reimagine
- AI hỗ trợ được gì và đâu là phần con người phải quyết định
- Quy trình hiện đại hóa 5 giai đoạn và một dự án thực tế của BAP
Vì sao hiện đại hóa COBOL đang trở thành ưu tiên?
COBOL không phải ngôn ngữ đã “chết”. Nó vẫn xử lý giao dịch cốt lõi trong ngân hàng, bảo hiểm, sản xuất và phân phối. Nhưng một hệ thống “chạy tốt” chưa chắc đã là hệ thống “bảo trì được”. Câu hỏi không phải công nghệ cũ đến đâu, mà là hệ thống có theo kịp tốc độ thay đổi của doanh nghiệp hay không. Thông thường, có 8 áp lực khiến việc hiện đại hóa trở nên cấp thiết.
| Áp lực | Điều gì xảy ra |
|---|---|
| 1. Rủi ro nhân sự | Chỉ vài kỹ sư lâu năm hiểu logic nghiệp vụ. Khi họ nghỉ, mọi thay đổi đều dừng lại — và nguồn kỹ sư COBOL ngày càng khan hiếm |
| 2. Chi phí sở hữu tăng | Ngoài phí bản quyền, phần cứng, việc không đánh giá được phạm vi ảnh hưởng khiến chi phí kiểm thử phình to. “Sửa một dòng, test ba tháng” làm chậm mọi quyết định |
| 3. Khả năng bảo trì suy giảm | Hàng chục năm vá víu biến chương trình thành “hộp đen”. Xác định một thay đổi có an toàn không còn tốn thời gian hơn chính việc sửa |
| 4. Nền tảng hết hỗ trợ | Vòng đời phần cứng và middleware do nhà cung cấp quyết định. Bắt đầu muộn, bạn dễ bị buộc phải chọn phương án nhanh nhất thay vì phương án đúng |
| 5. Rủi ro bảo mật, kiểm toán | Nền tảng hết hỗ trợ khó cập nhật bản vá hay chuẩn mã hóa mới, khiến ngày càng nhiều yêu cầu chỉ nhận được câu trả lời “không làm được” |
| 6. Hạn chế tích hợp | Dữ liệu bị “nhốt” trong hệ thống lõi khiến BI, nền tảng dữ liệu và AI đều dở dang. Mỗi giao diện batch mới lại sinh ra một “legacy” mới |
| 7. Tốc độ phát triển chậm | Dù front-end có agile đến đâu, tốc độ chung vẫn bị giới hạn bởi thời gian xử lý thay đổi ở hệ thống lõi |
| 8. Tính liên tục kinh doanh | “Đang chạy nên an toàn” không phải là khả năng phục hồi. Thiếu người và quy trình để khôi phục, hệ thống phụ thuộc cá nhân chính là rủi ro |
Migration và Modernization không phải là một
Đây là điểm dễ hiểu nhầm nhất ở giai đoạn đầu. Migration là chuyển hệ thống sang môi trường mới; modernization là tái cấu trúc để dễ bảo trì và mở rộng. Đó là hai quyết định đầu tư hoàn toàn khác nhau. Trên thực tế, ba hướng tiếp cận sau được kết hợp theo từng mảng nghiệp vụ.
| Hướng tiếp cận | Nội dung | Phù hợp khi | Lưu ý |
|---|---|---|---|
| Replatform (chuyển nền tảng) | Chuyển nền tảng sang hệ mở hoặc cloud, giữ nguyên phần lớn logic ứng dụng | Nền tảng sắp hết hỗ trợ, yêu cầu nghiệp vụ ổn định | Loại bỏ rủi ro nền tảng nhưng vấn đề bảo trì, phụ thuộc cá nhân vẫn còn. Cần tính trước bước tiếp theo |
| Refactor (COBOL → Java…) | Chuyển COBOL sang công nghệ dễ bảo trì như Java/Spring và tái cấu trúc | Mảng nghiệp vụ lõi còn thay đổi thường xuyên; muốn mở rộng nguồn tuyển dụng | Chuyển đổi máy móc thuần túy sẽ tạo ra “COBOL viết bằng Java”. Phải định nghĩa kiến trúc đích trước |
| Reimagine (thiết kế lại nghiệp vụ) | Thiết kế lại năng lực nghiệp vụ bằng API, microservices, dịch vụ cloud-native | Mảng tạo lợi thế cạnh tranh, cần tích hợp bên ngoài hoặc kênh mới | Chi phí và thời gian lớn. Chỉ hiệu quả khi phạm vi được khoanh vùng chặt |
Lời giải thực tế là kết hợp
Hiện đại hóa với AI: giao gì cho AI, giữ lại gì cho con người
AI ngày càng được ứng dụng rộng rãi trong các dự án hiện đại hóa. Tuy nhiên, AI hiện chưa thể tự hoàn thành trọn vẹn một dự án.
AI phát huy hiệu quả
- Phân loại, kiểm kê mã nguồn (đang dùng / không dùng / trùng lặp)
- Khảo sát ứng dụng và lập bản đồ phụ thuộc
- Tạo tài liệu cho những hệ thống đã mất đặc tả
- Trích xuất, tóm tắt logic nghiệp vụ; hỗ trợ chuyển đổi mã
- Sinh test case, tự động hóa kiểm thử, hỗ trợ lập kế hoạch các đợt chuyển đổi
Con người phải quyết định
- Các ngoại lệ nghiệp vụ, ví dụ “nhánh điều kiện này là quy tắc riêng cho một khách hàng”
- Bối cảnh lịch sử, ví dụ “cách làm tròn này xuất phát từ chính sách kế toán”
- Xác định khác biệt đầu ra là đặc tả hay lỗi
- Xác nhận cuối cùng về tính tương đương chức năng — bắt buộc có bộ phận nghiệp vụ tham gia
Cách tiếp cận của BAP: AI-assisted, expert-led
Quy trình hiện đại hóa COBOL: 5 giai đoạn
Khảo sát ứng dụng và lập bản đồ phụ thuộc
Kiểm kê chương trình, job, script, báo cáo và cơ sở dữ liệu; trực quan hóa quan hệ gọi hàm và luồng dữ liệu. Xác định được những thành phần không còn sử dụng sẽ ảnh hưởng lớn đến quy mô các bước sau. Phỏng vấn bộ phận nghiệp vụ giúp làm rõ các quy tắc chưa được ghi chép.
PoC và lập kế hoạch các đợt chuyển đổi
Chọn một nghiệp vụ có độ khó tiêu biểu để kiểm chứng phương án chuyển đổi, kiến trúc và cách kiểm thử. Mục tiêu không phải chứng minh “làm được”, mà là ước tính được công sức, chất lượng và rủi ro ở quy mô thực. Từ đó chia các đợt chuyển đổi và chọn phương thức chuyển giao, bao gồm có cần chạy song song hay không.
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ã: web hóa màn hình, dựng lại báo cáo, chuyển đổi dữ liệu (bao gồm khác biệt về mã ký tự và kiểu dữ liệu), chuyển middleware và vận hành job. Luôn đảm bảo truy vết được chương trình COBOL nào tương ứng với lớp Java nào.
Kiểm thử tương đương chức năng và đảm bảo chất lượng
Chất lượng của dự án được quyết định tại đây. Cần chứng minh bằng bằng chứng rằng hệ thống cũ và mới cho ra cùng một kết quả với cùng một đầu vào.
Unit test Component test Đối chiếu kết quả batch Integration test Đối soát dữ liệu System test Performance test (cửa sổ batch) Kiểm thử bảo mật Regression test UAT
Chuyển giao, ổn định và cải tiến liên tục
Chuẩn bị quy trình chuyển giao cùng tiêu chí rollback, tăng cường giám sát ngay sau khi chuyển. Hiện đại hóa không kết thúc khi go-live: khoản đầu tư chỉ thực sự sinh lời khi bạn tiếp tục phát triển trên nền tảng mới với API và dịch vụ cloud.
Giá trị kinh doanh mang lại
| Giá trị | Ý nghĩa |
|---|---|
| Giảm rủi ro vận hành | Thoát khỏi nền tảng hết hỗ trợ, mở rộng đội ngũ có thể xử lý sự cố |
| Giảm phụ thuộc cá nhân | Chuyển sang công nghệ như Java với nguồn nhân lực dồi dào hơn nhiều |
| Dễ bảo trì hơn | Cấu trúc và tài liệu rõ ràng giúp giảm công điều tra mỗi lần thay đổi |
| Rút ngắn chu kỳ phát hành | Đánh giá được phạm vi ảnh hưởng nên khoanh vùng kiểm thử hợp lý |
| Sẵn sàng tích hợp | Tạo điểm kết nối với API, cloud, nền tảng dữ liệu và AI |
| Bảo toàn logic nghiệp vụ | Kế thừa các quy tắc nghiệp vụ đã được kiểm chứng qua nhiều năm dưới dạng có thể giải thích |
| Trải nghiệm người dùng tốt hơn | Màn hình web loại bỏ giới hạn về thiết bị, trình duyệt và thao tác |
*Tỷ lệ cắt giảm chi phí và thời gian hoàn vốn phụ thuộc lớn vào quy mô, cấu trúc hệ thống và yêu cầu nghiệp vụ. Mục tiêu cụ thể nên được đặt dựa trên kết quả khảo sát hệ thống thực tế.
Dự án thực tế của BAP: chuyển nghiệp vụ lõi sang nền tảng mới mà không thay đổi quy trình
BAP đã tham gia dự án chuyể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 — từ hệ thống cũ sang nền tảng mới, với điều kiện không thay đổi quy trình nghiệp vụ hiện có.
~90
màn hình người dùng
~300
chương trình ứng dụng
~85
script batch và vận hành
~65
bảng cơ sở dữ liệu
BAP đảm nhận xác nhận yêu cầu và phân tích hệ thống tại chỗ, đề xuất phương án chuyển đổi, hỗ trợ phát triển, và thực hiện component test, system test đến UAT. Ràng buộc “không đổi quy trình” đồng nghĩa với việc chứng minh tính tương đương chức năng trở thành trọng tâm của dự án — vì vậy đưa kiểm thử vào thiết kế ngay từ đầu là đặc biệt quan trọng.
BAP có thể hỗ trợ gì?
| Lĩnh vực | Nội dung |
|---|---|
| Khảo sát, phân tích | Kiểm kê tài sản, lập bản đồ phụ thuộc, phỏng vấn nghiệp vụ, so sánh phương án chuyển đổi |
| PoC | Kiểm chứng trước khi triển khai toàn diện, nâng độ chính xác ước tính công sức, chất lượng, rủi ro |
| Chuyển đổi theo giai đoạn | Thiết kế và triển khai các đợt chuyển đổi theo nghiệp vụ và dữ liệu |
| Phát triển | Chuyển COBOL sang Java, phát triển Java/Spring, dựng lại màn hình web và báo cáo |
| Nền tảng và dữ liệu | Chuyển nền tảng/middleware, chuyển đổi và đối soát dữ liệu |
| Đảm bảo chất lượng | Kiểm thử end-to-end từ unit đến UAT, đối chiếu batch, kiểm thử hiệu năng và bảo mật |
| Mô hình triển khai | Offshore, onsite hoặc hybrid — hỗ trợ tiếng Việt, tiếng Anh, tiếng Nhật, tiếng Hàn |
| Hỗ trợ sau chuyển đổi | Ổn định vận hành, bảo trì và phát triển bổ sung liên tục |
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ỳ.
Câu hỏi thường gặp
Q. Chuyển COBOL sang Java là đã hoàn tất hiện đại hóa?
A. Chưa. Sao chép nguyên cấu trúc điều khiển của COBOL sang Java chỉ tạo ra “COBOL viết bằng Java”, công điều tra khi sửa đổi gần như không giảm. Cần đồng thời định nghĩa lại cấu trúc package, cách truy cập dữ liệu và xử lý ngoại lệ.
Q. Không còn tài liệu thiết kế nào, có chuyển đổi được không?
A. Được, và đây là tình huống khá phổ biến. Đặc tả được dựng lại bằng cách đối chiếu mã nguồn, định nghĩa job và hành vi dữ liệu thực tế, sau đó xác nhận với bộ phận nghiệp vụ. AI đặc biệt hiệu quả ở bước phân tích và tạo tài liệu này.
Q. Nên chuyển đổi một lần hay theo giai đoạn?
A. Tùy vào mức độ chấp nhận gián đoạn và quy mô hệ thống. Chuyển một lần giảm gánh nặng chạy song song nhưng khó rollback hơn. Chuyển theo giai đoạn giảm rủi ro mỗi bước nhưng phải thiết kế liên kết dữ liệu cũ – mới. Nên quyết định dựa trên kết quả PoC.
Q. Sau chuyển đổi, quy trình nghiệp vụ có bị thay đổi không?
A. Không, nếu kiểm thử tương đương được làm đúng. Đối chiếu đầu ra cũ và mới, điều tra mọi khác biệt và xác nhận với bộ phận nghiệp vụ đó là đặc tả hay lỗi. Không có lối tắt nào khác.
Q. Còn vài năm nữa mới hết hỗ trợ, có cần bắt đầu ngay không?
A. Có. Riêng khâu khảo sát và ra quyết định đã mất khá nhiều thời gian, sau đó còn chuyển đổi, kiểm thử và ổn định. Bắt đầu sát hạn thường chỉ còn lựa chọn replatform. Hãy bắt đầu từ kiểm kê tài sản và lập bản đồ phụ thuộc.
Trao đổi với BAP về hiện đại hóa COBOL
- Đánh giá: kiểm kê tài sản hiện có và lập bản đồ phụ thuộc
- Làm rõ vấn đề: nhân sự, khối lượng bảo trì, thời hạn hỗ trợ nền tảng
- Lộ trình: phân bổ hướng tiếp cận theo mảng nghiệp vụ và thiết kế các đợt chuyển đổi
- PoC: kiểm chứng phương án và ước tính trước khi đầu tư lớn
Ngay cả khi nội bộ chưa thống nhất định hướng, hãy chia sẻ tình trạng hệ thống hiện tại — chúng tôi sẽ đề xuất các vấn đề cần xem xét và lộ trình phù hợp.
