Cerobong asap Perusahaan

Cerobong asap Perusahaan
 
   Cerobong asap Perusahaan antipattern Nama: cerobong asap Kewirausahaan Disebut Juga Sebagai: Kepulauan Otomasi Paling Sering Skala: Kewirausahaan Refactored Solusi Nama: Enterprise Architecture Planning Refactored Solusi Jenis: Penyebab Proses Akar: Haste, Apatis, Narrow-Mindedness seimbang Angkatan: Manajemen Perubahan, Sumber Daya, Alih Teknologi Bukti anekdotal: "Dapatkah saya memiliki pulau sendiri (otomatisasi)?"

Latar belakang
   Cerobong asap adalah istilah populer yang digunakan untuk menggambarkan sistem perangkat lunak dengan arsitektur ad hoc. Ini adalah metafora untuk pipa knalpot dari tungku kayu bakar, yang disebut kompor pot-bellied.

    Sejak pembakaran kayu menghasilkan zat korosif yang mengikis logam, cerobong asap yang harus terus dipertahankan dan diperbaiki untuk menghindari kebocoran. Seringkali, pipa diperbaiki dengan bahan di tangan, pipa kompor sehingga membakar kayu cepat menjadi campur aduk ad hoc perbaikan-karenanya, referensi yang digunakan untuk menggambarkan struktur ad hoc dari banyak sistem perangkat lunak
.
Bentuk umum
   Beberapa sistem dalam suatu perusahaan yang dirancang secara independen pada setiap tingkat. Kurangnya kesamaan menghambat interoperabilitas antara sistem, mencegah penggunaan kembali, dan drive biaya; di samping itu, diciptakan kembali arsitektur sistem dan layanan kekurangan struktur berkualitas mendukung kemampuan beradaptasi.

    Pada tingkat terendah adalah standar dan pedoman. Ini bekerja seperti kode bangunan arsitektur dan hukum zonasi di seluruh sistem perusahaan. Tingkat berikutnya dalam hirarki adalah lingkungan operasi, yang terdiri layanan infrastruktur dan objek.

    Atas dua lapisan termasuk layanan fungsional nilai tambah dan layanan misi khusus. Dengan memilih dan mendefinisikan semua teknologi ini secara mandiri, cerobong asap Usaha "membuat pulau-pulau otomatisasi," terisolasi dari seluruh perusahaan.

 

Gejala Dan Konsekuensi

• Terminologi yang tidak kompatibel, pendekatan, dan teknologi antara sistem perusahaan.
• Rapuh, arsitektur sistem monolitik dan arsitektur yang tidak berdokumen.
• Ketidakmampuan untuk memperpanjang sistem untuk mendukung kebutuhan bisnis.
• Penggunaan yang tidak benar dari standar teknologi.
• Kurangnya penggunaan kembali perangkat lunak antara sistem perusahaan.
• Kurangnya interoperabilitas antara sistem perusahaan.
• Ketidakmampuan sistem untuk beroperasi bahkan ketika menggunakan standar yang sama.
• Biaya pemeliharaan yang berlebihan karena perubahan kebutuhan bisnis; kebutuhan untuk memperluas sistem untuk menggabungkan produk baru dan teknologi.
• Perputaran karyawan, yang menyebabkan diskontinuitas dan pemeliharaan proyek masalah. 

Penyebab khas

• Kurangnya strategi teknologi perusahaan, khususnya:
• Kurangnya model referensi standar
• Kurangnya profil sistem
• Kurangnya insentif bagi kerjasama lintas perkembangan sistem
• Kurangnya komunikasi antara proyek-proyek pengembangan sistem.
• Kurangnya pengetahuan tentang standar teknologi yang digunakan.
• Tidak adanya interface horisontal dalam solusi integrasi sistem. 

dikenal pengecualian
   The Stovepipe Perusahaan antipattern tidak dapat diterima untuk sistem baru pada tingkat perusahaan di hari ini dan usia, terutama ketika sebagian besar perusahaan menghadapi kebutuhan untuk memperluas sistem bisnis mereka. Namun, ketika perusahaan tumbuh dengan pengambilalihan atau merger, cerobong asap antipattern mungkin terjadi; dalam hal ini, membungkus beberapa sistem dapat menjadi solusi menengah.

    Pengecualian lain adalah ketika lapisan layanan umum dilaksanakan di seluruh sistem perusahaan. Ini biasanya merupakan manifestasi dari Vendor Lock-In antipattern. Sistem ini memiliki komponen horizontal umum; misalnya, dalam perbankan, hal ini sering benar database seperti DB2 dan Oracle.”








