Giriş

İletişimin en temel açıklaması, akla gelebilecek herhangi bir yöntemle bilgi alış-verişinin sağlanmasıdır. Doğadaki fizyolojik, biyolojik, teknolojik sistemler iletişim kurarak birbirleri ile haberleşirler. Örneğin siz bu satırları okurken gözlerinizin beyninizle iletişim halinde olması gibi. İletişim kurmak için bir mesaj üretilir, iletilir, karşı taraf bu mesajı alır ve genellikle bir geri bildirim ile iletişim döngüsünü tamamlar. Birbirleriyle devamlı iletişim halinde olan parçalar birleşerek daha büyük bir sistemi oluştururlar.

İnsanların birbirleriyle olan iletişiminden yakınlıklar, arkadaşlıklar, kurumlar, vakıflar, örgütler gibi küçük sistemlerden daha büyük sistemlere doğru, bir amaç çerçevesinde oluşturulmuş ekosistemler doğar. Günümüzde ise benzer olguyu teknolojik sistemlerde de görmekteyiz. Akıllı ev sistemleri gibi birçok farklı cihazın bir bütünü oluşturacak şekilde birbirleriyle konuştuğu sistemler artık bilim kurgu değil, bir çoğumuzun evinde yer almaya başladı. Eski zamanlarda bir şey satın almak istediğimizde satıcı ile iletişim kurmamız gerekirdi. Şimdi ise on-line marketlerden herhangi bir şey satın aldığımızda arka planda insanların değil entegre çalışan bir dizi sistemin konuştuğu, birbirleriyle haberleştiği işlemleri tetiklemiş oluyoruz.

Bu noktada, farklı işleri gerçekleştiren ancak birbirleriyle de iletişim kurması gereken farklı sistemleri bir bütün olarak ortaklaştıran entegrasyon kavramı sistemlerin iletişimi için elzem bir ihtiyaç olarak karşımıza çıkıyor. Sistemlerin birbirleri ile haberleşmesi, bir sistemin bir başka sisteme entegre olabilmesi için birbirleri ile mutabık kaldığı teknik bir yapının oluşturulması gerekir. Ancak işin sadece teknik tarafını ele almak, sistemler arası iletişimi sanki yapılabiliyormuş gibi göstermekten ileri gitmez. Bu yapının doğru oluşturulabilmesi için entegrasyon ihtiyaçlarının neler olduğunu, hem ihtiyaç sahiplerinin hem de ihtiyaca çözüm sunacak insanların kimler olduğunu da doğru analiz etmemiz gerekir.

Entegrasyon kavramı

Dilimize Fransızcadan geçen entegrasyon kelimesi, bütünleşme ve uyum anlamlarını içerisinde barındırır.

entegrasyon (fr. integration)
1. isim : Bütünleşme
2. isim : Uyum

Bütünleşme kısmı, çeşitli unsurların birbirini destekleme amacıyla bir araya gelmesini ifade ederken bu unsurların birbirlerini anlama, tanıma ve ahenk içerisinde birlikte çalışabilmesi de uyum kavramı ile ifade edilir. Dolayısıyla entegrasyon mevzusu ele alınırken sadece bütünleşme veya sadece uyum konusu dikkate alınırsa tam bir entegrasyondan söz edilmesi mümkün olmayacak, parçalardan bir kısmının eksik kalmasına yol açacaktır.

Entegrasyon kelimesi, genellikle insanların toplumla bütünleşmesi noktasında tercih edilir. Bu kullanımında bazen farklı değer yargılarına sahip ve yetiştiği kültürün dışındaki bir topluma kendini kabul ettirmeye, bütünleşmeye çalışan insanlar bazen de içinde bulunduğu topluma, toplumun kurallarına uyum gösterememiş görece sorunlu insanların topluma kazandırılması ifade edilmeye çalışılır. Bu tanımının içerisindeki toplum kelimesi yerine ERP(Kurumsal Kaynak Planlama) yazılımını, insan kelimesi yerine de ERP ile entegre olmaya çalışan yazılım ürününü yerleştirdiğimizde anlamını pek kaybetmese de ben yazının devamında entegrasyonun sosyal çerçevesinde değil yazılım ürünlerinin birbirleri ile ahenk içerisinde çalışmasına imkan verecek konulardan bahsedeceğim.

Ele alacağım entegrasyon, farklı yazılım ürünlerinin birbirleri ile olan ilişkileri üzerinedir. Yazının ilerleyen konularında başlı başına bir işi yapabilen yazılım ürünü olarak “birey” , bireylerin de yer aldığı Kurumsal Kaynak Planlaması (ERP) sistemi ile birlikte sistemin içindeki tüm yazılım ürünleri havuzunu işaret eden topluluğa ise “bütün” kelimesiyle ifade edeceğim. Entegrasyon yönü, bireyden → bütüne veya bütünden → bireye olabileceği gibi bütün ve birey arasında karşılıklı da olabilir. Az rastlansa da birey → birey arasında da entegrasyon söz konusu olabilir. Entegrasyona konu olabilmesi için her bir bireyin, bütün içerisinde işlenebilecek anlamlı veri üretmesi gerekmektedir. Bütün içerisinde anlamlı veri üretmeyen uygulamalar yer aldığında varlıkları bütüne zarar verebilir, diğer yönden bakıldığında ise yoklukları bir kayıp teşkil etmez. Aynı şekilde, entegrasyon katmanında bütünleşmeyi sağlayacak yapı kurgulanırken, taraflardan biri için anlam ifade etmeyen bilginin taşınması entegrasyon bütünlüğüne kimi zaman performans anlamında kimi zaman geliştirme maliyeti kimi zaman da bakım maliyeti açısından zarar verecektir. Minimum zamanda maksimum faydaya sahip olabilmek için yalınlık kavramı entegrasyon için de geçerlidir.

