Kami adalah perusahaan administrasi manfaat kecil, sangat terspesialisasi, dengan koleksi perangkat lunak yang sangat berguna dan kuat, beberapa ditulis dalam COBOL tetapi sebagian besar dalam BASIC. Dua konsultan penuh waktu dengan cakap memelihara dan meningkatkan sistem ini selama lebih dari 30 tahun. Tak perlu dikatakan mereka akan segera pensiun. (Salah satu dari mereka telah putus asa untuk pensiun selama beberapa tahun tetapi setia pada kesalahan dan tetap bertahan meskipun ada desakan dari suaminya bahwa golf harus diprioritaskan.)

Kami memulai jalur konversi ke sistem yang dikembangkan oleh satu dari hanya tiga perusahaan di negara yang menawarkan jenis perangkat lunak yang kami gunakan. Kami sekarang merasa bahwa meskipun perusahaan ini secara teoritis mampu menyelesaikan proses konversi, mereka tidak memiliki sumber daya untuk melakukannya tepat waktu, dan kami percaya bahwa mereka tidak akan dapat menawarkan jenis layanan yang kami butuhkan untuk menjalankan bisnis kami. (Tidak ada yang bisa mengatur prioritas sendiri dan memiliki wewenang untuk mengalokasikan sumber daya seseorang sesuai keinginan.)

Perangkat keras bukan masalah - kami dapat meniru sangat efektif pada server modern. Jika COBOL dan BASIC adalah bahasa modern, kami akan bersedia mengambil risiko bahwa kami dapat menemukan pengganti untuk konsultan kami saat ini ke depan.

Sepertinya harus ada model bisnis untuk sebuah perusahaan dukungan TI yang berkonsentrasi pada platform lama seperti ini dan menyediakan bakat pemrograman dan pengembangan perangkat lunak untuk mendukung sistem seperti kita, menghilangkan risiko menemukan bakat pemrograman yang tepat dan dari belakang kita. pekerjaan meyakinkan pemrogram muda bahwa mereka dapat memiliki karier yang produktif dan bermanfaat, sebagian dalam bahasa yang lama dan tidak seksi seperti BASIC.

Singkatnya, sebagai manajer non-IT, bagaimana kita dapat mengelola transisi ini dengan baik?

Mungkin kelihatannya "harus ada model bisnis untuk perusahaan dukungan TI yang berkonsentrasi pada platform lama seperti ini", tetapi secara pribadi saya pikir itu hanya angan-angan dari pihak Anda karena akan "menyelesaikan" tantangan yang Anda hadapi dalam satu menukik.

Tetap terjebak di lingkungan lama bukanlah cara untuk maju. Dan saya tidak akan mempertaruhkan nyawa perusahaan mana pun untuk tetap terjebak dengan menemukan perusahaan yang, untuk saat ini, bersedia melakukan apa yang tampaknya tidak dapat Anda lakukan.

Jadi bukan jawaban untuk pertanyaan aktual yang Anda tanyakan, tetapi saran yang tulus tentang bagaimana Anda dapat bergerak maju sambil menjaga risiko migrasi seminimal mungkin.

Baca "Cara bertahan hidup dari menulis ulang tanpa kehilangan kewarasan Anda"

Jangan membuat kesalahan dari proyek migrasi panjang tanpa hasil nyata untuk waktu yang lama. Baca "Cara bertahan hidup dari menulis ulang tanpa kehilangan kewarasan Anda"

Saya tidak bisa cukup menekankan bagaimana saran dalam artikel itu telah membantu saya dalam mengatasi / mendekati masalah yang sama setelah membakar diri saya sendiri dengan melakukan proyek semacam itu dengan cara "lama".

Siapkan pengujian otomatis

Jika Anda belum menggunakannya (mengapa tidak?), Minta programmer Anda saat ini untuk membuat test harness otomatis untuk aplikasi Anda.

