目前，許多公司正在探索移動和物聯(lián)網(wǎng)應用利益最大化的方式以加強生產(chǎn)力。

物聯(lián)網(wǎng)已經(jīng)獲得了可觀的報道，這引起了公司想要尋找利用物聯(lián)網(wǎng)概念來增強生產(chǎn)力的方式。這種研究往往會導致一種特殊的物聯(lián)網(wǎng)模式來展示這樣一種承諾：物聯(lián)網(wǎng)和行動工作者支持相結(jié)合。負責設計這一模式的架構(gòu)師和規(guī)劃者必須理解這一移動/物聯(lián)網(wǎng)模式的真正含義是什么，處理好給移動賦權(quán)增強物聯(lián)網(wǎng)所帶來的改變，并明確其自身的設計模式來表明下一步移動/物聯(lián)網(wǎng)應用將會如何得到處理。

大多數(shù)正統(tǒng)的物聯(lián)網(wǎng)應用都涉及到用戶與所謂的傳感器與控制網(wǎng)絡(SCN)的交互。在流程控制應用中，SCN就是機器對機器，即M2M，一個使用傳感器信息驅(qū)動物料運輸或加工的網(wǎng)絡。這些應用也許會利用移動技術(shù)作為與傳感器進行通信的手段，但是它們不會像正常的行業(yè)控制應用那樣強迫應用設計做出重大改變。

在員工被可視化為穿梭于傳感器與控制室之間與各種元素交互的應用中，移動和物聯(lián)網(wǎng)應用就會發(fā)生沖突。如果其潛能被充分認識到，那么這些應用就需要與一般的移動或物聯(lián)網(wǎng)應用所做的事情非常不同的設計理念。

邁出第一步

設計移動/物聯(lián)網(wǎng)應用的第一步是確保企業(yè)架構(gòu)流程模型是最新的，這些應用將要生成的信息流和活動序列能反映企業(yè)實際情況。許多利用移動/物聯(lián)網(wǎng)所帶來的好處早期嘗試之所以失敗，是因為那些好處并未與企業(yè)特定流程和流掛鉤，因此既無法被驗證，也得不到支持。

移動/物聯(lián)網(wǎng)應用設計的第二步是理解SCN空間里面有什么。是不是一個應用中員工從傳感器獲得信息，另一個應用中員工激活網(wǎng)絡控制元素去執(zhí)行特定任務，或者是兼而有之?答案將決定新應用設計的最佳起點——應用是否天然上下文式的或者是注冊激活式的?

一旦行動工作者獲得了來自于物聯(lián)網(wǎng)應用的傳感器信息，這一信息就可以被視為形成了所有移動賦權(quán)應用基礎的上下文概念的強化。這一方案包含了兩個寬泛的替代模型：延伸感知模型和傳感器驅(qū)動模型。

延伸感知模型利用物聯(lián)網(wǎng)傳感器來增強員工對當前環(huán)境—活動點的認識。通常而言，員工位置確定了周圍有哪些可用的物聯(lián)網(wǎng)傳感器信息，該信息被自動收集進員工的環(huán)境詳細資料庫里，然后像任何環(huán)境數(shù)據(jù)一樣進行處理。這是一種容易實現(xiàn)的模型，因為它擴展而不改變移動賦權(quán)應用模型。

傳感器驅(qū)動模型則是由應用識別出需要基于傳感器信息進行處理的情況，然后提醒及可能派遣員工到合適的地點。這一模型顯著有別于一般的移動應用，因為員工是由應用驅(qū)動而不是推動應用。工作的上下文是根據(jù)員工預計被激活的地點條件來設定的，其目標是讓員工到達那里。

一個重要因素

傳感器驅(qū)動模型的一個重要因素是第一時間識別告警條件。如果傳感器和控制網(wǎng)絡已被用于流程控制、設施監(jiān)控等，也許有可能為當前流程或監(jiān)控應用的物聯(lián)網(wǎng)/移動活動生成一個觸發(fā)器。采用這一方案是明智的，因為它降低了傳感器符合過重或給傳感器網(wǎng)絡增加流量的風險。如果無法在當前流程或監(jiān)控應用上加載的話，傳感器信息將需要進行分析。

可能的話要避免通過新應用去讀傳感器。大多數(shù)傳感器和控制應用一般都把傳感器數(shù)據(jù)存儲在數(shù)據(jù)庫里。通過對存儲數(shù)據(jù)進行分析處理，識別出不正常條件會更加容易。比方說，溫度和濕度變化通過趨勢線來觀察的話會更加容易，因為任何突然的變化都會是不正常的，有可能會需要技術(shù)人員前往察看情況。使用基于DBMS的分析作為物聯(lián)網(wǎng)上下文的來源也將降低尋找和讀取相關傳感器的復雜性。

最后一點是一致性的重要性。幾乎每一位看過移動/物聯(lián)網(wǎng)結(jié)合的用戶都承認這一點：許多應用都符合這一描述，但卻少有幾個體現(xiàn)出在新技術(shù)時代往往能推動項目的容易實現(xiàn)的特質(zhì)。一個主要的風險是每一個應用都會產(chǎn)生出自己基于獨特方案的軟件，這又會危害到應用的敏捷性和組建的可復用。如果員工賦權(quán)要素因應用而不同的話還會產(chǎn)生操作問題。

軟件架構(gòu)師和開發(fā)者知道，處理這些風險的一個可接受的方式是建立設計模式，一種模板式的辦法，可在需要時實施的解決問題辦法。對于混合了移動性和物聯(lián)網(wǎng)的應用來說，設計模式很可能是延伸感知和傳感器驅(qū)動模型的共同之需。如果有一個體現(xiàn)了可測試傳感器條件、可選員工位置并能返回一組代表傳感器結(jié)果的值的條件集，那么把一個接受體現(xiàn)了這種條件集的設計模式概念化是有可能的。

D1Net評論：

從目前來看，太快就想投入到API設計中是有誘惑力的。但在致力于特定的組件化和API設計之前，要確保對整個移動/物聯(lián)網(wǎng)應用范圍都有了足夠的暴露，這種暴露應該至少在業(yè)務流程的層次上。采用開發(fā)的中間步驟或更正規(guī)的設計模式可保證API過渡是在對需求和移動與物聯(lián)網(wǎng)結(jié)合所帶來的機遇有了廣泛認知的基礎上進行的。