Build, Buy ya da Con­fi­gure — özel yazılım ne zaman kârlıdır

Bir dokümana başlamanın alışılmadık bir yolu bu: Bir yazılım şirketinin bazen verebileceği en iyi tavsiye, yazılım geliştirtmemektir. Bu kulağa kendi çıkarına aykırı gelir ve tam da bu yüzden inandırıcıdır. Çünkü en pahalı projeler başarısız olanlar değil, hiç başlamaması gerekenlerdir — hazır bir ürünün daha iyi ve daha ucuza çözeceği bir sorun için geliştirilmiş özel yazılımlar.

Bu doküman, tüm teknik sorulardan önce gelen soruyu ele alıyor: geliştirmek, satın almak ya da yapılandırmak. Cevap “satın al” olduğunda da dürüsttür, çünkü bir tavsiye ancak, konu gerektirdiğinde kendi işine aykırı tavsiyede bulunma iradesi kadar değerlidir. Hiçbir ürün ve hiçbir rakam vermiyor; kararın dürüstçe verilebileceği ölçütü tarif ediyor.

1. Asıl soru

Soru “yazılım geliştirmeli miyiz?” değil, “bu sorun kendi yazılımını haklı çıkarıyor mu — yoksa bir başkası onu daha iyi mi çözüyor?” sorusudur. Neredeyse her operasyonel sorun daha önce bir kez çözülmüştür; çoğu zaman pek çok kişi tarafından, çoğu zaman da hazır bir ürün biçiminde. Kendi sorununuzun kendi yazılımını gerektirecek kadar özel olma olasılığı, şirket içinden hissedildiğinden daha düşüktür.

Bu yüzden başlangıçta tasarım değil, inceleme vardır: Bu zaten var mı? Varsa, kendi geliştirdiğimiz neden mevcut olandan daha iyi olsun? Bu soruyu atlayan, bilinçli olarak geliştirmeyi seçmiş olmaz; yalnızca ondan vazgeçme fırsatını kaçırmış olur. İlk mühendislik başarısı bazen geliştirmemektir.

Avantajlar ve sınırlamalar. Özel geliştirme yerine hazır ürün önermek, bizim için daha az geliştirme işi anlamına gelebilir. Seçimi projenin ihtiyaçları ve toplam maliyeti belirlemelidir.

Maliyet. Dürüst inceleme, projeden önce zaman ve bir girişimi daha başlamadan küçültme ya da iptal etme iradesi gerektirir.

Ne zaman farklı karar veririz. Hiçbir hazır ürünün soruna açıkça değmediği yerde — yalnızca bu şirkette var olan bir süreç gibi — uzun inceleme gereksizdir ve hızla geliştirmeye geçilir.

Peki neden bu kadar çok kişi bu soruyu atlıyor? Çünkü geliştirmek insanın kendi duygularını okşar. “Kimse işimizi bizim kadar anlamıyor” doğru hissettirir ve tam kontrol isteği anlaşılırdır. Ancak ikisi de kolayca kendi sorununuzu olduğundan daha özel sanmaya — ve sıradan olanı, benzersiz olduğuna inanarak pahalıya kendiniz geliştirmeye — yol açar. Soğukkanlı inceleme bu yüzden aynı zamanda kendi kurumsal körlüğünüzün de sınavıdır: Bu süreç gerçekten bizim farkımız mı — yoksa yaygın bir şeyi yapmanın yalnızca alışık olduğumuz yolu mu?

2. Build, Buy ve Configure ne anlama gelir

Üç yol keskin kategoriler değil, bir yelpaze üzerindeki noktalardır. Bir uçta Buy durur: olduğu gibi kullanılan hazır bir ürün. Ortada Configure durur: geliştirmeden kendi ihtiyaçlarınıza uyarladığınız bir platform — onun sınırları içinde çalışırsınız. Diğer uçta Build durur: tam olarak kendi sorununuza göre biçilmiş kendi yazılımınız. Noktalar arasında karma biçimler vardır; gerçek sistemlerin çoğu bir kombinasyondur.

