在向數(shù)字化轉(zhuǎn)型的道路中，我們終將用到更多的互聯(lián)事物。該新興領域注重軟件和數(shù)字體驗，這意味著軟件將會部署在更多的地方。物聯(lián)網(wǎng)關注的是如何將資產(chǎn)和數(shù)據(jù)整合到現(xiàn)有的基礎設施和系統(tǒng)中。為了滿足客戶對物聯(lián)網(wǎng)解決方案的需求，Microsoft、Amazon和IBM等服務供應商正在各自的云平臺大量投資。而Schneider、Mitsubishi和Siemens等傳統(tǒng)技術廠商也準備采取行動，計劃融入到這一新的生態(tài)系統(tǒng)中。

我這幾年來持續(xù)地參與了多個物聯(lián)網(wǎng)項目。我意識到，客戶需求與服務廠商所提供的服務間存在著很大差距。我并不是說服務提供商應該乃至可以解決所有的問題，而是盡量強調(diào)指出組織需要關注的一些領域。

第一個挑戰(zhàn)：所有權

物聯(lián)網(wǎng)在許多方面上與傳統(tǒng)的企業(yè)集成類似。然而在兩者間存在著一個非常顯著的差異。平臺集成最終是要服務于IT的，它幾乎與業(yè)務無關（除非發(fā)生失敗）。如果大家曾經(jīng)參與過一些集成平臺實施項目，那么就會明白我所要說的問題。要求企業(yè)贊助投資去實施EAI平臺，這無疑具有挑戰(zhàn)性的。因為平臺并不會產(chǎn)生收入，難以展示如何可以節(jié)省成本。我并不是說不應該去做EAI，只是指出平臺的要求和優(yōu)勢是與IT相關的，而非與業(yè)務相關。

如果使用了物聯(lián)網(wǎng)，那么事情就完全反過來了。一旦人們能認識到業(yè)務具有的所有優(yōu)點，將會非常樂意贊助該項目。在Axians IoT，我們通過召開一次僅針對業(yè)務的物聯(lián)網(wǎng)研討會解決了這個問題。研討會由用戶故事驅(qū)動，例如按使用付費、可預測的維護、設備編排等。所有的故事都分別寫在卡片上，在卡片上還給出了描述、價值和風險。這樣小組得到了一副牌，并在小組中討論牌中的每張卡片，排定優(yōu)先級，最終選定一張候選卡片去試行。這一方法已被證明是非常有效的，它可使每個人都參與其中，并成為產(chǎn)品的基石。

在研討會中可以引入IT，也應該引入IT，但IT并非會上的主角。如果我們將物聯(lián)網(wǎng)項目看作是一種IT項目，那么注定會產(chǎn)生失敗。由IT驅(qū)動的物聯(lián)網(wǎng)項目很少會取得成功。物聯(lián)網(wǎng)項目需要與業(yè)務保持一致，并由業(yè)務驅(qū)動。其中，我們需要對如何增加收入或削減成本具有明確的認識。這就是說，其中必須涉及IT和OT（操作技術，Operation Technology），以確保解決方案與現(xiàn)有的運行和維護過程相一致。

第二個挑戰(zhàn)：技能集

在一個“正?！钡腎T項目中，各個資源（即開發(fā)人員，測試人員和操作人員）應對其他同行的領域具有很好的了解。有時，例如在DevOps中，同一資源甚至可能擔當多個活躍的角色。

另一方面，物聯(lián)網(wǎng)項目由三個截然不同的群組構(gòu)成，也可以說是三種不同類型的人員組成。這些團體或角色往往不會去了解“另一面”。這并非像是十多年前Java和.Net開發(fā)者間那樣的水火不容，而是因為直到現(xiàn)在我們依然沒有看到互通有無的任何好處，因此沒有理由去這樣做。

一方面，我們的電氣工程師深入了解儀表、傳感器、電阻、PLC、布線等所有的現(xiàn)場設備，對于任何我們想要控制或與之互動的機械、車輛或電氣部件，他們也是專家。他們習慣于使用SCADA這樣的系統(tǒng)，專注于穩(wěn)定性，僅將Raspberry PI看成是一種可愛的小玩具。字節(jié)數(shù)組是他們唯一了解的數(shù)據(jù)格式，他們會將Float看成是一種平常的數(shù)據(jù)類型，而事實上Float并不是！他們無疑是核心人物，沒有必要解釋他們?yōu)槭裁丛陧椖恐惺遣豢苫蛉钡模?/p>

