İş akışı araçlarının değeri nedir? [kapalı]

Workflow geliştirmesinde yeniyim ve gerçekten "büyük resmi" elde ettiğimi sanmıyorum. Ya da belki farklı bir şekilde ifade etmek gerekirse, bu araçlar şu anda kafamda "tıklamıyor".

Bu nedenle, şirketler süreçleri tanımlamak için iş çizimleri oluşturmayı severler ve bir noktada birileri süreçleri bir çizgiden ve diyagram gibi kutulardan kontrol etmek için bir devlet makinesi gibi kullanabileceklerine karar verdiler. On yıl sonra, bu araçlar oldukça karmaşık ve karmaşıktır (şirketim şu anda WebSphere ile oynuyor ve bazı eğitimlere katıldım, bir canavar, hatta Activiti gibi bu iş akışı araçlarının "minimalist" versiyonları bile çok büyük ve karmaşık olmasına rağmen, WebSphere'in açıkladığı canavar kadar karmaşık olmasa da).

Bu şekilde yapmanın en büyük faydası nedir? Basit çizgiler ve kutu diyagramlarının kullanışlı olduğunu anlayabiliyorum, ancak söyleyebileceğim kadarıyla, bu noktada şartlandırmalar ve döngülerle tamamlanmış görsel programlama dilleri var. Buradaki programcılar, gerçekten çok berbat, gerçekten basit bir görsel programlama dili gibi görünen çizgiler ve kutular katmanında önemli miktarda çalışma yapıyor gibi görünüyor.

Eğer o kadar ileri gidecekseniz, neden sadece bir çeşit betik dili kullanmıyorsunuz? Bu konuda insanlar bebeği banyo suyuyla attı mı? Çizgiler ve kutular şey saçma bir seviyeye mi alındı, yoksa ben tüm bunlardaki değeri anlamıyorum?

Bu teknolojide çalışmış olan insanlar tarafından bunun savunulması konusundaki tartışmaları görmek ve neden faydalı olduğunu anlamak isterim. Buradaki değeri göremiyorum, ancak bunun için yeni olduğumu ve henüz tam olarak elde edemeyeceğimi biliyorum.

Bir geliştiricinin bakış açısından, bu "görsel" ortamların çalışmak için gerçekten zor olduğunu söylemekte haklısınız. Kullandığım SharePoint 2010 Workflows, iyi bir kurumsal yazılım yaratma konusundaki en iyi uygulamaları ortaya koyuyor - otomatik testler yok, kodların tekrar kullanımı yok, okunamayan yazılımlar , yaşadığın gibi.

Ancak iş açısından, iş akışlarının en azından teoride büyük faydaları var. Bu teknik incelemeden alıntı yapmak gerekirse , otomatikleştirilmiş bir iş akışının Verimliliği, Hesap Verebilirliği, Kontrolü ve Kullanım Kolaylığı büyük verimlilik kazanımları sağlar. Basit bir onay veya uçağa binme işleminin bu otomasyon olmadan ne kadar verimsiz olacağını hayal edin. Ayrıca, bir iş akışını tanımlama eylemi, iş süreçleri üzerinde kontrol sahibi olmaya çalışan bir kuruluş için değerlidir.

İş akışı yazılımının şu anki durumu işin hatası değildir. Sadece hayatlarını kolaylaştırmak istiyorlar ve iş akışları bunun için harika. Bilişim departmanı bizi daha çok suçlardı:

1. İşletmenin sistemi ne kadar karmaşık ve kırılgan olduğu konusunda daha şeffaf olmamak Tüm karmaşıklığı gizliyoruz.
2. Sezgisel, basit iş akışı çözümleriyle "kaşıntımızı çizememek" için. Bu muhtemelen SharePoint ve SAP gibi büyük kurumsal paketlere karşı daha fazla rant, ancak orada özel çözümler daha iyidir

Sadece tek bir faydası var, ancak bunun çok büyük: Endişelerin Ayrılması .

Dolayısıyla, sistemimize gömülü olan süreç düzenleme mantığı yerine, dış yapılandırma olur. Temelde bir harita. Bunu bağımsız olarak değiştirebilirsiniz (çok daha fazla), birden fazla işlem, birden fazla işlem sürümü, aynı anda çalışan birden fazla işlemin birden fazla sürümü olabilir ve bunların hepsi makul bir çözümdedir.

Tarihsel olarak, SoC kavramı birçok kez kazanmıştır - Unix ilkesinden başlayarak "bir şey yap, ama iyi yap" ve ESB gibi farklı sunucu sistemleri, önbellekleme, yük dengeleme gibi , HTML’den CSS’nin ayrılması gibi

İş süreciniz ve akış kuralları genellikle verilerinize, UI "ekranlarına" veya kullanıcıların "hiyerarşisine" göre diktir. Bu nedenle, onu sistemin diğer yönlerinden ayrı olarak geliştirmek ve değiştirmek mükemmel bir anlam ifade eder. Yani hangi öncül oldu BPM 1990'ların başlarında ortaya çıkmıştır.

O zamandan beri, bu kavramı desteklemek için birçok araç ve dil yaratıldı, en bilinenleri BPMN - doğrudan işlemlere eşlenen "akış çizelgeleri" oluşturmak için kullanılan grafik bir dil. İnsanlar büyük ve hantal olmadıklarından (kelime haznesinde 100'den fazla sembole sahip) ve S-BPM (sadece 5 temel sembole sahip) gibi modern yaklaşımları savunmaktan şikayet ederken , mevcut endüstri uygulaması BPMN'ye veya türevlerine, alt kümelerine veya kardeşlerine bağlı kalmaktır.

BPMN'den memnun görünmüyorsunuz:

Buradaki programcılar, gerçekten çok berbat, gerçekten basit bir görsel programlama dili gibi görünen çizgiler ve kutular katmanında önemli miktarda çalışma yapıyor gibi görünüyor.

Ama o kadar da kötü değil) Arkasında teori var. Ve sürüm 2.0, 1.0 eksiklikten biraz fikir aldı.

Eğer o kadar ileri gidecekseniz, neden sadece bir çeşit betik dili kullanmıyorsunuz?

Zorunlu paradigma ve betik dilleri her zaman en iyi cevap değildir. Muhtemelen bildirimsel dillerde gördüğünüz gibi (HTML, CSS, SQL, Drools veya Nginx, Graddle ve Maven, Puppet vb. Gibi dahili), sonuç kodu " iyi bir dilde " yazılmış bir sürümden çok daha küçük ve daha temiz olabilir. Java veya C ++ "gibi.

Diğer konuya gelince:

Söyleyebileceğim kadarıyla, bu noktada şartlandırma ve döngülerle birlikte görsel programlama dilleri var.

Eğer içine baktım Olaylar ve Tetikleyiciler ? BPMN bir dildir ve kullanmadan önce öğrenmek zorundasınız, ya da en azından aşina olmalısınız.

Kaputun altında, BPMN XML'dir, bu yüzden elle düzenleyebilir veya oluşturabilirsiniz. XML metin tabanlı olduğu için sürümleri kontrol edebilirsiniz. Bununla birlikte, akış çizelgelerine çevrilebilecek bir XML'in olması, goona'nın size yardımcı olduğu gibi gelmiyor ve bu doğru - kendi ayrıştırıcınızı veya editörünüzü yazmak, şüpheli faydaları olan zor ve pahalı bir iştir.

Neyse ki, zaten pazarda tam olarak bunu yapan araçlar var.

Activiti ücretsiz ve hem geliştiriciler hem de işletme sahipleri arasında oldukça popüler, çünkü ilk fiyatı ( sıfır ), bilginin kullanılabilirliği ve alçakgönüllülük. Son nokta gerçekten eşsizdir, çünkü Activi yalnızca iş süreçlerinizi yönetmeye odaklanır, sizi bütün paket çözümleriyle birleştirmeye çalışmadan. Ayrıca, onun açık - yani sadece onu çalıştırmak ve çalıştırmak için Java ve REST bilmek gerekir. Dezavantajı, müşteri tarafı, entegrasyon ve uygulama / işletme mantığı ve tüm mimarinin geliştiriciye bırakılmasıdır, yani geliştirme ekibiniz zayıfsa - başarısızlığa hazır olun. Toplam sahip olma maliyeti ücretsiz bir araç için şaşırtıcı derecede yüksek olabilir ;)

