畢竟廠商投入研發資源開發支持某一種protocol的裝置或應用方案後，最怕遇到當年VHS與Beta爭鋒的場面，一旦勝負分曉後所有配合Beta規格開發的錄影帶生產廠商最後都面臨設備養蚊子的窘境。如何解決這個問題，筆者將在下一篇文章中做深入的分析。
平台層
根據IIRA，平台層(platform tier)包含了兩個不同的功能領域(domain)：裝置管理(device management)與資料處理分析(data analytics)。目前台灣市場上大部分看得到的做法都是兩者合一，全部由同一個廠商完成。甚至，更精確的說，台灣廠商大多還沒有平台層的觀念，應用方案的發展廠商通常自己找尋合適的裝置，自己扮演系統整合商的角色，寫程式將所有的裝置串連起來，同時按照規劃邏輯自行收集與分析資料，並自行開發使用介面與儀表板(dashboard)供客戶使用。
這樣的模式接近於傳統的系統整合商模式，能否有效處理異質性裝置間因為所需的通訊協定不同導致的可操作性(interoperability)、能否在同一平台上連接與管理巨量的裝置 [i] 、能否專業地設計如天文數字般量級的數據處理分析平台、能否與其他物聯網應用方案採用者溝通、能否以比傳統系統整合商更有效率開發成本更低廉得物聯網應用方案，都是採用這種開發模式的廠商與使用者應該評估的重點。
以筆者觀察IIC由許多國際性公司籌組的試驗方案(testbed)，仍以各家按照自己的強項分工合作為主流。舉例來說，TCS, Cisco, Siemens, Oracle, Infineon, Tego共同組成一個團隊，研發smart supply chain testbed，以參與者的知名度與規模來說，這樣的研發團隊陣容堪稱夢幻，也顯示與其關起門來自己開發一個IoT solution，各大國際性公司寧可結合各自的強項，按照IIRA架構共同開發功能更強大的方案。
畢竟，如果真的如同IDC預測， 2018年將有高達220億個裝置連網，Cisco更預測2020年將有500億個裝置連網，平均每個人擁有6.58個連網裝置。屆時有規模的物聯網平台將同時串連數以億計的裝置，如何管理上億個裝置仍能精確不失誤，這個平台上又將同時收集與處理的資料量有多麼龐大可想而知 ，因此就可以想見為何連國際性公司都選擇「集體創作」與分工合作。身在台灣的我們，對於物聯網應用方案開發夥伴的選擇，豈可不慎。
企業層
最上層也是最關鍵的企業層(enterprise tier)則包含兩個不同的功能領域：應用軟體領域(application domain)與商業領域(business domain)。對於市民來說，公車候車亭是否智慧不是重點，只要能夠讓他們在苦苦等候公車20分鐘後，同時來了三班公車，他們能夠聰明地選擇三輛公車中有空位的那一部才是重點。在這個例子裡面，候車亭背後的電視面板偵測並顯示每一部公車的空閒座位的功能就是application，市政府或公車公司在後台監控每部公車行車狀況的軟體就是business domain software。
對市民來說應用方案的開發者(solution provider)與公車資訊服務提供者(service provider)是否採用具備聯網能力的智慧硬體裝置、運用哪幾種通訊協定根本不是他們關心的角度，所以他們不會因為政府宣佈候車亭導入物聯網而歡呼，他們關注的重點永遠在於這個新導入的應用方案能否帶來原本不曾被滿足的便利。
所以，由有能力發掘各行各業或民生消費中尚未被滿足的需求，並找到功能合適的智慧裝置，串連到性能優異的物聯網平台，開發簡便好用的使用者介面的軟體業者(solution provider)，才能提供讓被服務的市民有感覺，政府認同的便民服務。隨著個別application或business domain software被肯定而正式導入，相關的裝置自然就能順利銷售。
兩岸業者過去兩年曾經競相開發「智慧硬體」，過去幾年創投也轟轟烈烈的投資了許多智慧硬體，這些開發計畫或被投資的新創團隊大多面臨市場需求遲遲沒有出現的窘境。其理由就在於缺乏從需求端著手開發物聯網的application，並透過這些application創造或滿足使用者需求，光是一個「智慧硬體」對於使用者來說與玩具無異，但又比玩具貴了許多。
這也是為何筆者一直強調，台灣如果真的希望在物聯網產業有所斬獲， 如何有計畫的培養各個行業許許多多的enterprise tier開發團隊，才是政府應該投入的部分。至於應該在專區集中軟硬體廠商匯聚，減少整體物聯網開發團隊溝通成本，加快方案或智慧裝置開發速度 ，因為已經在前一篇文章中強調，在此不再贅述。