Pertimbangan apa yang harus diberikan untuk dan melawan situs "super"?

Perusahaan saya sedang mempertimbangkan untuk menggabungkan semua aplikasi dan situs tingkat-1 (yaitu produksi akhir atas) mereka menjadi satu basis kode yang mencakup semua.

Teorinya adalah bahwa izin, desain, dan fungsi keseluruhannya dapat dihomogenisasi dan dikelola secara terpusat.

Saya tidak memiliki akhir keprihatinan tentang pendekatan ini karena struktur data yang mendasari setiap aplikasi sangat berbeda, aturan bisnisnya kompleks dan unik untuk setiap aplikasi dan basis kode keseluruhan untuk aplikasi yang ada sangat berbeda dan sangat diabaikan.

EDIT :

Lingkungan saat ini terdiri dari tiga situs ASP.Net 1.1 yang hampir tidak pernah melihat cinta nyata sejak pertama kali ditulis (terutama karena tidak adanya pengembang berpengalaman di perusahaan) dan satu aplikasi MVC2 yang juga merupakan situs ASP.Net 1.1 sebelum menjadi ditingkatkan tahun lalu. Kami menulis secara eksklusif dalam C #.

Perusahaan ini tergolong kecil, dengan sekitar 50 staf; tiga di antaranya adalah pengembang aktual. Manajemen (bahkan manajemen TI) tidak memiliki latar belakang atau pengalaman TI selain manajemen proyek proyek TI (dan oleh karena itu beberapa pengetahuan yang lewat tentang terminologi dan dampak bisnis).

Aplikasi tersebut terutama adalah layanan online untuk mendukung produk yang dijual oleh perusahaan. Perusahaan tidak menjual perangkat lunak apa pun secara langsung.

Jadi untuk mengutarakan seluruh situasi ini dalam pertanyaan yang cukup spesifik dan dapat dijawab: Apa alasan kuat untuk dan menentang mencoba menarik semua sistem Anda menjadi satu solusi menyeluruh yang diberikan kondisi saat ini (yaitu basis kode lama, sistem bisnis yang kompleks, dan aturan )?

Ide buruk

Reaksi ini didasarkan pada asumsi berikut:

1. Ada banyak aplikasi yang cukup berbeda yang dihomogenisasi
2. Ada banyak tim yang mengerjakan berbagai aplikasi
3. Tidak ada arsitek perangkat lunak yang dihormati dan dihormati yang secara aktif mengelola aplikasi

Apa yang akan terjadi jika Anda terus maju

Kemungkinan besar akan ada upaya konsolidasi awal untuk menyatukan semuanya di bawah pendekatan desain tunggal. Ini akan menunjukkan upaya besar yang diperlukan untuk membuat semuanya bekerja sama dan mungkin mendapatkan kalengan sebagai tidak bisa bekerja.

Jika ditekan maka beberapa jenis repositori terpusat yang berisi data konfigurasi (misalnya akses keamanan, tingkat logging dll) akan diperlukan pada titik mana seseorang akan menunjukkan yang jelas dan mengatakan

"Hei, kenapa kita tidak melakukan retrofit pendekatan konfigurasi eksternal ini ke aplikasi lama, itu akan jauh lebih cepat?"

dan sesaat kemudian orang lain akan bergabung

"Dan, karena kita tetap melakukan refactoring, mengapa kita tidak menerapkan standar desain saja untuk masing-masing domain aplikasi - pemrosesan web terlihat seperti ini, pemrosesan aturan bisnis seperti ini dan akses basis data seperti, eh ini."

sampai akhirnya

"Oh, dan ada banyak kode umum di sini mengapa tidak mengumpulkan beberapa perpustakaan yang mudah dibagikan. Kita mungkin membutuhkan semacam integrasi build run secara berkala, katakanlah, setiap malam."

Pada saat itu semua orang menghela nafas lega karena monolit besar tidak dibangun.

Kami telah mengerjakan ini di perusahaan saya. Saya pikir itu mungkin dan ada manfaat yang jelas (Anda sebutkan), namun, ini mungkin akan menjadi proyek 5 hingga 7 tahun pada tingkat minimum absolut, dan pada dasarnya mengharuskan semuanya ditulis ulang. Jika Anda bisa menandatangani sesuatu seperti itu, maka saya akan mengatakan pergi untuk itu. Jika tidak, maka bersiaplah untuk mars kematian mengerikan.

Google melakukannya, jadi tentu saja itu mungkin .

Tautan BTW itu adalah presentasi yang menarik dari Googler tentang bagaimana mereka mengelola basis kode mereka, integrasi berkelanjutan, pengujian dll.

Namun, tanpa komitmen kuat yang sama untuk tooling, seperti yang telah dilakukan Google, Anda mungkin akan mengalami dunia yang terluka.

Pertanyaan kunci di sini adalah mengapa ? Mengapa manajemen senior ingin melakukan ini? Tabungan, leverage, atau keuntungan lain apa yang mereka harapkan untuk dapatkan?

