Terdapat solusi untuk masalah-masalah yang berlandaskan dr kerja dari organizasi.

Solusi tersebut alaminya sudah lama dan akhirnya menjadi sebuah warisan dari
rekayasa perangkat lunak era sebelumnya. Mendadak meninggalkan solusi warisan
dan pergantian secara instan mereka dengan sesuatu yang baru dan lebih baik
tentunya bukan sebuah pilihan yang normal. Padahal, harus dicari solusi yang
memungkinkan transisi yang halus dan pergantian secara bertahap.
Masalah utama dalam banyak kasus adalah tidak adanya keseluruhan arsitektur
yang jelas
dari sistem pewarisan, dikombinasikan
dengan arsitektur yang
halus/tersaring pada tingkat abstraksi yang lebih rendah. Tidak mengherankan,
beberapa jenis arsitektur biasanya muncul di waktu sistem baru pertama kali
disusun. Tentu, arsitektur awal ini membuktikan tidak memadai sebagai sistem
berkembang, malah berhati-hati perkembangan arsitektur juga, itu sering
tertinggal. Sebagai sistem berkembang secara independen dari arsitektur
dipertahankan, itu "memperburuk keadaan" dari waktu ke waktu. Migrasi ke
teknologi baru kemudian menjadi masalah re-engineering dan sering bahkan dari
reverse engineering dalam ketiadaan dari bimbingan dokumen tingkat tinggi.
Kemudian, warisan menjadi beban besar.
Untuk mencegah kerusakan arsitektur, sistem perlu diganti/diperiksa berkala.
Manfaat yang jelas dari arsitektur berbasis komponen adalah dukungan dari
refactoring lokal. Refactoring dalam komponen paling mudah, tapi sebuah hirarkis
arsitektur keseluruhan juga memungkinkan refactoring selektif dari subsistem.
Refactoring memiliki efek semakin luas seperti yang diambil jauh di hirarki
arsitektur secara keseluruhan. Hal demikian berguna untuk merancang sebuah
hirarki arsitektur dari awal dengan refactoring dalam pikiran. Secara khusus, setiap
bentuk penggabungan perlu menurunkan kecepatan ketika pindah menuju tingkat
hirarki yang lebih tinggi.
Sebuah aspek yang terpisah namun terkait adalah interoperabilitas melintasi ruang
dan waktu. Interoperabilitas melintasi waktu sering disebut kompatibilitas mundur
dan kompatibilitas maju. Masalahnya adalah: bagaimana dua sistem perangkat
lunak, dipisahkan keduanya oleh evolusi waktu atau dengan pengembangan
independen atas ruang, bekerja sama? Pada semantik level, ini memerlukan definisi
bersama. Pada tingkat infrastruktur, itu membutuhkan penghubung yang berbagi
bersama. Ini adalah aspek kedua yang sering disebut sebagai interoperabilitas.
Pengenalan teknologi baru - tanpa pengenalan pendekatan arsitektur yang
memadai menangani semua tingkatan relevan secara simultan - dapat memiliki
efek bencana. Dalam membangun adopsi awal teknologi berorientasi objek,
arsitektur yang besar sering diabaikan. Objek-objek dibuat dan saling dihubungkan,
semuanya melewati sebuah sistem. Lapisan-lapisan tidak diperkenalkan atau tidak
dihormati. Garis antara pusat dan ekstensinya tidak diambil atau dilanggar. Hasilnya
adalah bahwa warisan berorientasi objek menjadi sebuah masalah kadang-kadang
setelah hanya adopsi beberapa tahun (misalnya Casais et al., 1996).

Misalnya, Komisi Eropa di bawah program Esprit membiayai proyek besar tentang
evolusi dan rekayasa ulang dari "pewarisan sistem berorientasi objek" (FAMOOS
Consortium, 1996). Proyek tersebut berakhir pada tahun 1999 dan dikabarkan
terdapat sejumlah teknik-teknik yang dapat membantu untuk memperoleh kembali
pondasi kerangka kerja atau framework dari implementasi yang menghilangkan
informasi tampilan arsitektur. Berdasarkan informasi tersebut, membangun ulang
(refactoring) kerangka kerja didukung.
Dengan argumen yang ada dalam Bab 7 dalam pikiran , tidaklah mengherankan
bahwakurangnya arsitektur keseluruhan dalam sistem berorientasi objek adalah
jauh lebih buruk daripada di sistem prosedural tradisional . Hal ini semakin
dipahami hari ini dan sering mengarah ke pecahan awal " ilusi OO". Meskipun itu
adalah tugas yang sulit untuk memindahkan perangkat lunak ke perpustakaan
prosedural lainnya , itu adalah tugas yang sangat menakutkan untuk mencoba
migrasi ke kerangka kelas yang berbeda . Sangat sedikit kerangka kelas tradisional
telah dirancang bisa cocok dengan kerangka kerja lainnya . Implementasi yang
berasal dari kelas-kelas kerangka kelas tertentu sangat erat digabungkan dengan
kerangka kerja mereka . Evolusi Independen kerangka tersebut sudah menjadi
masalah ( lihat, misalnya , pembahasan masalah rapuhnya kelas dasar di Bab 7 ) .
Pertukaran kerangka kerja untuk yang lain hampir tidak mungkin .
Interoperabilitas pada skala global, seperti yang didorong oleh internet dan web ,
memperkenalkan dimensi baru . Arsitektur di tingkat atas sekarang harus bersifat
global itu sendiri . Hal ini untuk mencakup batasan , organisasi , pelanggan , dan
vendor yang serupa. Ada ruang untuk beberapa arsitektur - tidak semuanya perlu
mengintegrasikan dengan segala sesuatu yang lain pada tingkat semantik
tertinggi . Sebagai contoh, arsitektur manajemen objek ( OMA ) OMG merupakan
salah satu upaya ambisius untuk membakukan bagian dari arsitektur global ( Bab
13 ) .