Bir projede sistemleri birbirleri ile konuşturmak istediğimizde, bir sistemin söylemek istediğinden ziyade diğer sistemin duymak istediğini baz alırız. Örneğin, bütün içerisinde kayıtlı bir stok hakkında yüzlerce veri tutuluyor olabilir. Ancak birey, bu verilerin sadece bir kaç tanesini duymak istiyorsa entegrasyonun konusu bireyin duymak isteyeceği bu bir kaç veriden ibaret olmalıdır. Yalnız burada “bütün, sadece bir kısım veriyi duyurmalıdır” anlaşılmamadır. Bütünün diğer yazılım ürünleri olan bireylerle paylaşacağı bilginin kısıtlı olması entegrasyonu kısıtlar, ihtiyaçların karşılanamamasına veya maliyetin artmasına sebep olur. Bu da günümüzde bir yazılım ürününün olmazsa olmazları esneklik ve çevikliğin kaybedilmesine yol açar. Dolayısıyla başarılı bir entegrasyondan bahsedebilmemiz için yalınlık, esneklik ve çeviklik başlıklarının doğru harmanlandığı entegrasyon araç ve yöntemlerin kullanılması gerekmektedir.

Entegrasyon ihtiyaçları

Bir bilge evrendeki tüm bilgiye sahip olabilir mi? Bir kitap evrendeki tüm soruların cevaplarını içerebilir mi? Peki tek bir yazılım, sektördeki tüm ihtiyaçlara cevap verebilir mi? Bu soruların cevaplarını hepimiz biliyoruz. Her bir yazılım ürünü, onu geliştiren yazılım ekiplerinin sahada gördükleri belli özel ihtiyaçları çözmek için oluşturulmuştur. Bazı yazılımlar belli bir sektördeki ihtiyaçların büyük bölümünü çözerken bambaşka bir sektör için anlam ifade etmeyebilir. Tüm sektörlerdeki tüm ihtiyaçları aynı anda çözebilen paketlenebilmiş bir yazılım ürünü ise tamamen ütopyadır. Zira, değil tüm sektörler için genelleme yapabilmek, sektörel bazda bile ihtiyaçlar zaman içerisinde değişmekte veya aynı sektördeki iki farklı firma bile problemlerini farklı yöntemlerle çözmektedir. Onlarca yıldır süregelen çalışma alışkanlıkları bir anda değişebilir. Ayrıca bir sektörün, örneğin mobilya sektörünün 2010 yılındaki ihtiyaçlarının büyük bölümünü çözen yazılım 2020 senesinde ortaya çıkan yeni ihtiyaçları karşılayamayabilir.

Yeni ihtiyaçlar ortaya çıktıkça o ihtiyacı karşılayan yazılımlar da geliştirilecektir. Geliştirilen yazılımlar ise hem kullanıcı ara yüzü hem de veri işleme yöntemleri bakımından farklılık gösterecektir. Tüm bireylerin ürettiği bu verinin bir bütün içerisinde yer alması için ise doğru bir entegrasyon kurgusu oluşturulmalıdır. Sanılanın aksine, doğru entegrasyon kurgusu için sadece entegrasyon ihtiyaçlarının teknik olarak karşılanması yeterli değildir. Entegrasyonu geliştiren paydaşların da kimler olduğunu ve beklentilerini anlamak gerekir.

Entegrasyon ihtiyaçları başlıklarını belirlerken baz aldığım kriter entegrasyon ihtiyacı doğuran hususlardır. Entegrasyon yaparken ortaya çıkan ihtiyaçların nasıl karşılanacağı konusu ise bir sonraki “Entegrasyon araçlarının özellikleri ne olmalı” başlığında ele aldım. Temelde entegrasyon ihtiyaçlarını 4 ana başlıkta dile getirmeye çalıştım;

1. Yazılım değişikliğinden kaynaklanan geçmiş dönemlere ait verilerin yeni sistemlere entegrasyonu
2. Firmaya özel yazılımlardaki verilerin bütüne entegre edilmesi
3. Farklı profesyonel yazılımların bütüne entegre edilmesi
4. ERP yazılımı içerisinde kurgulanmış uyarlamaların ERP uygulamasının standart ara yüzleri ile entegrasyon

Yazılım değişikliğinden kaynaklanan geçmiş dönemlere ait verilerin yeni sistemlere entegrasyonu

