許多公司正在探索移動和物聯網應用利益最大化的方式以加強生產力。
物聯網已經獲得了可觀的報道，這引起了公司想要尋找利用物聯網概念來增強生產力的方式。這種研究往往會導致一種特殊的物聯網模式來展示這樣一種承諾：物聯網和行動工作者支持相結合。負責設計這一模式的架構師和規劃者必須理解這一移動/物聯網模式的真正含義是什么，處理好給移動賦權增強物聯網所帶來的改變，并明確其自身的設計模式來表明下一步移動/物聯網應用將會如何得到處理。
大多數正統的物聯網應用都涉及到用戶與所謂的傳感器與控制網絡(SCN)的交互。在流程控制應用中，SCN就是機器對機器，即M2M，一個使用傳感器信息驅動物料運輸或加工的網絡。這些應用也許會利用移動技術作為與傳感器進行通信的手段，但是它們不會像正常的行業控制應用那樣強迫應用設計做出重大改變。
在員工被可視化為穿梭于傳感器與控制室之間與各種元素交互的應用中，移動和物聯網應用就會發生沖突。如果其潛能被充分認識到，那么這些應用就需要與一般的移動或物聯網應用所做的事情非常不同的設計理念。
邁出第一步
設計移動/物聯網應用的第一步是確保企業架構流程模型是最新的，這些應用將要生成的信息流和活動序列能反映企業實際情況。許多利用移動/物聯網所帶來的好處早期嘗試之所以失敗，是因為那些好處并未與企業特定流程和流掛鉤，因此既無法被驗證，也得不到支持。
移動/物聯網應用設計的第二步是理解SCN空間里面有什么。是不是一個應用中員工從傳感器獲得信息，另一個應用中員工激活網絡控制元素去執行特定任務，或者是兼而有之?答案將決定新應用設計的最佳起點——應用是否天然上下文式的或者是注冊激活式的?
一旦行動工作者獲得了來自于物聯網應用的傳感器信息，這一信息就可以被視為形成了所有移動賦權應用基礎的上下文概念的強化。這一方案包含了兩個寬泛的替代模型：延伸感知模型和傳感器驅動模型。
延伸感知模型利用物聯網傳感器來增強員工對當前環境—活動點的認識。通常而言，員工位置確定了周圍有哪些可用的物聯網傳感器信息，該信息被自動收集進員工的環境詳細資料庫里，然后像任何環境數據一樣進行處理。這是一種容易實現的模型，因為它擴展而不改變移動賦權應用模型。
傳感器驅動模型則是由應用識別出需要基于傳感器信息進行處理的情況，然后提醒及可能派遣員工到合適的地點。這一模型顯著有別于一般的移動應用，因為員工是由應用驅動而不是推動應用。工作的上下文是根據員工預計被激活的地點條件來設定的，其目標是讓員工到達那里。
一個重要因素
傳感器驅動模型的一個重要因素是第一時間識別告警條件。如果傳感器和控制網絡已被用于流程控制、設施監控等，也許有可能為當前流程或監控應用的物聯網/移動活動生成一個觸發器。采用這一方案是明智的，因為它降低了傳感器符合過重或給傳感器網絡增加流量的風險。如果無法在當前流程或監控應用上加載的話，傳感器信息將需要進行分析。
可能的話要避免通過新應用去讀傳感器。大多數傳感器和控制應用一般都把傳感器數據存儲在數據庫里。通過對存儲數據進行分析處理，識別出不正常條件會更加容易。比方說，溫度和濕度變化通過趨勢線來觀察的話會更加容易，因為任何突然的變化都會是不正常的，有可能會需要技術人員前往察看情況。使用基于DBMS的分析作為物聯網上下文的來源也將降低尋找和讀取相關傳感器的復雜性。
最后一點是一致性的重要性。幾乎每一位看過移動/物聯網結合的用戶都承認這一點：許多應用都符合這一描述，但卻少有幾個體現出在新技術時代往往能推動項目的容易實現的特質。一個主要的風險是每一個應用都會產生出自己基于獨特方案的軟件，這又會危害到應用的敏捷性和組建的可復用。如果員工賦權要素因應用而不同的話還會產生操作問題。
軟件架構師和開發者知道，處理這些風險的一個可接受的方式是建立設計模式，一種模板式的辦法，可在需要時實施的解決問題辦法。對于混合了移動性和物聯網的應用來說，設計模式很可能是延伸感知和傳感器驅動模型的共同之需。如果有一個體現了可測試傳感器條件、可選員工位置并能返回一組代表傳感器結果的值的條件集，那么把一個接受體現了這種條件集的設計模式概念化是有可能的。
太快就想投入到API設計中是有誘惑力的。但在致力于特定的組件化和API設計之前，要確保對整個移動/物聯網應用范圍都有了足夠的暴露，這種暴露應該至少在業務流程的層次上。采用開發的中間步驟或更正規的設計模式可保證API過渡是在對需求和移動與物聯網結合所帶來的機遇有了廣泛認知的基礎上進行的。
京公網安備 11010502049343號