Solusi refactored
   Koordinasi teknologi pada beberapa tingkatan adalah penting untuk menghindari Enterprise cerobong asap. Awalnya, pemilihan standar dapat dikoordinasikan melalui definisi dari model referensi standar.

    Model referensi standar mendefinisikan standar umum dan arah migrasi sistem perusahaan. Pembentukan lingkungan operasi umum koordinat pemilihan produk dan mengontrol konfigurasi versi produk. Mendefinisikan profil sistem yang mengkoordinasikan pemanfaatan produk dan standar sangat penting untuk memastikan manfaat standar, reuse, dan interoperabilitas. Setidaknya satu profil sistem harus mendefinisikan konvensi penggunaan di seluruh sistem.

 

   Melalui banyak pengalaman, perusahaan besar telah bekerja beberapa konvensi berguna untuk definisi arsitektur berorientasi objek yang dapat berlaku untuk banyak organisasi. Tantangan utama dari arsitektur skala besar adalah untuk menentukan konvensi interoperabilitas rinci seluruh sistem sementara menangani strategi teknologi dan persyaratan. Untuk perusahaan yang sangat besar, pengalaman menunjukkan bahwa empat persyaratan model dan empat model spesifikasi yang diperlukan untuk benar lingkup dan interoperabilitas tekad tantangan. 

Persyaratan model meliputi:

• Sistem Terbuka Model Referensi.
• Profil teknologi.
• Operasi Lingkungan.
• Persyaratan sistem Profile.

Spesifikasi model meliputi:

• Arsitektur enterprise.
• Fasilitas Komputasi Arsitektur.
• Spesifikasi interoperabilitas.
• Profil pengembangan.

    Bagian berikut menjelaskan model ini, yang masing-masing merupakan bagian darirencana perusahaan-arsitektur secara keseluruhan. Rencananya memberikan koordinasi yang efektif antara proyek danmengurangi kebutuhan untuk solusiinteroperabilitas point-to-point.

Sistem Terbuka Model Referensi
    Sebuah model referensi sistem terbuka berisi diagramarsitektur tingkat tinggi dan daftar standar targetproyek pengembangan sistem. Tujuan dari model ini adalah untuk mengidentifikasi semua standar calon proyek, untuk mengkoordinasikan strategi opensistem.

    Sebuah model referensi off-the-rak jenis iniadalah 1003,0 standarIEEE POSIX. Bagian ini dari POSIX daftar berbagai standar terbuka sistem sehubungan denganpenerapan, jatuh tempo, dukungan komersial, dan faktor lainnya. Standar POSIX ini adalah titik awal untuk banyak model referensi-perusahaan tertentu.

 

Teknologi Profil
   Ketika model referensi open-sistem diciptakan kurang dari 10 tahun yang lalu, mereka dianggap menjadi jawaban lengkap untuk sistem interoperabilitas. Sayangnya, pengembang tidak yakin bagaimana model ini mempengaruhi proyek-proyek mereka. Masalah utama adalah bahwa model referensi menentukan tujuan arsitektur masa depan dengan jangka waktu yang tidak ditentukan untuk implementasi. Juga, sekitar sepertiga dari item mengubah status setiap tahun, karena kegiatan badan standar.

    Profil teknologi diciptakan untuk menentukan rencana standar jangka pendek untuk pengembang sistem. Profil teknologi adalah daftar singkat dari standar yang diambil dari model referensi, yang dianggap seperangkat pedoman yang fleksibel; tapi profil teknologi sering mandat standar untuk proyek-proyek pengembangan sistem saat ini dan baru.

    Profil teknologi menjelaskan apa pengembang harus dilakukan tentang standar model referensi; misalnya, AS-DOD Bersama Teknik Arsitektur adalah profil teknis yang mengidentifikasi standar untuk implementasi saat ini.


Lingkungan operasi
   Kebanyakan perusahaan besar memiliki hardware dan software yang heterogen arsitektur, tapi bahkan dengan infrastruktur yang konsisten, praktek instalasi bervariasi dapat menyebabkan masalah serius bagi perusahaan interoperabilitas, penggunaan kembali perangkat lunak, keamanan, dan manajemen sistem.

    Lingkungan operasi mendefinisikan rilis produk dan konvensi instalasi yang didukung oleh perusahaan, dan menetapkan pedoman yang harus fleksibel lokal, untuk mendukung R & D dan sistem yang unik persyaratan.

    Perusahaan dapat mendorong kepatuhan dengan konvensi ini melalui layanan dukungan teknis dan prosedur pembelian; dengan kata lain, perusahaan dapat mempengaruhi adopsi dari lingkungan yang direkomendasikan oleh membuat mereka konfigurasi sistem yang paling mudah untuk mendapatkan dan dukungan. Variasi dari lingkungan operasi harus didukung secara lokal dengan biaya tambahan.