Şema: Soldan sağa doğru çözüm üzerindeki kontrol artar — ve onunla birlikte emek ve sorumluluk. Hiçbir konum üstün değildir; her biri farklı bir soruna uyar.

Bu ayrımın amacı, kararı geliştirmeye evet/hayır olarak değil, bir yelpaze üzerinde bir seçim olarak görmektir. Çoğu zaman doğru cevap bir karışımdır: ortak olanı satın almak, özel olanı geliştirmek. Yelpazeyi bilen tek bir çözüm değil, doğru dağılımı arar.

Avantajlar ve sınırlamalar. Özel geliştirme, daha fazla kontrol ve uyum sağlar; ancak geliştirme ve uzun vadeli bakım sorumluluğunu artırır. Hazır ürün ise daha az iş gerektirir, fakat süreçlerin ürünün sınırlarına uymasını gerektirebilir.

Maliyet. Her konumun, seçim yapmadan önce bilinmesi gereken kendine özgü bir maliyet yapısı vardır (bkz. bölüm 6); yanlış seçim hemen değil, yıllar içinde fark edilir.

Ne zaman farklı karar veririz. Tek bir ürünün tüm sorunu düzgünce kapsadığı yerde karışım değmez; o ürün satın alınır ve birden fazla yapı taşının karmaşıklığından kaçınılır.

3. Buy ne zaman doğrudur

Satın almak, sorun yaygın ve çözülmüş olduğunda doğru seçimdir — pek çok şirket aynı şeye ihtiyaç duyduğunda ve bunun için bir pazar olduğunda. Muhasebe, e-posta kutuları, takvimler, işletmenin olağan yapı taşları: Burada hazır bir ürünün, makul sürede kendi başınıza geliştirebileceğiniz her şeyden daha olgun, daha ucuz ve daha güvenilir olma olasılığı yüksektir. Sağlayıcı geliştirme maliyetlerini çok sayıda müşteriye dağıtır; siz ise onları tek başınıza taşırdınız.

Belirleyici nokta şudur: Yaygın bir sorun için satın alınan bir ürün yalnızca edinimde daha ucuz değildir, bakımın kalıcı yükünü de üstünüzden alır. Yalnızca işlevi değil, işlevin geleceğini de satın alırsınız — hata düzeltmelerini, geliştirmeyi, zaten gelecek olan yeni gereksinimlere uyarlamayı. Kendi şirketinizi başkalarından ayırmayan her şey için bu daha akıllıca yoldur.

Buna hiçbir faturada yer almayan bir bedel eklenir: kaybettiğiniz dikkat. Bir ekibin sıradan olanı yeniden üretmeye harcadığı her saat, şirketi gerçekten farklı kılan yerden eksilir. Mühendislik gücü bir girişimin sahip olduğu en kıt kaynaktır ve bölünemez — başkalarının zaten çözdüğü çözülebilir olana akan, yalnızca sizin çözebileceğiniz kendinize ait olana akmaz. Yaygın olanı satın almanın en güçlü nedeni bu yüzden düşük fiyat değil, kendi gücünüzü asıl önemli olana saklamanızdır.

Avantajlar ve sınırlamalar. Hazır ürün, olgun işlevlerden daha düşük geliştirme yüküyle yararlanmayı sağlar. Karşılığında ürünün veri modeline, süreçlerine ve sınırlarına uyum gerekir.

Maliyet. Satın alınan bir ürün bir bağımlılık getirir: süregelen ücretler, bir sağlayıcıya bağlılık, onun soruna dair tasavvurunun sınırları (bkz. bölüm 6).

Ne zaman farklı karar veririz. Yaygın ürün kendi sorununuza yalnızca yaklaşık olarak denk geliyorsa ve boşluk işin özündeyse, satın almak artık yetmez — o zaman geliştirmenin kârlı olduğu alan başlar.

4. Configure ne zaman doğrudur

