İş Kuralları – Business Rules

Bir işi analiz ederken, en önemli iki analiz bilgisi olarak süreçler ve bu süreçleri yönlendiren kurallar öne çıkar. Sürecin ne olduğunu biliyoruz, kabaca, bir işin sonuçlanması için baştan sona yapılması gereken eylemler bütünüdür. İş kuralı ise, bir iş yapılış şeklini etkileyen herhangi bir karardır. İngilizce’de “business rule” olarak geçen bu kavram bir süredir hem iş süreçlerimizi anlamada hem de yazılımı geliştirmede ve programlamada bize çok faydalı bir bakış açısı sunuyor.

Aslında anlamayı kolaylaştırmak istersek, kurallar, örneğin hayatın kuralları, futbolun kuralları gibi, özel bir bağlamda uyulması-uygulanması gereken ilkelerdir. Bu anlamda iş kuralları, bir kurumun iş yapışı ile ilgili ilkeler, yönergeler, prensipler vb.den oluşan soyutlamalardır. İş kuralları, işin parçasıdır, işi yönlendirir, karar mekanizmalarını çalıştırır ya da işi yapış şeklini kısıtlar. İş yapış şekillerindeki hesaplamalarda kullanılan algoritmalar ile katsayılar, oranlar vb. özel anlamı olan sayılar, limitler, sınıflandırmalar hep iş kurallarının farklı görünümleridir.

İş kuralları, en temelde kurum tarafından belirlenir. Kurumlar farklı tanımlar ve sınıflandırmalar yapar, belli standartlar ortaya koyar, bazı değerleri hesaplamak için kendine algoritmalar oluşturur, yetkilendirmeler yapar, örneğin şu roldekiler şunu yapabilir, şu roldekiler şunu yapamaz cinsinden ifadeler belirler. Ayrıca kanuni düzenlemeler, ilgili meslek odaları vb. sektördeki ortak aklı temsil eden kurumların yaptığı düzenlemeler, endüstri standartları, uluslararası kuruluşların koyduğu kurallar vs. hep iş kurallarının kaynaklarındandır.

Literatürde farklı iş kuralı sınıflandırmaları bulunabilir. En temelde, gerçekler, algoritmalar, çıkarımlar ve kısıtlardan bahsedebiliriz. Örneğin ‘Kullanıcılar sistemde TCKN ile temsil edilirler.” sonuçta bir gerçektir ve bir iş kuralıdır. Bir e-alışveriş sisteminde gönderme ücretinin nasıl hesaplanacağı sonuçta algoritmik bir iş kuralıdır. Benzer şekilde vergilendirme de basit de olsa algoritmik yapıdadır. Çıkarımlar ise daha çok bir noktada tetiklenen kurallardır. Örneğin yine bir alışveriş sisteminde bazı mallardan satın alanlar için diğer bazı malların indirimli olarak önerilmesi ya da bazı kredi kartlarıyla ödeme yapacaklar için belli ödeme şartlarının sunulması türünden, iş sürecinde tetiklenen durumlarda kullanılacak iş kuralları mevcuttur. Son tür ise kısıtlardır ve örneğin bir B2B ısmarlama sistemi için “C tipi üye iş yerleri 10.000 TL’den daha fazla cari hesap bulundurmazlar.” şeklindeki bir iş kuralı buna örnektir.

Çoğu zaman iş kuralları bu kadar basit olmaz, içinde pek çok şart cümlesini barındıran, karmaşık cümlelerden oluşur. Bu şekildeki iş kurallarını, atomik alt parçalarına bölmek anlaşılırlık ve yönetilebilirliklerini olumlu yönde etkiler. Örneğin, “Müşteri idsi olarak, eğer müşteri TC vatandaşı ise ya web servisten ya da formdan gelen TCKN atanır. Eğer müşteri TC vatandaşı değilse müşteri idsi olarak olarak müşteri numarası atanır. Burada da yine ya web servisten ya da formdan gelen müşteri numarası kullanılır.” şeklindeki bir iş kuralını şu şekilde, dört ayrı iş kuralı olarak düzenlemek daha faydalı bir sonuç verecektir:

• TC vatandaşı olan müşterinin idsi, TCKNdir.
• TC vatandaşı olmayan müşterinin idsi, müşteri numarasıdır.
• TC vatandaşı olan bir müşterinin TCKNsi, formda gelmiyorsa, web servisten sorgulanır.
• TC vatandaşı olmayan bir müşterinin numarası, formda gelmiyorsa, web servisten sorgulanır.

İş kurallarını bu şekilde yakalamanın bir kaç faydası vardır. En temel faydası, analiste, analiz malzemesi hakkında analitik düşünme imkanı sağlamasıdır. Süreçleri yakalarken, farklı mahiyette olan iş kurallarını ayrı ihtiyaç tipi olarak yakalamak, üzerinden tartışmak, dokümante edip, doğrulama ve testin konusu olarak kullanmak son derece faydalıdır. Bu anlamda iş kuralları, yazılım ihtiyaçlarını analitik olarak çözümlemenin en temel yollarındandır.

Yazılım projelerinin ihtiyaç analizi sürecinde iş kurallarını ayrı bir şekilde yakalamak için, iş kuralı şablonu oluşturumalı ve bulunan her bir iş kuralı şablon ile belgelenmelidir. Bu amaçla analiz toplantılarında iş kurallarını keşfetmek için ayrı sorular sorulmalı ve kurallar tüm detayıyla, tipleri ve istisnaları dahil olmak üzere, yakalanmalıdır. Analiz ilerledikçe bu şekilde çalışarak bir iş kuralı kataloğu oluşacaktır. Bu katalog, iş süreçleri kadar önemli bir kaynak olacaktır.

Bununla birlikte iş kuralları, yazılım sistemlerinin sıklıkla değişen kısımlarını oluştururlar. Dolayısıyla iş kurallarının analizde yakalanıp tasarımda bunlara özel olarak yaklaşılması önemlidir. Nihayetinde yazılım sistemlerinin değişmesini tetikleyen en temel etmen, iş süreçleri ve kurallarındaki değişikliklerdir. Dolayısıyla iş kurallarının bir analiz konusu olarak yakalanması ve sonrasında tasarımda benzer şekilde özel bir şekilde ele alınması ve bu şekilde kodlanması, sistemin değişebilirliğini olumlu yönde etkileyecektir. Örneğin iş kurallarının rahatça yönetiminin ve değişmesinin sağlanması için bir iş kuralı motoru (rule engine) kullanılması ya da iş kurallarının kod içinde hard-coded olmasının önüne geçilmesi amacıyla örneğin veri tabanında tutulması ve dinamik olarak oradan yüklenmesi ve yönetilmesi, hep iş kuralı merkezli bir yaklaşımın sonucudur.

Aslolan iş kuralları ile ilgili hem iş düzeyinde hem de geliştirme düzeyinde farkındalığa ve bir metodolojiye sahip olmaktır. Yukarıda bahsettiğim sınıflandırmalar ya da isimlendirmeler bu tür yaklaşımlara bir örnektir ama sonuçta yaklaşımlar sadece bunlarla sınırlı değildir.

Tüm dünyada ve ülkemizde, projelerin ezici çoğunluğunda analiz süreci en problemli olan süreçtir. Analiz sürecini, bir malumat biriktiren, yapısallıktan uzak bir çalışma olarak ele almak, çok sık görünen bir yaklaşımdır. İş kuralları merkezli yaklaşım ise bizi daha analitik bir iş ve ihtiyaç analizi sürecine doğru götürecektir.

Toplam görüntülenme sayısı: 2619