Eski ve köklü yazılımların avantajı, piyasaya yeni giren yazılımların ise dezavantajı sayılabilecek bir konu, yıllarca biriktirilen geçmişe ait verilerin durumudur. Başarılı bir geçiş arzusundaki müteşebbisin talebi genellikle tüm eski verilerin eksiksiz bir şekilde yeni sisteme de aktarılabilmesidir. Yazılım şirketleri, kendi bünyelerindeki markalar arası geçişlerde, eski verilerin kendi ürünleri arasındaki bu transferini büyük oranda sağlayabiliyorken farklı şirketlerin yazılım ürünleri arasındaki geçişler genellikle asgari seviyedeki bazı veriler ile kısıtlı kalabiliyor. Özellikle ERP yazılımları üreten yazılım şirketlerinin ürünleri arasında bir verinin nasıl saklanacağının belli standartları olmadığından, ERP ürününün değiştirilmesi gibi büyük çaplı yazılım değişikliği projelerinde bahsedilen asgari seviye genellikle şu şekilde belirlenir;

• Kanun koyucular tarafından talep edilen bilgi miktarı

Asgari seviyenin belirlenmesindeki en önemli kriterdir. Herhangi bir cezai müeyyideye maruz kalınmaması adına devletlerin ilgili sektör için oluşturduğu mevzuat gereğince sistemler arasında aktarılması olmazsa olmaz, tartışmasız aktarım kalemleridir. Eğer devlet tarafından bir veri zorunlu tutuluyorsa, örneğin “fatura en az iki yıl saklanmalı ve fatura üzerinde müşteri bilgisi bulunmalı” kuralını zorunlu tutuyor ise geçiş esnasında en az iki yıl öncesinden itibaren tüm faturalar ve faturalara bağlı müşteri bilgilerinin en az faturada görüntülenecek kadarlık kısmı yeni sisteme aktarılması gerekmektedir. Firmanın bir diğer seçeneği yasal süre boyunca iki sistemi eş zamanlı kullanmak ve eski verilere eski sistem üzerinden ulaşmak, raporlamaktır ki bu durumda teknik bir entegrasyondan bahsedilemediğinden bu seçenek bu başlıkta ele alınmıyor.

İlgili ülke mevzuatını desteklediğini iddia eden yazılımlar arası geçişlerde, mevzuat zorunlu tuttuğu için karşılık bulma konusunda en az kayıp yaşanan entegrasyon işlemidir. Burada yaşanabilecek problemler genellikle ilgili ülke mevzuatına hakim olmayan bir yazılımın geçiş için tercih edilmesiyle ortaya çıkmaktadır.

• Fişlerde yer alan varlıkları temsil eden verilerinin minimum tanımlarını içeren bilgiler

Bahsi geçen kart bilgileri stok/ürün kartları, banka hesap kartları, müşteri/cari kartları gibi irsaliye, ambar transferi, sarf fişi, tahsilat fişi, kredi kartı fişi gibi fişlerle hareket kazandırılan verilerin sabit bilgileridir. Kurumsal kaynak planlama yazılımları bu verileri çok farklı ve değişik biçimlerde saklasa da asgari entegrasyon ihtiyacı, son kullanıcının tarifleyebildiği kadarıdır. Örneğin eline bir bardak alan tüketici bu bardakla ilgili hangi verileri söyleyebiliyorsa (birimi, kapasitesi, adı vb.) bu veriler stok kartı için asgari seviyede aktarılması gereken verilerdir. Bunun yanı sıra sektör bazlı ihtiyaçlar ise sonsuz olabilir. Örneğin bir lojistik firması için bu bardağın taşıma esnasında araç içerisinde kaplayacağı hacmi, iş akışı açısından hayati önemde olabilir. Dolayısıyla geçiş yapılan sistemde bu verinin de entegre edilmesi gerekir. Ancak bardağın hangi materyalden yapıldığı verisi yapılan iş açısından bir anlam taşımıyorsa bu verinin entegre edilmesi entegrasyon yükü ve maliyeti oluşturur.

• Karar destek sistemlerini besleyen rakamsal veriler

Karar destek sistemi, bir şirketin orta ve üst düzey yöneticilerinin geleceğe yönelik yapılacak operasyonlarını planlamak için verecekleri kararları destekleyen bilgi sistemleridir. Daha önce kullanılan yazılımda bu bilgi sistemini besleyen verilerin taşınması da şirket içerisinde alınacak kararları sekteye uğratmamak adına elzem entegrasyon ihtiyaçlarından biridir. Örneğin, bir ürünün geçmiş yıla ait satış adetlerinin yeni sisteme entegre edilmemesi ya geçmiş verilerin eski yazılımdan izlenmesi gerekliliğini dolayısıyla eski yazılımdan vazgeçememeyi ve kullanıcı alışkanlığının sağlanamamasını doğurur ya da planlamanın gerçek veriye dayalı yapılamamasından kaynaklı yanlış yönelimlere yol açar.

Büyük yazılım değişikliklerinin kararı genellikle yazılımı doğrudan kullanan son kullanıcılar tarafından verilmez. Yazılım üzerindeki tecrübesini bir anda kaybeden son kullanıcı, karar verme aşamasında kullandığı veriyi de kaybederse bir önceki yazılıma duyduğu özlem artacaktır. Bu ise sağlıklı bir geçişteki en büyük problemlerden biridir. Dolayısıyla yazılım değişikliklerinden kaynaklanan entegrasyonlarda en önemli kriterlerden biri olmasına karşın karar sistemlerini destekleyen rakamsal verilerin entegre edilmesi hususu en çok atlanılan kriterdir.

Firmaya özel yazılımlardaki verilerin bütüne entegre edilmesi

