Apa nilai alat workflow? [Tutup]

Saya baru dalam pengembangan Workflow, dan saya tidak berpikir saya benar-benar mendapatkan "gambaran besar". Atau mungkin dengan kata lain, alat-alat ini saat ini tidak "klik" di kepala saya.

Jadi tampaknya perusahaan suka membuat gambar bisnis untuk menggambarkan proses, dan pada titik tertentu seseorang memutuskan bahwa mereka dapat menggunakan program seperti mesin negara untuk benar-benar mengendalikan proses dari garis dan kotak seperti diagram. Sepuluh tahun kemudian, alat-alat ini sangat besar, sangat rumit (perusahaan saya saat ini bermain-main dengan WebSphere, dan saya telah mengikuti beberapa pelatihan, ini monster, bahkan versi yang disebut "minimalis" dari alat alur kerja ini seperti Activiti adalah besar dan rumit meskipun hampir tidak serumit binatang buas yang WebSphere afaict).

Apa manfaat besar melakukannya dengan cara ini? Saya bisa memahami diagram garis dan kotak sederhana yang bermanfaat, tetapi hal-hal ini, sejauh yang saya tahu, adalah bahasa pemrograman visual pada saat ini, lengkap dengan persyaratan dan loop. Programmer di sini tampaknya melakukan sejumlah besar pekerjaan di lapisan garis dan kotak, yang bagi saya hanya tampak seperti bahasa pemrograman visual yang benar-benar jelek, benar-benar dasar.

Jika Anda akan melangkah sejauh itu, mengapa tidak menggunakan semacam bahasa scripting saja? Pernahkah orang membuang bayi dengan air mandi? Apakah garis dan kotak telah dibawa ke tingkat yang tidak masuk akal, atau apakah saya hanya tidak memahami nilai dalam semua ini?

Saya benar-benar ingin melihat argumen yang mendukung hal ini oleh orang-orang yang telah bekerja dengan teknologi ini dan memahami mengapa ini berguna. Saya tidak melihat nilai di dalamnya, tetapi saya menyadari bahwa saya juga baru dalam hal ini dan mungkin belum mendapatkannya.

Dari sudut pandang pengembang, Anda benar mengatakan bahwa lingkungan "visual" ini sangat sulit untuk dikerjakan. Alur Kerja SharePoint 2010, yang saya gunakan, membuang setiap praktik terbaik dalam menciptakan perangkat lunak perusahaan yang baik - tidak ada pengujian otomatis, tidak ada kode yang digunakan kembali, perangkat lunak yang tidak dapat dibaca ... Apa pun yang lebih rumit daripada templat yang tidak biasa mungkin akan sulit untuk dipertahankan , seperti yang Anda alami.

Tetapi dari sudut pandang bisnis, alur kerja memiliki manfaat besar - setidaknya, secara teori. Mengutip dari buku putih ini , Efisiensi, Akuntabilitas, Kontrol dan Kemudahan penggunaan alur kerja otomatis memberikan keuntungan produktivitas yang sangat besar. Bayangkan betapa tidak efisiennya persetujuan sederhana atau proses naik pesawat tanpa otomatisasi ini. Juga, tindakan mendefinisikan alur kerja sangat berharga bagi organisasi yang mencoba untuk mendapatkan kontrol atas proses bisnis mereka.

Keadaan saat ini dari perangkat lunak alur kerja bukan kesalahan bisnis. Mereka hanya ingin membuat hidup mereka lebih mudah, dan alur kerja sangat bagus untuk itu. Saya kebanyakan akan menyalahkan kami, departemen TI:

1. Karena tidak lebih transparan dengan bisnis tentang betapa rumit dan rapuhnya sistem sebenarnya. Kami menyembunyikan semua kerumitan.
2. Karena tidak dapat "menggaruk gatal" dengan solusi alur kerja yang intuitif dan sederhana. Ini mungkin lebih dari kata kasar terhadap paket perusahaan besar seperti SharePoint dan SAP, tetapi mereka lebih baik daripada solusi kustom di luar sana

Hanya ada satu manfaat nyata, namun sangat besar: Pemisahan Kekhawatiran .

Jadi, alih-alih logika proses orkestrasi yang tertanam di sistem kami, itu menjadi dan konfigurasi eksternal. Peta, pada dasarnya. Anda dapat mengubahnya (lebih banyak) secara independen, Anda dapat memiliki beberapa proses, beberapa versi proses, beberapa versi dari beberapa proses yang berjalan pada saat yang sama, dan itu semua di luar kotak dalam solusi yang layak.

