Chúng tôi là một công ty quản trị lợi ích nhỏ, rất chuyên biệt với bộ sưu tập phần mềm cực kỳ hữu ích, mạnh mẽ, một số được viết bằng COBOL nhưng hầu hết bằng BASIC. Hai chuyên gia tư vấn toàn thời gian đã duy trì và cải thiện hệ thống này trong hơn 30 năm. Không cần phải nói họ sẽ sớm nghỉ hưu. (Một trong số họ đã tuyệt vọng nghỉ hưu trong vài năm nhưng trung thành với một lỗi lầm và cứ thế tiếp tục mặc dù chồng cô ấy khăng khăng rằng golf nên được ưu tiên.)

Chúng tôi bắt đầu con đường chuyển đổi sang một hệ thống được phát triển bởi một trong ba công ty trong cả nước cung cấp loại phần mềm chúng tôi sử dụng. Bây giờ chúng tôi cảm thấy rằng mặc dù công ty này về mặt lý thuyết có khả năng hoàn thành quá trình chuyển đổi, nhưng họ không có đủ nguồn lực để thực hiện kịp thời và chúng tôi đã tin rằng họ sẽ không thể cung cấp loại dịch vụ chúng tôi cần để chạy công việc kinh doanh của chúng tôi. (Không có gì giống như có thể đặt ưu tiên của riêng mình và có quyền phân bổ tài nguyên của một người khi phù hợp.)

Phần cứng không phải là vấn đề - chúng tôi có thể mô phỏng rất hiệu quả trên các máy chủ hiện đại. Nếu COBOL và BASIC là ngôn ngữ hiện đại, chúng tôi sẵn sàng chấp nhận rủi ro rằng chúng tôi có thể tìm được sự thay thế cho các chuyên gia tư vấn hiện tại của chúng tôi trong tương lai.

Có vẻ như phải có một mô hình kinh doanh cho một công ty hỗ trợ CNTT tập trung vào các nền tảng cũ như thế này và cung cấp tài năng phát triển phần mềm và lập trình để hỗ trợ một hệ thống như của chúng tôi, loại bỏ rủi ro tìm kiếm tài năng lập trình phù hợp và công việc thuyết phục các lập trình viên trẻ tuổi rằng họ có thể có một sự nghiệp hiệu quả, bổ ích, một phần bằng một ngôn ngữ cũ, không gợi cảm như BASIC.

Nói tóm lại, là những người quản lý không phải CNTT, làm thế nào chúng ta có thể quản lý tốt nhất quá trình chuyển đổi này?

Có vẻ như "phải có một mô hình kinh doanh cho một công ty hỗ trợ CNTT tập trung vào các nền tảng cũ như thế này", nhưng cá nhân tôi nghĩ rằng đó chỉ là suy nghĩ mong muốn của bạn vì nó sẽ "giải quyết" những thách thức bạn gặp phải trong một sà xuống.

Bị mắc kẹt trong môi trường cũ không phải là cách để đi về phía trước. Và tôi sẽ không đặt cược cuộc sống của bất kỳ công ty nào vào việc cố gắng duy trì tình trạng bế tắc bằng cách tìm một công ty mà bây giờ, sẽ sẵn sàng làm những gì bạn dường như không thể.

Vì vậy, không phải là một câu trả lời cho câu hỏi thực tế mà bạn đã hỏi, mà là lời khuyên chân thành về cách bạn có thể tiến về phía trước trong khi giữ cho rủi ro của việc di chuyển đến mức tối thiểu.

Đọc "Làm thế nào để sống sót khi viết lại từ đầu, mất đi sự tỉnh táo của bạn"

Đừng mắc lỗi của một dự án di chuyển dài mà không có kết quả thực sự trong một thời gian dài. Đọc "Làm thế nào để sống sót khi viết lại từ đầu, mất đi sự tỉnh táo của bạn"

Tôi không thể nhấn mạnh đủ làm thế nào những lời khuyên trong bài viết đó đã giúp tôi giải quyết / tiếp cận các vấn đề tương tự sau khi tự đốt cháy những dự án kiểu đó theo cách "cũ".

Thiết lập kiểm tra tự động

Nếu bạn chưa có nó (tại sao không?), Hãy nhờ các lập trình viên hiện tại của bạn tạo một khai thác thử nghiệm tự động cho các ứng dụng của bạn.

