👙 🧕🏿 👂🏿 Cara memigrasi proses besar dari IBM BPM ke Camunda dan tidak menghentikan pengembangan fitur 💄 🧓🏻 👐🏻

Hai, nama saya Denis, saya bekerja di Tinkoff dan melakukan sistem BPM. Pada artikel ini saya akan memberi tahu Anda cara bermigrasi dari sistem warisan ala IBM BPM ke mesin proses sumber terbuka Camunda menggunakan contoh proses besar. Dan pada akhirnya saya akan mengundang Anda ke pertemuan keempat di Camunda, yang akan diadakan pada 27 Februari di Tinkoff, di Moskow (metro Vodny Stadion) di malam hari.

Sistem BPMS dan BPMN sebagai cara memprogramnya

Gagasan bahwa melalui pemrograman dapat diprogram dijual dengan baik , pasar tumbuh dari tahun ke tahun. Beberapa bisnis mendapatkan hasil yang sangat keren.
Untuk membuat proyek yang baik dan berhasil menjual, sistem BPMS, selain "memakan" file BPMN, juga harus dapat:

Identifikasi pemain tertentu dalam proses
Menyediakan antarmuka untuk pengguna, pelaksana, dan administrator
Hubungi layanan eksternal, kirim dan dengarkan acara, dll. Secara umum, bisa "masuk" ke dalam kode
Menyediakan pemodelan dan penyimpanan data
Ikuti aturan bisnis
Uji semua yang dibuat

Kami menggunakan IBM BPM BPMS di Tinkoff, yang membantu kami berkembang karena kompleksitasnya dan cakupan fitur-fitur ini yang dapat diterima. Tapi kami memutuskan untuk menolaknya.

Alasan untuk meninggalkan IBM BPM

Kami menyadari bahwa dari fungsionalitas hebat sistem BPMS kami hanya menggunakan:

Interpretasi file bpmn
Jatuh ke dalam kode

Hal-hal lain dipindahkan ke sistem lain, misalnya:

, — , , . , BPMS. , — CRM Siebel.
Siebel CRM-. Siebel , — - UI.
Penyimpanan data di suatu tempat dipindahkan ke Siebel - dalam situasi di mana banyak konsumen memerlukan operasi CRUD pada data, dan di suatu tempat - dalam aplikasi terpisah. IBM BPM memungkinkan Anda untuk mensimulasikan data dalam gaya relasional, ia menciptakan pelat untuk model. Tetapi ia menyimpan semuanya dalam satu basis data untuk semua proses, yang menciptakan konektivitas tambahan dan memuat pada basis data.
Untuk aturan bisnis, kami secara tradisional menggunakan IBM ODM, dan sekarang kami mulai menggunakan kerangka kerja Kotlin kami.
Biasanya, dalam gaya pengembangan, kami tidak belajar cara menguji aplikasi pada IBM BPM.

Ada pertanyaan umum yang tidak kami sukai:

Kami beralih ke Kotlin dan Spring, yang sulit di IBM BPM.
Sangat sedikit spesialis atau mereka yang ingin bekerja dengan produk ini.
Kesulitan pengembangan bersama skema \ kode, pada dasarnya mode pengembangan monopoli.
4 3 ( ~40 ), .

Secara terpisah, perlu disebutkan masalah tetangga yang bising - pembatasan lisensi memaksa kami untuk memasukkan banyak produk ke dalam satu kluster. Kami mencoba menggunakan kembali kode umum dalam proses bisnis yang berbeda, yang menimbulkan kesulitan dengan modifikasi.

Misalnya, ada kode pengiriman SMS yang digunakan oleh 2 produk - layanan penyelesaian tunai dan akuntansi outsourcing. Sebelumnya, teks itu dikodekan pada tingkat komponen, tetapi sekarang proses "outsourcing akuntansi" ingin mentransfer teks SMS dari proses. Tetapi proses CSC tidak menginginkan ini, tetapi perubahan harus dilakukan di mana-mana.

Atau bug dangkal bisa menempatkan seluruh pangkalan sehingga banyak produk tidak berfungsi, meskipun mereka tidak bisa disalahkan.

Mengapa mereka memilih Camunda, tulis rekan saya Nikolai di posting sebelumnya.

Apa itu proses besar

Kami memutuskan untuk mentransfer proses besar dari IBM (pada awalnya, kami melatih yang kecil):

Contoh lebih dari 100rb per bulan.
Lebih dari 70 kotak
Lebih dari 30 integrasi dengan sistem lain
Tumpukan cepat tumbuh