Spektrumun diğer tarafında, BPM sistemlerinin hükümdar kralı (Gartner ve Forester'e göre) Pega (Pega PRPC) var. Bu ve bir mutfak lavabosunun behemoth'u bile CRM, OCR ve (yanılmıyorsam) konuşma tanıma yetenekleri, tahmine dayalı analitik, işletme kuralları yönetimi ve WYSIWYG UI editörü yeteneğine sahiptir. Yine de, ciddi bir fiyat etiketi ile geliyor. Sadece bir servete mal olmakla kalmaz, aynı zamanda tüm geliştirmeler bir web uygulaması içerisinde gerçekleştirilir, yani IE8 (ayrıca bazı eklentileri ve çirkin kesimleri, veri tablolarını düzenlemek için Excel kullanmak gibi) tarayıcı kullanmanız gerekir. Ayrıca, Java, Javascript veya HTML / CSS düzenleme de web tarayıcısı ile yapılmaktadır - bu nedenle birim testlerine, IDE kodunu vurgulama, yeniden düzenleme ve sevdiğiniz tüm programlama oyuncaklarınıza elveda deyin.

Bunun iyi tarafı? WEEKS İLE karmaşık bir sistemi uygulayabilirsiniz [ PDF , bkz. sayfa 22]. Ve evet, sonuç garanti edilmez.

IBM bir süre önce (kurumsal zamana göre) Lombardi'yi satın aldı ve şimdi çok rekabetçi bir çözüm sunuyor (ama sonra her şeyi satın almak zorunda kalacaksınız). Appian , ilginç görüşlere ve olumlu geri bildirimlere sahip genç bir satıcıdır, ancak yazılma şekli (görsel olana ek olarak iki ilave DSL dili) sadece bana çekici gelmiyor.

Başka oyuncular ve çözümleri var. Birçoğu sade korkunç. Mesela - sadece onlara baktığınızda gözleriniz, beyniniz ve kalbiniz tam anlamıyla kanar. Yani, bağırsaklarına güven ve geliştiricilerinin ve kullanıcının senden nefret etmesini sağlama.

Kapanış notu:

BPM sistemi, Photoshop'ta görüntülerin ne olduğu işlemler için aynıdır. Görsel olarak korkma. İşe uygun olmayan işi yapmayın (tamamen Photoshop'ta oluşturulan ve düzenlenmesi imkansız olan web sitelerini hatırlayın). Basit tutun ve hata yapmayın;)