Rangkaian uji otomatis harus mencakup semua area fungsional aplikasi Anda. Itu sh / akan mendokumentasikan spesifikasi kerja saat ini dalam aturan "when_X_then_Y" dari masing-masing kasus uji. Ini akan membantu baik dalam menjaga perubahan dalam kode Anda saat ini dari melanggar fungsi yang ada serta mendukung migrasi ke lingkungan baru.

Ketika Anda berurusan dengan COBOL dan BASIC, suite tes mungkin harus berada pada level tes integrasi: mengerjakan set file input / basis data "tetap" dan memeriksa file output / mengubah isi database dari program tertentu (COBOL) dan / atau aplikasi. Untuk bagian-bagian BASIC dari perangkat lunak Anda ini dapat berarti menambahkan parameter baris perintah untuk membuatnya menjalankan fungsi-fungsi tertentu tanpa intervensi (G) UI, atau mendapatkan alat uji otomatis berbasis UI (G).

Isolasi perhitungan dan algoritma lainnya

Bahkan Cobol mendukung gagasan tentang sub program yang dapat dipanggil dari program utama. Isolasi semua perhitungan impor dan algoritme lain dalam program atau modul terpisah. Tujuannya adalah untuk membuat perpustakaan program / modul / apa pun yang melakukan pekerjaan kasar terisolasi dari segala sesuatu yang mengumpulkan input dan menciptakan output.

Sesuaikan alat uji untuk mengujinya baik melalui aplikasi lama Anda maupun secara terpisah. Ini akan memastikan bahwa pekerjaan yang Anda lakukan pada kode "lama" untuk memfasilitasi migrasi ke lingkungan yang lebih baru akan memperkenalkan kesalahan sesedikit mungkin.

Mulai serangkaian aplikasi baru di lingkungan "saat ini"

Jangan mengonversi kode Anda saat ini. Mengubah satu bahasa ke bahasa lain berarti memaksakan batasan lingkungan lama pada yang baru. Hasilnya jika sering kurang dari yang diinginkan (baca: hasilnya akan mengerikan dan sakit untuk mempertahankan). Migrasi. Luangkan waktu untuk mengatur aplikasi Anda di lingkungan baru dengan cara yang dianggap praktik terbaik untuk lingkungan itu.

Dapatkan programmer baru, berpengalaman dalam lingkungan yang Anda pilih, untuk melakukannya. Jadikan sebagai prioritas sejak hari pertama untuk mengisolasi semua perhitungan dan algoritma penting dalam kelas dan / atau paket terpisah dan sembunyikan di belakang antarmuka. Gunakan injeksi ketergantungan (jenis injeksi ketergantungan DIY paling murah) untuk memberi tahu aplikasi baru Anda kelas mana yang akan dipakai / digunakan untuk melakukan perhitungan.

Ini adalah cara yang baik untuk melakukan banyak hal dan dalam kasus Anda akan memungkinkan Anda untuk melakukan migrasi bagian-bagian penting berdasarkan kasus. Ini juga akan menyembunyikan seluk-beluk program panggilan dasar dan / atau cobol dari fungsi panggilan di lingkungan baru.

Jangan melangkah lebih jauh dengan mengatur aplikasi dan mungkin mengatur fungsi input / output terpenting yang menggunakan perhitungan dari "perpustakaan" COBOL / BASIC Anda.

Integrasikan "perpustakaan" COBOL / BASIC Anda

Cari tahu bagaimana cara memanggil "perpustakaan" COBOL / BASIC Anda dari lingkungan baru Anda. Ini mungkin melibatkan pengaturan file parameter atau tabel database, menjalankan program COBOL / BASIC yang membungkus perpustakaan COBOL / BASIC yang Anda atur sebelumnya. Jika Anda beruntung, versi BASIC Anda memungkinkan pembuatan DLL yang dapat dipanggil langsung.