Firma içerisinde, genellikle firmanın kendi özel işlemlerini otomatize etmek için kodlanan uygulamalar bulunur. Veri girişini çalışanların doğrudan yaptığı masraf formu, izin formu barındıran Intranet uygulamaları, Excel gibi hazır ürünler içerisinde geliştirilmiş veri ve grafiklerin ERP ürününe entegrasyonu bunlara örnek gösterilebilir. Bunun yanı sıra veri girişinin bir insan tarafından yapılmadığı, bir sistemin sensörleri veya hesaplamaları sonucunda üretilen verilerin, örneğin üretim hattında tamamlanan ürün miktarı veya banka yazılımları tarafından üretilip sistemimize iletilen ekstrelerin entegrasyonu da bu kategorinin konusudur.

Bu uygulamalar genellikle aşağıdaki kişi veya ekiplerce geliştirilir;

• Firmanın kendi IT ekibi tarafından
• Firmadaki hevesli çalışanlar tarafından
• İşin out source edildiği bir yazılım evi tarafından
• ERP danışmanlığı alınan firma tarafından

Farklı profesyonel yazılımların bütüne entegre edilmesi

Yazılım şirketleri, müşteri özelinde proje bazlı çalışmalarda bulundukları gibi sektördeki özel bir konuya odaklanıp bu konuda kazandıkları tecrübeyi standart paket yazılım ürünü haline de getirebilir. Bu paket ürünlerin de firmanın verisinden pay alabilmesi veya veriyi besleyebilmesi için entegrasyon katmanına sahip olması gerekir. Paket ürün geliştiren yazılım şirketleri kendi müşteri topluluklarına sahiptir. Fakat aynı müşteriler başka bir yazılımın da müşteri topluluğunda daha yer alabilir. Kesişim kümesindeki müşterilerin genel beklentisi bu iki farklı yazılımın ortak noktalarda birlikte hareket etmesi ile mükerrer işlemlerin minimum seviyeye inmesi belki de ortadan kalkması yönündedir. Örneğin, otomotiv üretim sektöründe güçlü bir yazılım, depo yönetimi alanındaki bir yazılım ile kesişim kümesinde buluşabilir. Bu yazılımların birbirleri ile veya ortak bir ERP ürünü vasıtasıyla iletişim kurmaları beklenir.

Profesyonel yazılımların birbirleri ile entegrasyonu temel iki başlıkta değerlendirilir

• Yatay Ürün Entegrasyonu
• Dikey Ürün Entegrasyonu

ERP yazılımı içerisinde kurgulanmış uyarlamaların ERP uygulamasının standart ara yüzleri ile entegrasyonu

ERP yazılımları içerisindeki standart formlar (örneğin “stok kartı”) son kullanıcı açısından belli bir seviyeye kadar kabul görse de sektöre özgü veya firmanın iş yapış alışkanlıklarına özel bir takım eksiklikler barındırabilir. Bu durumda standart ara yüzlerin son kullanıcı için özelleştirilmesi gerekir. Bu özelleştirme entegrasyon kavramı ile değil uyarlama (customization) kavramı ile ifade edilir. Günümüzde birçok ERP ürünü, standart ara yüzlerinin uyarlanabileceği uygulamalara da sahip. Bu uyarlamalar kimi zaman ERP içerisindeki standart modüllerin birbirleri ile entegrasyonunu gerektirir. Örneğin, fatura girişi esnasında, fatura ara yüzündeki bir buton vasıtasıyla otomatik olarak müşteri(cari) kartın oluşturulması otomatize edilmek istenebilir.

Entegrasyon ihtiyaçlarına çözüm sunanlar

Futbol ülkemizde olduğu kadar dünyada da sevilen bir spor dalı. Futbola gönül veren insanlar arasında futbol karşılaşmalarını izleyenler arasında hayatlarına bir spor olarak da katan, örneğin halı sahada futbol oynayanlar da var. Bunun yanı sıra futbolu profesyonel olarak icra eden, bu işten para kazanan oyuncular da var. Bu oyuncular da amatör, 3.lig, 2.lig, 1. lig ve süper lig gibi kategorilere ayrılmış katmanlarda futbol oyunculuklarını sergiliyor. İstisnalar da olabileceğini öngörerek bir genelleme yaparsak, asıl işi futbolculuk olmayan, halı sahada bu oyunu oynayan insanlar ile profesyonel işi futbolculuk olan insanlar arasında bilgi, beceri, teknik, kondisyon kriterlerinde farklar olacağını söyleyebiliriz. Halı sahada futbol oynayan kişinin, oyunundan beklentisi iyi vakit geçirmek, spor yapmak veya belki lokal turnuvalarda başarı elde etmek olabilir. Ancak bu işi profesyonel olarak yapan bir süper lig oyuncusunun hedefleri çok daha farklıdır.

Yazılım geliştiren insanlar arasında da akademik olarak bu işin eğitimini almış, profesyonel olarak bu işi yürüten deneyimli insanlar olduğu gibi asıl uzmanlık alanları farklı, yazılım konusuna hevesli ancak teknik bilgisi nispeten daha az insanlar veya görece henüz amatör ligde yer alan yazılım geliştiricileri de olabilir.

Entegrasyon araçlarımızın kullanılabilmesi için gerekli teknik bilgi ne kadar yüksek ise entegrasyon ihtiyaçlarını karşılayabilecek kitle de o kadar azalır. Entegrasyon araçlarının sahip olması gereken özellikler bölümünde belirttiğim özelliklerin ne kadarı hayata geçirilirse bu konuda entegrasyon projesi de o oranda artacaktır.