Bộ kiểm tra tự động sẽ bao gồm tất cả các khu vực chức năng của ứng dụng của bạn. Nó sh / sẽ ghi lại các thông số kỹ thuật làm việc hiện tại trong các quy tắc "khi_X_then_Y" của các trường hợp thử nghiệm riêng lẻ. Điều này sẽ giúp cả hai trong việc giữ các thay đổi trong mã hiện tại của bạn khỏi phá vỡ chức năng hiện có cũng như hỗ trợ mọi di chuyển sang môi trường mới.

Khi bạn đang xử lý với COBOL và BASIC, bộ kiểm thử có thể ở mức độ kiểm tra tích hợp: xử lý một tập hợp các tệp / cơ sở dữ liệu "cố định" và kiểm tra các tệp đầu ra / thay đổi nội dung cơ sở dữ liệu của các chương trình cụ thể (COBOL) và / hoặc ứng dụng. Đối với các phần BASIC trong phần mềm của bạn, điều này có thể có nghĩa là thêm các tham số dòng lệnh để làm cho chúng thực hiện một số chức năng nhất định mà không cần (G) UI can thiệp hoặc nhận công cụ kiểm tra tự động dựa trên UI (G).

Cô lập tính toán và các thuật toán khác

Ngay cả Cobol cũng hỗ trợ khái niệm các chương trình phụ có thể gọi được từ một chương trình chính. Cô lập tất cả các tính toán nhập khẩu và các thuật toán khác trong các chương trình hoặc mô-đun riêng biệt. Mục tiêu là tạo ra một thư viện các chương trình / mô-đun / bất cứ thứ gì làm công việc lặt vặt tách biệt với mọi thứ thu thập đầu vào và tạo đầu ra.

Điều chỉnh khai thác thử nghiệm để kiểm tra cả hai thông qua các ứng dụng cũ của bạn cũng như cách ly. Điều này sẽ đảm bảo rằng công việc bạn đang thực hiện trên mã "cũ" để tạo điều kiện di chuyển sang môi trường mới hơn sẽ đưa ra càng ít lỗi càng tốt.

Bắt đầu một bộ ứng dụng mới trong môi trường "hiện tại"

Đừng chuyển đổi mã hiện tại của bạn. Chuyển đổi ngôn ngữ này sang ngôn ngữ khác có nghĩa là áp đặt các ràng buộc của môi trường cũ trên môi trường mới. Kết quả nếu thường ít hơn mong muốn (đọc: kết quả sẽ rất khủng khiếp và đau đớn để duy trì). Di cư. Dành thời gian để thiết lập các ứng dụng của bạn trong môi trường mới theo cách được coi là thực tiễn tốt nhất cho môi trường đó.

Nhận lập trình viên mới, thành thạo trong môi trường bạn chọn, để làm như vậy. Đặt ưu tiên ngay từ ngày đầu để tách biệt tất cả các tính toán và thuật toán quan trọng trong các lớp và / hoặc gói riêng biệt và ẩn chúng đằng sau các giao diện. Sử dụng phép tiêm phụ thuộc (loại tiêm phụ thuộc DIY rẻ nhất sẽ làm) để cho ứng dụng mới của bạn biết lớp nào sẽ khởi tạo / sử dụng để thực hiện các phép tính.

Đây là một cách tốt để làm mọi thứ và trong trường hợp của bạn sẽ cho phép bạn di chuyển những phần quan trọng trên cơ sở từng trường hợp. Nó cũng sẽ che giấu sự phức tạp của việc gọi các chương trình cơ bản và / hoặc cobol khỏi các chức năng gọi trong môi trường mới.

Đừng tiếp tục thiết lập các ứng dụng và có thể thiết lập chức năng đầu vào / đầu ra quan trọng nhất sử dụng phép tính từ "thư viện" COBOL / BASIC của bạn.

Tích hợp "thư viện" COBOL / BASIC của bạn

Tìm hiểu làm thế nào để gọi "thư viện" COBOL / BASIC từ môi trường mới của bạn. Điều này có thể liên quan đến việc thiết lập các tệp tham số hoặc bảng cơ sở dữ liệu, thực hiện chương trình COBOL / BASIC bao bọc thư viện COBOL / BASIC mà bạn đã thiết lập trước đó. Nếu bạn may mắn, phiên bản BASIC của bạn có thể cho phép tạo ra DLL có thể được gọi trực tiếp.

Triển khai lớp trong môi trường mới của bạn sẽ gọi "thư viện" COBOL / BASIC và kiểm tra cái quái đó bằng cách sử dụng các thử nghiệm tương tự trong khai thác thử nghiệm của môi trường cũ, nhưng bây giờ ở dạng thử nghiệm đơn vị trong môi trường mới .

