曾几何时，企业架构师要为了得到承认和支持而抗争，但这种时候正在过去。大多数企业现在已经意识到实现业务流程中敏捷性和效率需要业务目标、人力资源以及信息技术的结合。

EA的角色已经拓展，从关注于将业务流程映射为抽象转到映射为工作、工作流以及工作者的生产力。重要的一步是将软件架构设计引入EA里面，为了做到这一点，需要意识到软件架构演进的关键要素是工作流概念的转移，然后在EA规划当中进入事件驱动的概念，再按照领域将事件映射为IT服务，并将IT服务映射为软件架构、实践以及产品。

在典型的EA方法论中，架构师聚焦业务流程为建模的最后时刻。这种办法跟面向服务架构、服务总线以及工作流处理可以很好地对应，后者直到最近都还是软件架构设计的中流砥柱。但互联网和云计算的引入侵蚀了IT对“工作流”愿景的支持。今天，优选的方案是把软件考虑成一组临时搭配的微服务组合，这样可以服务于每一个员工的产品需求。在这种软件模型下，软件激活的驱动力不是线性流，而是事件。

尽管“业务流程”就是“业务流程流”的概念与事件结构或者说微服务架构存在脱节似乎十分明显，但却没有充分反映到大多数的企业架构方法论上面。EA的业务流程输出往往是前置到业务流程流里面，在把EA需求转化为IT需求时往往倾向于工作流思维。事后再把对基于云和微服务的现代软件架构演进和设计方案的理解放到今天的EA方法论里面不是不可能，但很难以一种一致且有组织的方式来做到。要做到这一点，开发者需要拒绝把业务流程视为EA的最后一环的观念，相反要聚焦到业务事件上面。

理解业务事件

在逻辑上企业已经是事务驱动的了，这意味着它们要对外部事情，如下订单来做出响应，然后产生其他东西来驱动合作伙伴活动，如下达发货通知等。这些都是业务事件，也是一切业务活动的常见驱动，从这些来看，它们是EA的一个合理的关注点。但是今天的EA更多的是描述流程而不是事件，而这种流程描述会把EA跟可能已经过时的软件架构设计绑定到一起。

业务事件是企业的驱动力或者是一个企业对另一个企业的输出，对它的描述要依据它在业务上代表着什么而不是用它来做什么来定义。它是事件树的起点而不是转发流。每一个事件或者事务都会催生出一系列必要的内部事件和事务。比方说订单可能会缠身“存货检查”事件和“信用检查”事件。这些都可以表示为初始事件的分支，跟往往描述事情顺序的传统EA流不一样的是，事件树仅聚焦于关键关系上。

可视化为事件树“森林”的业务能够为软件架构设计提供有用的洞察。比方说，许多主要事件都会自然而然地滋生出一批相关的二级事件—信用检查、客户订单管理甚至CRM这些都是相关的二级事件。这些关联事件在业务功能的层面上组成了领域，反过来也会成为固化的企业架构与软件架构的连接点。事件驱动EA把架构从对工作流的依赖中解放了出来，而领域则在独立事件分析和软件方案之间建立了连接。

区分领域责任

大多数领域相关的EA讨论聚焦在不同类型的领域上—比方说，安全、信息、IT基础设施以及网络等，许多组织在IT侧也都有这些领域的体现。这意味着把EA跟软件架构绑定是功能性和架构性IT域的联合。功能性领域专家应该放到EA组织内，从属于总体EA，而架构性领域专家则应该是IT组织本身的一部分。

功能性领域需求之汇总应该形成对软件架构设计的泛化模型的要求，然后提供给结构性领域专家选择。大多数情况下都会选出一个泛化的架构给软件，其中包括一些调优以及每一个功能领域的功能相关的映射。这意味着软件架构设计可以形象地看作是“两种类型的领域”的集体回忆来商定总体框架，然后再由每一位功能领域专家和结构领域专家开会确定设计。在经过最后的团队评审之后，领域映射的最后一步就是转化为软件设计和技术选择。

挑选你的流程

这一方案可以用各种办法实现当前IT模型的演进。方法之一是让领域专家检查传统IT方案与新策略的差异来对过程提供指导。由于你原来的EA各种可能是以业务流程为终结的，所以那些流程可以被视为功能性领域，而架构性领域专家然后就可以根据每一个功能性领域的新方案来调整步骤。这种做法适合于较早建立的事件树在EA模型旧的业务流程终结点之间存在最少的交叉时使用。

如果新的EA模型会将IT变革为一组广泛分布的服务时，最好的办法是看看每一个旧的业务流程，从中找出哪个映射到新的事件树最容易。也就是说要找到包含一组事件单集的流程。这些流程可以转化为事件驱动模型，所得结果将会用来做出可用于选择后续EA业务流程目标的服务的详细清单。

这种软件架构演进最关键的一点是不要掉进过去的陷阱里面。EA软件架构设计的影响极其重大，因为它改变了员工可以利用的工具。事件和服务驱动方案的灵活性依赖于对当前的IT流程解耦，而不是不经意间延续下去。