Secara historis, konsep SoC telah menang berkali-kali - mulai dari prinsip Unix "lakukan satu hal, tapi lakukan dengan baik", dan diterapkan berulang-ulang - seperti memiliki komponen server khusus seperti ESB, sistem ketahanan berbeda, caching, load balancing , memantau, seperti memisahkan CSS dari HTML, dll.

Proses bisnis Anda dan aturan alirannya seringkali ortogonal dengan data Anda, "layar" UI, atau "hierarki" pengguna. Jadi, sangat masuk akal untuk mengembangkan dan mengubahnya secara terpisah dari aspek lain dari sistem. Itu adalah premis di mana BPM muncul di awal 1990-an.

Sejak itu, banyak alat dan bahasa diciptakan untuk mendukung konsep ini, dengan yang paling terkenal adalah BPMN - bahasa grafis untuk membuat "diagram alur" yang secara langsung memetakan ke proses. Sementara orang-orang mengeluh bahwa itu besar dan berat (memiliki lebih dari 100 simbol dalam kosa kata), dan menganjurkan pendekatan modern seperti S-BPM (hanya memiliki 5 simbol dasar), praktik industri saat ini adalah tetap berpegang pada BPMN atau turunannya, himpunan bagian atau saudara kandungnya.

Anda tidak terlihat senang dengan BPMN:

Programmer di sini tampaknya melakukan sejumlah besar pekerjaan di lapisan garis dan kotak, yang bagi saya hanya tampak seperti bahasa pemrograman visual yang benar-benar jelek, benar-benar dasar.

Tapi itu tidak seburuk itu) Ada teori di baliknya. Dan versi 2.0 mengambil beberapa wawasan yang bagus dari 1.0 kekurangan.

Jika Anda akan melangkah sejauh itu, mengapa tidak menggunakan semacam bahasa scripting saja?

Paradigma imperatif dan bahasa penulisan skrip tidak selalu merupakan jawaban terbaik. Seperti yang mungkin Anda lihat dalam bahasa deklaratif (seperti HTML, CSS, SQL, Drools atau internal Nginx, Graddle dan Maven, Puppet dll) kode yang dihasilkan bisa jauh lebih kecil dan lebih bersih, daripada versi yang ditulis dalam " bahasa yang layak," seperti Java atau C ++ ".

Adapun poin Anda yang lain:

sejauh yang saya tahu, adalah bahasa pemrograman visual pada saat ini, lengkap dengan persyaratan dan loop.

apakah Anda sudah melihat Acara dan Pemicu ? BPMN adalah bahasa dan Anda harus mempelajarinya sebelum menggunakan, atau paling tidak membiasakan diri dengannya.

Di bawah tenda, BPMN adalah XML, sehingga Anda dapat mengeditnya dengan tangan, atau menghasilkan. Dan Anda dapat mengontrol versi mereka, karena XML berbasis teks. Namun, hanya memiliki XML yang dapat diterjemahkan ke dalam diagram alur, tidak terdengar seperti goona membantu Anda, dan itu benar - menulis parser atau editor Anda sendiri untuk itu adalah tugas yang sulit dan mahal dengan manfaat yang dipertanyakan.

Untungnya, sudah ada alat di pasar yang melakukan hal itu.

Activiti gratis, dan cukup populer di kalangan pengembang dan pemilik bisnis, karena harga awalnya ( nol ), ketersediaan informasi, dan kerendahan hati. Poin terakhir benar-benar unik, karena Activi hanya berfokus pada pengelolaan proses bisnis Anda, tanpa berusaha mengikat Anda dengan solusi seluruh paket. Selain itu, terbuka - jadi Anda hanya perlu tahu Java dan REST untuk menjalankannya. Kekurangannya adalah sisi klien, integrasi dan logika aplikasi / bisnis dan seluruh arsitektur diserahkan kepada pengembang, jadi jika tim pengembangan Anda lemah - bersiaplah untuk yang gagal. Total biaya kepemilikan bisa sangat tinggi untuk alat gratis ;)

Di sisi lain spektrum adalah Pega (Pega PRPC), raja yang berkuasa dari sistem BPM (menurut Gartner dan Forester), yang terlihat sangat baik untuk usianya. Raksasa dapur-wastafel ini bahkan mampu CRM, OCR dan (jika saya tidak salah) kemampuan pengenalan suara, analisis prediktif, manajemen aturan bisnis dan editor WYSIWYG UI. Muncul dengan label harga yang serius. Tidak hanya harganya mahal, tetapi semua pengembangan sedang dilakukan dalam aplikasi web, yang berarti Anda harus menggunakan browser, yaitu IE8 (plus beberapa plugin, ditambah peretasan jelek, seperti menggunakan Excel untuk mengedit tabel data). Juga, pengeditan Java, Javascript, atau HTML / CSS juga dilakukan dengan browser web - jadi selamat tinggal pada tes unit, menyoroti kode IDE, refactoring, dan semua mainan pemrograman yang Anda sukai.