Yıllar önce, çoğumuz doğmadan önce, yazılım geliştiricileri veri depolamak için kendi kodlarını yazmak zorunda kaldılar. Program durumunu kaydetmeniz gerekiyorsa, bu kodun işlevinin bir parçası olarak görüldü, pek çok yazılım geliştiricisi verileri düzenlemek, kaydetmek ve okumak ve bunları okumak için kod yazdı.

Ve sonra birileri bunun çok yaşandığı bir şey olduğunu fark etti - verilerin kaydedilmesi, düzenlenmesi, okunması ve aranması mantığı aslında kendi bileşeni olması gerektiği kadar yaygın olarak kullanılan bir bileşendi. Ve veritabanlarımız var.

Son 10 ila 15 yılda, BT departmanları, iş süreçlerini koreografiye ve / veya yönetmeye yönelik mantığın o kadar yaygın olduğunu ve her türlü farklı iş akışı aracına yol açan kendi bileşeni olması gerektiğinin farkındaydı.

Bir iş akışı aracının 3 temel avantajı vardır:

1. Değişiklik yapmak ve uygulamak için gereken zaman : Bir kod parçasını değiştirmekle aynı teknik riskler olmadan bir iş akışının mantığını geliştirebilir ve değiştirebilirsiniz.
2. Şeffaflık : BPM tabanlı bir sistemdeki iş mantığı, iş analisti tarafından hemen kullanılabilir durumda ve okunabilir durumda iken, sadece geliştiriciler iş mantığını "kod tabanlı" sistemlerde okuyabilecek.
3. Teknik bileşenlerin yeniden kullanımı : BPM araçları genellikle Servis Odaklı Mimarisine sahip sistemler ile birlikte kullanılır. İş mantığını teknik bileşenlerden - özellikle de yüzlerce veya binlerce farklı iş sürecini uygulamak zorunda olan kurumsal sistemler için - ayırarak, iş mantığını geliştirmek için nispeten az zaman harcayarak teknik bileşenleri yeniden kullanabilirsiniz. aracı).

Bununla birlikte, iş akışı ve BPM aracı kullanımıyla karşılaştığım en yaygın sorunlardan biri, geliştiricilerin iş mantığını saydam olmayan kodda "gömmeye" çalıştıklarıdır.

Gördüğüm şey, her zaman , geliştiriciler hala yerine mümkün olan en şeffaf şekilde, mümkün olan en teknik yollarla iş mantığı eklemek için çalışıyor. Bu doğaldır, çünkü geliştiriciler, doğaları gereği, kodlarla bir iş akışı aracından çok daha rahattır. Dahası, teknik olarak ne kadar mantıklı kalırsanız, geliştirici olarak o kadar çok ihtiyacınız olacaktır. Ne yazık ki, bu bir geliştiricinin BPM sistemine yapabileceği en kötü şeydir, çünkü BPM kullanmanın birincil yararlarını kısıyor.