Yapılandırmak, bir platform kendi ihtiyacınıza uyarlamanın geliştirmekten daha ucuz olacağı kadar yakın olduğunda — ve onun sınırlarıyla yaşamaya hazır olduğunuzda — doğru seçimdir. Pek çok platform tam da bunun için yapılmıştır: kendi geliştirmenize gerek kalmadan kendi süreçlerinize uyarladığınız sağlam bir iskelet. Yolun büyük bir kısmı size hediye edilir ve yalnızca geri kalanını biçimlendirirsiniz.

Yapılandırma sanatı, sınırlara dürüstçe bakmakta yatar. Bir platform, onu yapanların varsayımlarını içinde taşır; onu bükebilirsiniz, ama istediğiniz kadar değil. Kendi süreçleriniz bu varsayımların içinde kaldığı sürece yapılandırma iyi bir takastır. Platformu doğasına aykırı zorlamaya başladığınız anda — onun amaçlanmadığı bir şeyi elde etmek için uyarlama üstüne uyarlama —, hesap tersine döner ve sonunda kendi geliştirmenizden daha fazla öder, daha azını alırsınız.

Avantajlar ve sınırlamalar. Bir platformu yapılandırmak, mevcut özelliklerden yararlanmayı sağlar. Karşılığında platformun sınırlarına ve sağlayıcısına bağımlılık oluşur.

Maliyet. Her uyarlama platforma bağlar ve onun gelişimi sırasında birlikte taşınmalıdır; çok fazla uyarlama avantajı bir yüke dönüştürür.

Ne zaman farklı karar veririz. Platformu sistematik olarak doğasına aykırı bükmeye başladığınız yerde yapılandırma avantajını yitirmiştir — o zaman aslında geliştirdiğinizi dürüstçe kabul etmek, bükmeye devam etmekten daha ucuzdur.

5. Build ne zaman kârlıdır

Geliştirmek dar ama gerçek bir alanda kârlıdır: yazılımın kendisinin fark olduğu yerde. Bir süreç şirketinizi diğerlerinden ayırıyorsa, onu yalnızca bu şirket bu şekilde yürüttüğü için hiçbir ürün yansıtmıyorsa ya da satın alınabilir olanın sınırları özde geliştirmekten daha pahalıya mal oluyorsa — o zaman özel yazılım doğru cevaptır. Sizi siz yapan ve uzun süre taşıması gereken şeyi geliştirirsiniz.

Ölçüt, geliştirip geliştiremeyeceğiniz değildir — neredeyse her şeyi geliştirebilirsiniz —; geliştirilenin, satın alınanın yaratamayacağı bir değer yaratıp yaratmadığıdır. Bu değer neredeyse her zaman iki yerden birindedir: farklılaşmada, çünkü yazılım rakiplerin hazır raftan alamayacağı bir yetenek kazandırır; ya da uyumda, çünkü kendinize ait, temel bir süreç pahalıya acı çekmeden hiçbir yabancı korseye sıkıştırılamaz. Bu yerlerden hiçbirine dokunulmayan yerde geliştirmek, satın alabileceğiniz şeyi elde etmenin pahalı bir yoludur.

Avantajlar ve sınırlamalar. Özel geliştirme, süreçlere uyum ve kontrol sağlar. Karşılığında en yüksek başlangıç emeğini ve sürekli bakım sorumluluğunu gerektirir.

Maliyet. Kendi yazılımınız tamamlandığında bitmez; tüm ömrü boyunca işletilmeli, bakımı yapılmalı ve uyarlanmalıdır — bu maliyetleri tek başınıza taşırsınız.

Ne zaman farklı karar veririz. Hazır bir ürün sorunu yeterince iyi karşıladığında ve fark işin özünde olmadığında geliştirmek yanlış seçimdir — o zaman satın alınır ve kendi güç gerçekten farklılaştıran şeye yöneltilir.

Ayrıca kararın sonsuza kadar verilmesi gerekmez. Çoğu zaman en akıllıca yol satın alarak başlamak ve ancak hazır bir ürünün kendi avantajınızı gerçekten sınırladığı ortaya çıktığında geliştirmektir. Sorunu henüz tam olarak bilmediğiniz sürece satın alırsınız ve farklılaşma görünür ve kanıtlanmış hâle gelir gelmez satın alınanı kendinize ait olanla değiştirirsiniz — her yerdeki tutumun aynısı: erken bağlanmamak, pahalı ve zor geri alınabilir seçimi en çok şey bildiğiniz anda yapmak. Geliştirmek nadiren acildir; nedeni netleştiğinde neredeyse her zaman sonradan yapılabilir.