Örneklendirmek gerekirse, üzerindeki verinin bir başka uygulamaya aktarıldığı veya kendisine veri aktarımının yapıldığı, dolayısıyla entegrasyon işlemlerinde en yoğun kullanılan yazılımın Microsoft Excel olduğunu söylersek herhalde yanılmış olmayız. Microsoft Excel iş hayatının içerisinde o kadar yer etmiştir ki Excel yönüne veya Excelden yapılan aktarımların aslında bir entegrasyon olduğu bile fark edilmez. Excel entegrasyonu, her seviyedeki yazılım geliştiricisinin gerek kendi bilgi, beceri, deneyimiyle gerekse internet üzerinde bulabileceği bir kaç örneği inceleyerek gerçekleştirebileceği düzeydedir ve entegrasyon araçlarının sahip olması gereken özellikler bölümünde bahsettiğim tüm kriterleri karşılamaktadır.

Entegrasyon yöntemi, formatı, aracı tasarımında hedeflediğimiz kitlenin öneminden bahsetmiştik. Firma içi yazılım projelerini ve bu iç projeleri geliştiren insanları biraz tanıyalım.

Firmanın kendi IT Ekibi tarafından geliştirilen iç yazılımlar

Muhtemelen akademik olarak da yazılım geliştirme konusunda eğitim almış kişilerce geliştirilen küçük yazılımlardır. Küçük ölçekli firmalardaki yaklaşımlar ile büyük ölçekli firmalardaki IT yapısı bu maddeyi iki kırılıma ayırır.

Nispeten küçük ölçekli firmalarda, mesailerinin tamamı yazılım geliştirmek olmayan, genellikle donanım problemlerine ve iç yazılımlara da destek olan personel tarafından geliştirilmiş uygulamalardır. Geliştirme ortamı, dili ve kullanılacak araçlar yazılımı geliştiren kişi veya ekibe bırakılır. Dolayısıyla her geliştirilen uygulama farklı programlama dili veya ortamına sahip olabilir. IT ekibinin genel yönelimi, aynı zamanda destek de verdikleri iç müşterilerinden minimum kötü geri bildirim almaktır. En büyük risk ise, bu tip geliştirmeler genellikle proje kapsamında ele alınmadığından ihtiyaçların belirlenmesi, değişikliklerin uygulanması (genellikle) bir sistem üzerinden takip edilmemesidir. Bir diğer riskli konu ise analiz eksikliği olabilir. IT ekibi çalıştığı şirketin mekaniklerine hakim olmayabilir. IT ekibi, iç müşterilerinin onlara aktardığı kadarıyla, o çerçeve içerisinde kalarak bu geliştirmeyi yapacaktır. İç müşteriler ise işi tariflerken o işin minimum gereksinimlerinin herkes tarafından bilindiğini varsayarak tariflemiş olabilir. Bu tip projeler çok sayıda revizyon içerir.

Büyük ölçekli firmalarda ise (eğer geliştirme kendi bünyesinde yapılacaksa) IT departmanına bağlı iç yazılımlar ekibi bulunur. Bu tip firmalarda görece olarak geliştirme ortamı, programlama dili seçimleri, analiz ve test süreçleri normlara daha uygun ve sistemli ilerlese de çok sayıda revizyonla bu tip firmalarda da sıklıkla karşılaşılır.

Entegrasyon aracının sahip olması gereken özelliklerin her biri önem arz eder. Ancak bu kriterler içerisindeki veri bütünlüğünü bozmadan aktarım yapılabilmeli ve hata oluşmadan yakalanabilmeli kriterleri hem bu grup hem de müşteri memnuniyeti açısından hayati önem arz eder.

Firmanın hevesli çalışanı tarafından geliştirilen iç yazılımlar

Kendi işlerinde uzmanlaşmış, firmanın iş yapış şekillerine hakim ve problemleri nokta atışı tarifleyebilen bazı çalışanlar, kendi işlerini daha hızlı tamamlayabilmek amacıyla birçok inovatif fikre sahip olabilir. Akademik olarak yazılım geliştirme konusunda eğitim almamış olsa dahi bu fikirlerini hayata geçirmek amacıyla araştırıp, öğrenip entegrasyon çalışmalarına girişebilir. En büyük kaynakları forum, entegrasyon dokümantasyonları ve örnek uygulamalardır. Bu geliştiricilerdeki en büyük risk ise çalışana bağımlı uygulamaların varlığıdır. Firma ile hevesli çalışan yollarını ayırdığında genellikle bilgi birikimi de kaybolur ve entegrasyon çalışmaları baştan ele alınmak zorunda kalır.

Hızlı ve basit kodlama imkanı ve bakım maliyetinin düşük olması kriterleri bu kitle için üst sıralarda yer alan kriterlerdir.

Yazılım firmaları tarafından geliştirilen iç yazılımlar

