认识达内从这里开始

随着互联网的不断发展，越来越多的行业领域都将网络化使用到了各个地方。今天，我们就来了解一下，由于客户需求和服务提供商之间存在的差距如何才能被减小。

第一个挑战：所有权

物联网在许多方面上与传统的企业集成类似。然而在两者间存在着一个非常显著的差异。平台集成最终是要服务于IT的，它几乎与业务无关(除非发生失败)。如果大家曾经参与过一些集成平台实施项目，那么就会明白我所要说的问题。要求企业赞助投资去实施EAI平台，这无疑具有挑战性的。因为平台并不会产生收入，难以展示如何可以节省成本。我并不是说不应该去做EAI，只是指出平台的要求和优势是与IT相关的，而非与业务相关。

如果使用了物联网，那么事情就完全反过来了。一旦人们能认识到业务具有的所有优点，将会非常乐意赞助该项目。在Axians IoT，我们通过召开一次仅针对业务的物联网研讨会解决了这个问题。研讨会由用户故事驱动，例如按使用付费、可预测的维护、设备编排等。所有的故事都分别写在卡片上，在卡片上还给出了描述、价值和风险。这样小组得到了一副牌，并在小组中讨论牌中的每张卡片，排定优先级，最终选定一张候选卡片去试行。这一方法已被证明是非常有效的，它可使每个人都参与其中，并成为产品的基石。

在研讨会中可以引入IT，也应该引入IT，但IT并非会上的主角。如果我们将物联网项目看作是一种IT项目，那么注定会产生失败。由IT驱动的物联网项目很少会取得成功。物联网项目需要与业务保持一致，并由业务驱动。其中，我们需要对如何增加收入或削减成本具有明确的认识。这就是说，其中必须涉及IT和OT(操作技术，Operation Technology)，以确保解决方案与现有的运行和维护过程相一致。

第二个挑战：技能集

在一个“正常”的IT项目中，各个资源(即开发人员，测试人员和操作人员)应对其他同行的领域具有很好的了解。有时，例如在DevOps中，同一资源甚至可能担当多个活跃的角色。

另一方面，物联网项目由三个截然不同的群组构成，也可以说是三种不同类型的人员组成。这些团体或角色往往不会去了解“另一面”。这并非像是十多年前Java和.Net开发者间那样的水火不容，而是因为直到现在我们依然没有看到互通有无的任何好处，因此没有理由去这样做。

一方面，我们的电气工程师深入了解仪表、传感器、电阻、PLC、布线等所有的现场设备，对于任何我们想要控制或与之互动的机械、车辆或电气部件，他们也是专家。他们习惯于使用SCADA这样的系统，专注于稳定性，仅将Raspberry PI看成是一种可爱的小玩具。字节数组是他们唯一了解的数据格式，他们会将Float看成是一种平常的数据类型，而事实上Float并不是!他们无疑是核心人物，没有必要解释他们为什么在项目中是不可或缺的!

换一个角度看技能集，我们还有一些业务分析师。他们对业务有着深入的了解，并且对如何处理数据以及如何使用数据改变收入模式有着深刻的理解。处于这个位置的人，往往就是推动商业案例的人，而且他们也应该这样做。在他们看来，MS Excel只是一种开发平台，虽然事实并非如此。他们喜欢使用Power BI。尽管他们可能不太熟悉一些领域，例如机器学习，但是他们很快就会熟悉这些领域。虽然Excel、机器学习和Power BI似乎与其它类型的开发是密切相关的，但事实上并非如此。

最后让我们看一下云开发人员。尽管我十分想解释清楚，但是该角色十分模糊。在当前的场景下，云开发人员指的是那些精通网络、存储和集成的传统开发人员。如果这些工程师认为系统是稳定的，那么电器工程师会对此不屑一顾冷嘲热讽。尽管该角色称为云开发，但我认为，只要关注了诸如Node.js、Java或.Net等高级编程平台，就应将设备开发人员也包括在其中。如果项目考虑使用嵌入式系统和C编程实现微控制器，那么设备开发人员可能与电气工程师更密切相关。

