企业帮助员工在移动方面做了大量努力，但结果仍不如预期。Tom Nolle解释了企业架构模型如何帮助企业实现移动授权。

几乎每一家企业都希望通过移动改进员工生产力，然而大多数调查表明，他们对自己努力的效果并不满意的。原因是什么？企业对移动员工需要什么并不是很清楚。第一个解决方案应该考虑企业架构。

首先，组织应该把移动授权视为员工与企业关系的转型。然后，他们应该识别移动使能的新方法。最后，这些过程应该转化为特定的移动应用能力。遵循这些步骤可以改进任何的移动项目。可能它们还可以改善你的总体企业架构模型流程。

移动的问题

移动授权的最大问题是典型的策略并不考虑移动，而只针对移动设备。获得移动设备支持的员工并不需要再次提供同样的信息，那些信息只是针对移动显示调整一下格式而已。他们需要的是获得不同的信息，因为有IT支持，他们的工作方式发生了改变。理想情况下，一个企业架构模型可回退到业务流程，然后以针对移动优化的方式去定义实现。这一般可以通过企业架构师和软件架构师之间的合作来完成，但这不是一件容易的事情。

即便是非移动应用，企业架构业务流程也应该转化为最适合、实用且技术性的应用架构。软件架构师和企业架构师应该一起合作创建一个套技术框架来支持特定的工作方法。这样可以采用采取新的、移动效率高的方案。它的成功取决于是否应用了企业架构建模的最佳实践。

企业架构建模的办法

企业架构模型有很多，每一个都采取略为不同的办法，但每一个模型都有一个从业务到IT的显式转换——从目标和需求转为应用和系统。尽管很少会用这些术语，但所有架构都假设业务目标和功能应该可以从完成它们的方法中抽象出来。如果有时候被称为“业务流程”的一项业务目标或功能表明“测试某种条件下的每一条电路”、“隔离故障”等等，就可以使用该方法，实现既定的目标。如果它的定义类似“修理线路”之类的话，并不会预设特定的系列步骤，而会把焦点放在整体需求而不是特定任务上。

在推动移动授权方面，许多企业架构师重视的挑战将会减少，因为纯粹需求消失或者令人困惑。在每一个企业架构模型中，业务流程需求与专门针对现有IT工具的方法之间会存在隐形或显式的边界。你必须清除这条边界，确保自己从实际业务需求开始而不是从非移动技术的实践集开始。这个过程可能会同时涉及到企业架构师和软件架构师。

企业架构师与软件架构师之间的协调

任何有关移动授权优化的交流都应该从描述当前员工与IT的关系或者当前手工流程开始。然后，再考察这一流程可进行怎样的修改来利用机动性的独特能力，将IT技术与具体活动结合起来。

比方说，如果检查的是“修理线路”流程的话，第一步也许可以概括为“识别要修理的目标”，这样比较泛化，不像之前“测试每一条电路”那么具体。然后，软件架构师可能会提出，将移动设备与线路故障检测系统绑定，这样也许就可以给工人提供面板照片，从而高亮显示正确的线路给他看。

这种方法还可以引领新步骤的识别。在此，员工出现在目标面板这一点是隐含条件。假设不是这种情况，GPS或者近场通信技术（NFC）是不是可以用来引导员工去到目标面板，然后展示适当线路的图像呢？在某些情况下，是不是想要这样的功能，即根据员工所在位置来识别可以在那个地方完成的任务，而不是把员工分配到指定点去执行任务？

虽然企业架构师和软件架构师之间的这类信息交换并不是闻所未闻，但相比于过去却没那么常见，而这是移动授权成功的必要条件。

当每一种组合都检查过之后，具备最佳ROI或者长期利益的组合就可以识别出来，那一个就应该成为努力实现的目标。

企业架构师的角色

把新的员工方法转化为移动开发蓝图的第一步，一般都是由IT组织、软件架构师以及开发者承担的。许多用户认为，当企业架构师参与到移动授权新实践的框架中时，他们也应该在应用设计期间协调软件和员工之间的关系，并且在应用程序生命周期管理中提供必要的更改。新方法需要新的员工集成，需要新的合规要求和安全验证以及新的测试数据。在优化这些变更和减少错误方面，企业架构师的角色非常重要。

企业架构师还需要把移动授权视为通过自身实践出真知的机会。今天的大多数企业都有集成技术工具，这些工具不仅仅是到方法里面，还在架构层面植入到了业务实践上。这违背了一个基本原则，即架构应该描述业务流程而不是特定的工作方法或者IT授权的具体跟踪指标。移动性还显示出企业架构建模和开发之间的边界已经软化到区域而不是像一条线那么清楚，要想取得合适的成果，在这个区域内展开更大的协作是必不可少的。