企业架构（EA）和应用生命周期管理（ALM）在很多情况下都是共生的。通过正式化业务目标、流程和信息技术之间的关系，EA可以轻松地建立治理政策，这可以放入到功能和性能的标准中，通过ALM发布的管理规则得到加强。

伴随着这个幸福联盟的一个问题是应用变成了组件，可以自由地用于多个任务中。使EA连接在ALM上很难，因为应用程序的单独组件的附件可以改变所有。IT和EA专业人士可以使用虚拟应用来连接EA和ALM，从而改进两者的治理和应用质量。

在给EA和ALM之间和组件和治理之间建立联系时，大多数公司都对继承很熟悉。应用程序有一组通过EA环境创建的治理政策，并且组件继承了这些政策。组件重用创建更多的继承，但是随着应用程序变得更加组件化，以及大量的继承规则的曝光，管理这些政策变得越来越困难。

因为在组件世界中，应用程序实际上就一个虚拟概念，它可以使用虚拟化/抽象原则来找到走出继承困境的路径。定义虚拟应用的目标是基于在信息化工作类别中，用户是如何区分的，以及联盟IT在全组织范围内是如何定义信息信赖的。虚拟应用然后可以用于设计基于治理的ALM实践。

如果你的公司已经创建了EA/治理和组件之间的继承映射关系的话，那么你可以从这一过程的结果开始。忘记当前应用的界限，聚合基于常用连接的应用组件到业务流程和业务单元中。这往往可以通过收集组件和常用治理需要来完成。结果就会在功能上富庶虚拟应，以及支持常见行为的组件。

企业架构的演进

如果继承映射已经失控，或从未成功，那么创建虚拟应用的最好方法是从上到下遵循EA的发展，如以下：

1.业务目标给业务流程要
2.业务流程给技术/信息支持活动的功能等级
3.功能支持给它提供的组件

从功能支持关键级别上看，大多数EA模型将把业务功能连接到技术功能上，这就是虚拟应用发挥的作用。无论应用的当前结构化如何，看待一个应用的逻辑方法是组合起基于业务功能映射的组件。

统一用于支持常用业务应用的组件是虚拟应用的一部分。你可以为运营/职能组命名虚拟应用，这些可以在EA中已经命名过。要指出的是，完成这一工作在一定程度上取决于特殊的EA模型的使用，但所有模型都将遵循这里描述的流程。

在给ALM创建基于EA的虚拟应用时的另一个工作是具体的IT元素，这些元素参与的联盟IT架构，并通过EA曝光/开发。联盟IT通常用于EA模型来分散业务（这些业务作为独立单元进行操作），从而是定义信息和技术组件共享的方式。

EA人士和IT架构师都报告说，与联盟IT关系有关的组件通常既支持水平功能，如工资和人员，还支持高水平的业务目标。在许多情况下，聚合一些围绕在组件周围的组件会创建出一个优化了的组件驱动虚拟应用集合。对于虚拟应用创建来说，联盟IT方法还可以用来对继承或稍早描述的流程驱动机制的结果进行复核。

满足业务目标

当你有了虚拟应用集合，那么下一步就是把这些应用与你的“真实”应用对齐，并使用简单的图表展示在电脑上。这将会做两件事：帮助把虚拟应用ALM与真实应用关联起来，并告诉你你的真实应用是否已经很好的结构化，来服务于你的业务目标，就如你的EA模型定义的一样。

在真实的应用程序边界没有对应到功能/操作虚拟应用边界的地方，那么你的软件就不会很好映射到业务流程上，这样在你进行重新思考你的软件解决方案时就会受益。跨多个虚拟应用的应用程序表现出一种明显的横向技术方向，它可能不适合自己垂直市场的特殊需求。

一旦你有了真正的/虚拟的应用关系图里，你就可以决定是完全在虚拟应用中设计ALM，还是在真实的应用中，还是在两者都用。公司报告称哪里的组件重用的级别高，那里的虚拟应用ALM就更有意义，因为虚拟应用更好满足了业务功能，并促进了测试和治理。

在ALM实践中，哪里通过真实应用组件重用率低，那么你就要密切注意那里的组件化趋势了，而且随着时间的推移你也关注真实与虚拟应用之间的关系了。组件中的一个转变将会很快速好改变你的ALM平衡，更倾向于虚拟应用映射。

一些尝试过虚拟应用方法的用户抱怨说，通过加强一致性测试和对给定的组件改变的验证，它增加了ALM的复杂性。这根本不是事实；正确ALM必须在他们的业务上下文中测试应用程序，这是组件重用创造的复杂性。虚拟应用只是揭开了复杂性，和这是一个更好的结果，总比在ALM实践定义中忽略业务问题要好。