6. Her seçeneğin gizli maliyetleri

Üç yolun her birinin, karar anında gölgede kalan ve ancak yıllar içinde görünür hâle gelen maliyetleri vardır. Bunları bilmek edinim fiyatından daha önemlidir, çünkü ömür boyunca hesabı bunlar belirler.

En yaygın hata, yalnızca görünür maliyetleri — satın alma fiyatını geliştirme maliyetleriyle — karşılaştırmak ve gizli olanları gözden kaçırmaktır. Satın almak, sağlayıcıya bağımlılık pahalılaşana kadar ucuz görünür; geliştirmek ise kendi sürecinizi gerçekten taşıyan tek şeyin o olduğunu fark edene kadar pahalı görünür.

Kendi yazılımınızda gizli maliyet türü en büyük olanıdır: İnşa yalnızca uçtur, ömür boyunca bakım ise altındaki gövdedir. Kendi yazılımınız işletilmeli, güncellenmeli, yeni gereksinimlere uyarlanmalı ve yıllar boyunca anlaşılmalıdır — onu inşa etmemiş insanlar tarafından da. Yalnızca geliştirmeyi hesaplayıp bakımı unutan, geliştirmenin gerçek maliyetlerini sistematik olarak hafife alır. Özel yazılımı bu kadar değerli kılan yükümlülüğün aynısı — tamamen size aittir — onu kalıcı olarak pahalı da kılar: Geleceği sizinle birlikte taşıyan bir sağlayıcı yoktur. Dürüst hesap fiyatı fiyatla değil, ömür boyu toplam maliyeti çözümün işin özünde yarattığı değerle karşılaştırır.

Avantajlar ve sınırlamalar. Toplam maliyeti değerlendirmek, yalnızca satın alma fiyatını karşılaştırmaktan daha fazla araştırma gerektirir. Entegrasyon, işletim, bakım ve geçiş maliyetleri de hesaba katılır.

Maliyet. Ömür boyunca eksiksiz hesap, kesin olarak bilinemeyen gelecek hakkında varsayımlar gerektirir — bulanıklıkla hesap yaparsınız, ama salt fiyatla olduğundan daha dürüstçe.

Ne zaman farklı karar veririz. Küçük, kısa ömürlü bir edinimde fiyat karşılaştırması yeterlidir; tam ömür hesabı ancak şirketi yıllarca bağlayan kararlarda karşılığını verir.

7. Ölçüt: farklılaşma ve ömür

Sonunda üç yol tek bir ölçütte birleşir: Seni farklı kılanı ve uzun süre taşıması gerekeni geliştir; yaygın ve değiştirilebilir olanı satın al ya da yapılandır. İşin özü — başkalarından daha iyi yaptığınız ve şirketin dayandığı şey — kendi yazılımını hak eder, çünkü onu yabancı ellere ve yabancı varsayımlara bırakmak istemezsiniz. Geri kalan her şeyi, gerekli ama farklılaştırmayanı, satın alırsınız.

Şema: İki soru karar verir — sorun bizi farklı kılıyor mu ve uyan bir ürün var mı? Geliştirmek yalnızca sol üstte, hazır cevabı olmayan farklılaştırıcı alanda kesinlikle kârlıdır.

Ömür ölçütü keskinleştirir. Uzun süre taşıması gereken bir şeyi, geleceğini bilmediğiniz bir sağlayıcıya bağlamak istemezsiniz; kısa ömürlü bir şeyi ise gönül rahatlığıyla satın alabilirsiniz. Farklılaşma ve ömür birlikte dürüst cevabı verir: İşin uzun ömürlü özü geliştirilir, kısa ömürlü ya da değiştirilebilir eklentiler satın alınır — ve çoğu şey arada yer alır ve karıştırılır.

