İş akışı otomasyonu neden ortak bir veri modeli olmadan başarısız olur

Sorun asla tetikleyici değildir

Bir iş akışı otomasyonu uygulaması tıkandığında, olay sonrası değerlendirme neredeyse her zaman tetikleyici mantığını suçlar: webhook geç tetiklendi, zamanlama bir saat dilimini kaçırdı, koşul düğümü yanlış alanı değerlendirdi. Bunlar gerçek hatalardır, ancak otomasyon projelerinin altı ay sonra sessizce ölmesinin nedeni nadiren bunlardır. Asıl hata biçimi tek bir düğümün yukarısındadır — birbirine bağlanan sistemlerin "müşteri", "görev" ya da "fatura"nın ne olduğu konusunda anlaşamamasıdır.

TotalApp'teki gibi bir iş akışı editörü yapısal olarak, kenarlar boyunca veri ileten düğümlerden oluşan bir graftır. Her düğüm, aldığı verinin şeklini varsayar. İki modül bu şekil konusunda anlaşamadığı an — biri buna clientId, diğeri customer_ref der, üçüncüsü ise ID yerine görünen adı saklar — her aşağı akış düğümü ya yüksek sesle bozulur ya da daha kötüsü, yanlış kayıt üzerinde sessizce başarılı olur. Sessiz hatalar, otomasyona olan güveni en hızlı aşındıranlardır; çünkü üç hafta sonra bir rapor yanlış çıkana dek kimse fark etmez.

Bu, tekil araçlardan çok çok modüllü SaaS'ta neden daha sık görülür

Tek amaçlı bir araç bu sorunu hiç yaşamaz, çünkü yalnızca tek bir veri modeli vardır. Sorun tam olarak bir platform TotalApp'in yapmaya çalıştığı şeyi yapmaya kalktığında başlar: İK, Finans, Depo, CRM ve Proje Yönetimi'nin hepsinin tek bir kiracıda yaşaması ve aynı otomasyon katmanını beslemesi. Bu modüllerin her biri önce kendi alanını düşünen insanlar tarafından tasarlandı — ki bu doğrudur, derinlik böyle gelir — ama bu, İK'daki "çalışan" ile Proje Yönetimi'ndeki "atanan kişi"nin varsayılmış değil, bilinçli bir eşlemeye ihtiyaç duyduğu anlamına gelir.

Çözüm, otomasyon kuranlar için daha kalın bir kural kitabı değildir. Her modülün karşısında yayın yaptığı bir şema katmanıdır; böylece CRM'den okuyan bir iş akışı düğümü ile Finans'a yazan bir iş akışı düğümü, her seferinde aynı biçimde adreslenen aynı temel varlıktan söz eder.

Ortak bir veri modeli aslında ne gerektirir

Uygulamada bu, büyük bir birleştirici ontoloji değil, birkaç somut disiplin anlamına gelir:

• ✓
  Modül sınırlarını aşan her varlığın — çalışan, müşteri, proje, kalem — bir kez üretilen ve başka her yerde ona referans verilen tek bir kanonik ID'si vardır
• ✓
  Alan adları modül başına kaymaya bırakılmaz, API sınırında normalleştirilir; bir iş akışı düğümünün koşul mantığında asla bir çeviri tablosuna ihtiyacı olmamalıdır
• ✓
  Kiracıya özel depolama, modüller arasında şekil bakımından tutarlı kalır — veri kiracı başına JSON olarak tutulduğunda, TotalApp'in server/data/tenants/<tenantId>/ yapısında olduğu gibi, kaymayı yakalayacak veritabanı düzeyinde bir yabancı anahtar olmadığından şema disiplininin gelenek ve doğrulama ile sağlanması gerekir
• ✓
  Yeni modüllerin, ikinci ekip bir uyumsuzluğa çarptıktan sonra değil, ilk iş akışı entegrasyonu yayınlanmadan önce paylaşılan varlık modeline eşlenmesi zorunludur

React Flow katmanı sebebi değil, maliyeti görünür kılar

Bir otomasyon bozulduğunda suçu iş akışı editörünün kendisine yüklemek cazip gelir — graf, hatanın yüzeye çıktığı son yerdir, bu yüzden kaynak gibi görünür. Oysa görsel bir pipeline oluşturucu yalnızca altındaki veri sözleşmelerinin sonuçlarını çizer. Bu sözleşmeler sağlamsa graf kolayca hata ayıklanabilir: bir değeri düğümden düğüme izleyip beklentiden tam olarak nerede saptığını görebilirsiniz. Değilse, düğüm düzeyinde hiçbir hata yönetimi sizi kurtarmaz; çünkü düğümlerin her biri kendi başına doğrudur — sadece birbiriyle uyumsuz şeyler konusunda doğrudur.

Otomasyonlar modüller arasında yanlış davrandığında "daha fazla doğrulama düğümü ekle" reçetesinin genellikle yanlış olmasının nedeni de budur. Doğrulama düğümleri hatalı biçimlendirilmiş veriyi yakalar; farklı modellenmiş veriyi yakalamaz. Tamamen yanlış tabloyu gösteren, ama biçimi düzgün bir customer_ref dizesi, iş akışı grafına eklediğiniz hiçbir şema kontrolüne takılmadan geçer.

İlk seferde doğru yapmak

Bunu doğru yapan ekipler veri modelini, kendi sahibi olan bir ürün yüzeyi olarak ele alır ve bir API sözleşmesi gibi gözden geçirir — her modül ekibinin bağımsız olarak çözeceği bir uygulama ayrıntısı olarak değil. Bir sonraki otomasyon tetikleyicisini kurmaktan daha az heyecan vericidir, ama bir düzine modüle temiz biçimde ölçeklenen bir iş akışı platformu ile on birinci modül üçüncüyle konuşmak istediği an yeniden yazılması gereken bir platform arasındaki farktır.

İnsanların fark ettiği kısım tetikleyici mantığıdır. Tetikleyici mantığının hiç işe yarayıp yaramayacağını belirleyen kısım ise veri modelidir.

Daha fazla yazı oku