Son olarak, çoğu BPM aracı, iş analistlerinin iş akışlarını kendi geliştirebilecekleri kadar uzakta değil: ancak hedef bu. İdeal olarak, iş analistleri iş akışlarını / iş süreci diyagramlarını geliştirecek ve geliştiriciler yalnızca iş akışı motoru tarafından çağrılan teknik bileşenler üzerinde çalışacaklardır.

Aşağıdaki ifadeler, iş akışı araçlarını, özellikle Oracle BPM Suite (10.3G & 11G) kullanan kişisel deneyimim. İlk olarak, sorunuzun çalıştırılabilir işlem modellerini modellemeye olanak sağlayan iş akışı araçlarına odaklanması olduğunu, bu araçların İş Süreci Yönetim Sistemleri'nin (BPMS) bir parçası olduğunu belirtin. Bu özel süreç modellemesi kesinlikle gelişmektedir ve görsel programlama dili olarak adlandırılabilir.

Temel fayda, süreç mantığını anlama ve değiştirmenin çevikliğidir.

İş süreci modelleriyle, işlem mantığının görsel bir açıklamasını ve aynı zamanda yürütülebilir bir bütünleştirici bileşeni içerirsiniz. Bu, programcıların daha hızlı ve daha hızlı bir şekilde kullanılmasını sağlar, çünkü geçişler, şartlamalar (Ağ Geçitleri veya İş Kuralları) ve genel olarak işlem akışı hakkında daha az dokümantasyonun, geliştirme sürecinden bu yana belgelenmesi gerekir.

Ek olarak, çoğu BPMS tarafından kapsanan her bir uygulama için ayrı ayrı geliştirmeniz gereken raporlama / izleme yeteneklerini de eklediniz.

Ayrıca, çoğu BPM geliştirme ortamında servis adaptörleri önceden yapılandırılmıştır (örn. JMS, Web Servisleri, JDBC'ler vb.), Adım adım etkileşimli entegrasyonla katman yazılım çözümlerini daha hızlı geliştirerek kodlamadaki insan hatalarını azaltır.

Aşağıdaki iş akışı platformu yukarıda belirtilen birçok avantajı sağlar - İş akışlarının otomasyonu için platform tabanlı yaklaşım

Değer

Değer önerisi, iş akışlarının bir işletmenin değişen doğasına uyacak şekilde hızlı ve kolay bir şekilde oluşturulabilmesi veya değiştirilebilmesidir. Bu değer önerisini gerçekleştirmenin önemli bir kısmı, iş süreçlerinin kendilerinin sistemdeki kaynak birimleri olduğudur.

Kaynak birimleri olarak iş akışları, bir iş sürecinin tek bir 'birim' olarak tanımlandığı anlamına gelir. Bununla ne demek istediğimi anlamak için, bir iş için yazılmış herhangi bir bilgisayar programını düşünün. Kesinlikle bir iş süreci uygular, ancak bu sürecin mantığının kaynak kodunun etrafına bir dereceye kadar yayılması muhtemeldir. Bir iş akışı aracı, işlemin iyi bir yerde tanımlanmasına izin vermelidir. Tek bir yapılandırma dosyasında olabilir veya tek bir görsel şemadan çıkarılabilir veya iş akışının, takılabildiği, hatta anında değiştirilebileceği veya yapılandırılabildiği tek bir kod modülünde olduğu anlamına gelebilir.

Değer Neden Gerçekleşmiyor?

Bu değer önerisi, vanilya olmayan vakaların kapatılması, çok hızlı değişen UI teknolojisi ile entegrasyon zorluğu, iş akışı aracını yalnızca sarıcı olarak kullanma ve gerçek mantığı yine de koda koyma gibi kötü uygulamalar nedeniyle zarar görebilir.

Araçların zayıf tasarımı, kısıtlayıcı bir faktör olabilir. Bir örnek, Java Haritasındaki işlemler arasında geçirilen tüm parametreleri gerektiren bir araç olabilir, yalnızca düz eski yöntem parametreleri yerine haritada hangi değerleri gerçekten koyabileceğinize dair kısıtlamalar vardır (daha fazlasını düşünüyorum. Özellikle bunu yapan popüler araçlar).

IBM’in büyük bir eko sisteme sahip büyük bir oyuncu olarak, diğerlerinden daha iyi fuarlar olduğunu söylemenin adil olacağını düşünüyorum. Ayrıca, kullanıcı arayüzü teknolojisini, iş akışı aracıyla birlikte kullanılan veritabanı ve SOA teknolojisini de kontrol ediyorlarsa, birlikte güzel bir şekilde bütünleşen bir eko sisteme sahip olma şansı daha yüksektir ve gerçekten yararlanma fırsatı yaratırlar. bu fikir.

Bir iş akışı aracı ile bir sistemin diğer kısımları arasına ara yüz oluşturma çabasının tüm değer önerisini tamamen olumsuz etkileyebileceği kesinlikle doğrudur. Her şeyi daha iyi yapmanın bir yolu olup olmadığını düşünmeye değer.

Programlama İş Akışıdır

Gerçek şu ki programlama (en azından zorunlu dillerde) zaten İŞ AKIŞI IS. Sistem teknolojisini kullanmakla ilgili olan iş akışını uygulayan kodunuz olabilir; dosyalara erişme ve SQL sorguları çalıştırma vb. İş iş akışını uygulayan kodunuz olabilir; örneğin bir dokümanın durumunu belirlemek ve onu bir inceleyene geçirmek.

Bunu tanımak ve kodunuzu bu ayrı endişeleri temiz bir şekilde bölmek için tasarlamak tamamen ortadan kaldırmak zordur, ancak kesinlikle tam da bunu yapmanın uzun bir yolunu alabilirsiniz.

Sizinle aynı fikirdeyim, bazen bu araçları kullanıyoruz çünkü bir başkası bunun iyi bir fikir olduğuna karar verdi ve çok daha karmaşıklar ve işimizi zorlaştırıyorlar. Bunun her zaman böyle olduğunu sanmıyorum, buna değer olup olmadığına karar vermek için biraz dikkatli düşünmeye ihtiyacı var.

Hangi aracı kullandığınız belli değil. Sanırım İş Süreci Modelleme araçları adı verilen genel araçlara atıfta bulunuyorsunuz. Bu tür araçları kullanmak için iyi bir neden var. Herhangi bir kalite işletmesi, işlevlerini süreçler ve analistler olarak tanımlarken, işletme uzmanları da bu süreçleri rahatça çekebilirler (siz bunları standartlara bağlayana kadar ...). Web programlama bilgisi olmadan kavramsal düzeyde bu tür süreçler oluşturabilirsiniz ve doğru araca sahipseniz, süreci çalışan bir uygulamaya da dönüştürebilirsiniz. tabii ki). Yani fikir güzel.

