Can Cobanoglu's Picture

Can Cobanoglu

geek, technologist, life-long learner, kinda musician, phd candidate in computer science, fitness addict, entrepreneur...

12 posts

StartUp'lar Kimi İşe Almalı/Almamalı

Tech Uniform : ref http://static6.businessinsider.com/tech-uniform-2014-5

Bu yazıya nasıl bir başlık atacağımı açıkçası bulamadım. Yazılım ekibinizde olmasını isteyeceğiniz ve şirketinizi sizinle birlikte büyütebilecek kadar etkisi olabilecek tarzda insanların ne gibi ortak özelliklerinin olduğunu şimdiye kadar verdiğim doğru ve yanlış kararlarla az çok anlayabildiğime inanıyorum. Karar vermeniz gerekiyor ve zorlanıyorsunuz. Bazen iç güdülerinize güvenmeniz gerekiyor. Tecrübe ile oturan bir özellik kazandığınızı farkedeceksiniz. Halen tam olarak "işte budur" diyebilecek kadar kararlı olamıyorum.

Kariyerimin büyük bir bölümü "startup" şirketlerde geçti. Startup dünyası ile ilgili ahkam kesme niyetinde olmadığımı önceden belirteyim. Şimdiye kadar sürekli aklımı kurcalayan bir konu üzerinde düşünüyorum. Kısıtlı bütçelerle, yeni bir ürün etrafında organize olan, sıfırdan birşeyler yapmak isteyenler yolun başındayken doğru insanı bulmak adına ne gibi sorular soruyorlar ? Sormalılar ya da sormamalılar. Bu insanları ararken neye bakmamız gerekiyor ? Yaşam tarzları mı ? Giyim tarzları mı ?

Eminim birçoğumuz Silicon Valley adlı diziyi duymuştur. Bu yazıyı okuma ihtiyacı duyuyorsanız diziye da rastlama ihtimaliniz var. Peki izleyenler Gavin Belson'ın 5'li grup analizini hatırlıyor mu ?

Eğer bir startup için işe alım sürecinde yer alıyorsanız ve de Gavin Belson gibi muazzam analiz yetenekleriniz yoksa (!) dikkat edin derim.

Şimdiye kadar yüzlerce iş görüşmesine katılmış biri olarak hem işe alım süreçlerini hem de iş başvurusunda bulunan insanları gözlemleme şansını yakalamış oldum. Adayları işe alım süreçlerinde değerlendirirken bazı şeylere dikkat etmeye başladım onlardan bahsedeyim.

Boş zamanlarında ne yapmayı tercih ediyorsun ? sorusuna verilen cevaplar

Sana ne ? diyen olmadı tabi ki. İnsanların boş zamanlarına da talip olmak çok hoş görünmese de, bizim işin raconu bu. Üniversite çağından itibaren sadece sınavlar için evde sabahlamış ve iş hayatında akşamını gündüzüne katmamış insanların sana katkısı olmaz. Olamaz. Ele gitsin. !

Kariyer hedefim yönetici/müdür olmak ...

Kişinin, şirketlerin ve ülkenin gelişimine balta vuran bir anlayış. Yöneticiliği kariyer planı olarak değerlendirmek. Unutmayın, liderlik insanların doğasında olan bir yetenektir. Çalışarak bunu olmaya çalışanlara dikkat edin. Tabi eğer gerçekten yönetici aramıyorsanız. Yazılımcıdan yönetici olmaz, lider olur. Onu bulun. Gelişmek üretmekle mümkün olur. Üretim yapabilecek kabiliyetimiz olduğu müddetçe devam etmemiz gerektiğini düşünüyorum. Süreç böyle insanları doğru zamanda doğru yerlere taşıyacaktır.

Sadece X programlama dilini yazarım onun dışındakilerle ilgilenmiyorum !

Ekibinize yazılımcı olan mühendisler alın. Teknoloji heveslilerini bulun ama sadece birine ya da birkaçına takılmış olanlardan uzak durun. Bunlar dikkafalı insanlar oluyorlar. Sürekli sizinle takılıp kaldıkları teknolojileri veya dilleri kabul ettirmeye çalışacaklardır. İşinizi büyütmek için hangi teknoloji ile yapılması gerekiyor konusu ana işiniz olmamalı. Hatırlatmakta fayda var. Konu startuplarla sınırlı. Kurumsal şirketlerin işe aldığı profillerden bahsetmiyorum.

Aday tarafından soru : Mesai yapıyor musunuz ?

Sorulmasında bir sakınca yok elbette. Ama bu direk doğru kişi olmadığını gösteriyor. Startup iseniz zaman kavramınız olmamalı. Dolayısıyla mesai kavramı da yok. Arkadaş nereye geldiğini bilmiyor muhtemelen.

Hisse / stock option verebileceğiniz kadar güvenebileceğiniz kişileri seçin

