Bagaimana transisi multinasional saya dari satu platform pengembangan ke platform lain?


10

Saya bekerja di departemen TI perusahaan besar internasional. Kami sedang mengembangkan berbagai aplikasi Intranet yang berbeda untuk bisnis (Pengaduan, Rabat, Service Desk dll). Sekarang kami memutuskan untuk bermigrasi dari platform PHP ke .NET (integrasi dengan MS CRM Dynamics, Exchange, dan MS Office menjadi beberapa alasan). Karena ada sekitar 20 aplikasi berbeda yang digunakan bisnis pada platform PHP saat ini, kita harus menemukan cara terbaik untuk memindahkan semuanya ke platform baru. Saya tidak ingin masuk ke detail bagaimana mengkonversi kode dll, karena sementara kami melakukan migrasi kami ingin meningkatkan semua aplikasi ini.

Jadi kami menemukan 2 cara utama untuk memindahkan aplikasi ini:

  1. Mendukung hanya satu platform. Apa artinya itu? Buat beranda dan migrasi semua aplikasi secara harfiah ke .NET (tanpa memperbaikinya saat kami melakukannya). Setelah intranet baru berjalan, kami akan mulai membangun kembali aplikasi yang dimigrasi dan memperbaikinya. Itu akan menyelamatkan kita mengembangkan intranet di .NET sambil harus mendukung platform PHP.

  2. Mendukung kedua platform untuk beberapa waktu. Itu berarti membangun hanya beranda dan 1 atau 2 aplikasi baru (yang tidak ada di platform PHP kami). Menyediakan ini untuk pengguna tetapi tidak melepas platform PHP (kami akan memasukkan menu dan tautan untuk memudahkan pengguna untuk berpindah antar aplikasi di halaman PHP dan yang baru). Kemudian kita akan mulai menulis ulang aplikasi PHP sambil meningkatkannya.

Sekarang saya tidak yakin apa yang akan lebih baik, di satu sisi (opsi 1) kami akan berpotensi membuat segalanya lebih mudah bagi pengguna dengan tidak memaksa mereka untuk menggunakan dua platform yang berbeda secara bersamaan. Meskipun mereka tidak akan melihat peningkatan memiliki platform baru, selain dari segalanya tampak lebih bagus, fungsionalitas aplikasi pada platform baru akan sama untuk beberapa waktu. Juga saya pikir kita akan menambahkan diri kita (IT dep) lebih banyak pekerjaan karena pada dasarnya kita akan menulis setiap aplikasi dua kali.
Di sisi lain dalam opsi dua (2) pengguna akan memiliki pengalaman yang lebih buruk karena dua platform terlihat berbeda, tetapi mereka akan menyadari manfaat dari platform baru saat aplikasi baru dipindahkan.

Apakah ada di antara Anda yang menemukan sesuatu seperti itu? Apa yang akan kamu pilih? Atau mungkin ada yang berbeda, cara yang lebih baik untuk yang telah saya sajikan? Saya ingin tahu apa yang Anda pikirkan dan bagaimana Anda akan mendekati itu.


1
Bukankan # 2 langkah ke # 1?
Tae-Sung Shin

Tidak, ini adalah 2 hal yang berbeda. Dalam 1 kami akan memigrasi seluruh intranet sebelum mengizinkan pengguna untuk menggunakannya dan kemudian kami akan bekerja untuk meningkatkan aplikasi. Dalam 2 kita akan memigrasi bagian penting dari intranet, memungkinkan pengguna untuk menggunakannya, dan kemudian mulai memigrasi aplikasi lain dan meningkatkannya saat kita bermigrasi ...

@greengit: membaca topik, integrasi dengan yang lain, aplikasi bisnis penting adalah salah satu alasannya. Namun pertanyaan saya bukan tentang 'Mengapa harus bermigrasi', tetapi 'Bagaimana cara bermigrasi'.
Daniel Gruszczyk

Saya membaca topik & memiliki pertanyaan yang sama. Saya sangat meragukan apakah proyek itu dapat dibenarkan biaya. Bisakah Anda memberi tahu kami nama perusahaan sehingga kami dapat menjualnya dengan singkat? ;)
mcottle

haha, saya tidak peduli dengan biaya yang jujur ​​karena saya hanya seorang siswa IT pada penempatan kerja dengan perusahaan. Saya hanya meminta pengetahuan saya sendiri ... Benar-benar manajer saya membenarkan biaya yang cukup untuk mendapatkan lampu hijau dari CEO ...
Daniel Gruszczyk

Jawaban:


5

Mari kita pertimbangkan kedua skenario ini:

Migrasi semuanya sekaligus