Laksanakan kelas di lingkungan baru Anda yang akan memanggil COBOL / BASIC "perpustakaan" dan uji heck keluar dari itu menggunakan tes yang sama yang memanfaatkan uji lingkungan lama, tetapi sekarang dalam bentuk unit test di lingkungan baru .

Ya ini berarti "menduplikasi" tes, tetapi ini adalah jaring pengaman yang tidak ingin Anda lakukan tanpanya. Jika hanya karena unit test ini nantinya akan berfungsi sebagai tes untuk memeriksa implementasi perhitungan dan algoritma Anda ketika mereka dimigrasi ke lingkungan baru Anda.

Tetapi sekali lagi: jangan melangkah lebih jauh daripada menambahkan tes unit untuk perhitungan yang digunakan oleh yang paling penting dari langkah sebelumnya.

Selesaikan aplikasi baru dalam iterasi

Selesaikan aplikasi baru dengan mengulangi dua langkah sebelumnya untuk semua fungsi di aplikasi lama Anda. Terus tambahkan tes unit yang memeriksa perhitungan ke harness pengujian aplikasi baru Anda. Gunakan suite tes integrasi untuk memeriksa apakah fungsi yang dimigrasi berfungsi sama dengan aplikasi lama Anda.

Migrasikan pustaka inti dalam iterasi

Dan akhirnya migrasi perhitungan dan algoritme di "pustaka" COBOL / BASIC Anda, implementasikan kembali di lingkungan baru Anda. Sekali lagi, lakukan ini secara iteratif dengan menggunakan tes (unit) sebagai cara untuk menjaga kewarasan Anda.

Sepertinya aplikasi ini "inti" untuk bisnis Anda. Dalam kasus di mana suatu sistem atau proses adalah apa bisnis Anda itu adalah kasus untuk memiliki solusi kustom Anda sendiri.

Anda menyinggung ini. Sayangnya mengingat lama waktu yang Anda habiskan sejak memperbarui teknologi, ini akan menjadi tugas yang sangat sulit.

Saya akan merekomendasikan satu dari dua rute.

1. Staf kelompok TI pengembang / manajer proyek / QE / operasi dan membangun sistem Anda secara bertahap, seperti yang disebutkan dalam jawaban yang agak teknis di atas. Namun ini akan menjadi sangat mahal.
2. Daripada penyedia rak, mencari konsultan pengembang kustom yang memenuhi syarat. Grup ini akan menangani semua sumber daya untuk membangun sistem baru Anda, maka Anda dapat membawanya dengan staf kecil daripada opsi 1 untuk melanjutkan. Opsi ini memiliki serangkaian risiko berbeda, namun memilih penyedia yang baik bisa sangat sulit bagi yang non-teknis. Mereka juga bisa berisiko sangat tinggi dengan pembengkakan biaya, dll. Untuk mengurangi rute ini, gunakan staf Anda yang sudah ada untuk menyusun serangkaian persyaratan yang sangat rinci (dari perspektif pengguna) untuk tawaran Anda. Kemudian minta penawaran harga tetap juga.

Semoga beruntung, Anda memiliki sekitar 20 tahun warisan untuk diatasi. Itu tidak akan murah, mudah, atau bersih.

Daripada mencari perusahaan untuk memelihara perangkat lunak warisan Anda atau perusahaan untuk menulis ulang perangkat lunak warisan Anda, mencari perusahaan untuk memberikan layanan sistem administrasi manfaat lanjutan. Alihkan masalah untuk memutuskan apakah akan menulis ulang perangkat lunak atau tidak, jadwal apa yang harus ditentukan, bahasa atau alat apa yang digunakan.

Ya, biaya yang jelas dari pendekatan ini mungkin melebihi biaya yang jelas untuk merekrut programmer baru, tetapi, menurut pengakuan Anda sendiri, Anda adalah manajer non-TI dan mudah untuk memperkirakan skenario di mana Anda membuat keputusan yang pada akhirnya membuat perusahaan Anda lebih mahal daripada biaya outsourcing yang jelas.