主管不能简单地把移动工作者认为是不坐在一起的人。相反，赋权要从评估员工需求开始。

如果提高生产力是推动企业技术投资的利益引擎的话，那么接下来关键的速度爆发当然就必须来自于移动设备和宽带服务的利用。不过正如一位运营主管所言：“移动工作者不仅仅是离开办公桌的人，”移动赋权往往就是在这种过分简单化的基础上进行的。

真正的移动赋权始于对活动点员工信息需求的评估，然后设计工作流来优化该点的生产力。最后，赋权止于在行动工作者的灵活性需求最大的地方创建敏捷API。

好的移动赋权架构并非始于工作流和API，而是从业务流和流程开始。为了最大限度利用行动工作者，其活动可能需要一个新的企业架构评审。

使用活动驱动模型

传统的企业架构流往往会描述流程，并且接上假定的序列信息流去匹配序列应用流程。移动性引入了更为事件驱动或活动驱动的模型。这意味着要定义的不是员工如何工作，而是员工在特定点针对特定条件做什么。

企业架构师会发现，业务流程分析的活动驱动模型往往会产生更短的工作流，活动涉及的流程步骤仅限于对特定事件的处理。许多企业架构师说，基于传统模型的业务流程描述与基于活动工作流的活动模型的巨大区别在于，基于活动的工作流从员工的环境继承了上下文。而另一方面，传统模型则是通过顺序映射步骤来建立员工的上下文的。员工信息需求基于活动的映射是移动工作流和API设计的基础。

共同工作流阶段

在软件架构水平上，所有的移动赋权工作流都有一组共同的阶段。首先，必须建立员工的上下文以便精确框定信息需求。上下文意味着员工的位置、任务以及已有的沟通渠道。

其次，员工必须推动信息交付，甚至基于该任务的通信连接，所以会有一个事件分析阶段。最后，活动必须以有秩序的方式结束自己且把它的完成状态作为提供给其他事件上下文的输入。然后活动流就变成这样：设置—上下文，做—工作，设置—终止条件。

这些要素组合的特别方式将取决于工作性质以及需要考虑哪些激活条件。如果员工被派遣到沿着一条特定路线去执行一系列任务，那么员工位置就是上下文的元素，也是工作的驱动因素。比方说，如果员工是自我导向的， 那么员工有可能必须明确发起流程。

移动工作者赋权在工作流的设定上下文阶段很有可能需要新的逻辑。一般的移动模型是假设员工通过在活动点上做某特定的事情来激活该工作流。在那个点上，软件必须通过数据库收集员工上下文。赋权工作流的第一步是创建上下文映射把员工不能通过设备提供的东西填充上。

由于大多数移动工作者都会尝试利用当前应用，一个方便的做法是把该工作流模型视为由前端基于Web的创建上下文的流程发起，这涉及到调用当前信息检索与处理组件。意味着整个执行工作阶段或信息交付的第二阶段可被表示为前端处理当前组件的外观设计模式。

设定上下文和执行工作阶段可被视为是迭代式的；员工通过在上下文背景下发出变化信号（显式或通过条件）来推动流程，然后基于上下文迭代执行工作活动。这种序列有可能利用标准的消息总线和BPEL技术来完成，但把这一阶段可视化为个体需求驱动响应流程的状态事件流程也许更好。

工作结束引发了一个移动赋权的特殊问题，因为这不仅意味着执行工作阶段的结束，而且它还必须管理该活动和相关或后续活动的过渡，这些活动当中有的可能是异步的或甚至是传统的批处理系统流程。一旦给定活动结束，按照假定员工应该转移到工作之间的上下文环境，当他们要么（根据安排）抵达下一个活动点或发出新的启动信号（如果是自主引导）时重启工作流。

活动本身往往会触发后续步骤。比方说，服务调用的完成可能意味着必须发起账单，而这一工作流也许已经定义了。设定终止条件阶段的目的是恢复员工到合适的状态以便同意下一活动及正确触发后续或相关活动。

API和工作流有何不同

移动赋权API与工作流最大的不同在于通过活动维护上下文或状态的需求。大多数情况下这意味着要么员工设备（通过app）正在管理上下文和状态，要么某后端状态管理流程（上下文映射）维护住流程。这一映射不需要传递给现有提供员工信息或流程输入的组件，但它必须是受到维护的，这一员工请求或事件才能被解释并引导到合适的流程上。

另一个值得观察的总体问题是移动赋权的API设计是有颗粒度的。事件驱动流程必须局限在处理单个逻辑事件上来保证效率。可能有必要把某些信息交付相关的当前流程步骤进行分隔并更新，这样才适合包含到上下文或事件驱动流中。