Saat Anda memigrasi basis kode Anda, pelanggan Anda akan tetap menggunakan aplikasi yang ada. Karena migrasi akan memakan waktu yang tidak sepele, ini berarti Anda perlu memiliki tim pemeliharaan pada basis kode lama, untuk perbaikan bug dan pengembangan fitur. Setiap perubahan yang Anda buat di basis kode lama perlu terjadi di basis kode baru. Anda akhirnya akan menulis setiap baris kode dua kali selama migrasi tidak dilakukan, membuatnya lebih mahal semakin lama untuk bermigrasi. Jadi, semuanya bermuara pada: apa waktu penyelesaian untuk migrasi penuh nantinya? Biaya pengembangan Anda akan meroket selama waktu penyelesaian berlangsung.

Migrasi sepotong demi sepotong

Dalam skenario ini Anda akan memiliki kontrol yang lebih baik atas upaya ganda, tetapi Anda masih akan memiliki banyak biaya tambahan. Penempatan Anda akan melibatkan dua platform terpisah, dengan dua kali masalah penyebaran dan sumber daya server tambahan yang dibutuhkan. Kecuali jika Anda memiliki aplikasi yang sangat modular, Anda akan menemukan bahwa sering ada kode di platform lain selain yang Anda perlukan, sehingga menyebabkan upaya porting dan pemeliharaan tambahan. Selama migrasi tidak dilakukan, biaya pengembangan Anda akan lebih tinggi. Pada saat yang sama, tekanan fitur akan berarti Anda butuh waktu yang sangat lama untuk menyelesaikan migrasi.

Kesimpulan

Dari pengalaman pribadi saya dapat memberi tahu Anda dua hal:

  • Berpindah bahasa pemrograman jarang terbayar. Dari analisis biaya-manfaat, sangat kecil kemungkinannya akan menguntungkan untuk beralih ke .NET dari PHP. Jadi saran utama saya adalah: jangan. Cobalah untuk menyelesaikan masalah Anda dengan basis kode yang ada.
  • Sepotong demi sepotong adalah pendekatan terbaik, tetapi Anda akan kesulitan melakukannya pada tingkat modul aplikasi. Anda akan menemukan bahwa Anda harus mengembangkan dan memelihara fitur di kedua sisi arsitektur selama migrasi tidak sepenuhnya dilakukan. Ini bisa menjadi ide yang baik untuk memprioritaskan fitur yang tidak didasarkan pada apa yang paling dibutuhkan pelanggan tetapi pada apa yang akan membatasi jumlah upaya ganda (sehingga menurunkan biaya).

Anda telah membuat poin yang sangat menarik. Meskipun tidak sampai pada diri saya sendiri apakah kita mengganti platform atau tidak, dan saya akan bekerja untuk perusahaan hanya sampai akhir september (saya bersama mereka pada penempatan kerja yang sama). Beralih dari PHP ke .NET mungkin merupakan ide yang baik karena kerangka PHP lama yang kita miliki memerlukan beberapa pekerjaan utama, juga database, sistem yang digunakan perusahaan saat ini adalah TUA dan dibuat oleh orang-orang yang tidak memiliki keterampilan pengembangan yang hebat. ..
Daniel Gruszczyk

Pertanyaan saya adalah: Apakah 'ganti beku' di platform lama adalah ide yang bagus? Yang saya maksud dengan itu adalah bahwa setiap perubahan pada sistem yang ada pada platform PHP, selain perbaikan bug, dibekukan sampai kita mulai memindahkan aplikasi yang diberikan ke .NET. Itu adalah bagian manajer saya dari rencana migrasi ...
Daniel Gruszczyk

Jika ini adalah sistem non-sepele, sangat tidak mungkin bahwa pembekuan perubahan akan berhasil dalam praktiknya. Jika seseorang benar-benar membutuhkan fitur, mereka akan meningkatkannya ke tingkat yang lebih tinggi daripada manajer Anda, dan Anda akan dipaksa untuk melakukan perubahan. Juga, perbaikan bug sendiri dapat mengambil sumber daya tim yang cukup besar. Dan selalu ingat bahwa sistem lama telah mengalami banyak perubahan, dan desain baru cenderung melupakan semua perbaikan kecil satu-baris, yang akan perlu terjadi lagi agar pengguna dapat menerima produk yang didesain ulang.
Joeri Sebrechts

Satu hal lagi: jika sistem akan dibangun kembali, penjaga aman apa yang ada untuk memastikan kualitas kode yang lebih baik kali ini? Saya telah melihat aplikasi yang ditulis ulang sebanyak 4 kali karena masalah kualitas platform dan kode.
Joeri Sebrechts

2

Untuk alasan keuangan, sebagian besar perusahaan tempat saya bekerja menggunakan pendekatan kedua, yang seharusnya saya tambahkan. Dibutuhkan banyak uang, waktu, dan risiko bagi mereka untuk mencapai # 1. Sebagian besar pengguna akan mengerti # 2 selama mereka melihat kemajuan dan interaksi Anda dengan mereka. Dalam ekonomi ramping & kejam ini, saya ragu ada orang yang akan mengambil pendekatan # 1.


Itu persis pikiran saya. Manajer saya ingin melanjutkan dengan # 1, yang menurut saya sulit untuk dipahami.

