最后让我们看一下云开发人员。尽管我十分想解释清楚，但是该角色十分模糊。在当前的场景下，云开发人员指的是那些精通网络、存储和集成的传统开发人员。如果这些工程师认为系统是稳定的，那么电器工程师会对此不屑一顾冷嘲热讽。尽管该角色称为云开发，但我认为，只要关注了诸如Node.js、Java或.Net等高级编程平台，就应将设备开发人员也包括在其中。如果项目考虑使用嵌入式系统和C编程实现微控制器，那么设备开发人员可能与电气工程师更密切相关。
与其它任何项目一样，规划整个项目的发布和任务同样需要具有很好的领导和管理。但是考虑到各个群组具有完全不同的想法，我们需要做得更多。每个群组都必须主动去了解其它的群组。对于云开发人员来说，尤其应该这样做，因为他们与其它群组间交流存在一些不顺。云开发人员必须协调从业务/数据分析人员到电气工程师的需求，反之亦然。
第三个挑战：板载
在首次Sprint时，Trello面板上可能不会出现“如何配置设备”这一问题。当你意识到推出成百数千种设备的挑战时，我可以保证你会在同一块面板上碰壁。为满足你的需求，你可以也应该预先安装并配置设备，但是每个设备都或多或少地与其它设备类似，区分它们的是自动注册设备时所需要使用的信息。这些信息可以是MAC地址、IMEI id、SIM卡ID(ICCID)、证书，或是你所希望的任何组合。虽然你可以订购预先配置了密钥或证书的设备，但这往往是非常昂贵的。
但是在某些情况下，我们不需要大量板载设备，只需要在使用WiFi的地点一次部署一个设备。物联网设备可以由技术人员安装在建筑物中，甚至可以由其中居住的居民安装。在这种情况下，我们可以考虑让设备提供一个WiFi热点，任何人都可以使用智能手机现场配置设备。
无论使用哪种方式，板载是设备管理的一个重要组成部分，出于多种目的考虑应做分开部署，并以此作为整体解决方案的一个重要组成部分。除了管理配置过程的需求，我们可能还应考虑支持在某个时间点更换云服务提供商，或者支持从跨数据中心的灾难恢复。
在Axians，我们使用了microServiceBus.com。它支持Azure、AWS和IBM 的物联网、跨数据中心的灾难恢复，并与Cisco Jasper集成，为我们提供了使用SIM卡的开箱即用的板载功能。它还支持使用MAC地址及其他一些方式的白名单。
第四个挑战：规划更改
对于一个企业而言，部署Web应用却不监视其运行状况，或者不修补其操作系统，这是不可以接受的。企业也不会漠不关心每台工作站和笔记本是否安装了更新的防病毒软件和防火墙。
不过出于某些原因，这看上去似乎与物联网解决方案毫不相关。人们似乎认为物联网设备能够抵御各种威胁，是运行在经得起时间考验的神奇操作系统之上的。事实并非如此!
无论大小和形状如何，设备和网关在本质上都是小型的计算机，它们的操作系统需要修补，还需要不断地更新的平台和自定义代码，以及我们所能想象到的更多依赖性。所有这些都是可以更改的。如果有人不承认这一点，那么我们大可以礼貌地点点头，然后就离开房间不再回来。
但是，设备管理不仅是远程更新和配置新设备。现有的IT操作可能会使用System Center或同类工具管理服务器和工作站。服务台和NOC可能会使用像ServiceNow或JIRA这样的工具来升级问题、发现问题并计划发布。无论我们选择了哪种设备管理系统，都必须保持与现有流程的一致。一旦解决方案投入生产，没有人不希望面对的是一个没有人可以也不想管理的混乱系统。
除了板载之外，microServiceBus.com还支持我们控制设备并配置更新，甚至是管理代码。它集成了ServiceNow，该工具是我们用于管理状况、问题和发布的工具。
第五个挑战：测试
对于从事各种类型应用开发的组织，测试驱动设计(TDD)和持续集成(CI)都得到了广泛的应用。但是，物联网解决方案的性质和体系结构，决定了这些测试方法是难以接受的。测试的目标是快速失败，为适应物联网的需求，我们需要跳出其中考虑问题。
为了更好地解释这些挑战，我将它们分成三类：