Avantajlar ve sınırlamalar. Özel geliştirmeyi gerekçelendirmek için işletmeyi gerçekten farklılaştıran süreçlerin belirlenmesi gerekir. Her ihtiyaç özel yazılım gerektirmez.

Maliyet. Ölçüt rahat bir kural yerine ayrıntılı bir cevaba zorlar; bir kez ve sonsuza kadar “geliştir” ya da “satın al” demek yerine her yapı taşı için yeniden değerlendirme yapmanız gerekir.

Ne zaman farklı karar veririz. Farklılaşmanın ve ömrün ikisinin de düşük olduğu yerde ince tartıdan kaçınılır ve satın alınır; tam ölçüt, işin özüne ya da süresine dokunan yapı taşları içindir.

8. Tipik hatalar

Kararın başarısız olduğu tekrarlayan kalıplar — neredeyse hepsi ölçütü atlamanın varyasyonlarıdır:

• Sorunun çoktan çözülüp satın alınabilir olup olmadığını kontrol etmeden hemen geliştirmeyi düşünmek.
• Farklılaştıranı satın almak ve yabancı varsayımlara bırakmak — ve böylece kendi avantajınızdan vazgeçmek.
• Değiştirilebilir olanı geliştirmek — daha olgun ve daha ucuza satın alınabilecek olanı pahalıya kendiniz üretmek.
• Yalnızca edinim fiyatlarını karşılaştırmak ve ömür boyu gizli maliyetleri gözden kaçırmak.
• Bir platformu, yapılandırma geliştirmenin olacağından daha pahalı hâle gelene kadar doğasına aykırı bükmek.
• Kendi farklılaşmanızı abartmak ve gerçekte yaygın olanı sıra dışı sanmak.
• Yalnızca geliştirmek ya da satın almak varmış gibi karar vermek ve çoğu zaman doğru olan karışımı gözden kaçırmak.
• Uzun ömürlü bir çekirdek sistemi, geleceğini bilmediğiniz bir sağlayıcıya bağlamak.

9. Karar kontrol listesi

Her Build, Buy ya da Configure kararından önce sırayla netleştirilecekler:

• Zaten çözülmüş mü? Bu sorun için hazır bir ürün var mı — varsa, kendimize ait olan neden daha iyi olsun?
• Farklılaştırıcı mı? Bu yapı taşı bizi başkalarından ayırıyor mu — yoksa gerekli ama sıradan mı?
• Ömür? Uzun süre taşıması gerekiyor mu, yoksa kısa ömürlü ve gönül rahatlığıyla değiştirilebilir mi?
• Uyum? Bir ürün ya da platform sorunu yeterince iyi karşılıyor mu — yoksa yalnızca yaklaşık olarak mı ve boşluk özde mi?
• Gizli maliyetler düşünüldü mü? Yalnızca edinim fiyatlarını değil, ömür boyu toplam maliyetleri karşılaştırdım mı?
• Karışım incelendi mi? Ortak olan satın alınıp yalnızca özel olan geliştirilebilir mi?
• Platform sınırları? Yapılandırırken: platformun varsayımları içinde mi kalıyorum — yoksa onu doğasına aykırı mı büküyorum?
• Bağımlılık katlanılabilir mi? Satın alırken: bu yapı taşı için sağlayıcıya bağımlılık kabul edilebilir mi?

Bu sorulara cevap verebilen, yalnızca yazılım geliştirebileceğine değil, sorunun kendi yazılımını hak edip etmediğine karar vermiştir.

Sıkça Sorulan Sorular

Bir yazılım şirketi gerçekten bazen “geliştirmeyin” der mi? Sorumlu olanı evet. En pahalı yazılım, hiç geliştirilmemesi gereken yazılımdır — bir ürünün daha iyi çözeceği bir sorun için yapılmış özel bir çözüm. Yalnızca geliştiren, kısa vadeli işine hizmet eder; konu gerektirdiğinde vazgeçirmeye de çalışan ise müşteriye hizmet eder ve uzun vadede daha değerli olan güveni hak eder.