2

Pendekatan big bang jarang konstruktif sejauh menyangkut pengguna akhir. Saya akan menyarankan untuk tidak jujur ​​dan saya tidak percaya ada orang yang serius mempertimbangkannya sebagai pilihan mengingat jumlah aplikasi yang bersangkutan.

Saya akan cenderung untuk pergi dengan opsi dua dan menangani kembali bekerja berdasarkan kasus per kasus. Memang ini mungkin membutuhkan waktu lebih lama daripada pendekatan satu di atas kertas tetapi pada kenyataannya, Anda membuka sejumlah besar risiko bisnis dengan mengambil pendekatan satu dan saya benar-benar tidak ingin berada di sekitar untuk panggilan dukungan pada hari pertama jika ada bahkan hanya satu masalah kecil di ujung pengguna.

Selain itu, jika sebagian besar aplikasi berbasis layanan web Anda sudah ditulis dalam php, bagaimana keahlian .Net yang tersedia?

Saya pikir baik cara pengguna Anda harus mengalami perubahan, baik big bang (memberi banyak panggilan dukungan) atau sedikit demi sedikit (meningkatkan keakraban). Saya cenderung berpikir Anda belum benar-benar mengukur dengan tepat berapa banyak pekerjaan yang harus dilakukan untuk beralih dari hampir semua php menjadi sepenuhnya. Net juga.


Saya kira ini lebih rumit daripada hanya mendukung dua platform yang terpisah atau tidak. Apa pun itu bukan pendekatan yang benar-benar baik ... Terima kasih atas waktu Anda!
Daniel Gruszczyk

1

Pertama, saya setuju dengan semua yang dikatakan Joeri.

Opsi satu benar-benar mengerikan. Jika Anda melakukan ini dan tidak melanjutkan dukungan seperti yang dijelaskan Joeri, Anda mematikan dukungan selama beberapa tahun sejauh yang dilihat pelanggan. Setelah dua tahun mereka secara efektif mendapatkan situs yang sama dengan semua masalah yang sama yang telah mereka ketahui dan benci selama beberapa tahun terakhir. Ditambah risiko bahwa pasar telah berubah untuk sementara dan membuat aplikasi usang & membutuhkan perombakan besar. Juga, jika Anda mematikan dukungan selama dua tahun, apa yang menurut Anda akan terjadi pada semua permintaan layanan? Mereka tidak akan pergi. Paling tidak beberapa pengguna Anda akan "bangkrut" dan mengembangkan sistem misi kritis di (mungkin) Akses untuk menyumbat celah dalam sistem yang Anda tulis ulang - maka Anda tetap akan mendukung dua platform ...

Opsi dua berarti bahwa Anda akan mendukung kedua teknologi untuk jangka waktu yang lama. Periode waktu ini akan lebih lama dari yang Anda pikirkan dan Anda bisa berakhir dengan ekosistem yang terfragmentasi secara permanen - yaitu sejumlah besar kode PHP yang tidak ekonomis untuk ditulis ulang bercampur dengan kode .NET yang lebih baru.

Dorong kembali keras terhadap siapa pun yang menyarankan ini. Akan jauh lebih murah untuk menulis kode untuk mengintegrasikan aplikasi PHP dengan produk yang Anda sarankan daripada menulis ulang semuanya. NET kemudian mengintegrasikan kode yang ditulis ulang dengan produk, jangan lupa, integrasi tidak akan secara ajaib terjadi jika Anda menggunakan .NET .

Satu hal lagi, ambil jumlah baris kode PHP dan masukkan ke dalam alat COCOMO 2 untuk mendapatkan ide berapa lama dan berapa banyak pengembang yang Anda perlukan untuk menyelesaikan penulisan ulang.


Poin yang bagus. Apa yang akan Anda lakukan, jika itu tidak terserah Anda jika Anda memigrasi sistem atau tidak. Pendekatan mana yang akan Anda pilih? Atau apakah ada pendekatan lain terhadap mereka yang telah saya daftarkan? Jika manajer Anda tidak setuju dengan Anda, apakah Anda akan mencoba membuktikan bahwa pendekatan Anda lebih baik?
Daniel Gruszczyk

Tulis aplikasi PHP dengan cara yang lebih berlapis "Berorientasi Layanan". Gunakan bus layanan perusahaan untuk buffer antarmuka antara PHP & Microsoft land. Kuncinya adalah melakukan estimasi COCOMO, yang seharusnya menakuti penulisan langsung dari manajer Anda.
mcottle

1

Anda memiliki opsi ketiga: -

Migrasikan kode php ke server windows Anda dan ISS (sama dengan yang Anda rencanakan untuk menjalankan .NET!)

Anda kemudian dapat menambahkan aplikasi baru di .NET (dan secara perlahan mengonversi beberapa yang lebih lama ke .NET) sambil menghadirkan kepada pengguna Anda apa yang tampak seperti satu sistem.


PHP memang berjalan di bawah IIS
Bart
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.