 |
| 5 Pertanyaan Ketika Merencanakan Sistem Integrator |
Perencanaan sistem integrator adalah proses menggabungkan sub-sistem yang lebih kecil ke dalam satu sistem yang lebih besar untuk memastikan mereka semua bekerja bersama. Integrasi adalah landasan lingkungan perusahaan saat ini dengan banyak sistem perencanaan sumber daya perusahaan (ERP) mereka.
Kekuatan dari aplikasi perangkat lunak itu tidak hanya terletak pada fungsi yang mereka sediakan sendiri, tetapi pada kemampuan mereka untuk berkomunikasi satu sama lain, untuk membuat data mengalir mulus melalui lingkungan. Ini meningkatkan proses dan membuat perusahaan lebih efisien secara keseluruhan.
Ketika memikirkan integrasi, standar layanan web seperti SOAP dan REST muncul di pikiran. Itu dimaksudkan untuk menyederhanakan integrasi dengan sejumlah besar alat pendukung yang dibangun di sekitarnya.
Sayangnya, alat itu sendiri bukanlah solusi untuk masalah integrasi Anda, tetapi hanya alat untuk implementasi yang lebih cepat. Solusi nyata adalah perencanaan dan desain integrasi sistem yang tepat , yang perlu didasarkan pada kriteria yang tepat. Dan itu tidak selalu terjadi dalam suatu proyek.
Jadi, apa metode terbaik untuk desain ketika mengintegrasikan dua sistem ? Nah, ada sejumlah pertanyaan yang perlu dijawab dalam tahap perencanaan.
Mari kita membahas 5 pertanyaan utama ini:
1. Apa data yang dibutuhkan sistem target untuk menyelesaikan tugas integrasi?
Identifikasi data target adalah langkah pertama yang penting. Ini mendefinisikan objek atau tabel apa yang perlu diakses, dan aturan yang harus dipenuhi oleh data. Biasanya, model data target mendorong desain titik integrasi khusus, jika diperlukan.
2. Di mana data yang dibutuhkan oleh sistem target berada di sistem sumber, dan transformasi apa yang diperlukan?
Contoh umum untuk tipe data yang perlu diubah adalah angka dan tanggal. Misalnya, format tanggal dan zona waktu mungkin berbeda antara sistem dan harus dikonversi.
3. Apa yang dianggap sebagai transaksi dalam tugas integrasi dan apakah ada ketergantungan antara transaksi?
Transaksi adalah unit kerja atom. Ini hanya mengubah keadaan sistem target jika data berhasil ditransfer dan diproses.
Jika ada kegagalan, apakah itu selama transportasi atau pemrosesan (yaitu validasi), harus dipastikan bahwa sistem target tetap tidak berubah. Misalnya, jika transaksi membuat beberapa catatan dalam sistem target (yaitu akun dan kontak, dan akun berhasil dibuat tetapi kontak gagal validasi), harus dipastikan bahwa catatan akun dihapus lagi. Dengan cara ini sistem target memiliki status yang sama di akhir transaksi seperti ketika dimulai.
4. Bagaimana Anda akan terhubung ke sistem target (nama domain, IP, dll.) Dan kendala keamanan apa yang berlaku (sertifikat, kredensial, dll.)?
Konektivitas dan kendala keamanan harus diidentifikasi dan diverifikasi sejak awal dalam proyek. Karena itu sering dapat menjadi alasan untuk proyek ditunda atau bahkan gagal sama sekali. Alasannya bermacam-macam seperti: aturan firewall yang hilang, sertifikat yang diperlukan, pengaturan peran keamanan dan kredensial baru, ketidakcocokan protokol antara sumber dan sistem target - hanya untuk beberapa nama.
Dari perspektif teknis, sebagian besar masalah tersebut dapat diselesaikan. Tetapi seringkali proses atau kendala tambahan yang hanya diidentifikasi selama validasi, yang menambah lebih banyak risiko dan upaya untuk proyek sistem integrator.
Misalnya, sistem target atau sumber mungkin perlu ditambal sebelum mereka dapat berkomunikasi satu sama lain. Di sisi lain, tim jaringan mungkin perlu membuka firewall dan membuat entri nama domain (DNS) baru untuk koneksi yang akan dibuat. Ini biasanya bukan masalah teknis yang sangat kompleks, tetapi tergantung pada ukuran perusahaan, mereka mungkin memerlukan persetujuan dan keterlibatan kelompok lain yang membutuhkan waktu tambahan.
Dalam beberapa kasus, perubahan seperti menambal sistem dapat menimbulkan konflik ke bagian lain dari organisasi, yang dapat membuat integrasi menjadi lebih sulit atau bahkan tidak mungkin.
5. Opsi antarmuka apa yang Anda miliki (REST, SOAP, Custom, dll.)?
Opsi antarmuka berdampak pada alat dan desain implementasi. Ini karena mereka membantu menentukan apakah solusi harus sepenuhnya sesuai pesanan atau apakah solusi yang dihasilkan adalah metode integrasi sistem yang efektif.
Menciptakan desain yang tepat mungkin tidak selalu termasuk jalur solusi paling sederhana atau paling mudah.
Pengaruh Persyaratan Transaksional pada Proses Integrasi Sistem
Untuk menunjukkan dampak persyaratan transaksional pada desain integrasi, mari kita lihat contoh pengiriman pesanan dari sistem Manajemen Hubungan Pelanggan (CRM) ke sistem manajemen pesanan (OMS). Sebelum pesanan dapat dikirimkan, sistem perlu memastikan bahwa akun ada karena pesanan harus ditautkan dengannya. Jika tidak ada, anggap persyaratannya adalah untuk membuatnya sebagai bagian dari integrasi juga. Akun hanya boleh dibuat untuk pengiriman pesanan yang berhasil, tetapi tidak jika pengiriman pesanan gagal.
OMS menyediakan antarmuka SOAP standar yang memungkinkan operasi data tipikal (dibuat CRUD, diperbarui, dihapus) pada entitas, seperti akun dan pesanan. Ini juga menyediakan kemampuan untuk membuat titik akhir layanan web kustom yang diekspos melalui antarmuka SOAP yang sama.
Sekarang, memilih antarmuka SOAP standar memiliki keuntungan yang tidak diperlukan pengembangan kustom di dalam OMS. CRM pertama dapat membuat akun menggunakan antarmuka akun dan kemudian membuat pesanan melalui antarmuka pesanan. Namun, sementara ini tampaknya seperti pendekatan yang diinginkan untuk implementasi, ada kelemahan yang perlu dipertimbangkan.
Karena antarmuka akun dan pesanan dipisahkan oleh titik akhir yang berbeda, itu memerlukan dua permintaan SOAP independen untuk mengirimkan pesanan. Ini berarti bahwa risiko saluran komunikasi menyebabkan kesalahan berlipat ganda. Ini juga berarti bahwa itu memerlukan permintaan tambahan untuk menghapus akun jika pengiriman pesanan gagal memenuhi persyaratan transaksional untuk akun yang hanya dibuat dengan pesanan yang berhasil. Permintaan penghapusan itu sendiri memiliki risiko kegagalan, dan itu akan membuat OMS dalam keadaan tidak valid, karena akun itu ada, tetapi pesanannya tidak.
Perencanaan Integrasi yang Lebih Baik
Untuk mengatasi semua masalah yang disebutkan di atas, titik akhir khusus dapat dibuat dalam OMS yang akan menggunakan data untuk akun dan memesan dalam satu permintaan. Logika yang memproses permintaan akan memiliki kemampuan untuk memvalidasi semua data yang ditransmisikan untuk pembuatan akun dan pesanan sebelum bahkan mencoba untuk mempertahankan informasi dalam database. Dan itu akan dapat menangani pembersihan akun jika entri pesanan gagal.
Selain itu, hanya satu permintaan akan dibuat dari CRM, yang berarti lebih sedikit overhead, lebih sedikit risiko kegagalan, dan keseluruhan proses integrasi diselesaikan lebih cepat daripada jika menggunakan beberapa permintaan melalui antarmuka standar.
Ini hanya satu contoh. Tentu saja, meskipun ada banyak alasan untuk mempertimbangkan titik akhir kustom dalam kasus yang diberikan, itu tidak berarti bahwa itu selalu merupakan pilihan untuk menempuh jalan itu. Menggunakan antarmuka standar jelas merupakan opsi yang layak juga, tetapi disertai dengan peningkatan risiko dan kompleksitas, dan itu perlu dipahami dan dimasukkan dalam perencanaan proyek.
Setiap sistem integrator dilengkapi dengan tantangannya sendiri. Menjawab pertanyaan-pertanyaan yang tercantum di atas akan membantu menyelesaikan tantangan-tantangan itu dengan cara yang benar. Selain itu, jika validasi yang benar dilakukan dimuka untuk mengidentifikasi dan mengatasi faktor-faktor risiko di sekitar konektivitas dan keamanan, itu hanya masalah waktu sampai kedua sistem terintegrasi satu sama lain, sehingga meningkatkan produktivitas perusahaan Anda.
0 Komentar