換一個角度看技能集，我們還有一些業(yè)務分析師。他們對業(yè)務有著深入的了解，并且對如何處理數(shù)據(jù)以及如何使用數(shù)據(jù)改變收入模式有著深刻的理解。處于這個位置的人，往往就是推動商業(yè)案例的人，而且他們也應該這樣做。在他們看來，MS Excel只是一種開發(fā)平臺，雖然事實并非如此。他們喜歡使用Power BI。盡管他們可能不太熟悉一些領域，例如機器學習，但是他們很快就會熟悉這些領域。雖然Excel、機器學習和Power BI似乎與其它類型的開發(fā)是密切相關的，但事實上并非如此。

最后讓我們看一下云開發(fā)人員。盡管我十分想解釋清楚，但是該角色十分模糊。在當前的場景下，云開發(fā)人員指的是那些精通網(wǎng)絡、存儲和集成的傳統(tǒng)開發(fā)人員。如果這些工程師認為系統(tǒng)是穩(wěn)定的，那么電器工程師會對此不屑一顧冷嘲熱諷。盡管該角色稱為云開發(fā)，但我認為，只要關注了諸如Node.js、Java或.Net等高級編程平臺，就應將設備開發(fā)人員也包括在其中。如果項目考慮使用嵌入式系統(tǒng)和C編程實現(xiàn)微控制器，那么設備開發(fā)人員可能與電氣工程師更密切相關。

與其它任何項目一樣，規(guī)劃整個項目的發(fā)布和任務同樣需要具有很好的領導和管理。但是考慮到各個群組具有完全不同的想法，我們需要做得更多。每個群組都必須主動去了解其它的群組。對于云開發(fā)人員來說，尤其應該這樣做，因為他們與其它群組間交流存在一些不順。云開發(fā)人員必須協(xié)調(diào)從業(yè)務/數(shù)據(jù)分析人員到電氣工程師的需求，反之亦然。

第三個挑戰(zhàn)：板載

在首次Sprint時，Trello面板上可能不會出現(xiàn)“如何配置設備”這一問題。當你意識到推出成百數(shù)千種設備的挑戰(zhàn)時，我可以保證你會在同一塊面板上碰壁。為滿足你的需求，你可以也應該預先安裝并配置設備，但是每個設備都或多或少地與其它設備類似，區(qū)分它們的是自動注冊設備時所需要使用的信息。這些信息可以是MAC地址、IMEI id、SIM卡ID（ICCID）、證書，或是你所希望的任何組合。雖然你可以訂購預先配置了密鑰或證書的設備，但這往往是非常昂貴的。

但是在某些情況下，我們不需要大量板載設備，只需要在使用WiFi的地點一次部署一個設備。物聯(lián)網(wǎng)設備可以由技術人員安裝在建筑物中，甚至可以由其中居住的居民安裝。在這種情況下，我們可以考慮讓設備提供一個WiFi熱點，任何人都可以使用智能手機現(xiàn)場配置設備。

無論使用哪種方式，板載是設備管理的一個重要組成部分，出于多種目的考慮應做分開部署，并以此作為整體解決方案的一個重要組成部分。除了管理配置過程的需求，我們可能還應考慮支持在某個時間點更換云服務提供商，或者支持從跨數(shù)據(jù)中心的災難恢復。

在Axians，我們使用了microServiceBus.com。它支持Azure、AWS和IBM 的物聯(lián)網(wǎng)、跨數(shù)據(jù)中心的災難恢復，并與Cisco Jasper集成，為我們提供了使用SIM卡的開箱即用的板載功能。它還支持使用MAC地址及其他一些方式的白名單。

第四個挑戰(zhàn)：規(guī)則更改

對于一個企業(yè)而言，部署Web應用卻不監(jiān)視其運行狀況，或者不修補其操作系統(tǒng)，這是不可以接受的。企業(yè)也不會漠不關心每臺工作站和筆記本是否安裝了更新的防病毒軟件和防火墻。

不過出于某些原因，這看上去似乎與物聯(lián)網(wǎng)解決方案毫不相關。人們似乎認為物聯(lián)網(wǎng)設備能夠抵御各種威脅，是運行在經(jīng)得起時間考驗的神奇操作系統(tǒng)之上的。事實并非如此！

無論大小和形狀如何，設備和網(wǎng)關在本質(zhì)上都是小型的計算機，它們的操作系統(tǒng)需要修補，還需要不斷地更新的平臺和自定義代碼，以及我們所能想象到的更多依賴性。所有這些都是可以更改的。如果有人不承認這一點，那么我們大可以禮貌地點點頭，然后就離開房間不再回來。

