2008年的经济变革给长期财务规划带来了巨大挑战，同时也激发了企业追求更高的生产率和效率，但是与此同时，企业也获得到了更好地响应和敏捷性。尽管移动性允许工作人员每时每刻都能对准目标，但是云计算会向工作人员提供他们所需的敏捷信息资源。为了有所改变我们必须充分利用高效的生产力、效率和敏捷性。

面向服务架构有助于IT技术业务转型，但是却产生新问题：

• 我们正从工作流时代转向时间驱动时代吗？
• 企业架构(EA)使IT模型变得效率变得更低了吗？
• 我们可以将应用程序视为松散的元素组合？

从IT技术变革的角度来看，面向服务架构(SOA)迈出了积极的一步。软件被组件化，并视为带有松散耦合的敏捷服务，增加到使用面向业务流程语言(例如 BPEL)的应用程序中。SOA已经保存了应用开发的集成模型，并使连接人员和IT元素的工作流更加灵活，以此解决业务中会出现的问题。然而其他技术也对SOA构成挑战，最大的障碍可能来自于最先推动业务转型的一方。

工作流与IT技术革命

个人电脑的出现，使得移动性成为生产力发展最重要的因素。通过一个简单的手持设备，工作人员就可以进入公司的资源，当然仅限于特定工作人员，而不是任意一个工作人员。

面临的挑战是,每个空桌子上有一个输入、输出盒子。这些盒子表明工作人员已经被工作流驱动；然而，正如在现实生活中一样，工作人员是事件的驱动力量。正如大多数架构师所知，SOA一直专注于工作流和编排工作。这是如何固定下来的？

答案是后端操作。现代化SOA应用程序并没有按照流程顺序逐次安排工作，而是允许流程事件并行运行，其中只需要掌握信息的传递关系即可。其目标并不是序列任务，而是要以某种方式完成业务流程的改变。

还会完成其他的事情吗？会有新服务吗？现在就可以运行吗？现在是手动调用吗？每时每刻现代化SOA流程都可以进行任何工作，而不需要按清单顺序进行工作，并且将工作提前化分为一系列独立的服务或事件活动。

IT模型设计与结构

第二个问题是EA影响软件设计和结构的方式。十年或者更久以后，人们会普遍认为EA应该专注于业务而不是IT工具。使用过几乎所有EA方法完成功能或流程设计时，EA和软件架构之间存在一种特定的传递。问题是，工具和业务流程都是处于被动活动状态——不考虑需要哪种设备支持的情况下你就不能构建出处理流程。

由于人们的思维方式，因此传统EA模型倾向于创建流水线式工作方式。这些流水线式工作方式然后固化成工作流，成为至今仍然使用的工作流程。然而，随着生产规划中移动意识的增强，这些流水线式工作方式在未来的生产中是不可行的。

我们需要做的是在功能/流程设计阶段找到EA和软件架构之间的共同之处。这么做的目的是要删除工作流中的特定概念，集中于工作者个人任务。

每个工作者都有事情要做，也需要使用一系列的工具。在构建业务流程中配对是很重要的，这一过程不是人们凭借想象而创建出来的。我们将提供给工作人员的服务投入到EA流程中，这样基于事件的输出结果会出现，并以服务为基础（而不是以工作流为基础）与服务相结合。

政府应该如何治理IT革命

如今正在使用的SOA通过网络服务描述语言提供了一种强结构化服务/流程输入和输出定义和业务流程执行语言（BPEL）。随着工作人员授权范围越来越以事件为中心，以及企业转向处理这些事件，因此，这些定义的严谨性会不够充分。特别是，一种纯以事件为导向的架构必须要么重新定义工作流概念，要么弄清楚如何将流程规则强加于断开式事件驱动任务集中。

由于服务会从工作流程中重新传入到支持工作者所需要完成的任务中，因此任务级别治理必须被视为与任务功能并行的服务。你不能在事件流程中同时进行治理活动，而是必须在处理事件的过程中进行治理。实际上，这就意味着，在服务背后存在一个治理层，该治理层提供了安全保障和政策协调。工作人员处理后的事件还要经过治理实践，因为它们将会成为数据库资源。

当将事件驱动流程添加到整个应用程序或者业务流程中时，同样要遵循这一原则。当工作人员完成任务时，他们实际上正在选择一系列必须做的事务清单。每次选择都会改变事件（也就是流程步骤）以后的处理方式。这种事件驱动的检验必须保证未来事件是已经被解释过的，而不是工作流的线性描述。通过事件驱动任务的积累来确保满足合规性需求，这样就可以在这一层级中加入治理工作。

不是所有的业务流程都是事件驱动的；装配线上会显示一些必须按顺序进行才有效的任务。然而，原有流程的变革需要引进新技术并对新工作实践进行思索。如果能勇于面对未来的挑战，那么SOA未来会占有一席之地。