Firma tarafından iç yazılım projesi out-source edilmiş olabilir. İhtiyaçların profesyonel yazılım firmaları tarafından geliştirilmesi programatik açıdan görece daha kusursuz iç yazılımlar ortaya çıkaracaktır. Bu iç yazılımların bütüne entegrasyon başarısı ise yazılım şirketinin diğer entegre edilecek yazılımlar konusundaki tecrübesiyle orantılıdır. İlgili yazılım firması doğru yönlendirildiğinde, özellikle de ERP danışmanlığı alınan firma ile ortak bir proje ortaya konulduğunda oldukça başarılı sonuçlar elde edilebilir.

Bu tip yazılım firmaları proje usulü çalıştığından benzer projelerde hızlı hareket edebilmek için kod kütüphaneleri oluştururlar. Entegrasyon aracının sahip olması gereken kriterlerden hazırlanan kodların tekrar kullanılabilmesi ve yöntemlerde kullanılan geri bildirimlerin belli bir standartta kurgulanmasının yanı sıra, “bu veri daha önce kaydedilmiş” gibi sıradan bir problemde son kullanıcının tekrar tekrar yazılım şirketinden destek alma ihtiyacı oluşmaması adına hata mesajlarının son kullanıcıya gösterebilecek netlikte olması entegrasyon kriterleri içerisindeki en elzem konularındandır.

Danışmanlık alınan firmalar tarafından geliştirilen iç yazılımlar

Özellikle profesyonel ERP desteği veren firmaların çalışanları genellikle firmadaki farklı departmanların çalışma şekillerine, problemlerine de hakimdir. Bu nedenle hem işin tariflenmesi hem de entegrasyon sonuçlarının değerlendirilmesi konusunda riskleri düşüktür. Daha açık bir ifadeyle son kullanıcı tarafından arzu edilen fayda ile ortaya çıkan fayda birbirine en yakın seviyededir. Ancak, özellikle yapılan entegrasyonun kaynak kodu hakları konusu her iki firma arasındaki bağlayıcılığı da belirleyen kritik bir konudur. Aynı zamanda ERP desteği ile yazılım desteği konusunun çatışmasına sebep olabilir.

Velhasıl bu kitle daha önce bahsettiğimiz firmanın kendi IT ekibinin, hevesli çalışanın ve yazılım firması çalışanın duygu, düşünce ve teknik kabiliyetlerinin bir veya birden fazlasını barındırabilir. Diğer gruplardan bu grubu ayıran özellik ise diğer gruplar elindeki yazılımı değerlendirir veya bir iş olarak paslanmış entegrasyon ihtiyacını çözmeye çalışırken, bu grup danışmanlık verdiği yazılımı kendisi belirleyebilir, kariyer yolunu belli bir yazılımın danışmanlığını verecek şekilde belirleyebilir. Danışmanlar, entegrasyon konusunda müşteri ihtiyacını müşteriden daha iyi tarifleyebilir.

Danışmanlık alınan firmalar tarafından geliştirilen iç yazılımlar

Özellikle profesyonel ERP desteği veren firmaların çalışanları genellikle firmadaki farklı departmanların çalışma şekillerine, problemlerine de hakimdir. Bu nedenle hem işin tariflenmesi hem de entegrasyon sonuçlarının değerlendirilmesi konusunda riskleri düşüktür. Daha açık bir ifadeyle son kullanıcı tarafından arzu edilen fayda ile ortaya çıkan fayda birbirine en yakın seviyededir. Ancak, özellikle yapılan entegrasyonun kaynak kodu hakları konusu her iki firma arasındaki bağlayıcılığı da belirleyen kritik bir konudur. Aynı zamanda ERP desteği ile yazılım desteği konusunun çatışmasına sebep olabilir.

Velhasıl bu kitle daha önce bahsettiğimiz firmanın kendi IT ekibinin, hevesli çalışanın ve yazılım firması çalışanın duygu, düşünce ve teknik kabiliyetlerinin bir veya birden fazlasını barındırabilir. Diğer gruplardan bu grubu ayıran özellik ise diğer gruplar elindeki yazılımı değerlendirir veya bir iş olarak paslanmış entegrasyon ihtiyacını çözmeye çalışırken, bu grup danışmanlık verdiği yazılımı kendisi belirleyebilir, kariyer yolunu belli bir yazılımın danışmanlığını verecek şekilde belirleyebilir. Danışmanlar, entegrasyon konusunda müşteri ihtiyacını müşteriden daha iyi tarifleyebilir.

Geri bildirimin her türlüsü fayda sağlasa da bu grupta yer alan kişilerden alınan geri bildirim, problemlere genellikle kendi kısıtlı çerçevesinden bakan diğer gruplara nazaran çok daha değerlidir.

Kendi yazılımlarını bütüne entegre edenler

Tecrübe ve yeteneklerini kullanarak, sahada gördükleri ihtiyaçlara çözüm sunan yazılım veya yazılımları geliştiren sektör profesyonelleridir. İş ortaklıkları kapsamında bir veya birden fazla yazılımla birlikte çalışabilir, diğer yazılımlara veri sağlayabilir, diğer yazılımların verisini de işleyebilirler. Genellikle kendi entegrasyon katmanlarına da sahiptirler ve kendi entegrasyon katmanları ile diğer yazılımların entegrasyon katmanlarını konuştururlar. Tam olarak yazımızın başlığındaki insanlar değil sistemler konuşuyor konusunun temelini oluştururlar.