Persyaratan sistem Profile
    Perencanaan arsitektur enterprisesering menghasilkan luas, tingkat tinggi dokumenpersyaratan. Untuk keluarga tertentu sistem, persyaratan mungkin tidak jelas bagi pengembang karena tipis volume informasi. Profil persyaratan sistem adalah ringkasan persyaratan kunci untuk keluarga sistem terkait. Kerangka waktu adalah jangka pendek. Idealnya, dokumen ini hanya beberapa lusin halaman panjang, ditulis untuk memperjelas tujuan pelaksanaan ditujukan untuk sistem komponen dan proyek pengembangan aplikasi.

    Profil persyaratan sistem mengidentifikasi scoping diperlukan kemampuan sistem, dan dengan demikian merupakan titikloncatan off untukperencanaan kebutuhan perusahaan. Saldo model perencanaanperusahaan yang arsitektur dan desain spesifikasi (yang dijelaskan dalam bagian berikutnya), yang diekspresikan melalui model berorientasi objek dan terdiri satu setarsitektur perangkat lunak berorientasi objek.

Enterprise Architecture
    Arsitektur enterprise adalah seperangkat diagram dan tabel yang mendefinisikan sebuah sistem atau keluarga sistem dari berbagai sudut pandang pemangku kepentingan; dengan demikian, arsitektur enterprise terdiri pemandangan seluruh sistem. Frame waktu sekarang dan masa depan digambarkan, dan masing-masing pandangan membahas isu-isu yang ditimbulkan oleh pemangku kepentingan utama, seperti pengguna akhir, pengembang, operator sistem, dan spesialis teknis.

    Konsistensi pandangan arsitektur dan notasi seluruh proyek penting, untuk arsitektur enterprise memungkinkan komunikasi teknis di seluruh proyek. Reuse dan interoperabilitas peluang dapat diidentifikasi ketika proyek berbagi arsitektur mereka. Sejak proyek-proyek individu memiliki pengetahuan sebagian besar rincian teknis, arsitektur-proyek tertentu dapat dikompilasi menjadi akurat, perusahaan lebar arsitektur. 

Fasilitas Komputasi Arsitektur
   Seperti hanya menjelaskan, arsitektur enterprise adalah alat komunikasi penting bagi pengguna akhir dan arsitek. Setiap detail spesifikasi yang tersisa arsitektur komputasi yang mendefinisikan antarmuka untuk interoperabilitas dan digunakan kembali.

    Sebuah fasilitas komputasi arsitektur (CFA) mengidentifikasi dan mendefinisikan poin kunci interoperabilitas untuk keluarga sistem. Setiap fasilitas mengidentifikasi satu set antarmuka program aplikasi (API) dan objek data umum yang didefinisikan secara rinci dalam spesifikasi interoperabilitas.

    Sebuah CFA partisi interoperabilitas perusahaan itu perlu menjadi spesifikasi dikelola; itu juga mendefinisikan peta jalan prioritas dan jadwal untuk fasilitas. Hal ini diperlukan untuk memulai dan memandu perumusan spesifikasi interoperabilitas.

    Mencapai konsensus pada fasilitas dalam CFA merupakan tantangan utama bagi banyak perusahaan. Kesalahpahaman berlimpah mengenai peran fasilitas dalam kaitannya dengan persyaratan eksternal, kebutuhan untuk sistem kemerdekaan, definisi abstraksi umum, dan perlunya membatasi lingkup fasilitas.
Interoperabilitas Spesifikasi

    Spesifikasi interoperabilitas mendefinisikan rincian teknis dari fasilitas komputasi. Spesifikasi interoperabilitas khas termasuk API didefinisikan dalam IDL dan objek data umum definisi.

    Spesifikasi interoperabilitas membangun poin kunci dari interoperabilitas dengan cara yang independen dari setiap sistem tertentu pelaksanaan subsistem. Pertambangan arsitektur adalah proses yang sangat efektif untuk menciptakan spesifikasi ini Selama pemeliharaan sistem, poin-poin penting dari interoperabilitas menjadi nilai tambah entry point untuk perpanjangan sistem.
