Bağlantılı bir ürün, etrafındaki mühendislik çalışmaları tamamlanmadan çok önce bitmiş gibi görünebilir. Prototip stabildir, veriler buluta ulaşır, uygulama doğru değerleri gösterir ve ilk cihaz grubu zaten kullanıcıların elindedir. Bu noktada, arka uç hala yeterince basit olabilir ve ekip neredeyse her cihazı ayrı ayrı tanıyabilir. Sağlama işlemi bir komut dosyasıyla yapılabilir, yapılandırma değişiklikleri manuel olarak yapılabilir ve bir şey başarısız olursa, bir mühendis genellikle sorunu doğrudan tespit edebilir.
Sonrasında gerçek dünyada yaşamaya başlaması gerekiyor. İkinci bir donanım revizyonu ortaya çıkıyor. Bazı müşteriler hala ilk revizyonu kullanıyor. Yazılım sürümleri birbirinden farklılaşmaya başlıyor. Farklı bir müşteri veya pazar için yeni bir yapılandırma gerekirken, eski cihazlar hala güncellemelere ve desteğe ihtiyaç duyuyor.
Aslında hiçbir şey bozuk değil. Cihazın arkasındaki yazılım, kendine özgü bir yaşam döngüsü kazanmış durumda.
Bu geçişi gözden kaçırmak kolaydır çünkü prototip mükemmel şekilde çalışmaya devam edebilir. Ancak aynı fiziksel ürünün birden fazla versiyonunun sahada birlikte var olması gerektiğinde, arka uç artık sadece donanımın arkasındaki altyapı olmaktan çıkar. Ürün mimarisinin bir parçası haline gelir.
Çalışır durumda ve bağlantılı bir prototip henüz ölçeklenebilir bir ürün değildir.
Bir prototipin önemli bir görevi vardır: sistemin baştan sona çalıştığını kanıtlamak. Cihaz temel işlevini yerine getirir, bellenim arka uçla iletişim kurar, telemetri verileri olması gereken yere ulaşır, komutlar geri dönüş yolculuğunu yapar ve mobil veya web arayüzü işlevselliği kullanıcıya sunar.
Genellikle kanıtlayamadığı şey ise aynı sistemin çeşitlilikle ne kadar iyi başa çıkabildiğidir.
İlk yirmi cihazın tamamı aynı bellenimi çalıştırabilir, aynı donanım sürümüne göre üretilebilir ve aynı mühendisler tarafından yapılandırılabilir. Bu aşamada, manuel kayıt, doğrudan yapılandırma değişiklikleri veya küçük bir kurulum komut dosyası tamamen mantıklı olabilir. Ürün kendini kanıtlamadan önce üretim kalitesinde araçlar oluşturmak erken olabilir.
Sorun, ölçek büyüdükçe değişiyor. Cihazlar çevrimdışı kalabiliyor, değiştirilebiliyor, farklı yazılımlar çalıştırabiliyor ve farklı müşteri yapılandırmaları gerektirebiliyor. Destek ekibi, doğru şekilde yapılandırılmamış bir cihazı, yanlış yapılandırılmış veya erişilemez bir cihazdan ayırt etmek zorunda kalıyor.
Prototip borcu genellikle şöyle başlar: kötü bir kararla değil, ürün piyasaya sürüldükten sonra da devam eden geçici bir kararla. Ve bu geçişi görünür kılan ilk şeylerden biri de donanımın kendisidir. Yeni bir revizyon, eskisinin yerini basitçe almaz; onunla birlikte var olmak zorundadır.
Her donanım revizyonu, yazılım yaşam döngüsünde bir sorun yaratır.
Yeni bir donanım revizyonu nadiren eskisinin yerini tamamen alacak şekilde gelir. Pratikte, her iki sürüm de bazen yıllarca sahada kalır. Bir geçiş partisi, birkaç bellenim dalı ve müşteriye özel yapılandırmalar eklendiğinde, filo hızla orijinal ürün modelinin önerdiğinden daha çeşitli hale gelir.
Yazılım katmanı artık her birimi soyut bir "cihaz" olarak ele alamaz. O birimin ne yapabileceğini bilmesi gerekir.
Yenilenmiş bir kart farklı bir sensör, iletişim modülü veya kontrolcü kullanabilir. En son sürüm için geçerli olan bir komut, önceki bir sürüm tarafından desteklenmeyebilir. Kalibrasyon değerleri değişebilir. Yapılandırma sınırları kayabilir. Bir nesil için uygun olan bir bellenim paketi, başka bir nesil için güvenli olmayabilir.
Fiziksel ürün mühendisleri zaten bu şekilde çalışıyor. Neredeyse aynı görünen iki bileşen, revizyonları, toleransları veya özellikleri farklıysa birbirinin yerine kullanılamaz. Bağlantılı ürünler, yazılım tarafında da aynı sorunu yaratır: platformun, hangi fiziksel ürün sürümüyle iletişim kurduğunu ve hangi kuralların geçerli olduğunu anlamanın güvenilir bir yoluna ihtiyacı vardır.
İlk revizyonunda bir kalibrasyon prosedürü kullanılırken, ikinci revizyonunda yeni bir sensör ve farklı bir parametre seti tanıtılan bir ürünü düşünün. Müşteri için her iki ünite de aynı ürün olabilir. Ancak platform için aynı olamazlar.
Bu farklılıklar açıkça belirtilmediği takdirde, özel durumlar olarak uygulama mantığına sızma eğilimindedirler. Bir iş akışı seri numarası aralığını kontrol eder. Bir diğeri donanım nesli için bir vekil olarak ürün yazılımı sürümünü kullanır. Üçüncüsü, destek ekibinin sahada farklı davranan eski bir partiyi keşfetmesinin ardından eklenen bir istisna içerir. Bu düzeltmelerin hiçbiri tek başına özellikle tehlikeli görünmese de, birlikte her gelecekteki değişikliği anlamayı daha da zorlaştırırlar.
Eski donanımlar nadiren planlanan zamanda ortadan kaybolur. Ürün ekipleri doğal olarak en yeni sürüme odaklanırken, müşteriler genellikle önceki sürümleri beklenenden çok daha uzun süre kullanırlar. Bu nedenle platform, kurulu tabanın hiçbir zaman tek bir mevcut durumda birleşeceğini varsaymak yerine, aynı anda birkaç nesli desteklemek zorundadır.
Bu gerçekleştiğinde, donanım evrimi ve yazılım yaşam döngüsü yönetimi birbirinden ayrılamaz hale gelir. Platformun yalnızca bir cihazın nerede olduğunu ve çevrimiçi olup olmadığını değil, aynı zamanda ne olduğunu, ne çalıştırabileceğini, nasıl yapılandırılması gerektiğini ve hangi değişikliklerin güvenli bir şekilde uygulanabileceğini de bilmesi gerekir.
Bu soruların herhangi birine güvenilir bir şekilde cevap verilebilmesi için öncelikle her cihazın sisteme tutarlı bir şekilde dahil edilmesi gerekiyor.
Tedarik süreci, manuel mühendisliğin ölçeklendirmenin durduğu noktadır.
Filo küçük olduğunda tedarik işlemi basit görünür: bir cihaz kaydı oluşturun, seri numarası girin, kimlik bilgilerini oluşturun, cihazı bir müşteriye atayın, bir yapılandırma uygulayın ve devam edin. Birkaç düzine cihaz için, bunların bir kısmını manuel olarak yapmak yine de doğru seçim olabilir.
Üretim ölçeğinde ise, tedarik süreci cihaz kimliği, kimlik bilgileri, sahiplik, yapılandırma ve yaşam döngüsü durumu gibi unsurların kesiştiği noktada yer alır. Kurulum sırasında yapılan bir hata, cihazın fabrikadan çıktıktan çok sonra bile nasıl çalıştırılacağını ve destekleneceğini etkileyebilir.
Bir elektronik tablo, gerçekte kurulu olanla artık eşleşmeyebilir. Yedek bir cihazın, yanlış kimliği devralmadan doğru müşteriyle ilişkilendirilmesi gerekir. Fabrika ayarlarına sıfırlama, süreçte başka bir yol oluşturur. Bir kurulumcu, bir cihazı yanlış hesaba atayabilir ve bu durumda destek ekibi, cihazın çevrimdışı olup olmadığını, yanlış yapılandırılıp yapılandırılmadığını veya yanlış yapılandırmaya sahip olup olmadığını belirlemek zorunda kalır.
Bu tür soruları yanıtlamak için geliştiricinin rutin olarak bir veritabanını incelemesi veya dahili bir komut dosyası çalıştırması gerektiğinde, süreç ürünle birlikte ölçeklenebilirliğini yitirmiştir.
Tekrarlama da bir diğer uyarı işaretidir. Her ürün varyantı kendi kurulum komut dosyasını, yapılandırma aracını veya yükleyici iş akışını edinmeye başlar. Bu farklılıklar küçük görünebilir, ancak temel sorumluluk aynıdır. Sağlama işlemi, belirli bir cihaza bağlı bir kurulum görevi olmaktan ziyade, yeniden kullanılabilir bir platform altyapısı haline gelmiştir.
Ve yeniden kullanılabilir hale gelmesi gereken tek yetenek nadiren budur.
Platform katmanı yeniden kullanılabilir bir altyapı haline gelmelidir.
Birkaç ürün veya donanım revizyonu aynı temel ihtiyaçları paylaştığında, bazı yazılım yetenekleri ürüne özgü olmaktan çıkar. Cihaz kimliği, tedarik, bağlantı, telemetri, bellenim dağıtımı, yaşam döngüsü durumu, filo görünürlüğü ve teşhis, bunun iyi örnekleridir. Bunları her yeni varyant için yeniden oluşturmak, ürünü daha ayırt edici hale getirmeden daha fazla kod ve daha fazla operasyonel yol oluşturur.
Ekipler nadiren bu tür bir tekrarlamayı hedefleyerek yola çıkarlar. Her ürün etrafında küçük farklılıklar birikir ve sonunda ekip, aynı mühendislik sorumluluğu haline gelen şeyin birkaç uygulamasını sürdürmek zorunda kalır.
Daha net bir sınır, ürün katmanını platform katmanından ayırmaktır. Ürün katmanı, belirli bir cihazı değerli kılan davranışları, iş akışlarını, arayüzleri, entegrasyonları ve alan mantığını içerir. Platform katmanı ise donanım değişse bile tutarlı kalması gereken mekanikleri ele alır.
Bağlantılı ürünler ilk sürümlerini geride bıraktıkça, cihaz tedariği, cihaz yaşam döngüsü yönetimi, filo yönetimi ve destek araçları, tek seferlik proje detayları olmaktan ziyade paylaşılan altyapı haline gelir. Kurumsal bir IoT PaaS, birden fazla ürün veya ürün varyantı genelinde yeniden kullanılabilir bir platform katmanı sağlayarak, mühendislik ekipleri özel çalışmalarını donanım, iş akışları ve kullanıcı deneyimine odaklarken, yeniden kullanılabilir yapı taşları aracılığıyla standart cihaz ve veri yönetimini ele alabilir.
Ortak bir temel, gerçek ürün farklılıklarına da yer bırakmalıdır. Yeni bir cihaz farklı bir veri modeline, yapılandırma akışına, entegrasyona veya kontrol mantığına ihtiyaç duyabilir ve bu farklılıkların kolayca uygulanabilir olması gerekir. Amaç, her farklılığın başka bir cihaz kaydı, telemetri hattı, tedarik mekanizması veya filo yönetim araçları kümesini de beraberinde getirmesini önlemektir.
Ekip ilk ürünü geliştirirken platform bir maliyet kalemi gibi görünebilir, ancak ikinci veya üçüncü üründe bir varlık haline gelebilir. Ortak operasyonel mekanizmalar yerleştikten sonra, yeni bir varyant, ekibin ürünün ömrünün geri kalanında bakımını üstlenmesi gereken başka bir arka uçla gelmek yerine, çalışan bir temeli devralabilir.
Ürünün gerçekten farklı olduğu yerlerde özel mühendislik çalışmalarına devam edin.
Yeniden kullanılabilir bir platform, bağlantılı ürünleri daha genel hale getirmemeli. Görevi, farklılık yaratmayan parçalardan tekrarlanan mühendislik çalışmalarını ortadan kaldırmaktır.
Özel geliştirme çalışmaları, cihaz davranışı, alana özgü mantık, iş akışları, kullanıcı deneyimi, özel entegrasyonlar ve belirli bir ürünün fiziksel dünyayla etkileşim biçimi gibi alanlarda hala gereklidir. Mühendislik tercihleri, bir ürünü diğerinden anlamlı derecede daha iyi hale getirebilecek alanlardır tam olarak.
Genellikle aynı özeni hak etmeyen şey ise çevresel operasyonel tesisatlardır. Aynı makinenin temel ve endüstriyel versiyonları farklı sensörlere, kontrollere ve arayüzlere ihtiyaç duyabilir, ancak cihazları tanımlamak, ürün yazılımı sürümlerini izlemek veya bir filoyu yönetmek için ayrı yöntemlere ihtiyaç duymamalıdırlar.
Mühendislerin o zamanı, ekibin başka bir ürün için zaten mevcut olan mekanizmaları yeniden inşa etmek yerine, ürünün sahada nasıl davrandığını iyileştirmeye harcamalarını tercih ederim. Ortak bir altyapı, özel mühendislik kapsamını azaltmaz; bu çabayı altyapı tarafından tüketilmekten korur.
Asıl sınav, ekip ikinci ürünü üretmeye başladığında başlayacak.
İyi bir platform, bir sonraki ürünü ilk ürüne göre daha kolay hale getirir.
İkinci ürün, birinci ürünle neredeyse aynı platform çalışmasını gerektiriyorsa, aslında çok az şey yeniden kullanılmış demektir.
Yeni bir varyant, işletim modelinin değişmeyen kısımlarını miras alabilmelidir: tedarik akışları, kimlik, yaşam döngüsü mekaniği, filo araçları, bellenim süreçleri, destek görünürlüğü ve ortak entegrasyonlar. Mühendislik çalışmaları daha sonra temeli yeniden oluşturmak yerine farklılıklara odaklanır; örneğin yeni bir sensör paketi, farklı bir kontrol iş akışı veya müşteriye özel bir entegrasyon.
Yeni bir donanım nesli, aynı fikri daha fazla baskı altına alıyor. Yetenekleri önemli ölçüde değişebilirken, eski üniteler sahada aktif kalmaya devam edebilir. Olgun bir platform, müşterilerin hala tek bir ürün ailesi olarak algıladığı şey için ekibin iki ayrı platform yığını sürdürmesini gerektirmeden her ikisini de destekleyebilir.
Bunların hiçbiri tek bir monolitik arka uç gerektirmez. Farklı ürünler yine de net mimari sınırlara ihtiyaç duyabilir. Önemli olan, geçerli bir neden olmadan aynı mühendislik sorumluluğunun ikinci bir uygulamasını önlemektir.
İşte o zaman platform, birikmiş bir yük olmaktan ziyade bir varlık haline gelir. Destek ekibinin anlaması gereken paralel araç sayısı azalır, sürümler daha tutarlı yolları izler ve başka bir ürün eklemek, şirketin süresiz olarak devralacağı başka bir arka uç yerine kontrollü bir uzantı haline gelir.
Platformu ürün mimarisinin bir parçası olarak ele alın.
Fiziksel ürünler, revizyonlar, servis kolaylığı, üretilebilirlik ve gelecekteki değişiklikler göz önünde bulundurularak tasarlanır. Bağlantılı ürünler de yazılım tarafında aynı disipline ihtiyaç duyar.
İlk arka uç geçici olabilir. İlk tedarik betiği veya destek aracı da öyle. Bunda özünde yanlış bir şey yok. Sorunlar, bu geçici mekanizmaların sessizce kalıcı bir mimariye dönüşmesi ve ürünün kendisinin gelişmeye devam etmesiyle başlar.
O zamana kadar, bağlantılı ürün artık sadece donanım, yazılım ve bir uygulamadan ibaret değildir. Aynı zamanda her cihazı tanımlayan, yeteneklerini anlayan, doğru yapılandırmayı uygulayan, güncellemeleri destekleyen ve ekiplerin sevkiyattan yıllar sonra bile sorunları teşhis etmesine yardımcı olan altyapıya da bağlıdır.
Bu katman ürün mimarisi olarak ele alındığında, ayrım daha net hale gelir: standart mekanikler yeniden kullanılabilir kalırken, özel çalışmalar bir ürünü veya ürün ailesini diğerinden ayıran unsurlara odaklanır.
En güçlü platform, yalnızca ilk bağlantılı ürünü mümkün kılan platform değildir. Mühendislik ekibinin her seferinde yeni bir arka uç devralmadan ikinci, üçüncü ve dördüncü ürünleri geliştirmesine olanak sağlayan platformdur.