Sisi baiknya? Anda dapat menerapkan sistem yang kompleks DALAM MINGGU [ PDF , lihat halaman 22]. Dan ya, hasilnya tidak dijamin.

IBM baru-baru ini (menyesuaikan dengan kecepatan waktu perusahaan) telah membeli Lombardi, dan sekarang menawarkan solusi yang sangat kompetitif (tetapi kemudian Anda harus membeli semuanya ibm , Anda tahu). Appian adalah vendor muda yang memiliki wawasan menarik dan umpan balik positif, tetapi cara mereka ditulis (dua bahasa DSL tambahan selain yang visual) tidak menarik bagi saya.

Ada pemain lain, dan solusinya. Kebanyakan dari mereka benar -benar mengerikan. Seperti - mata, otak, dan hati Anda akan benar-benar berdarah, ketika Anda hanya melihatnya. Jadi, percayalah pada nyali Anda dan jangan membuat pengembang dan pengguna Anda membenci Anda.

Catatan penutup:

Sistem BPM sama untuk proses, apa Photoshop untuk gambar. Jangan takut itu visual. Jangan membuatnya melakukan pekerjaan yang tidak sesuai untuk itu (ingat situs web yang dibuat seluruhnya di Photoshop, yang hampir mustahil untuk diedit?). Tetap sederhana dan jangan membuat bug;)

Bertahun-tahun yang lalu, sebelum kebanyakan dari kita dilahirkan, pengembang perangkat lunak harus menulis kode mereka sendiri untuk menyimpan data. Jika Anda perlu menyimpan status program, yah, itu dilihat sebagai bagian dari fungsi kode, sehingga banyak pengembang perangkat lunak akhirnya menulis kode untuk mengatur data dan menyimpan serta membacanya dan sebagainya.

Dan kemudian seseorang menyadari bahwa ini adalah sesuatu yang sering terjadi - bahwa, logika untuk menyimpan, mengatur, membaca dan mencari data sebenarnya adalah komponen yang sangat umum digunakan sehingga seharusnya komponen itu sendiri. Dan kami punya basis data.

Dalam 10 hingga 15 tahun terakhir, departemen TI telah menyadari bahwa logika untuk koreografi dan / atau mengatur proses bisnis sangat umum sehingga juga harus merupakan komponennya sendiri, yang telah mengarah ke semua jenis alat alur kerja yang berbeda.

Ada 3 manfaat utama alat alur kerja:

1. Waktu yang diperlukan untuk membuat dan menggunakan perubahan : Anda dapat mengembangkan dan mengubah logika alur kerja tanpa risiko teknis yang sama dengan yang Anda miliki dengan mengubah sepotong kode.
2. Transparansi : logika bisnis dalam sistem berbasis BPM segera tersedia dan dapat dibaca oleh analis bisnis, sedangkan hanya pengembang yang dapat membaca logika bisnis dalam sistem "berbasis kode".
3. Penggunaan kembali komponen teknis : Alat BPM sering digunakan bersama dengan sistem yang memiliki Arsitektur Berorientasi Layanan. Dengan memisahkan logika bisnis dari komponen teknis - terutama untuk sistem perusahaan yang harus menerapkan ratusan atau ribuan proses bisnis yang berbeda - Anda dapat menggunakan kembali komponen teknis sambil menghabiskan sedikit waktu untuk mengembangkan logika bisnis (dengan alur kerja alat).

Namun, salah satu masalah paling umum yang saya hadapi dengan alur kerja dan penggunaan alat BPM, adalah bahwa pengembang masih mencoba untuk "mengubur" logika bisnis dalam kode yang tidak transparan.

Apa yang saya lihat, sepanjang waktu , adalah pengembang masih berusaha menambahkan logika bisnis dengan cara yang paling teknis, bukan dengan cara yang paling transparan. Ini wajar, karena pengembang, pada dasarnya, jauh lebih nyaman dengan kode daripada dengan alat alur kerja. Selain itu, semakin banyak logika yang Anda simpan secara teknis, semakin Anda akan dibutuhkan sebagai pengembang. Sayangnya, ini adalah hal terburuk yang dapat dilakukan pengembang terhadap sistem BPM karena ia meremehkan manfaat utama menggunakan BPM.