与其它任何项目一样，规划整个项目的发布和任务同样需要具有很好的领导和管理。但是考虑到各个群组具有完全不同的想法，我们需要做得更多。每个群组都必须主动去了解其它的群组。对于云开发人员来说，尤其应该这样做，因为他们与其它群组间交流存在一些不顺。云开发人员必须协调从业务/数据分析人员到电气工程师的需求，反之亦然。

第三个挑战：板载

在首次Sprint时，Trello面板上可能不会出现“如何配置设备”这一问题。当你意识到推出成百数千种设备的挑战时，我可以保证你会在同一块面板上碰壁。为满足你的需求，你可以也应该预先安装并配置设备，但是每个设备都或多或少地与其它设备类似，区分它们的是自动注册设备时所需要使用的信息。这些信息可以是MAC地址、IMEI id、SIM卡ID(ICCID)、证书，或是你所希望的任何组合。虽然你可以订购预先配置了密钥或证书的设备，但这往往是非常昂贵的。

但是在某些情况下，我们不需要大量板载设备，只需要在使用WiFi的地点一次部署一个设备。物联网设备可以由技术人员安装在建筑物中，甚至可以由其中居住的居民安装。在这种情况下，我们可以考虑让设备提供一个WiFi热点，任何人都可以使用智能手机现场配置设备。

无论使用哪种方式，板载是设备管理的一个重要组成部分，出于多种目的考虑应做分开部署，并以此作为整体解决方案的一个重要组成部分。除了管理配置过程的需求，我们可能还应考虑支持在某个时间点更换云服务提供商，或者支持从跨数据中心的灾难恢复。

在Axians，我们使用了#。它支持Azure、AWS和IBM 的物联网、跨数据中心的灾难恢复，并与Cisco Jasper集成，为我们提供了使用SIM卡的开箱即用的板载功能。它还支持使用MAC地址及其他一些方式的白名单。

第四个挑战：规划更改

对于一个企业而言，部署Web应用却不监视其运行状况，或者不修补其操作系统，这是不可以接受的。企业也不会漠不关心每台工作站和笔记本是否安装了更新的防病毒软件和防火墙。

不过出于某些原因，这看上去似乎与物联网解决方案毫不相关。人们似乎认为物联网设备能够抵御各种威胁，是运行在经得起时间考验的神奇操作系统之上的。事实并非如此!

无论大小和形状如何，设备和网关在本质上都是小型的计算机，它们的操作系统需要修补，还需要不断地更新的平台和自定义代码，以及我们所能想象到的更多依赖性。所有这些都是可以更改的。如果有人不承认这一点，那么我们大可以礼貌地点点头，然后就离开房间不再回来。

但是，设备管理不仅是远程更新和配置新设备。现有的IT操作可能会使用System Center或同类工具管理服务器和工作站。服务台和NOC可能会使用像ServiceNow或JIRA这样的工具来升级问题、发现问题并计划发布。无论我们选择了哪种设备管理系统，都必须保持与现有流程的一致。一旦解决方案投入生产，没有人不希望面对的是一个没有人可以也不想管理的混乱系统。

除了板载之外，#还支持我们控制设备并配置更新，甚至是管理代码。它集成了ServiceNow，该工具是我们用于管理状况、问题和发布的工具。

第五个挑战：测试

对于从事各种类型应用开发的组织，测试驱动设计(TDD)和持续集成(CI)都得到了广泛的应用。但是，物联网解决方案的性质和体系结构，决定了这些测试方法是难以接受的。测试的目标是快速失败，为适应物联网的需求，我们需要跳出其中考虑问题。

作者：Mikael Hakansson

译者：盖磊

来源：infoq

【免责声明】：本内容转载于网络，转载目的在于传递最新信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。