许多公司正在探索移动和物联网应用利益最大化的方式以加强生产力。
物联网已经获得了可观的报道，这引起了公司想要寻找利用物联网概念来增强生产力的方式。这种研究往往会导致一种特殊的物联网模式来展示这样一种承诺：物联网和行动工作者支持相结合。负责设计这一模式的架构师和规划者必须理解这一移动/物联网模式的真正含义是什么，处理好给移动赋权增强物联网所带来的改变，并明确其自身的设计模式来表明下一步移动/物联网应用将会如何得到处理。
大多数正统的物联网应用都涉及到用户与所谓的传感器与控制网络(SCN)的交互。在流程控制应用中，SCN就是机器对机器，即M2M，一个使用传感器信息驱动物料运输或加工的网络。这些应用也许会利用移动技术作为与传感器进行通信的手段，但是它们不会像正常的行业控制应用那样强迫应用设计做出重大改变。
在员工被可视化为穿梭于传感器与控制室之间与各种元素交互的应用中，移动和物联网应用就会发生冲突。如果其潜能被充分认识到，那么这些应用就需要与一般的移动或物联网应用所做的事情非常不同的设计理念。
迈出第一步
设计移动/物联网应用的第一步是确保企业架构流程模型是最新的，这些应用将要生成的信息流和活动序列能反映企业实际情况。许多利用移动/物联网所带来的好处早期尝试之所以失败，是因为那些好处并未与企业特定流程和流挂钩，因此既无法被验证，也得不到支持。
移动/物联网应用设计的第二步是理解SCN空间里面有什么。是不是一个应用中员工从传感器获得信息，另一个应用中员工激活网络控制元素去执行特定任务，或者是兼而有之?答案将决定新应用设计的最佳起点——应用是否天然上下文式的或者是注册激活式的?
一旦行动工作者获得了来自于物联网应用的传感器信息，这一信息就可以被视为形成了所有移动赋权应用基础的上下文概念的强化。这一方案包含了两个宽泛的替代模型：延伸感知模型和传感器驱动模型。
延伸感知模型利用物联网传感器来增强员工对当前环境—活动点的认识。通常而言，员工位置确定了周围有哪些可用的物联网传感器信息，该信息被自动收集进员工的环境详细资料库里，然后像任何环境数据一样进行处理。这是一种容易实现的模型，因为它扩展而不改变移动赋权应用模型。
传感器驱动模型则是由应用识别出需要基于传感器信息进行处理的情况，然后提醒及可能派遣员工到合适的地点。这一模型显著有别于一般的移动应用，因为员工是由应用驱动而不是推动应用。工作的上下文是根据员工预计被激活的地点条件来设定的，其目标是让员工到达那里。
一个重要因素
传感器驱动模型的一个重要因素是第一时间识别告警条件。如果传感器和控制网络已被用于流程控制、设施监控等，也许有可能为当前流程或监控应用的物联网/移动活动生成一个触发器。采用这一方案是明智的，因为它降低了传感器符合过重或给传感器网络增加流量的风险。如果无法在当前流程或监控应用上加载的话，传感器信息将需要进行分析。
可能的话要避免通过新应用去读传感器。大多数传感器和控制应用一般都把传感器数据存储在数据库里。通过对存储数据进行分析处理，识别出不正常条件会更加容易。比方说，温度和湿度变化通过趋势线来观察的话会更加容易，因为任何突然的变化都会是不正常的，有可能会需要技术人员前往察看情况。使用基于DBMS的分析作为物联网上下文的来源也将降低寻找和读取相关传感器的复杂性。
最后一点是一致性的重要性。几乎每一位看过移动/物联网结合的用户都承认这一点：许多应用都符合这一描述，但却少有几个体现出在新技术时代往往能推动项目的容易实现的特质。一个主要的风险是每一个应用都会产生出自己基于独特方案的软件，这又会危害到应用的敏捷性和组建的可复用。如果员工赋权要素因应用而不同的话还会产生操作问题。
软件架构师和开发者知道，处理这些风险的一个可接受的方式是建立设计模式，一种模板式的办法，可在需要时实施的解决问题办法。对于混合了移动性和物联网的应用来说，设计模式很可能是延伸感知和传感器驱动模型的共同之需。如果有一个体现了可测试传感器条件、可选员工位置并能返回一组代表传感器结果的值的条件集，那么把一个接受体现了这种条件集的设计模式概念化是有可能的。
太快就想投入到API设计中是有诱惑力的。但在致力于特定的组件化和API设计之前，要确保对整个移动/物联网应用范围都有了足够的暴露，这种暴露应该至少在业务流程的层次上。采用开发的中间步骤或更正规的设计模式可保证API过渡是在对需求和移动与物联网结合所带来的机遇有了广泛认知的基础上进行的。