Pengembangan Profil

    Sebuah spesifikasi interoperabilitas saja tidak cukup untuk menjamin keberhasilan integrasi, karena semantik API dapat diartikan berbeda oleh pelaksana yang berbeda. Desain API kuat telah built-in fleksibilitas yang memungkinkan perluasan dan penggunaan kembali, dan rincian penggunaannya sering ditemukan dalam proses pembangunan. Beberapa rincian ini mungkin unik untuk satu set tertentu dari sistem.

    Profil pengembangan mencatat rencana pelaksanaan dan perjanjian pengembang yang diperlukan untuk menjamin interoperabilitas dan integrasi sukses. Profil pengembangan mengidentifikasi bagian-bagian dari spesifikasi API yang digunakan, ekstensi lokal untuk spesifikasi, dan konvensi yang mengkoordinasikan integrasi.

    Meskipun penting untuk konfigurasi kontrol semua model ini, profil pembangunan dokumen yang berkembang di seluruh pembangunan dan kehidupan pemeliharaan siklus kerja. Profil pengembangan beberapa mungkin ada untuk spesifikasi API tunggal, yang masing-masing membahas kebutuhan integrasi domain tertentu atau keluarga sistem.

Contoh
   Sistem 1 dan sistem 2 mewakili dua Sistem cerobong asap di perusahaan yang sama. Sementara serupa dalam banyak cara, sistem ini kurang kesamaan; mereka menggunakan produk database yang berbeda, alat otomatisasi kantor yang berbeda, memiliki antarmuka perangkat lunak yang berbeda, dan menggunakan antarmuka pengguna grafis yang unik (GUI). Kesamaan potensial antara sistem ini tidak diakui dan karenanya tidak dimanfaatkan oleh para desainer dan pengembang.”

 

   Untuk mengatasi antipattern, perusahaan mulai dengan mendefinisikan model referensi standar. Model ini, memilih beberapa standar dasar untuk pertukaran di semua sistem. Langkah berikutnya adalah memilih produk untuk lingkungan operasi. Dalam hal ini, kedua produk database yang dipilih, tetapi hanya salah satu alat otomatisasi kantor.

    Ini adalah arah didukung untuk migrasi masa depan perusahaan. Perusahaan dapat memfasilitasi lingkungan operasi ini melalui lisensi produk perusahaan, pelatihan, dan dukungan teknis. Tingkat ini juga mendefinisikan profil untuk penggunaan teknologi tersebut dan antarmuka umum dengan implementasi layanan dapat digunakan kembali. Aplikasi GUI terdiri dari implementasi sistem yang tersisa.”  

Solusi terkait
    Menemukan kembali roda merupakan antipattern yang terdiri dari subset dari masalah keseluruhan Stovepipe Systems. Menemukan kembali roda difokuskan pada kurangnya kematangan desain dan implementasi yang disebabkan oleh kurangnya komunikasi antara proyek-proyek pembangunan.

Standar model referensi, lingkungan operasi, dan profil solusi dari Pola Desain buku CORBA Mereka semua komponen penting dalam larutan Stovepipe Enterprises.

Contoh model referensi standar termasuk IEEE POSIX.0, NIST Aplikasi
Berlakunya Untuk Pandangan Dan Timbangan Lainnya

    Cerobong asap Usaha seringkali merupakan konsekuensi dari batas-batas organisasi yang dikenakan oleh manajemen. Struktur organisasi yang menghambat komunikasi dan transfer teknologi menghasilkan jenis terputus yang mengakibatkan kurangnya koordinasi yang mencirikan cerobong asap Enterprises.

    Dampak dari Stovepipe Perusahaan antipattern pada manajemen adalah bahwa setiap pengembangan sistem melibatkan risiko yang signifikan tetapi tidak perlu dan biaya. Karena sistem tidak beroperasi dan sulit untuk mengintegrasikan, efektivitas organisasi secara keseluruhan dipengaruhi.

    Kemampuan organisasi untuk mengakomodasi perubahan kebutuhan bisnis yang sangat terhambat oleh cerobong asap Perusahaan. Sebuah persyaratan yang muncul untuk perusahaan disebut sistem gesit, yang mampu mengakomodasi perubahan dalam proses bisnis karena mereka sudah mendukung interoperabilitas di sebagian atau seluruh sistem perusahaan.

    Pengembang juga dipengaruhi oleh Stovepipe Perusahaan karena mereka sering diminta untuk menciptakan solusi rapuh untuk menjembatani sistem mandiri architected. Interface ini sulit untuk mempertahankan dan menggunakan kembali, dan tidak adanya koordinasi teknologi membuat penciptaan antarmuka ini cukup menantang. Seringkali, kombinasi dari solusi middleware dan produk komersial (mesin database) harus dijembatani untuk mencapai interoperabilitas.”