Servis Tabanlı Ürün Mimarisi Tasarım Sorunları – Product Service System Design Problems

Yazılım mimarisinde zorlandığımız konulardan biri aynı sistem üzerinde somut ürünleri ve hizmet bazlı ürünleri bir arada satmak istediğimizde ortak bir yazılım mimarisi oturtabilmekti. Bu zorluk hem veritabanı hem de sınıf yapıları için geçerli bir durum.

Neden?
Bugünkü dünyada ürünlerle sağlanan hizmetler giderek daha çok yer tutmaktadır. Eskiden araba satışı yapıldıktan sonra üreticinin müşteriyle ilişkisi kesilirken, bugün gelinen noktada üreticilerin bir bölümü araçları kiralama modeliyle müşterilerine sunmaktadırlar. Yani müşteri arabayı değil, belirli sürelerle araç kullanma hizmetini almaktadır [2]. Bu durumda eskiden üretim tarafında kullanılan BT sistemleri yeni ihtiyaçlar için yetersiz hale gelmiştir.

serviceproductsubs-01

Ürünlere İlişkin Hizmetlerin Sınıflandırılması [3]

Zorluklar

Somutlaştırma,
Somut ürünlerde ürün stok kodunun yanında, ürün tanımı (ad, üretici kodu, vb.) gibi bilgiler kullanılırıken, servis bazlı ürünlerde servisin başlangıç, bitiş süresi, tanımı ve opsiyonel bazı diğer seçenekler söz konusu. Somut ürün satışından sonra buna ilişkin bakım, yenileme ve benzeri servis bazlı özelliklerin bilgilerinin tutulması ve bunlara ilişkin iş akışlarının tasarlanması gerekiyor. Servis üyelikleri (sesli ve görüntülü iletişim), sigorta, finans, eğitim, tatil ve yazılım gibi hizmet ağırlıklı ürünlerde ise satış sonrasında yerine getirilmesi gereken işlemler ağırlık kazanmaktadır.

Somut ve Servis Tabanlı Ürünlerin Karşılaştırması

serviceproductmapping-02

Servis ve Somut Ürün Karşılaştırması

Zorluklar

Hem ürün hem de servis bazlı sistemlerde değişiklik talepleri karşısında karşılaşılabilecek zorluklar,

  • Bağımlılık yönetimi: Bir değişikliğin sistemdeki diğer nesneler üzerindeki etkisi
  • Yeni değişiklik noktaları: Sisteme yeni değişiklik noktalarının eklenmesi.
  • Sistem tasarımın değiştirilmesi: Değişen ihtiyaçlar doğrultusunda tasarımın değişmesi. İçlerinde ne pahalı olan güncellemedir.

Çözüm Yöntemleri

  • Ayrık Sistemler: Somut ve servis bazlı ürünlerin ayrı sistemler sahip olması. Aradaki ilişkinin paylaşılan ürün tekil numaraları üzerinden sağlanması.
  • Karma Sistemler: Ayrım yapılmaksızın somut ürünleri ve hizmetleri tek bir sistemde barınması.
  • Tümleşik Sistemler: Somut ürünler ve bunlara ilişkin hizmetleri ayrık yapılarda olmasına karşın aralarında güçlü bağların olması.

Bağlantılar,

[1] http://www.servicedesignresearch.com
[2] Oksana Mont (2002). “Clarifying the Concept of Product-Service System”(PDF). Journal of Cleaner Production 10 (3): 237–245. doi:10.1016/S0959-6526(01)00039-7.
[3] Brezet, H. (2000). Product-Service Substitution: Examples and Cases from the Netherlands. In Mont, O. & Ryan, C. (Eds.), “Funktionsförsäljning” – productservice systems, AFR-report 299 (pp. 16-18). Stockholm: Swedish EPA.

Reklamlar

Servis Tabanlı Ürün Mimarisine Tasarım Önerisi – A Design Model for Service Based Systems

Önerilen mimaride iş geliştirme, pazarlama, v.b. departmanlar tarafından tasarlanan servislerin BT sistemlerinde nasıl uygulanabilir sorusuna yanıt aranmaktadır.

Mimaride yer alan temel birimler,

ServiceModel-01.png

Servis Modeli

Servis Paketi: hizmet satışlarında genellikle tek bir paketin içinde birden fazla servis tanımlanır. Müşteri tarafında ise bunlar tek bir paket altında sunulur. Konuyu anlatmak için İnternet’te yapılan alışverişler üzerinden bir benzetme kullanabilir. Bu alışverişlerde genellikle sepet mantığı kullanılır. Seçtiğiniz ürünleri sepete tek tek eklersiniz. Sonra da sepeti satın alırsınız. Servis paketi ise bunun tersyüz edilmiş halidir. Müşteri paketin tamamını alır. Sistemler arka planda paketi oluşturan servisleri oluşturur ve gerekli işlemleri başlatır. Her servis paketinde bir veya birden fazla servis bulunabilir.

Servis: Esas hizmete ilişkin Servisi Birimi, Kural Dizgisi, Veri Erişim Katmanı ve Uygulama Adaptörü gibi bileşenleri barındırır.

Servis Birimi: Hizmete ilişkin işleyişleri (iş mantığını) barındırır. Durum makineleri ve BPEL süreçleri servisleri uygulamak için kullanılabilir. Galatataş üyeliği sonrasında veri tabanına gerekli kayıtların açılması, müşteriye SMS atılması, iş ortaklarına mesaj geçilmesi, sözleşme belgelerinin hazırlanması bu servis birimlerinin içinde tanımlanabilir.

Kural Dizgisi: Hizmete ilişkin kuralların tanımları yer alır. Bunlar arasında çalışma zamanları, kontroller (Maça gelişlerde Galatataş üyeliğinin devam edip etmediğinin kontrolü), vb. yer alır.

Veri Erişim Katmanı: Veritabanlarını veya diğer XML servislerine erişimde kullanılır.

Uygulama Adaptörü: Diğer sistemlerdeki servislere tek bir arayüz üzerinden erişmeye imkan sağlar. Sistem üzerinden farklı operatörlede bulunan SMS servislerine tek bir arayüz üzerinden göndermek için kullanılabilir.

Mimaride önerilen peketlerin altında yer alabilecek uygulamalara ilişkin örnekler,

Servis Modeli Uygulamaları

ServiceModelExamples-02.png

Servis mimarisinde çeşitli birimlerde kullanılabilecek teknolojiler,

Servis Modeli Teknolojileri

ServiceModelTechnology-03.png

Servis Modelinin Kullanımı

Önerilen servis modeli teknoloji ve uygulamadan bağımsız olarak tasarlanmış ve geneli kapsaması düşünülmüştür. Benzer bir model uygulanmak istendiğinde kullanılan teknolojilere ve uygulamanın alanına bağlı olarak bazı kısıtlamalar oluşacaktır. Uygulama servis modeli buna göre şekillenecektir. Modeli gerçeklemede yazılım tasarımın temel ilkelerinden uzmanlık (expert), az bağımlılık (low coupling), iyi uyum (high cohesion), arabirim (indirection, adapter, facade) kullanılması durumunda daha sağlıklı yapılar elde edilecektir.