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 ) .