Có, điều này có nghĩa là "nhân đôi" các bài kiểm tra, nhưng đó là một mạng lưới an toàn mà bạn không muốn làm mà không có. Nếu chỉ bởi vì các bài kiểm tra đơn vị này sau này sẽ đóng vai trò là các bài kiểm tra để kiểm tra việc thực hiện các tính toán và thuật toán của bạn khi chúng được di chuyển sang môi trường mới của bạn.

Nhưng một lần nữa: không đi xa hơn là thêm các bài kiểm tra đơn vị cho (các) phép tính được sử dụng bởi bước quan trọng nhất từ ​​bước trước.

Xác định các ứng dụng mới trong các lần lặp

Xác định các ứng dụng mới bằng cách lặp lại hai bước trước đó cho tất cả các chức năng trong các ứng dụng cũ của bạn. Tiếp tục thêm các bài kiểm tra đơn vị kiểm tra các tính toán vào khai thác kiểm tra ứng dụng mới của bạn. Sử dụng bộ kiểm thử tích hợp để kiểm tra xem các hàm di chuyển có hoạt động giống như các ứng dụng cũ của bạn không.

Di chuyển thư viện lõi trong các lần lặp

Và cuối cùng di chuyển các tính toán và thuật toán trong "thư viện" COBOL / BASIC của bạn, triển khai lại chúng trong môi trường mới của bạn. Một lần nữa, làm điều này lặp đi lặp lại bằng cách sử dụng các bài kiểm tra (đơn vị) như một cách để giữ sự tỉnh táo của bạn.

Có vẻ như ứng dụng này là "cốt lõi" cho doanh nghiệp của bạn. Trong trường hợp một hệ thống hoặc quy trình là doanh nghiệp của bạn, đó là trường hợp có giải pháp tùy chỉnh của riêng bạn.

Bạn ám chỉ điều này. Thật không may với thời gian dài bạn đã đi kể từ khi cập nhật công nghệ của bạn, đây sẽ là một công việc cực kỳ khó khăn.

Tôi muốn giới thiệu một trong hai tuyến đường.

1. Nhân viên một nhóm CNTT gồm các nhà phát triển / quản lý dự án / QE / hoạt động và xây dựng hệ thống của bạn tăng dần, như đã lưu ý trong câu trả lời khá kỹ thuật ở trên. Điều này tuy nhiên, sẽ đặc biệt đắt tiền.
2. Thay vì một nhà cung cấp ngoài kệ, hãy tìm một nhà tư vấn phát triển tùy chỉnh đủ điều kiện. Nhóm này sẽ xử lý tất cả các tài nguyên để xây dựng hệ thống mới của bạn, sau đó bạn có thể mang nó vào nhà với một đội ngũ nhân viên nhỏ hơn tùy chọn 1 để tiếp tục. Tùy chọn này có một loạt rủi ro khác nhau, tuy nhiên, việc chọn một nhà cung cấp tốt có thể rất khó khăn cho những người không có kỹ thuật. Chúng cũng có thể có rủi ro rất cao với chi phí vượt mức, v.v. Để giảm thiểu tuyến đường này, hãy sử dụng đội ngũ nhân viên hiện tại của bạn để tạo ra một bộ yêu cầu rất chi tiết (từ góc độ người dùng) cho giá thầu của bạn. Sau đó yêu cầu chào giá cố định là tốt.

Chúc may mắn, bạn có khoảng 20 năm di sản để vượt qua. Nó sẽ không rẻ, dễ dàng, hoặc sạch sẽ.

Thay vì tìm một công ty để duy trì phần mềm kế thừa của bạn hoặc cho một công ty viết lại phần mềm kế thừa của bạn, hãy tìm một công ty để cung cấp dịch vụ hệ thống quản trị lợi ích liên tục. Thuê ngoài các vấn đề quyết định có nên viết lại phần mềm hay không, lịch trình nào để đặt, ngôn ngữ hoặc công cụ nào sẽ sử dụng.

Đúng, chi phí rõ ràng của phương pháp này có thể vượt quá chi phí rõ ràng khi thuê lập trình viên mới, nhưng bằng cách thừa nhận của bạn, bạn là người quản lý không phải CNTT và rất dễ thấy trước các tình huống mà bạn đưa ra quyết định mà cuối cùng phải trả cho công ty của bạn nhiều hơn chi phí rõ ràng của gia công.