Jika Anda dapat mengatasi cukup banyak masalah tersebut sehingga Anda mencapai tujuan mereka, Anda dapat menghindari basis kode tunggal yang menjadi perhatian Anda, sambil tetap memberikan mereka hasil efektif yang sama.

Kami telah melalui proses serupa. Kami memiliki produk yang sudah ada sejak lama. Tahun lalu kami memperkenalkan produk lain yang 95% sama dengan yang pertama, dengan 5% perbedaan yang kentara namun signifikan, dengan perbedaan itu untuk dikembangkan dan dikelola oleh tim yang terpisah.

Ketika kami pertama kali mulai bekerja pada produk baru, tim lama terus melakukan perubahan yang berdampak buruk pada kami sebesar 5% itu, karena mereka tidak memahami produk baru. Jadi kami benar-benar memotong 5% kode, yang memungkinkan kami menyelesaikan rilis pertama tepat waktu.

Kemudian lebih banyak pekerjaan pemeliharaan dimulai, dan kami mendapati kami sering membuat perubahan yang hampir sama dalam kode yang hampir sama. Tim lama juga memiliki pemahaman yang jauh lebih baik tentang produk baru sekarang, jadi kami secara bertahap mengintegrasikan kembali apa yang kami garpu, dan menemukan cara arsitektur yang lebih efisien untuk mengekspresikan perbedaan.

Jadi ketika Anda mengatakan struktur data berbeda dan keseluruhan basis kode berbeda, pertanyaan yang akan saya tanyakan adalah apakah mereka harus seperti itu atau hanya bagaimana mereka berevolusi karena kelayakan saat ini. Jelas Anda harus memperhitungkan perbedaan aturan dan persyaratan bisnis, tetapi kuncinya adalah mengisolasi perbedaan-perbedaan tersebut menjadi modul sekecil mungkin. Jika Anda sering mendapati diri Anda menerapkan fitur yang sama persis untuk banyak pelanggan dengan cara yang sedikit berbeda untuk basis kode yang berbeda, maka konsolidasi dapat sangat membantu, dan saya curiga itu masalahnya atau manajemen mungkin tidak akan mengusulkan hal ini.

Anda kemungkinan besar tidak akan dapat mengkonsolidasikan banyak aplikasi ke dalam basis kode yang sama karena itu akan membutuhkan sedikit usaha dan untuk program yang lama dan terabaikan, ini mungkin jauh lebih banyak pekerjaan daripada yang diperkirakan sebelumnya.

Yang mengatakan, tidak ada yang salah dalam memiliki semua aplikasi Anda di repositori kode yang sama , di mana setiap aplikasi memiliki area yang terpisah. Ini memungkinkan Anda, misalnya, memiliki dokumentasi online apa pun yang dihasilkan untuk seluruh basis kode dalam satu tampilan yang konsisten, yang pada umumnya merupakan hal yang baik karena Anda menginginkan visibilitas sebanyak mungkin.

Mereka yang memutuskan ini, harus sangat mempertimbangkan MENGAPA mereka ingin melakukannya, dan mempertimbangkan berapa banyak pekerjaan yang ingin mereka habiskan untuk sampai di sana.

Jika ada satu hal yang membuat pengembangan usaha jadi tidak efisien dan mahal, itu adalah ilusi bahwa dimungkinkan untuk membuat satu sistem yang melakukan segalanya. Jika Anda memiliki satu pemilik produk yang memahami semua detail sistem dan dapat membuat semua keputusan tanpa perlu satu minggu rapat, itu mungkin berhasil, tetapi saya belum pernah melihat itu terjadi.

Secara umum Anda akan lebih baik jika Anda memperlakukannya lebih seperti mengembangkan untuk internet - cukup buat aplikasi Anda sendiri, mengakui bahwa dalam praktiknya Anda tidak memiliki kendali apa pun di luar kode Anda sendiri. Anda bisa mendapatkan hampir semua konsistensi yang Anda inginkan dengan OAuth dan API sederhana untuk pengaturan pengguna dan sedikit CSS yang dibagikan.

Ini sangat mirip dengan maksud asli SOA, tetapi jika Anda menyebutnya bahwa Anda hanya akan berakhir dengan jenis yang berbeda, sistem yang hampir tidak berfungsi yang mencoba melakukan semuanya.

Pemikiran pertama saya adalah ini akan menjadi PITA total untuk rilis.

Memisahkan menjadi beberapa fungsi yang dapat dikelola jauh lebih masuk akal, jika hanya untuk menghindari semua lapisan manajemen dan persetujuan.

Membagi hal-hal umum menjadi komponen / layanan dan standarisasi dengan cara itu akan jauh lebih mudah IMHO.

Anda dapat melakukan pendekatan ini secara berbeda, menggunakan teknologi integrasi seperti Deliverance untuk menentukan tema semua aplikasi web Anda dengan cara yang sama. Pada dasarnya, setiap aplikasi masih terpisah; Deliverance menggunakan aturan XSLT untuk memilih output mereka menjadi template HTML statis yang Anda desain. Hal ini memungkinkan tema HTML / CSS statis yang relatif sederhana untuk diterapkan ke seluruh rangkaian aplikasi dengan minimum celaka.