Bu firmaların beklentisi ise standartlara uygun bir entegrasyon katmanının var olmasıdır. Örneğin bir web servis entegrasyonunda başarılı bir aktarımın karşılığında bu aktarımın sorunsuz gerçeklendiğini belirten “200” grubu mesaj kodlarından biri beklenir. Ancak 200 mesajı dönmesine rağmen bir işin yapılmamış olması veyahut tersi yani başarısız olduğuna dair bir mesajın dönmesine rağmen verinin işlenmiş olması entegrasyon katmanının başarısız kurgulandığını veya hatalı çalıştığını gösterir.

Başarısız kurgulanmış entegrasyon katmanı firmalar arası yapılacak iş ortaklıklarında ortaya çıkarılacak işin proje süresinin uzamasına, belki de hiç gerçekleşememesine yol açacaktır. Başarısız bir entegrasyon kurgusu, yüksek memnuniyetsizlik, zaman ve emek kaybına yol açtığı gibi entegrasyon katmanı gibi teknik konunun standartlara uymaması, aynı zamanda yazılımın entegrasyon dışı katmanlarındaki yapının da güvenilirliğini sorgulatır.

Kendi yazılımlarını başka ürünlere entegre edenler aynı zamanda yazılımımızın pazar açılımında da rol oynarlar. Müşterilerine tavsiyede bulunmaları gerektiğinde, kendilerinin sorunsuz entegre oldukları yazılımları müşterilerine önerecekleri şüphesizdir. Dolayısıyla kendi yazılımlarını bütüne entegre edecek firmaların entegrasyon ihtiyaçlarının analiz edilmesi, bu firmaların ihtiyaçlarını karşılayacak bir yapının kurgulanması, bunun getirisi olarak da ekosistemimizi geliştirecek iş birliklerinin artması, sektörde uzun süre var olmak isteyen her yazılım için hayati kriterdir.

Entegrasyon katmanında kullanılacak araçların özellikleri ne olmalı?

Eğer teknik biri iseniz muhtemelen önceki yazılanları okumadan doğrudan bu başlığa geldiniz 🙂 Ancak önceki konu başlıklarını okumadan, aşağıda sıraladığım kriterlerin öneminin anlaşılması mümkün değildir. Doğru bir entegrasyon katmanı kurgulamak istiyorsanız öncelikle daha önce yazdıklarımı okumanızı tavsiye ederim.

Entegrasyon katmanı kurgularken aklımızdan çıkarmamamız gereken önemli hususlardan biri şudur; entegrasyonun alt katmanlarından “aktarım katmanı” için günümüzde kullanılan teknik yöntem ve formatların neredeyse tamamı 2000li yıllara gelmeden önce icat edildi. Dolayısıyla o dönemde oluşturulan entegrasyon katmanı ve araçları, eğer aşağıdaki kriterlere cevap verebilir şekilde doğru kurgulandı ise on yıllardır yapısal bir değişikliğe ihtiyaç duymadan geçerliliğini koruyor olmalı.

Doğru kurgulanmayan entegrasyon katmanları ise entegrasyonu gerçekleştirecek insanların eğitilememesine, entegrasyon problemlerinin sıklıkla tekrar tekrar dile getirilmesine, proje bazlı entegrasyon aracı/katmanı oluşturulmasına, eko sistemimize katılma hevesi içerisindeki potansiyel iş ortaklıklarının kaybedilmesine ve nihayetinde de dar bir ekosisteme yol açar.

Entegrasyon araçlarının özelliklerinin belirlenmesi, yazılım ürünümüze kimlerin entegre olmasını istediğimizle doğrudan ilgilidir. Entegrasyon yönteminin belli bir programlama dilini veya belirli bir işletim sistemini baz alması, bizim yazılımımızla entegre olabilecek paket yazılım sayısını oldukça kısıtlar. Entegrasyon araç ve yönteminin aşağıda sıralanan yeteneklere sahip olmaması, yazılımımızla bir proje geliştirmek isteyen yazılım firmaları ve müşterilerimiz için daha uzun proje süresi, dolayısıyla da daha maliyetli projeler ortaya çıkmasına sebep olur. Ancak bu bir tercih de olabilir. Entegrasyon aracının aşağıdaki yeteneklere sahip olması, doğru bir kurgu için operasyonel ekipler ile koordinasyon, doğru bir analiz ve ekstra efor gerektirir. Entegrasyon altyapısı için yazılım şirketleri bu maliyete katlanmak istemeyebilir. Dolayısıyla çok daha kısıtlı entegrasyon yapıları ile varlıklarını sürdürmeye çalışabilir.

Yazılımların altyapıları çeşitlilik gösterse bile, bu entegrasyonları gerçekleştirecek olan ihtiyaç sahipleri(ister insan ister bir yazılım ürünü) beklentilerinin farklılık göstermeyeceğini öngörebiliriz. Aşağıda sıralanan başlıklar için ileride iyi ve kötü örnekleri ile birlikte daha ayrıntılı konuları ele alacağım. Özetle, entegrasyonun teknik ve sistematik yapısı, aktarım formatı ne olursa olsun, geniş kitlelerce kabul görebilmesi için karşılaması gereken kriterler şunlar olmalıdır;

• Hızlı ve basit kodlama imkanı sunmalı

Hızlı : Herhangi bir dokümantasyon ihtiyacı olmadan dahi entegrasyon belli kurallar çerçevesinde gerçekleştirilebilmeli. Örneğin; içeriden okunan bir veri değişikliğe gerek duyulmadan tekrar içeriye aktarılabilmeli.