Satın almak her zaman geliştirmekten daha ucuz değil mi? Edinimde çoğu zaman evet, ömür boyunca her zaman değil. Satın alınan bir ürün ücretleri, sağlayıcıya bağımlılığı ve yabancı varsayımların sınırlarını da beraberinde getirir; özde uymuyorsa bu maliyetlerin toplamı geliştirmeyi aşabilir. Dürüst hesap fiyatı fiyatla değil, zaman içindeki toplam maliyeti yaratılan değerle karşılaştırır.

Neyi geliştirmem gerektiğini nasıl anlarım? Farklılaşmadan. Seni başkalarından ayıranı ve uzun süre taşıması gerekeni geliştir — işin dayandığı özü. Yaygın ve değiştirilebilir olanı satın al ya da yapılandır. En yaygın hata, kendi avantajını satın alıp sıradan olanı geliştirmektir — tam tersi.

Orta yol olarak yapılandırma ne durumda? Yapılandırma, bir platform ihtiyaca yeterince yakınsa ve sınırlarıyla yaşanabiliyorsa güçlüdür. Onu sistematik olarak doğasına aykırı büktüğünüz anda tersine döner — o zaman sonunda kendi geliştirmenizden daha fazla öder, daha azını alırsınız. O noktada aslında geliştirdiğinizi dürüstçe kabul etmek daha ucuz seçimdir.

Tek bir yola mı karar vermem gerekiyor? Nadiren. Sistemlerin çoğu bir karışımdır: ortak olan satın alınmış, özel olan geliştirilmiş, çerçeve için bir platform yapılandırılmış. Soru “hangi yol” değil, “hangi dağılım”dır — hangi yapı taşı hangi yolu hak ediyor.

Bunun uzun ömürlülükle ilişkisi nedir? Yakındır. Uzun süre taşıması gerekeni, geleceğini bilmediğiniz yabancı ellere bırakmak istemezsiniz; kısa ömürlü olanı gönül rahatlığıyla satın alırsınız. Ömür ve farklılaşma birlikte cevabı verir — uzun ömürlü öz geliştirilir, değiştirilebilir eklentiler satın alınır.

İleri okuma

• On yıl sonra hâlâ çalışan yazılım — ömrün Build-Buy kararını da neden belirlediği.
• Yenilikten önce olgun teknoloji — aynı soğukkanlılık, tedarik yerine teknoloji seçimine uygulanmış hâli.
• Yazılım projeleri gerçekte neden başarısız olur — en pahalı projenin neden çoğu zaman hiç başlamaması gereken proje olduğu.
• Tahminden önce geri alınabilirlik — yapı taşlarını, bir yol sonradan da geri alınabilir kalacak şekilde seçmek.

Temelinde Batunet Engineering Method yatar: önce geliştirilmesi gerekip gerekmediğini incelemek; farklılaştıranı geliştirmek, sıradan olanı satın almak, gerisini bilinçli olarak karıştırmak.

Temel mühendislik ilkesi

Her şeyi bir arada tutan kural kısadır: Çekirdeğini geliştir, çevreni satın al. Farklılaştıran, uzun süre taşıması gereken ve işin dayandığı şey yabancı ellere bırakılmaz — orada geliştirirsiniz, çünkü onu elinizden aldırmak istemezsiniz. Pek çok kişinin ihtiyaç duyduğu ve bir pazarın daha olgun ve daha ucuza sunduğu sıradan olan satın alınır — orada geliştirmek pahalı bir kibir olurdu. Bu sorudaki hataların çoğu bu iki tarafın karıştırılmasıdır: çekirdeği satın alıp avantajı elden çıkarmak ya da çevreyi geliştirip parayı ve dikkati yanlış şeye bağlamak. İkisini düzgünce ayıran, en kıt kaynağını — kendi mühendislik gücünü — gerçekten önemli olana yöneltir.

İlk soru asla bir şeyin nasıl geliştirileceği değil, geliştirilip geliştirilmeyeceğidir. Bir mühendisin en olgun cevabı bazen onu yapmamak — ve nedenini söylemektir.