Görsel araçların amacı sadece süreçlerin belgelendirilmesi değildir. Araçların kullanımı profesyonellerin süreçleri yeniden tasarlamalarına yardımcı olmak ve zaman zaman, işlemlerin istenenden daha az verimli olduğu noktaları bulmak için simülasyonlar yapmak, böylece tıkanıklıkları gidermek için planların uygulanabilmesini sağlamak içindir.

Bugün birçok şirketin BPMN 2.0 (İş Süreçleri Modellemesi Notasyonu) adı verilen standart bir yolu var. Aracınız kullanıyorsa, bu gösterimi anlamanızı tavsiye ederim.

Bilginin İş Süreçleri Yönetimi Vücut siz de dikkate almak isteyebilirsiniz, ünlü bir kaynaktır.

Yukarıdakiler iş tarafını kapsar. Teknik taraf SOA ve BPEL gerektiriyor, burada ve şimdi olanlar hakkında tavsiyeler verebileceğimden emin değilim.

Tarihe göre basit bir örnekte.

Taş Devri

İlk başta insanların nerede yapacaklarını söyledikleri küçük erkek şirketleri vardı ve bunu yaptılar. Bazen işler yanlış gider ve Kişi X veya Y suçlanır (gerçekten kimin yaptığını asla bilemezsiniz).

Sonraki internet ve e-posta icat edildi.

İnsanlar şimdi başkalarına ne yapmaları gerektiğini yazdı ve bu kişiler çoğu zaman E-postalarında sorun yaşıyor, yanlış okuyor veya yalnızca bir E-postayı hiç okumadan silmiş; Çoğu zaman kötü e-postayla suçlamadığınız şeyler

İş akışı yönetim dışında gelişti Eylemleri standartlaştırarak, insanlar nihayet bir süreci hangi aşamada durdurduğunu ve aynı zamanda gerçekte ne yapıldığını dijital olarak görebildiler. Bu, insanlar standart süreçleri değiştirmek isteyinceye ya da bazı bilinmeyen XY şahıslarının veri tabanının bozulmasına neden olacak şekilde yanlış bir veritabanı talebine neden olana ve üretimin taş devrine geri gönderilmesine kadar güzeldi.