Basit : Mümkün olan en az veri alanı ile yapılabilecek en fazla iş yapılmalı. Aynı verinin taşındığı birden fazla mükerrer alan veya blok olmamalı, entegrasyonu yapan kişi için anlamsız alanlar aktarım formatı içerisinde de yer almamalı.

Bu adımda bahsedilmek istenen “Hızlı” ve “Basit” kavramları günümüzde sıklıkla ifade edilen “Low-Code No Code” kavramı ile doğrudan ilintilidir.

• Veri bütünlüğünü bozmadan aktarım yapmalı

Yeni oluşturulacak veri, ara yüzden girilmiş gibi hareket etmeli, tüm hesaplamalar ve veri ilişkileri yazılımın ara yüzündeki süreçler ile uyumlu olmalı. Aktarılan herhangi bir veri, entegrasyonu veya son kullanıcı tarafındaki akışı bozmamalı/bozamamalı. Nasıl ki ara yüzden son kullanıcı tarafında manuel girilen bir bilgi ile hatalı bir kayıt oluşturulamıyorsa(veya oluşturulamaması bekleniyorsa) aynı şekilde entegrasyon ile de (bile isteye yapılmaya çalışılsa dahi) hatalı kayıt oluşturulamamalı.

• Bakım maliyetleri düşük olmalı

Yürüyen projelerde aynı koda tekrar tekrar müdahalede bulunma ihtiyacı olmamalı. Standart veya tekrar eden işlemler için ayrı ayrı metotlar yer almamalı, örneğin ara yüzde hesaplama işlemleri kaydetme esnasında otomatik oluyorsa entegrasyon ile de otomatik olmalı. Bu işlem için entegrasyonu yapmaya çalışan yazılımcıdan ayrıca “hesapla” rutinini çağırması beklenmemeli. Fazladan kullanılan her metot, hem geliştirme süresini hem de bakım maliyetini arttırır.

• Versiyon değişikliklerinden etkilenmemeli

Kanunen zorunlu olmadığı sürece veya son kullanıcı ara yüzünde olmazsa olmaz bir bilgi eklenmediğinde daha önce yazılmış kod güncel versiyonlarda da çalışmalı.

• Hazırlanan kodlar tekrar kullanılabilir olmalı

Veri aktarımlarının genel kuralları olmalı, müşteri(cari) kartı aktarımı ile stok(ürün/malzeme) kartı aktarımı arasında şeklen bir fark olmamalı. Kod kütüphaneleri, kopyalanarak çoğaltıldıklarında küçük değişiklikler ile farklı aktarımlara da imkan vermeli.

• Yöntemler ve geri bildirimlerde bir standart izlenmeli

Entegrasyon esnasında, olumlu veya olumsuz bildirimler standart olmalı. Örneğin stok kartının silinmesi sonrasındaki geri bildirim ile müşteri kartının silinmesi esnasındaki geri bildirim benzer içerikte olmalı.

• Entegrasyondaki yöntem programlama dili ve geliştirme ortamından bağımsız olmalı

Entegrasyon aracı/yönteminde belli bir dile özgü yöntemler yer almamalı, örneğin herhangi bir metottaki çıktısı sadece .NET deki bir komponenti işaret etmemeli, sadece Java içerisinden tetiklenebilecek bir kural yer almamalı. Yalnız burada tekrar ifade etmeliyim, entegrasyondan kastım sadece veri alış-verişidir. Uyarlama (UI üzerindeki etkileşimler) ise bambaşka bir konudur. Uyarlama kavramında entegrasyonun aksine popüler geliştirme ortamları hem uyarlanan hem de uyarlayan için faydalıdır.

• Hata, oluşmadan yakalanabilmeli

Herhangi bir hata ortaya çıkması durumunda kayıt işlemi yapılmamalı. Herhangi bir hatanın mesajı entegrasyon aracı üzerinden iletilmeli, farklı kaynaklar içerisinde problem aranmamalı. Validasyon hataları, entegrasyonu geliştiren yazılımcının son kullanıcıya doğrudan gösterebileceği netlikte olmalı.

• Toplu işlemlere izin vermeli

Entegrasyon işlemlerinde son kullanıcıların ara yüzde yapabilecekleri işlemlerin yanı sıra toplu entegrasyon işlemleri de kurgulanmalıdır. Bu kurgudaki en önemli kriter performans olmalı. Örneğin bir stok kartı entegrasyonu esnasında validasyonda tek stok kartı dikkate alınır ve kontrol edilir, ancak toplu stok kartı aktarımında, aktarım bloğu içerisindeki stok kartları tek tek değil toplu halde göz önünde bulundurularak validasyondan geçmeli.

Sonuç

Bu ilk yazımda entegrasyonu kavramsal olarak betimlemeye çalıştım. Teknik kısımda da günün şartlarına uygun doğru yöntemler kullanıldığında sorunsuz bir entegrasyonun kurgulanabileceğine inanıyorum. Umarım yıllar içerisinde karşılaştığım iyi ve kötü tecrübelerime dayanarak özetlemeye çalıştığım konuları doğru aktarabilmişimdir.

Kaynak: https://medium.com/@naciozkan/i%CC%87nsanlar-de%C4%9Fil-sistemler-konu%C5%9Fuyor-28e555d8550d