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

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

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

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

邁出第一步

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

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

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

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

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

一個重要因素

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

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

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

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

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