Terakhir, sebagian besar alat BPM tidak cukup jauh sehingga analis bisnis dapat mengembangkan alur kerja sendiri: namun, itulah tujuannya. Idealnya, analis bisnis akan mengembangkan alur kerja / diagram proses bisnis dan pengembang hanya akan bekerja pada komponen teknis yang disebut oleh mesin alur kerja.

Pernyataan di bawah ini adalah pengalaman pribadi saya menggunakan alat alur kerja, khususnya Oracle BPM Suite (10.3G & 11G). Pertama-tama untuk menentukan, pertanyaan Anda berfokus pada alat alur kerja yang memungkinkan pemodelan model proses yang dapat dieksekusi, alat ini adalah bagian dari Sistem Manajemen Proses Bisnis (BPMS). Pemodelan proses spesifik ini pasti berkembang dan Anda dapat menyebutnya sebagai bahasa pemrograman visual.

Manfaat utama adalah kelincahan memahami dan mengubah logika proses

Dengan model proses bisnis Anda mencakup penjelasan visual dari logika proses dan pada saat yang sama merupakan komponen integratif yang dapat dieksekusi. Hal ini memungkinkan lebih cepat on-dan offboarding programmer, karena lebih sedikit dokumentasi tentang transisi, persyaratan (Gateway atau Aturan Bisnis) dan aliran proses secara umum harus didokumentasikan, karena merupakan bagian dari pengembangan.

Selain itu, Anda telah melampirkan kemampuan pelaporan / pemantauan, apa yang harus Anda kembangkan secara terpisah untuk setiap aplikasi, yang dicakup oleh sebagian besar BPMS.

Terlebih lagi di sebagian besar lingkungan pengembangan BPM, adaptor layanan sudah dibuat sebelumnya (misalnya JMS, Layanan Web, JDBC, dll.), Memungkinkan untuk mengembangkan solusi middleware dengan lebih cepat dalam integrasi langkah demi langkah, mengurangi kesalahan manusia dalam pengkodean.

Mengikuti alur kerja platform tidak mencapai banyak manfaat yang disebutkan di atas - Pendekatan berbasis platform untuk otomatisasi alur kerja

Nilai

Proposisi nilai adalah bahwa alur kerja dapat dibuat atau diubah dengan cepat dan mudah agar sesuai dengan sifat bisnis yang berubah. Bagian penting dari mewujudkan proposisi nilai ini, adalah bahwa proses bisnis itu sendiri adalah unit sumber daya dalam sistem.

Alur kerja sebagai unit sumber daya, berarti bahwa proses bisnis didefinisikan sebagai 'unit' tunggal. Untuk memahami apa yang saya maksud dengan ini, pertimbangkan program komputer apa pun yang ditulis untuk bisnis. Ini mengimplementasikan proses bisnis pasti, tetapi logika untuk proses itu kemungkinan akan menyebar di sekitar kode sumber sampai batas tertentu. Alat alur kerja harus memungkinkan proses untuk didefinisikan di satu tempat yang terkandung dengan baik. Itu bisa dalam satu file konfigurasi tunggal, atau diekstraksi dari satu diagram visual, atau itu bisa berarti bahwa alur kerja ada dalam modul kode tunggal yang dapat dicolokkan, mungkin bahkan ditukar atau dikonfigurasi dengan cepat.

Mengapa Nilai tersebut mungkin tidak direalisasikan

Proposisi nilai ini dapat dirusak oleh kesulitan menutupi kasus non-vanilla, berintegrasi dengan teknologi UI yang berubah sangat cepat, praktik buruk seperti menggunakan alat alur kerja sebagai pembungkus saja dan tetap menempatkan logika nyata dalam kode.

Desain alat yang buruk itu sendiri mungkin menjadi faktor pembatas. Sebuah contoh akan menjadi alat yang mengharuskan semua parameter yang dilewati antara proses berada di Java Map, dengan batasan nilai apa yang sebenarnya dapat Anda tempatkan di peta, alih-alih hanya parameter metode biasa (saya memikirkan salah satu dari lebih alat populer khususnya yang melakukan ini).

Saya pikir mungkin adil untuk mengatakan bahwa IBM sebagai pemain besar dengan sistem eko-teknologi besar, pameran lebih baik daripada yang lain. Jika mereka juga mengontrol teknologi UI, dan database serta teknologi SOA yang digunakan bersama dengan alat alur kerja, mereka memiliki peluang lebih baik untuk menghasilkan sistem-eko yang terintegrasi bersama dengan baik, dan menciptakan peluang untuk benar-benar memanfaatkan ide ini.