Bir elin nesi var iki elin sesi var. Başarmak için yardıma ihtiyacınızın olmadığını mı düşünüyorsunuz yanılıyorsunuz. Mutlaka yardıma ihtiyacınız olacak. Bu isterseniz yazılımcı, isterseniz pazarlamacı, satışçı ya da başka bir profil olsun. 4 ayağınızın üzerinde düşmediyseniz ya da altın kasenin içine doğmadıysanız (Ali Sabancı'nın sevdiğim laflarından birisi) başta paraya sonra da güvenilir insanlara ihtiyacınız olacak. Bu insanların sizi yolculuğunuzda yarı yolda bırakmasını istemiyorsanız onlara güvendiğinizi göstermelisiniz. Bunun karşılığını alacağını ve yaptığınız işin önemli bir parçası olduğunu bilmeli.

Kariyer.net gibi yerlerde aramayın

Birilerine sorun. Güvendiğiniz insanların direkt referansları ile görüşün. "Şöyle biri var mutlaka tanışmalısın" denilen insanlara gidin. Birini bulduğunuz zaman 2.sini de onun yardımıyla bulun. Bu kişiler muhtemelen önceki işlerini de öyle buluyorlar.

Önceden şirket kurmuş ve başaramamış insanları bulun

Cofounder arıyorsanız en iyisi, fail etmiş girişimi olanlar. Onlar başarıya açlar. Onları bulun. Artık onlar nerede yanlış yaptıklarını biliyorlar. Güvenebileceğiniz insanları bulabileceğiniz gibi IT tüccarlarına da denk gelebilirsiniz. Dikkat edin.

IT tüccarlarından uzak durun

Bunlar genelde 10 sene ve üzeri tecrübesi olan kişiler oluyorlar. Onca sene duya duya ezberledikleri terimleri ve yöntemleri konuşma konusunda çok başarılıdırlar. En tehlikeli kitle de bunlardır. Hem paranızı, hem motivasyonunuzu kaybederek şirketten atmak zorunda kalabilirsiniz. Can sıkar.

Az konuşan çok iş yapanı bulun

Bazıları çok konuşur. Eleştirir, hoşnut olmaz, herşeyden şikayet eder. Bunları önceden tanımak ve tespit etmek çok zor. Belki de bunları erkenden elemekte fayda var.

Geek/Nerd insanlar bulun

Gereksiz işlerle uğraşan insanlar bulun. Durduk yere kendi TCP/IP stackini yazan insanlar, biryerlere atak yapmaya çalışanlar, bitcoin kodunu okuyanlar, dünyada 10 kişinin bildiği bir programlama dilini merak edip öğrenenler... bunlar size en uygun insanlar olabilir.

Bu liste daha uzar. Aklıma geldikçe eklerim.

0'dan 1'e IoT Serüvenim

2017 Mart ile başlayan ve 2018 Temmuz ayında sona eren Iven maceramdan bahsetmek istiyorum. Bir buçuk sene içerisinde karşılaştığımız birçok sorun ve sıkıntının yanında heyecan verici ve bol öğrenmeli bir deneyim oldu benim için. Bu yazının ise aldığımız kararlar, hatalarımız ve güzel yaptığımız seyler üzerine geç kalınmış bir derleme olmasını umuyorum.

Bütün hikayeyi tek bir yazıya sığdırmak zor olacak. Bu nedenle bu yazı giriş niteliğinde olacaktır. Yapabildiğim kadarıyla sistematik bir şekilde yazmayı deneyeceğim. Yine de söz vermeyeyim . Serüvenimin taslağını aşağıdaki gibi başlıklara bölümledim. Kolay okunmasını diliyorum.

  • IoT Dünyası ile Tanışmam
  • A'dan Z'ye Geliştirme Süreci
  • Domain Driven Design ile Kültürel Yapılanma (hazırlanıyor...)
  • Bir Startup'ın İşe Alım Kriterleri (hazırlanıyor...)
  • Apache Kafka, Apache Flink ve Lagom'un Muhteşem Uyumu (hazırlanıyor...)
  • Çağın Modası "DevOps" (hazırlanıyor...)

IoT Dünyası ile Tanışmam

Iven'de çalışmaya, büyük ölçekli bir platform geliştirme zorluğunu kabul etmekle başlamaya karar verdim diyebilirim. Genç bir ekibin elindeki mevcut fırsatları zorlayarak geliştirdiği amatör ruhlu IoT platformunun artık ölçeklenebilmesi gerektiği bir zamanda, daha ciddi bir teknoloji alt yapısıyla yeniden yazılması fikri ortaya atılmış. Vizyoner bir karar ama net değil. Turkiyede, IoT alanında gelişme ve ilerleme o kadar da hızlı ve rahat değil (rahatlıktan kastım, kendisini iyi ifade edebilen diyebilirim). Özellikle halen dijital dönüşüm başlığı altında IoT'nin faydaları ve gerekliliği üzerinde hem fikir olamamış sektör liderleri firmalarımızın öncelikle bu girişimleri desteklemeleri ve yatırım yapmaları gerekiyor. Tabi onlar da haklılar, ülke olarak çözülmesi gereken daha onemli sorunlarla uğraşıyoruz (!)

Iven, müşterileri ev eşyaları üreticilerinden, endüstriyel cihaz üreticilerine (medikal cihazlar, otomatlar, fırınlar.. vs), donanım üreticileri partnerlerine kadar geniş bir grubun içinde yer alıyor. Ayrıca IoT, sektörel olarak birden fazla partinin bir arada hareket etmesi gereken bir ekosistem ile beraber anlam kazanıyor.

Image Description

Yukarıdaki resim, bir IoT uygulaması gercekleştirebilmek icin gereken teknoloji katmanlarını gösteriyor.

  • Donanım (bildiğimiz cihazlar)
  • Donanımın icinde, sözüm ona, onu akıllı yapan yazılım (firmware)
  • İletişim protokolü (Wifi, Bluetooth vs)
  • Cihazlardan alınan veriyi karşılayan, saklayan ve anlamlandıran, aynı zamanda cihaz ve son kullanıcı arasındaki iletişimi de saglayan bulut katmanı (cloud platform)
  • Platformun sunduğu servisleri kullanarak belirli bir amaç için geliştirilecek uygulamalar

Bu katmanları ortak olarak ilgilendiren bir başkası ise "Güvenlik" konusu. Güvenlik, hem cihaz tarafli hem de son kullanıcıların iletişiminde olduğu cihaz + uygulamalar tarafında da dikkat edilmesi gereken önemli bir mesele haline gelmiş durumda. Otoriteler 2020 - 2025 yıllarına geldiğimizde dünyada 80 milyar akıllı ve internete bağlı cihaz sayısına ulaşacağımızı öngörürken aynı oranda güvenlik problemlerinin de onemli ve karmaşık hale geldiğini belirtmektedir. Şu site üzerinden en kötü 5 IoT güvenlik zafiyet örneklerine bakabilirsiniz. Iven güvenlik konusunda neler düşündü ve uyguladı bahsetmeye çalışırım.

Yeni bir Platform Gelistirme Fikri

Index.co üzerinden bakacak olursak, Xively, Cumulocity, Arrayent, Nest, Carriots gibi IoT platformlarının Google, Amazon, Software AG gibi firmalar tarafından satın alınması önemli gelişmeler. Gartner'in 2017 de yayınladığı hype cycle grafiğine bakacak olursak, IoT platformları, Gartner'in tanımladığı "Peak of Inflated Expectations" evresinde yer alır. Herkesin o dönem içinde kabul gören en onemli/büyük teknoloji gelişmelerinin yer aldığı bu tepede, Machine learning, Deep Learning, Autonomous Vehicles, Connected home gibi diğer teknoloji gelişmeleri de bulunmaktadır.

Image Description

Bu kadar rakip varken yeni bir platform geliştirmek doğru mu ?

IoT platform pazarı yatay ve dikey olarak ikiye ayrılıyor. Yatay eksende Google, AWS, IBM, Microsoft, Thingworx gibi platform devleri yer alıyor. Hemen hemen her sektör için alt yapı sağlayabilecek şekilde kendilerini konumlandıran bu devler ile yarışabilmek için haklı ve geçerli sebepleriniz olmalı. Önce belli başlı IoT platformları için ortak olan ana bileşenlerden bahsedelim.

Aşağıdaki blok diagram Microsoft Azure IoT platformunun referans mimarisini gösteriyor. Microsoft, alt yapısının açıkça nelerden oluştuğunu anlatan bir döküman oluşturmuş ve bunu halka açık yapmış (dökümana buradan ulaşabilirsiniz).

Image Description

Peki bunu neden yapıyor ? İşletim sistemi pazarında yıllarca liderliğini korumuş ve sektör önderliği konusunda oldukça hırçın olan Microsoft, IoT konusunda da sektöre yön vermek istiyor. Bunu da standardı tam oturmayan IoT sektöründe yapmaya çalışıyor. Bunu sadece Microsoft degil adı duyulmuş, duyulmaya yeni başlamış neredeyse her IoT platform şirketi mimari yapılarını dışarı açarak adeta birbirlerine meydan okuyorlar. Genel olarak bu dökümanlarda, cihazlardan verilerin nasıl alındıklarından, veriyi canlı veya yarı-canlı olarak analiz yöntemlerine, yüksek hacimli verinin nasıl işlenmesi ve saklanması gerektiğinden, bunların yöntem ve prensiplerinin ne ve nasıl olması gerektiğine kadar bizi aydınlatmaya çalışıyorlar. Açıkçası hepsi sonunda su döngüyü uyguluyor :

(Topla) Collect -> (İşle) Process -> (Sakla) Store -> (Analiz et) Analyze

Örneğin AWS IoT bir IoT platformunda olması gereken temel mimari yapıyı sunmaktadır. Bileşenlerini istediğiniz gibi kullanabileceğiniz bir model sunduğu için istediğiniz servisi alıp kullanabilirsiniz. Ancak yine işler sanıldığı kadar kolay olmuyor. Türkiye'deki firmalar yatayda konumlanmış bu tarz platformlardan hizmet almak istediklerinde sert kayaya tosluyorlar. Vestel, Arcelik, Arzum, Beko gibi Turkiye'de ev eşyaları endüstrisinde tanınan markaların karşılaştığı güçlüklerden biri de IoT'leşme süreçlerindeki bu tercihlerinden kaynaklı hesaba katmadıkları öğrenme güçlüğü ve adaptasyon sorunları (learning-curve) ve keşif süreçlerindeki zorluklar oluyor. Zaten firmaların bu tarz "hype" teknoloji ağırlıklı gelişmeleri takip edebilmek adına yaptıkları yatırımlar, "modaya ayak uyduralım, kervanı yolda düzelim ..." anlayışı ile olduğu zaman başarısızlıkla yüzleşiyorlar.

Kısacası IoT çözümleri anahtar teslim olamıyor, olmamalı da. Iven'de bu zorlukları aşabilmek icin bütün süreci 3'e bölerek değerlendirmeye karar vermiştik.

Seviye 0, Müşteriyi Anlamak ve Keşif Süreci

Bu seviyede müşterinin istekleri ve ihtiyaçları analiz ediliyor. Keşif süreci de diyebileceğimiz bu evrede IoT ürünleri üretmek isteyen firmaların doğru yönlendirilmesi sağlanılmalıdır. Hizmet alanı/üretilen ürünün uygunluğu analiz edilir ve maksimum fayda sağlamak için çalışmalar yapılır.

Seviye 1, Teknoloji Entegrasyonu

İhtiyaçları daha gercekçi olan ve amacı olan bir değişim/dönüşüm süreci içine artık teknoloji de dahil olmalı ve bu amaç doğrultusunda transformasyonu destekleyecek her birim bu sürece dahil olmalıdır. Iven, bu evrede yer alan ve teknoloji alt yapısını da saglayan bir pozisyonda bulunuyor.

Yerel pazarda, yatayda konumlanan büyük rakipler gibi IoT platformu satmaya çalışmak pek mantıklı değil. Özellikle startuplar için riskli bir yatırım olabilir. Açıkçası bu seviyelendirme yöntemiyle müşterilere yaklaşmak da bizim gibi bir oyuncuyu daha tercih edilebilir kılıyor. Müşterilerle yakın ve zamana yayarak çalışmak daha verimli sonuçlar doğuracak gibi görünüyor. Müşteriye daha yakın olabilmek ve onların hem süreçsel hem de teknoloji ile alakalı her türlü ihtiyaçlarına, taleplerine geri dönüş yapabilmek için kendine ait bir platform ile bunu yapmak istemesi de çok mantıksız görünmüyor.

Veri toplamak, işlemek, saklamak ve analiz etmekten ibaret olan teknolojiyi yani platformu geliştirmek için harcadığımız 1 bucuk sene içinde nelerle karşılaştık onlardan bahsetmeye başlayabilirim artık. Buraya kadar uzun bir giriş yaptım biliyorum. Ama öncesinde ne sebeple aşağıdaki sıraladığım işlere kalkıştık onu anlatmayı da gerekli gördüm.

Yeni bir IoT platformunun en baştan geliştirilmesi fikrinin ne kadar doğru ya da yanlış olduğuna siz karar verin. Ama önce bu serüvenin mühendislik tarafındaki detaylara inelim.

A'dan Z'ye Geliştirme Süreci
  • Başlama vuruşu
  • Kurallar ve Prensipler
  • Voltranı oluşturmak
  • Teknoloji ve Mimari
  • Geliştirme süreci
  • İletişim
  • DevOps
Nereden başlamalıyız ?

Elbette önce ne yapacağımızı bilmemiz gerekiyor. Bu konuda önemli ölçüde yatırım yaptık. Zamanımızın büyük bir kısmını şirketin gitmek istediği yeri anlamaya ve doğru hamleleri yapmaya çalıştık. Fakat bu konuda biraz fazla zaman kaybettiğimiz konusundaki öz eleştirimizi de esirgemiyoruz. 4 - 5 ay gibi bir süre harcayarak IoT platformunun neye benzemesi gerektiğine karar verdik. Bunu da bir yönteme uyarak yapmak en doğrusuydu. Biz de IBM'in Disciplined Agile Delivery adında bir agile proje yönetim yaklaşımını dikkate alarak yaptık. Oldukça faydasını gördüğümüzü söyleyebilirim. Eğer inceleme fırsatı bulabilirseniz tavsiye ederim. Özellikle büyük ölçekli bir proje geliştirmeye başlayacaksanız DAD kullanabilirsiniz. Ama her boyuttaki projeler için de kullanılabilir diye düşünüyorum.

DAD nedir ? Nasıl İşimize Yaradı ?

Disciplined Agile Delivery (hiç tr'ye çevirme niyetim yok :)), bu linkte DAD'nin tercih edilmesinin 10 sebebi sıralanmış.

Kısaca DAD; yazılım geliştirme sürecinin zorluklarını sadece teknik odaklı bir anlayışla değil de çözüm odaklı bir perspektifle aşmaya çalışıyor. Bildiğimiz agile geliştirme metotlarından birini seçebilecek bir çatı sunarak, bizi herhangi birinin sunduğu reçeteye uymak zorunda bırakmıyor. Bu sayede mevcut koşullara uygun olacak şekilde strateji değişikliğini kabul ediyor ve destekliyor. Bir süreç karar çatısı ortaya koyuyor diyebilirim.

Çoğumuzun yolun başında yapmayı unuttuğumuz veya yapmaya erindiğimiz konuların önemine değiniyor. Konsept belirlenmesi, başlangıç için gerekli hazirlıkların yapılması, geliştirme sürecinde kanban, scrum, scrumban gibi herhangi bir agile yöntemin aparat gibi takıp çıkarılarak uygulanabilmesi konusunda da yöntemler ortaya koyuyor.

Tam bu noktada DAD'nin neden bizim işimize yaradığını anlamak kolaylaşıyor. Büyük ölçekli (large-scale) bir projeye start verdikten sonra ipin ucunu kaçırmak çok kolay. Ortaya çıkan ürünün/platformun/sistemin ana kullanıcılarını tanımlamaktan tutun da, satışı yapılacak bir ürün ise satış ve teslimat (delivery) süreçlerine kadar her konuyu düşünmeniz ve beklediğiniz çıktıları ona göre şekillendirmeniz gerekiyor. Eğer düşünmeniz gereken şeylerin listesini oluşturmak zorlaşıyorsa DAD bu konuda aradığınız şey olabilir.

Bize gereksinimlerimizi toplamaya yardımcı olan ve geliştirme öncesi üzerinde çalışılması gerekenleri derlememizi kolaylaştıran listemizi özetliyorum.

DAD bütün proje sürecini 3 bölüme ayırıyor. İlk etap olan Başlangıç Aşamasında (Inception Phase) bazı hedefleri yerine getirmemiz gerekiyor. Bunlar :

Takımını kur

Bir proje başlangıcında herhalde en zorlu konu takımın kurulması olabilir. Doğru insanları doğru rollerle bir araya getirmeyi, işin yarısını tamamlamak olarak görüyorum. Eğer doğru insanlar bir araya gelemiyorsa istediğiniz kadar uğraşın, modeller çizin, planlar yapıp hedefler koyun. Öyle ya da böyle başarılı olmanız çok kolay değil.

(Bir startupın nasıl elemanlara ihtiyacı olmalı konusunda da bir yazı hazırlıyorum)

Ortak vizyon geliştir

Takımınla iletişim yöntemine karar ver, stratejini oluştur. Çalışma şeklin ve düzeni hakkında kararlar ver ve birliktelik nasıl sağlanacak tartış.

Dökümantasyon ! Herşey (hemen hemen) dökümante edilmeli. Aslında temel iletişim modelimiz dökümantasyon üzerine oldu. Yani konuştuğumuz karar verdiğimiz, yapacağımız herşey dökümanlar üzerinden ilerledi.

Sanırım şimdiye kadar yaptığım en faydalı şey bu oldu. Yani dökümantasyonun önemini aktarabilmek. Ne zaman döküman desem insanlar korkuyorlar. Nedense birine döküman yaz demek ona verilebilecek en ağır iş gibi geliyor. Halbuki dökümanlar da agile olduğu müddetçe bir yazılımcının kendisini yanlış anlaşılmalardan koruyabilmesinin en basit yolu oluyor. Yani geleneksel yöntemlerle hazırlanmış dökümanlar değil, daha çok sistemi genel olarak tanımlayan, belirli bir yöntemle hazırlanmış, çizimlerle desteklenmiş dökümanlar gayet yeterli olacaktır. Bu işi kurum kültürüne entegre edebilmek zor bir konu olsa da, orantılı bir şekilde bunu başabilmiş olmamızdan ötürü karşılığını farklı şekillerde aldığımızı da söylemeliyim (Tübitak hibe programlarından 1501 için çok az efor harcamış olmamız, yeni gelenlerin oryantasyon süreçleri gibi).

Kurumun fikri mülkiyetini (IP : Intellectual Property) yönetebilmesi ve saklayabilmesinin başka bir yolu var mı bilmiyorum. Patentleri, ulusal ve uluslararası proje başvurularının hepsi dökümanlardan oluşuyor. Buna ek olarak şirketin başarısızlık/darboğaz noktalarını (single point of failure) ortadan kaldırması şirketin kendine yapabileceği en iyi yatırım olarak görüyorum. En basit şekliyle, müşteriye yapılacak olan bir sistemin kurulumuyla ilgili detaylar sadece bir kişinin kafasındakilerden ibaret ise ve bu kişi bir şekilde ortalarda yoksa başarısız oldunuz. Bu konuyla ilgili güzel bir yazı (truck factor) var okumanızı tavsiye ederim.

Kurumun stratejisi ile paralel hareket et

Şirketin mevcut koşulları değerlendirilmelidir. Pazardaki stratejisine uygun hareket etmeli ve finansal durumlardan haberdar olunması gerekmektedir.

Iven'ki yanlışlarımızdan birisi de kurum stratejisini iyi tanımlayamamaktan kaynaklandı. IoT pazarındaki yeri önce platform üreticileri ile aynı seviyede iken sonrasında bunun çok ciddi yatırım gerektirdiği ortaya çıktı. Halbuki bunu en baştan hesaba katmalıydık. İlk başlarda belirttiğim gibi "yataydaki platformlar" ile rekabete girmek Türkiye içerisinde çok da mantıksız görünmese de, bunun için şirketin kaynaklarının yeterli olup olmadığının iyi analiz edilmesi gerekiyordu. Bir süre sonra Iven stratejisini değiştirerek, odağını ev aletleri (home appliances), elektronik eşyalar, HVAC (heater, vantilator, air conditioners), aydınlatma, wellness pazarlarında internete bağlı ürün (connected products) geliştirme üzerine vermiş oldu. Bu önemli ve doğru bir adımdı. Daha belirgin ve net bir pazara hitap ediyor olmak, dışarıya platform şirketi görünümünden çok işini iyi bilen, IoT ve dijitalleşme süreçlerinde müşterilerinin yanında yer alma sözü veren ve her iki seviyede de (seviye 0 ve 1) destek veren, kendi yerli teknoloji alt yapısını kullanan bir şirket profili çizmek istemesi çok mantıklıydı.

Mimari ve teknoloji alt yapısı konusunda verilecek kararlar tamamen buradaki tetkiklere bağlı olarak değişmelidir. Herşeye en baştan başlamak çok da akıllıca olmasa da, geldiğimiz noktada başarı veya başarısızlığın teknoloji veya mimari yöntemlerin seçimine bağlı olmadığını da görüyor olduk. Ayrıntıları yazılarımın devamında keşfetmenizi isterim.

Kapsamı keşfet

Kapsam keşfi ile ne yapacağımızı en kaba düzeyde netleştirmemiz gerekiyor. Kapsam belirlemek için çok çeşitli yöntemler tercih edilebiliyor. Yöntemler, projenin tipine (müşteri talebine göre, şirketin kendi ürünü vb.) ve koşulların uygunluğuna göre belirlenebilir. Kapsam detayına ne kadar inilmesi gerekiyorsa bu da proje tipine göre değişecektir. Bu sürede,

  • Kullanım senaryolarının ne kadar detaylı analiz edilmesi gerekiyor ?
  • İş süreçlerinin tanımlanması (business processes) gerekiyor mu ? Gerekiyorsa ne kadar detayda tanımlanması gerekiyor ?
  • Sistemin/Ürünün kullanıcıları var mı ? varsa personaların tanımlanması gerekiyor mu ?
  • UI (user interface) ihtiyacı var mı ? Mockup, wireframe gibi çizimler gerekiyor mu ?
  • Fonksiyonel olmayan durumlar için kabul kriterlerinin belirlenmesi gerekiyor mu ?
  • Geliştirme süreci için görevlerin oluşturulma stratejisi ne olmalı ? (Scrum, Kanban) Makul yönteme karar verilmeli. İş takibi için nasıl bir yöntem izlenecek ?

Yukarıdaki soruların cevaplarını bulmaya çalıştık. Makul düzeyde de dökümante ettik. En başta Trello üzerinde bu gibi işlerin takibini yapmaya başlamıştık. Sonrasinda JIRA ve Confluence'u birlikte kullanmaya başladık.

Platformun kullanıcılarının persona analizlerini farklı profillerdeki kullanıcı adayları ile görüşmeler yaparak çıkarmaya çalıştık, genel temaların belirlenmesi ve ihtiyaçların ortaya çıkmasıyla süreçlerin çıktılarını Confluence üzerinde kayıt altına aldık. Ayrıca rakip firmaların analizlerini de yine Confluence'a ekledik. (Tavsiye : şirketinizin döküman alanına güzel bir isim bulun. Bizimki IVENPEDIA'ydı )

Mimari ve teknik stratejini belirle

Bu aşamada projenin sıfırdan mı tasarlanacağı veya referans bir mimari üzerinde mi çalışılacağı ya da satın alınan ticari bir ürün mü kullanılacağı konuları tartışılıyor. Bizim yaptığımız ise referans mimarileri sentezleyip onun üzerine bir yapı geliştirmek oldu. Aslında neredeyse herşeyi en baştan yapmayı planlamıştık. Örnek alabileceğimiz oldukça başarılı referans mimariler vardı. Diğer bir konu ise teknoloji seçimimizin ne olması gerektiğiydi. Bir CTO'nun sanırım en kritik görevlerinden birisi de teknoloji seçimleridir. Bu noktadaki seçimler şirketi çok büyük zararlara götürebileceği gibi hem ekibi hem de şirketi çok güzel noktalara da taşıyabilir.

Uzun yıllar JVM ekosisteminde dolaşan biri olarak elimde çok da fazla seçenek olduğunu söyleyemezdim. Koşullar teknoloji seçimlerini de etkiliyor. Öncelikle geliştirme yükü fazla olacak bir proje için programlama dili konusunda dikkatli olmak gerekiyor. Ekibin seçilecek dil(ler) veya araç(lar) konusundaki bilgisi, yatkınlığı ve eğitimleri çok önemli bir konu. Ayrıca ilk etapta 10 binlerce cihazın bağlı olacağı ve çok hızlı şekilde yükün artacağını planlayarak işe başlıyorsanız en iyi kozunuzu kullanmak istemeniz çok doğal olacaktır (tabi ki Java).

4 - 5 aylık başlangıç süresi içinde mimari yapının neye benzemesi ve alt yapımızda ne gibi yöntemler ve teknolojiler kullanmamız gerektiğine karar vermeye çalıştık. Aslında işin en güzel kısımları burada başlıyor. Normalde DAD bu kararları hızlıca verdikten sonra "prove architecture early", yani mimari yapını erkenden ispatla der. Bunu da geliştirme aşamasına geldiğimizde yapabiliriz. Fakat o kadar çok prensip ve yöntem üzerinde hemfikir olduk ki (gerekli olduğuna inandık diyelim) hızlıca PoC (proof of concept) yapabileceğimiz kadar küçük bir yapıyı kurmak bile çok zamanımızı aldı. Peki neydi bu üzerinde hem fikir olduğumuz prensipler ve yöntemler ?

  • Domain Driven Design uygulamak
  • Event Sourcing ve CQRS
  • Event driven, message passing ve actor based programlama (Akka.io)
  • Kappa mimarisi
  • Real time stream processing (teknoloji : Apache Flink)
  • Microservice mimarisi (teknoloji : Lagom Framework)
  • Cihazlardan veri toplamak için MQTT broker (teknoloji : eMqtt)
  • Polyglot persistence (Cassandra, MySQL, Redis, Elasticsearch)
  • Streaming -> Apache Kafka
  • Kubernetes, AWS
  • UI ReactJs
  • Continuous Integration ve Delivery (Jenkins)
  • Unit ve Integration testler
  • Trunk based geliştirme (Bitbucket ve Jira)
  • Code review ve Pull request zorunluluğu

Evet ! tam olarak yukarıdakilerin hepsi bizim kurguladığımız sistemin ana çatısını oluşturuyor. Daha belirtmediklerim bile olabilir. İlk bakışta korkutucu görünüyor ama içine girdiğimiz işi en baştan tasarlayıp kendimiz geliştireceksek bunlara ihtiyacımız var. Bu konuda eleştiriler aldığım da oldu ama önceden de dediğim gibi Iven'in tam olarak sahip olmak istediği buydu. (o zamanlar öyleydi ). Bunları nasıl uyguladığımızı ve platformu hayata geçirirken nelerle karşılaştığımızı daha sonraki yazılarda anlatmayı planlıyorum.

Book Review : Pür-Dikkat, Cal Newport

Sürekli olarak yaşadığımız bir sorundan bahsetmek istiyorum. Sadece benim değil, tanıdığım neredeyse herkesin muzdarip olduğu bir sorun; Odaklanamamak. Bence çağımızın sorunlarından bir tanesi olabilir kendisi. Klişe olacak ama ben yine de belirtmek istiyorum. İnternet ve sosyal medya uygulamaları için harcadığımız zamanı kontrol edemiyor, emaillerimize ne kadar oranda zaman harcamamız gerektiğini bilmiyoruz. Bu durumda suçlu internet mi oluyor peki ? Olmamalı ! Bu odaklanamama sorununu ve çözümünü anlamak için vakit harcayan ve faydalı bir kitap yazan Cal Newport kitabına şöyle başlıyor:

Odaklanma becerisini nasıl yitirdik, nasıl geri kazanabiliriz ?

Image Description

Geçenlerde karşıma çıkan ve ingilizcesi Deep Work olan bu kitabın Türkçe'sini okuma fırsatım oldu. Kitabın altını çizerek okudum.

Bu yazıdaki motivasyonum, benim de bir türlü çözemediğim pür-dikkat çalışamama, odaklanamama sorunu için yazarın ortaya koyduğu önerileri ve yöntemleri özetlemek ve hoşuma giden noktaları derlemek. Yazının devamında ise kitaptan alıntılarla beraber kendi yorumlarımı da katacağım. Umarım bunları benim gibi uygulamak isteyip de uygulayamayanlara faydası olur, farkındalığı arttırır. İyi okumalar.

Her ne yapıyorsak yapalım odaklanarak yapabiliyorsak hayatımız olduğundan daha anlamlı hale geliyor. Bunun felsefi ya da bilimsel bir açıklaması yok. Hayat düşündüğümüzden çok kısa ve yapmak istediğimiz çok şey var. Bu her zaman, yüzeysel işlere daha az zaman harcayarak hayatımızı daha anlamlı hale getirebileceğimiz anlamına gelmiyor. Beklentilerimize cevap verebilmek, mutlu olduğumuz konulara ve işlere yönelebilmek ve hayatı bizim için anlamlı kılabilecek şeylere zaman harcayabilmek bir noktadan sonra en çok zaman harcadığımız konular haline geliyor. Benim gibi zihin emekçileri için olduğu kadar zanaatkarlar için de derinleşerek yaşanan hayat yalnızca maddi açıdan kazanç değil beraberinde dolu dolu yaşanabilecek bir hayatı da beraberinde getirebilir.

Newport, "beynimiz dünyaya bakış açımızı inşa ederken neye odaklandığımızdan yola çıkıyor ve kim olduğunuz, ne düşündüğünüz, ne hissettiğiniz, ne yaptığınız, neyi sevdiğiniz, odaklandığınız şeylerin toplamıdır" diyor.

Eğer bir akademisyenseniz ve yüzeysel işlerle uğraşıyorsanız muhtemelen mutsuzsunuz. Çünkü akademisyenliği tercih eden kişi hayatının büyük bir bölümünü belki de sadece bir konu üzerinde düşünerek geçirebilecek riski almıştır.


Bazen yapmamız gereken o kadar işimiz varken olmadık yerlerde motivasyonumuzu kaybederiz. Neyi neden yaptığımızı ve hayatımızın amacını sorgulamaya başlarız. Amaçsız olduğumuzu düşünürüz. İşte bunu farkettiğimiz anda herşeyi bırakıp bir değerlendirme yapmamız için kendimize bir şans vermeliyiz.

Odaklanabilmek o kadar basit bir konu değil. Varoluşsal temelli sorularımızla da çok ilişkili olduğunu düşünüyorum. Bu hayatta en çok yapmak/olmak istediğiniz şey nedir ? Çok iyi bir basketbolcu olmak istiyorsanız her gün saatlerce çalışmak zorundasınız. Dünyaca ünlü bir piyanist ya da bir yazar olabilmek için en kralından yetenekli olmak ve odaklanabilmeniz gerekmektedir.

Kitabı tavsiye ederim.

Nesnelerin İnterneti (IoT) - Nereden Başlamalıyım ?

IoT sıkça duyduğumuz bir kavram. Blog'umu İngilizce yazmaya çalışırken IoT ile ilgili Türkçe bir yazı yazma ihtiyacı duydum. Her konuyu İngilizce araştırıp, çözmeye çalıştığımız için kavramlara da İngilizce aşina oluyoruz maalesef. Bu durumda nasıl Blockchain'i Türkçe'ye çeviremiyorsak IoT'yi de (Internet of Things kısaltması) çevirmeyelim ve onu öyle kabul edelim.

Bu yazıyla aktarmayı düşündüklerim şunlar olacak;

  • Kısaca IoT nedir ?
  • Bir IoT projesi geliştirmek için temelde bilmemiz gereken adımlar nelerdir ?

Nedir IoT ? Yeni bir teknoloji mi ? Bir araç mı ?

Hayır değil.

ref: http://intersog.com/blog/internet-of-things-the-future-of-your-tomorrow/

IoT yani Nesnelerin İnterneti, içinde bulunduğumuz çağı en iyi şekilde anlatan ve geçmişten bugüne kullanılan teknolojilerle beraber değişen yöntemleri, geliştirilen yaklaşımları bir arada barındıran bir gereksinim. Tavuk-yumurta çelişkisine düşmeyelim. Yani IoT olsun istedik de ona göre mi yöntemleri ve teknolojiyi geliştirdik. Bence öyle olmadı. Nikola Tesla elektrikle oynarken sanayi devrimi (2. sanayi devrimi, endüstride petrol ve elektriğin kullanımıyla mümkün olmuş.) yapmak için uğraştığını düşünmüyorum. Açıkçası teknoloji adına atılan her adımın neyi doğuracağını bilmek çok da kolay değil. Bugün Blockchain'in neleri değiştirebileceğini anlamaya çalışıyoruz. 90'lı yılların ortalarında Internet ile beraber popülerliğini gösteren WWW ile de ne yapılabilir diye düşünürken erken ve doğru hareket edenler tarafından yaratılan sosyal uygulamalar (Facebook vb.), e-ticaret siteleri (Amazon, Alibaba vb) bugün halen popülerliğini korusa da yeni bir paradigmaya da elbette hayır demeyiz. Bu konuyu sonra tartışırız.

... Zamanla Nesnelerin İnterneti de kendi başına kutsallığını ilan edecektir.

Nesnelerin İnterneti'ni yapılandırmaya çalışıyoruz çünkü bizi daha sağlıklı mutlu ve güçlü yapmasını umuyoruz. Nesnelerin İnterneti sorunsuz işlemeye başladığında mühendisten çipe çipten veriye indirgenerek, gürleyerek akan bir nehirdeki toprak parçası misali, veri selinde eriyip gidebiliriz.

Yuval Noah Harari - Veri Dini, Homo Deus

Teknik detay vermeden size IoT'nin temel bileşenlerini, varlık göstediği eksenleri aktarmaya çalışacağım. Belki yapı taşlarını ve bir IoT sistemi/platformu için gerekli adımları ve teknolojileri anlattığım başka bir yazı daha yayınlayabilirim. Bu yazıda daha çok sektörel boyutta IoT nasıl varlık gösteriyor mevcut trendlerle birlikte anlatmak istiyorum.

Yatayda ve Dikeyde IoT

Nesnelerin İnterneti iki temel eksende varlığını gösteriyor. İlki Amazon, Google, Thingworx, IBM gibi hemen hemen her sektör için alt yapı sağlayabilen platformların olduğu bir eksen (yatay eksen) var. Burada IoT alt yapı sağlayıcıları herhangi bir sektör için çözüm üretilebilecek gerekli materyalleri ve ortamı sağlamaya çalışmaktadırlar. Ulaşım, tarım, şehircilik/belediyecilik, lojistik, sağlık, elektronik ev aletleri (ve daha fazlası) gibi sektörlerin herbirindeki üreticiler ve hizmet sağlayıcılar kendi ürün ve süreçlerini iyileştirmek ve son kullanıcıları ile iletişim yöntemlerine teknolojik yenilikler/iyileştirmeler getirebilmek adına bu platformları veya daha özelleşmiş olanlarını tercih ediyorlar.

Bu bahsettiğim sektörler için platform sağlayıcıların sunduğu alt yapılar ile herşeyi yapabiliriz. Cihazlarının internete bağlanması, veriyi akıtabilmek ve toplayabilmek, veri üzerinde istatistiksel analiz geliştirebilmek ve uygulamalar geliştirebilmek - özelleşmiş ve sektöre uygun çözümler geliştirmek bu platformlar ile mümkün. Unutmadan bu kadar çabanın nedeni veri. Veri herşeyin ortasında duruyor ve amaç bir yerlerde duran bu verilere ulaşabilmek. Sonrasında işler kolaylaşıyor. Tabi günümüz koşullarında. Eskiden de veri üretiyorduk ama bugünkü kadar değil. Yapılan araştırmalara göre internet üzerinde üretilen verinin 2.5 exabytes olduğu hesaplanmış (2016 istatistiğine göre).

Gartner'ın raporuna göre ise bu senenin (2017) sonuna doğru 8.4 milyar cihaz internete bağlanacak ve veri üretecek. 2020 de ise bu sayı 20 milyarlara çıkacak. Küreselde üretilecek veri miktarını tahmin etmek bile yorucu. Dolayısıyla ortaya çıkan bu muazzam veriyi kullanabilecek sistemlere ihtiyacımız var ve olacak. Bu veriler ne işe yarar ve ne yapabiliriz diye düşünüyorsanız söyleyebilirim. Herşey !

Pekala bir şekilde fikre aşina olduğumuzu varsayalım. Bizim veriyi toplamamız gerekiyor. Bunu nasıl yapabiliriz diye soru sorup cevabını arayalım o zaman. IoT kapsamında bir proje/çözüm üretmek istiyorsam bir platforma ihtiyacım var. Eğer platform üretebilecek yetkinliğim yoksa bu platformu sunan platform sağlayıcılardan satın alabilirim. Bu platformun üzerinde bir uygulama geliştirip ürünlerimi veya süreçlerimi internete bağlı ve akıllı hale getirmek istiyorsam içinde bulunduğum sektöre uygun özelleştirmeleri barındıran bir uygulamayı bu platformun üzerine geliştirebilirim ya da bunu zaten yapmış olan bir uygulama sağlayıcıdan satın alabilirim.

IoT platform/sistem/uygulama sağlayıcıları perspektifinden 2'ye ayrılabilir.

  • Yatayda platform sağlayıcılar (sektörel derinliği olmayanlar)
  • Dikeyde platform/uygulama geliştiriciler (sektörü tanıyanlar ve özelleşmiş taleplere cevap verebilecek olanlar)
İnternete Bağlı Nesneler (Connected Products) ve Operasyonlar (Connected Operations)

IoT kendi içerisinde bir sınıflandırmaya tabi tutulursa birden fazla eksende sınıflandırma yapmak mümkün.

  • Tüketici IoT'si
  • Ticari IoT
  • Endüstriyel IoT

Yukarıdaki maddeler IoT'nin etki ve fayda alanı ile ilgili bir sınıflandırma olabilir. Eğer IoT'yi aşamalı bir süreç olarak ele alırsak hem kullanılan yöntemler hem de teknolojide farklılaşmalar gösterebilir. Ama temelde aşağıdaki aşamaların bütün eksenlerde ve sınıflandırmalarda ortak olması kaçınılmazdır.

  • Veri oluşturabilen cihazlar (IoT devices/hardwares) - Ürünün kendisiyle veya ortamıyla ilgili veri oluşturabilmesi.
  • Cihaz bağlanılabilirliği (Connectivity) - Bu cihazların/sensorlerin internete bağlanabilirliğinin sağlanması
  • Verinin anlık toplaması (Data Capturing) - Oluşturduğu verinin daha anlamlı hale gelebilmesi için bulunduğu yerden istenilen bir platforma akıtılması.
  • Veri işleme (Data Processing) - Akan verinin isteğe göre anlık olarak işlenmesi ve verinin değerlerine göre çeşitli ölçümler yapılması.
  • Veri saklama (Data Storing) - Veri üzerinde analitik çıkarımlar yapabilmek için saklanması
  • Veri analitiği (Data Analytics) - Yapay zeka uygulamaları, büyük veri analizi, ileriye yönelik tahminler gibi yöntemler
  • Uygulamalar (Human value) - Veri üzerinde anlık yapılan işlemler ve analitik işlemlerle beraber insanların/son kullanıcıların sahip oldukları ürünlerle direkt olarak iletişime geçebilmesi.
  • Uygulamalar (Operational value) - Veri üzerindeki anlık işlemler ve analitik ile operasyonların iyileştirilmesi ve üreticilerin endüstriyel faaliyetlerini takip edebileceği uygulamaların geliştirilmesi.
IoT uygulamari neden basarisiz oluyor ?

Başarısızlığın bir çok sebebi var. Genelde IoT ile ilgili başarısızlıklar doğru bir yol haritası ortaya koyamamak ve doğru insanlardan oluşan bir takım kuramamak ile başlıyor. Exosite, IoT projesi geliştirmeyi süreçsel olarak bir çatıya oturtmaya çalışarak başarılı bir IoT projesi geliştirebilmek için gerekli olan doğru adımları anlatan güzel bir whitepaper yayınlamış. Başarıya giden yoldaki önemli adımları şöyle sıralıyor.

  • Explore (Keşfet)
  • Validate (Doğrula)
  • Accelerate (Hız kazandır)
  • Commercialize (Ticarileştir)

İşletmelerin önce IoT uygulamaları ile ürünlerine ve/veya süreçlerine ne gibi katkıları ve faydaları olabileceğini anlamaları gerekmektedir. Eğer müşteri memnuniyetini arttırmak istiyorlarsa ve ürünlerine katma değer sağlamak istiyorlarsa bunu direk son kullanıcının faydalanacağı şekilde konumlandırabileceği gibi süreçlerini iyileştirerek de bunu sağlayabilir.

Bundan sonra uygulanacak adım düşünülen çözümlerin fikirlerin kanıtlanması (proof of concept) evresi olmalıdır. Düşük maliyetlerle hızlı sonuç alınabilecek ufak çaplı geliştirmeler yapılabilir. Bunu geleneksel yazılım geliştirme yöntemleri yerine agile(çevik) geliştirme yöntemlerini tercih etmemizle aynı sebeplere benzetebiliriz. Zararın neresinden dönersek kardır !

Müşterinin satın almasından sonra üretici firmanın müdahalesinin mümkün olmadığı bir süreç başlıyorsa burada risk çok fazla. Connected product dediğimiz internete bağlı cihazlar için ticarileşme sürecinden önce testlerin çok iyi yapılması gerekmektedir.

IoT projesi geliştirebilmek ve başarıya ulaşmak hem teknolojik gelişmeleri hem de işletmelerin uzmanlık alanlarını iyi anlamakla mümkün. Günümüzün şartlarıyla beraber gelen bazı avantajlara sahibiz. Gelişen teknoloji ve yöntemler bizi eskiden aklımızda olmayan yenilikleri düşünmeye zorluyor. Gelişim ve değişim ivmesi çok daha fazla ve bu esneklik çok çabuk dezavantaja dönüşebilir.

Domain-centric Architectures are Cool, but Why ?

Finding the best architecture suited for your culture

I always believe that an organisational culture reflects production culture. I have been working in startup companies throughout my professional career -including my company- since i graduated from the university. And every time, i had a chance to create a team and development culture from the scratch. People who had been experienced in working at a startup company can understand me well. Anyway, you would like to create a team with full of rock stars... Limited funding... you think you had at most two changes to release your product and of course you barely know how to sell it...

There are lots of practices to start a new product. It's absolutely reasonable that you should make a prototype first and proof your idea, then get funding, increase your resources and design + implement your glowing and bubbling product again. Because millions of millions of users are holding their breathes and waiting for your product (am i right ?). So now, you should decide or you have to hire some one to decide the next step.

In the next step, you probably would like to use your wealth to get wealthier than now. Hence, reaching your users at high scale is not as easy as you did before. Spending some money for re-organisation... paying more salaries to hire qualified engineers etc. Right here, right now, if your are a technology oriented company and spending your money for your technology infrastructure and have complex domains. Someone would say that "if we want to redesign our software infrastructure, maintainability, flexibility and scalability should be our key concerns to think about...". And the reasoning should come in; "if we need to construct a well communication flow and integration between all parts of our complex domains, we should also come up with a solution to this with the new architecture."

In this post i would like to help those who are in the next step by trying to explain next generation architecture approaches developed by software gurus.

According to Conway's law, "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." As it is clearly stated that there is a strong relationship between organizational structures and software, even codebase structures and conventions.

The law is based on the reasoning that in order for a software module to function, multiple authors must communicate frequently with each other. Therefore, the software interface structure of a system will reflect the social boundaries of the organization(s) that produced it, across which communication is more difficult. Conway's law was intended as a valid sociological observation, although sometimes it's taken in a humorous context. (Source : Wikipedia)

Building up a team according to their functionalities or domain knowledge is a strategical decision. There will be another post to discuss functional organisation of a software development team.
Database-centric architecture, Source : pluralsight
The visualisation above shows the relationship between a software architecture layers and functional teams in a traditional organisation.

I have to admit this post includes quotations from Clean Architecture course in Pluralsight which i reviewed in my another post. here.

Traditional Database-centric Architecture

In the database-centric architectures, database is in the center of the organisation. In this approach, UI, business logic and data access depend on the database. It is the essential part of the system naturally. Everything goes around the database. It's worth denoting that i'm not aiming at campaigning to discredit this approach, but there are some facts we cannot ignore.

Database-centric architecture, Source : pluralsight

Disadvantages of Database-centric Approach
  • It was just designed to serve single type of presentation layered applications. I mean before smart phones comes into play.
  • It is not flexible and agile. You cannot move the essential parts because the parts which you want to change are stick to the layer up or down.
  • All dependencies are towards the database.

Domain-centric Architectures

In domain-centric architectures the domain and use cases are essential, presentation and databases are just a detail.

Domain-centric architecture, Source : pluralsight

All dependencies point towards the domain. There are three well known domain-centric architectures. One of them is "hexagonal architecture" from Alistair Cockburn, It is layered architecture model that application is at the center of the system. It is a plugin architecture which includes ports and adapters.

Next with the onion architecture, Jeffrey Palermo. This is also a layered architecture with the domain at the center surrounded by the application layer. The outer layers consist of a thin UI as a presentation layer and an infrastructure layer which includes persistence layer. In addition all dependencies point towards the center of the architecture. There is no inner layer knows about any outer layer

In this architecture, we can test application without UI and database dependencies.

Database-centric architecture, Source : pluralsight

Finally author mentions about Clean Architecture from Uncle Bob here.

In this architecture, entities are at the center surrounded by the application that is the use cases. The outer layer consists of ports and adapters adapting the application core to the external dependencies via controllers and gateways and presenters. The little illustration at the bottom right of the image below is Ivan Jacobson's BCE architecture pattern to explain how the presentation layer and application layer should be wired up.

These three architectures are focusing to come up with the same solution. The fundamental issues in traditional architectures like tight coupling, separation of concerns are all addressed by them pragmatically. As you've already known that traditional MVC like architecture is one of the most used and accepted approach in industrial applications. But things are changing and visionaries are aware that designing softwares that UI - business logic and business logic - persistence layer are tightly coupled is not a good way of designing software, because of maintainability and flexibility issues.

Technology is always changing because of the real world needs so, successful change management becomes increasingly important subject for businesses. For instance, What happens in the case of replacing your data access system from relational database to any NoSQL data storing system or adding another NoSQL ? What if you want to change your caching storage system from one to another ? Long story short, this shouldn't be a pain in the ass on your every attempt for a change.