Ini adalah proses membuka akun saat ini di Tinkoff Business. Itu tidak mungkin untuk mentransfer proses seperti itu dalam satu pendekatan, jeda 3-4 bulan dalam pengembangan akan diperlukan, yang tidak terlalu cocok untuk laju pengembangan bisnis.
Kami memutuskan untuk pindah berkeping-keping dan memperbaiki segala sesuatu yang ada di tangan. Dan untuk mengatasi masalah tetangga yang bising, kami membuat aplikasi terpisah, yang hanya bertanggung jawab untuk aplikasi layanan penyelesaian tunai.

Di tingkat atas, prosesnya terlihat seperti ini:
gambar

Aturan Transisi

1: Berhenti menggali

Kami memutuskan untuk berhenti membuat fitur baru di aplikasi lama. Ketika tugas muncul di backlog, kami mencoba mengidentifikasi layanan box \ component \ yang terkait dan menulis ulang hal ini dari awal di Camunda. Terkadang dengan biaya 1,2x (x - jika mereka melakukannya di IBM), kadang-kadang - 3x atau 5x.

# 2: Camunda tidak tahu apa-apa tentang IBM

Setelah refactoring, kami hanya ingin mematikan aplikasi lama, jadi kami memutuskan untuk membuat fitur baru di Camunda sehingga tidak tahu apa-apa tentang IBM sama sekali. Dua hal membantu kami:

Data bisnis disimpan di Siebel
API siap pakai dari Camuda yang membantu Anda memahami sepenuhnya bagaimana dan bagaimana proses berakhir.

Sebagai hasilnya, kami membuat proses di IBM yang memulai dan menerima hasil dari Camunda:
gambar

3: "tugas-tugas manual" yang panjang dan proses perekatan

Pertama, kami memindahkan panggilan sinkron satu langkah sederhana ke Camunda dan semuanya bekerja dengan baik. Setelah itu, kami mulai merekatkan hal-hal ini ke dalam "proses bisnis" yang normal, di mana harapan dari pengguna mulai muncul.
Pengguna dapat melakukan tugas mereka selama bertahun-tahun, jadi kami mulai memiliki banyak tugas untuk memperbaiki proses secara manual dari trashhold. Kami menang dengan cara ini - kami baru saja mulai mempertimbangkan jenis tugas tertentu di Camunda dan tidak memperhitungkan trashhold pada tugas-tugas di mana penantian panjang mungkin terjadi.

No 4: Fitur beralih di garpu

Beberapa potongan kode sangat bingung sehingga lebih mudah untuk menulis dari awal dan melihat apakah itu berfungsi dengan baik. Untuk melakukan ini, diperkenalkan ke fitur fitur IBM toggling with gateway. Kami mengirim aliran kecil aplikasi ke Camuda dan melihat pena, semuanya baik-baik saja.
gambar

Migrasi mesin virtual dari IBM ke Camunda

Pada akhirnya, proses di IBM hanya terdiri dari panggilan ke Camunda, dan 3 tingkat proses dikumpulkan di Camunda. Proses bisnis itu sendiri tidak banyak berubah, jadi kami berhasil mentransfer mesin virtual lama dari IBM ke Camunda ke titik tunggu yang sama. Dan mematikan IBM.
gambar

Apa yang harus dilakukan jika Anda memiliki situasi yang serupa

Jika Anda ingin pindah ke Camunda dengan warisan BPMS, maka:

Pindahkan konteks ke database terpisah.
Pindahkan antarmuka pengguna ke aplikasi terpisah.
Hentikan pengkodean fungsionalitas baru di aplikasi lama.
Gunakan panggilan satu arah sehingga Camunda tidak tahu tentang sistem yang lama.
Mulailah dengan kotak kecil, tetapi jangan lupa tentang tugas khusus yang panjang.

Pendekatan ini membantu kami mengurangi jumlah insiden sebanyak 14 kali, waktu regresi sebanyak 4 kali, memungkinkan untuk melepaskan sehari-hari dan mengurangi biaya pengujian manual sebanyak 4 kali. Sekarang 5 orang sedang mengerjakan proyek dan melakukan jumlah pekerjaan yang sama dengan 9 orang dengan IBM. Saya harap hasil Anda tidak akan lebih buruk.

Undangan untuk mitap No. 4 oleh Camunda

27 Februari 2020 (Kamis) pukul 19:30 di Moskow, Golovinskoye Shosse 5A, Pusat Bisnis Vodny, kami akan mengadakan pertemuan lain di Camunda. Anda dapat mendaftar dan membaca tentang speaker di tautan . Datang!

Cara memigrasi proses besar dari IBM BPM ke Camunda dan tidak menghentikan pengembangan fitur