但是，設備管理不僅是遠程更新和配置新設備?，F(xiàn)有的IT操作可能會使用System Center或同類工具管理服務器和工作站。服務臺和NOC可能會使用像ServiceNow或JIRA這樣的工具來升級問題、發(fā)現(xiàn)問題并計劃發(fā)布。無論我們選擇了哪種設備管理系統(tǒng)，都必須保持與現(xiàn)有流程的一致。一旦解決方案投入生產(chǎn)，沒有人不希望面對的是一個沒有人可以也不想管理的混亂系統(tǒng)。

除了板載之外，microServiceBus.com還支持我們控制設備并配置更新，甚至是管理代碼。它集成了ServiceNow，該工具是我們用于管理狀況、問題和發(fā)布的工具。

第五個挑戰(zhàn)：測試

對于從事各種類型應用開發(fā)的組織，測試驅(qū)動設計（TDD）和持續(xù)集成（CI）都得到了廣泛的應用。但是，物聯(lián)網(wǎng)解決方案的性質(zhì)和體系結(jié)構(gòu)，決定了這些測試方法是難以接受的。測試的目標是快速失敗，為適應物聯(lián)網(wǎng)的需求，我們需要跳出其中考慮問題。

為了更好地解釋這些挑戰(zhàn)，我將它們分成三類：

技能集和隔離

正如在“第二個挑戰(zhàn)：技能集”一節(jié)中所介紹的，物聯(lián)網(wǎng)項目通常包括三個群組，各個群組間是相互隔離的，分別具有不同的關注點、技能集，當然還有工具集。由于所做的測試是完全不同的，因此結(jié)果通常相互不符。

由于每個群組都與其它群組隔離，單元測試和模擬模型成為每個人日常生活的一部分。開發(fā)人員可能需要數(shù)個月的時間才能第一次看到PLC。而分析師則繼續(xù)使用假設的數(shù)據(jù)結(jié)構(gòu)，直到他們最終能看到一些真實數(shù)據(jù)。因此，我需要在此強調(diào)指出組間協(xié)商接口和文檔化的重要性。

位置

物聯(lián)網(wǎng)的分布式本質(zhì)并不會簡化測試過程，但是對測試和演示環(huán)境的訪問的確十分有幫助。通常，企業(yè)不可能對站點設置創(chuàng)建副本，因為這往往需要耗費大量的設備、管道和電線，讓原本整潔的辦公環(huán)境一團糟。

盡管如此，我們還是要用心去創(chuàng)造一個很好的演示環(huán)境。不要在乎做適當?shù)耐顿Y，要讓演示閃亮美麗。假定演示并非是未來測試，而是要打動你的利益相關者。給出一個好的物聯(lián)網(wǎng)演示，這無疑是最好的！

現(xiàn)場安裝

我們都希望團隊能擁有優(yōu)秀的工程師，在設備站點或車輛上安裝儀表、網(wǎng)關、通信和電纜。但是隨著項目的推進，這些工程師可能不會繼續(xù)去設置站點。此時通常是由一些不太熟練的人接手。他們對項目缺乏洞察力，也不了解企業(yè)所創(chuàng)造的價值觀。

為了適應這種狀況，我們需要給出安全可靠的安裝指南和過程，常常需要給出多種語言的版本。安裝指南必須經(jīng)過測試！

結(jié)論

物聯(lián)網(wǎng)驅(qū)動了大量人力物力的參與，并帶來了新的機遇。但我們應確保以業(yè)務為驅(qū)動?？紤]我們需要做的是什么，而不是我們能做什么。盡早給出對收益的估算，并確保向目標推進。

建立合伙關系，組建一支優(yōu)秀的團隊。無論人們身處何種角色和職責，鼓勵他們分享自己的知識和經(jīng)驗。使用日常站會（Standup）建立人們間的合作，與整個團隊一起規(guī)劃項目，無論是長期的還是短期的。

考慮板載等現(xiàn)實挑戰(zhàn)，并盡早在項目中分配任務。深入查看自身所面對的機會，并確保硬件符合要求。不要使用Raspberry Pi或Arduino這樣的設備做概念驗證。

對更改做出規(guī)劃！確保選擇一個可讓我們遠程控制設備的平臺，不要把物聯(lián)網(wǎng)設備與其它的IT設備（如服務器，電話或工作站）區(qū)別對待。確保物聯(lián)網(wǎng)設備始終與最新的固件、操作系統(tǒng)及其它軟件保持同步。