一款互聯產品的外觀可能在相關工程完成之前就已經初具規模。原型機運作穩定，資料已上傳至雲端，應用程式顯示的資料也正確無誤，首批裝置也已交付使用者。此時，後端可能還比較簡單，團隊幾乎對每台裝置都瞭如指掌。配置可以透過腳本完成，更改配置資訊可以手動操作，如果發生故障，工程師通常也能直接追蹤到問題所在。
然後，它必須開始在現實世界中運行。第二代硬體版本問世。一些客戶仍在繼續使用第一代版本。韌體版本開始出現差異。針對不同的客戶或市場，需要新的配置，而舊設備仍需要更新和支援。
設備本身並沒有損壞。只是設備背後的軟體已經到了它自身的生命週期結束的時候。
這種轉變很容易被忽略，因為原型機可以繼續完美運作。但是，一旦同一產品的多個版本需要在實際應用中共存，後端就不再只是硬體背後的基礎設施，而是成為了產品架構本身的一部分。
一個可運作的連網原型還不是可擴充的產品。
原型機肩負著一項重要任務：驗證系統端到端運作正常。設備執行其核心功能，韌體與後端通信，遙測資料到達目標位置，指令返回，並透過移動或網頁介面向用戶展示各項功能。
它通常無法證明的是，同一系統在應對多樣性方面表現如何。
前二十台設備可能都運行相同的韌體，採用相同的硬體版本，並由同一批工程師配置。在這個階段，手動註冊、直接配置變更或編寫一個簡單的引導腳本都是完全合理的。在產品尚未經過市場驗證之前就建立生產級工具可能為時過早。
規模擴大改變了問題。設備會離線、更換、運作不同的韌體，需要不同的客戶配置。支援人員必須區分從未正確配置的設備、配置錯誤的設備或根本無法存取的設備。
原型債務往往始於此：並非源自於錯誤的決策，而是源自於產品迭代後仍存在的臨時性決策。而促使這種轉變的首要因素之一就是硬體本身。新版本並非簡單地取代舊版本，而是必須與之共存。
每次硬體更新都會帶來軟體生命週期問題。
新硬體版本很少能完全取代舊版本。實際上，兩個版本都會繼續在市場上使用，有時甚至長達數年。再加上過渡批次、幾個韌體分支以及客戶特定的配置，最終的設備種類很快就會比最初的產品模型所設想的要豐富得多。
軟體層不能再將每個單元視為抽象的“設備”，它需要知道該特定單元能夠做什麼。
修改後的電路板可能使用不同的感測器、通訊模組或控制器。適用於最新版本的命令可能不會被早期版本支援。校準值可能會改變。配置限制可能會變更。適用於某一代產品的韌體包可能對另一代產品不安全。
實體產品工程師早已採用這種工作方式。即使兩個組件看起來幾乎完全相同，但如果它們的版本、公差或規格不同，也無法互換。聯網產品在軟體方面也存在同樣的問題：平台需要一種可靠的方法來識別它正在與哪個版本的實體產品通信，以及哪些規則適用於該版本。
假設某產品的第一版採用一種校準程序，而第二版則引入了新的感測器和不同的參數集。對客戶而言，這兩個版本可能仍然是同一款產品。但對平台而言，它們並非如此。
如果這些差異沒有被明確地表示出來，它們往往會以特殊情況的形式滲透到應用程式邏輯中。例如，一個工作流程會檢查序號範圍；另一個工作流程則使用韌體版本作為硬體代數的代理；第三個工作流程包含一個例外，這是在技術支援人員發現某個舊批次的產品在實際應用中存在不同行為後添加的。這些修復單獨來看似乎都不算特別危險，但它們加在一起卻使得未來的每一次變更都更難被理解和應對。
老舊硬體很少能依計畫淘汰。產品團隊自然會專注於最新版本，而客戶往往會比預期更長時間地保留早期版本。因此，平台必須同時支援多個版本，而不是假設用戶群最終會統一使用單一版本。
一旦這種情況發生，硬體演進和軟體生命週期管理就密不可分了。平台不僅需要知道設備的位置和在線狀態，還需要知道設備的具體信息，包括設備的功能、運行的程序、配置方式以及哪些更改可以安全應用。
在能夠可靠地回答這些問題之前，每個設備都必須以一致的方式進入系統。
配置環節是人工工程無法擴充的地方。
當設備數量不多時，配置過程看起來很簡單：建立設備記錄、輸入序號、產生憑證、將設備分配給客戶、應用程式配置，然後就完成了。對於數十台設備來說，手動處理其中一些步驟可能仍然是正確的選擇。
然而，在生產規模下，設備配置涉及設備身分、憑證、所有權、配置和生命週期狀態等多個面向。入職過程中的任何錯誤都可能影響設備出廠後很長一段時間內的運作和支援。
電子表格可能與實際安裝的設備不符。更換的設備需要與正確的客戶關聯，且不能繼承錯誤的身份資訊。恢復出廠設定會引發另一種情況。安裝人員可能會將裝置指派給錯誤的帳戶，導致技術支援人員需要確定裝置是離線、設定錯誤還是只是設定資訊錯誤。
一旦回答這些問題需要開發人員檢查資料庫或執行內部腳本，該流程就無法隨著產品的發展而擴展。
重複是另一個警示信號。每個產品變體都開始擁有自己的引導腳本、設定工具或安裝程式工作流程。這些差異看似微小，但根本責任卻是一樣的。配置已演變為可重複使用的平台基礎設施，而非附加到特定設備的設定任務。
而且，這通常不是唯一需要實現可重複使用的功能。
平台層應成為可重複使用的基礎設施
一旦多個產品或硬體版本擁有相同的基本需求，某些軟體功能就不再是產品特有的了。設備標識、配置、連接、遙測、韌體交付、生命週期狀態、設備群可視性和診斷就是很好的例子。為每個新版本重新建置這些功能會增加程式碼量和維護流程，但不會讓產品本身更有特色。
團隊很少會刻意造成這種重複勞動。隨著產品差異的不斷累積，最終團隊需要維護多個實作版本，而這些實作其實都屬於同一工程職責。
更清楚的界線是將產品層與平台層分開。產品層包含使特定設備具有價值的行為、工作流程、介面、整合和領域邏輯。平台層則處理即使硬體發生變化也應保持一致的機制。
隨著連網產品走出首個版本，設備配置、設備生命週期管理、車隊管理和支援工具不再是針對特定專案的一次性細節，而是逐漸演變為共享的基礎架構。以企業為導向的物聯網平台即服務 (PaaS)可以提供跨多個產品或產品變體的可重複使用平台層，透過可重複使用的建置模組處理標準的裝置和資料管理，使工程團隊能夠將客製化開發工作集中在硬體、工作流程和使用者體驗上。
通用基礎架構仍需為實際產品差異留出空間。新設備可能需要不同的資料模型、配置流程、整合或控制邏輯，而這些差異應該易於引入。目標很簡單，就是避免讓每一次差異都牽扯出另一套設備註冊表、遙測管道、配置機製或設備管理工具。
當團隊開發第一個產品時，平台可能看起來像是額外的負擔，但到了第二或第三個產品時，它就變成了寶貴的資產。一旦通用的操作機製到位，新的產品版本就可以繼承現有的基礎架構，而無需引入另一個後端，也無需團隊在產品整個生命週期中維護它。
只有在產品真正與眾不同的情況下，才進行客製化工程。
可重複使用平台不應使互聯產品變得更加通用。它的作用在於消除那些不創造差異化的部件的重複工程。
客製化工作仍體現在設備行為、特定領域邏輯、工作流程、使用者體驗、專用整合以及特定產品與實體世界的互動方式等方面。這些領域正是工程決策能顯著提升產品性能的關鍵。
然而，往往得不到同等重視的是其配套的運作系統。同一台機器的基本版本和工業版本可能需要不同的感測器、控制器和接口，但它們不應該需要不同的設備識別、韌體版本追蹤或設備管理方式。
我更希望工程師把時間花在改進產品在實際應用上的表現上，而不是重新建構團隊已經為其他產品建立好的機制。共享基礎架構並不會減少客製化工程的空間；它只是保護這些工作不被基礎設施建設所消耗。
真正的考驗在於團隊開始研發第二個產品的時候。
一個好的平台會讓下一個產品的開發比第一個產品更容易。
如果第二個產品需要的平台工作量與第一個產品幾乎相同，那麼實際上很少有東西被重複利用。
新版本應能繼承營運模式中未發生變化的部分：配置流程、身分認證、生命週期機制、車隊工具、韌體流程、支援可見性以及通用整合。工程工作則應集中於差異部分——例如新的感測器元件、不同的控制工作流程或客戶特定的整合——而不是重構基礎架構。
新一代硬體的出現為同樣的理念帶來了更大的挑戰。其功能可能會發生顯著變化，而舊款設備仍將繼續服役。一個成熟的平台可以同時支援這兩款設備，而無需團隊為了維護兩套獨立的平台架構而疲於應對客戶眼中仍屬於同一產品系列的產品。
這一切都不需要單一的後端架構。不同的產品仍然需要清晰的架構邊界。關鍵在於，如果沒有充分的理由，就避免重複實現相同的工程職責。
這時，平台就變成了資產，而不是不斷累積的負擔。支援團隊需要理解的平行工具更少，版本發布遵循更一致的路徑，添加新產品也變成了可控的擴展，而不是公司無限期繼承的另一個後端。
將平台視為產品架構的一部分
實體產品在設計時會考慮修訂、可維護性、可製造性和未來變更。聯網產品在軟體方面也需要同樣的嚴謹性。
第一個後端可以是臨時的，第一個設定腳本或支援工具也可以是臨時的。這本身並沒有什麼問題。問題在於，當這些臨時機制悄悄變成永久架構，而產品本身卻在不斷發展演進時。
到那時，互聯產品不再只是硬體、韌體和應用程式。它還依賴基礎設施，該基礎設施能夠識別每個設備、了解其功能、應用正確的配置、支援更新，並幫助團隊在產品交付數年後診斷問題。
一旦將該層視為產品架構，劃分就變得更加清晰：標準機制保持可重複使用性，而客製化工作則用於真正將一個產品或產品系列與另一個產品或產品系列區分開來。
最強大的平台不僅是讓第一個互聯產品成為可能的平台，它還能讓工程團隊在建立第二個、第三個甚至第四個產品時，無需每次都繼承新的後端。