Memang benar bahwa upaya menulis interfacing antara alat alur kerja dan bagian lain dari suatu sistem dapat sepenuhnya meniadakan seluruh proposisi nilai. Itu selalu layak dipertimbangkan jika ada cara yang lebih baik dalam melakukan sesuatu.

Pemrograman adalah Alur Kerja

Yang benar adalah bahwa pemrograman (setidaknya dalam bahasa imperatif) sudah WORKFLOW. Anda mungkin memiliki kode yang mengimplementasikan alur kerja yang berkaitan dengan penanganan teknologi sistem; mengakses file dan menjalankan query SQL dan sebagainya. Anda mungkin memiliki kode yang mengimplementasikan alur kerja bisnis; mengatur keadaan dokumen dan meneruskannya ke peninjau misalnya.

Mengenali hal ini dan mendesain kode Anda untuk memisahkan masalah-masalah yang terpisah ini sulit dilakukan sepenuhnya, tetapi Anda pasti bisa menempuh jalan panjang dengan melakukan hal itu.

Saya setuju dengan Anda, kadang-kadang kami akhirnya menggunakan alat-alat ini karena orang lain memutuskan itu adalah ide yang bagus, dan itu terlalu rumit dan membuat pekerjaan kami lebih sulit. Saya tidak berpikir bahwa itu selalu terjadi, perlu pertimbangan cermat untuk memutuskan apakah itu layak atau tidak.

Tidak terlalu jelas alat mana yang Anda gunakan. Saya kira Anda mungkin merujuk pada seperangkat alat umum yang disebut alat Pemodelan Proses Bisnis. Ada alasan bagus untuk menggunakan alat tersebut. Setiap bisnis yang berkualitas menentukan fungsinya dalam hal proses dan analis serta pakar bisnis dapat menggambar proses tersebut dengan nyaman (sampai Anda mengikatnya dengan standar ...). Anda dapat membuat proses seperti itu pada tingkat konseptual tanpa pengetahuan pemrograman web dan jika Anda memiliki alat yang tepat, Anda mungkin dapat mengubah proses tersebut menjadi aplikasi yang berfungsi juga (orang-orang yang berpengalaman harus ikut serta agar keajaiban ini dapat mulai diproduksi tentu saja). Jadi idenya bagus.

Tujuan dari alat visual bukan hanya dokumentasi proses. Penggunaan alat ini dimaksudkan untuk membantu proses rekayasa ulang profesional dan, pada saatnya, menjalankan simulasi untuk menemukan titik-titik di mana proses tersebut kurang efisien daripada yang diinginkan sehingga rencana dapat dilakukan untuk menghilangkan kemacetan.

Ada cara standar yang digunakan banyak perusahaan saat ini yang disebut BPMN 2.0 (Business Process Modeling Notation). Saya merekomendasikan Anda untuk memahami notasi ini jika alat Anda menggunakannya.

The Manajemen Badan Proses Bisnis Pengetahuan adalah sumber daya yang terkenal, bahwa Anda mungkin ingin mempertimbangkan juga.

Di atas mencakup sisi bisnis. Sisi teknis membutuhkan SOA dan BPEL, saya tidak yakin saya bisa memberikan saran tentang mereka di sini dan sekarang.

Dalam contoh sederhana berdasarkan sejarah.

Jaman Batu

Pada awalnya Anda memiliki perusahaan menhir kecil di mana orang-orang hanya mengatakan apa yang harus dilakukan, dan mereka melakukannya. Kadang-kadang ada yang salah, dan Orang X atau Y disalahkan (tidak pernah yakin siapa yang benar-benar melakukannya).

Internet dan Email selanjutnya diciptakan.

Orang-orang sekarang menulis kepada orang lain apa yang harus dilakukan, dan orang-orang itu sering mengalami masalah dengan Email mereka, membacanya salah, atau hanya menghapus Email tanpa pernah membacanya; begitu sering hal-hal yang tidak disalahkan pada Email yang buruk

Alur kerja berevolusi dari administrasi Dengan membakukan tindakan, akhirnya orang dapat melihat pada fase apa yang menghentikan suatu proses, dan pada saat yang sama, mendapatkan gambaran digital dari apa yang sebenarnya telah dilakukan. Ini bekerja dengan baik sampai orang ingin mengubah proses standar, atau sampai beberapa orang XY yang tidak dikenal menyebabkan permintaan basis data yang tidak benar yang mengakibatkan korupsi basis data, mengirimkan produksi kembali ke zaman batu ..