无论流程是由正规的SOA原则驱动，还是通过将Web、应用及数据库工具组合来创建客户门户的，IT专业人士面对的都是一个多组件应用构成的世界。这些组件往往在一个以上的应用中被用过几次，意味着简单的应用治理模型已经不再可以有效运作。

为了对多组件应用进行治理，IT专业人士必须从基于组件的治理模型开始着手，建立一棵受应用生命周期管理驱动的依存关系树，然后组织治理实践，挑选工具来适应这一以组件为基础的框架。

大多数IT治理都是以垂直集成的多层模型为基础的，就像Federal IT用过的那样。该模型以战略/业务目标为开端，往下是功能域的战术/运营目标，包括为一线运营部门提供的IT和IT支持。大多数情况下，这一框架适合于对多组件应用的治理，至少可以下至功能/运营层。实际上，任何对应用设计/结构的依赖到了那种程度都将成为治理计划设计不正确的指示器；实现细节不应该出现在需求的层面。此处的窍门是让功能/运营目标与组件和应用相适应。

为针对重用设计的组件设立治理目标几乎是不可能的，因为大多数公司部署应用是为了支撑运营使命。哪怕是一个多组件应用也会从功能/运营层的合规计划中继承自己的合规目标。然后这些目标再转移到组件身上。

组件化应用的不同在于每一个组件从每一个用它的应用处继承合规要求。这是现代软件合规管理中额外的一个关键维度。

多组件应用的合规性

多组件应用引起的主要合规性挑战是，变更出现在组件而非整个应用上。新的组件可被追加到应用中，马上就会改变治理需求或引起问题。

当组件做出软件变更时，在每一个组件使用的应用中的治理实践中，这些变更必须做出反映。为了抓住这些变更，并在合规/治理中解决他们，把从应用继承到组件中的治理目标引入到组件级的ALM流程中至关重要。

要想处理组件变更对治理实践的影响问题，最容易的方式是建立组件与应用的关联关系图/树，然后在功能/运营层加以治理。既然多组件应用的有效ALM必须反映每一个应用的组件构成，因此从ALM过程这里应该很容易获得信息。

一旦组件/应用关系图与治理策略在功能/应用层关联到一起，就有可能评估每一个组件变化并将其与可能受影响的治理策略关联起来。如果你是从图开始的，那就从组件开始画线，向上连接到含有该组件的应用，再到治理计划的功能/运营层，你就会识别出受影响的应用和实践，知道从何开始验证这些变化的目标及合规性影响。

广泛的组件化至少会导致上层传统的治理模式中的部分治理变化。这意味着当你考虑组件化应用的治理工具时，不要去找仅处理问题的微观部分的端点解决方案，而要去找能全面处理整个治理结构的工具，这一点很关键。

兼容SOA的治理工具

IBM、Oracle和SOA软件提供了知名的兼容SOA的治理套件。Open Group SOA Governance Reference Model （SGRM）是SOA组件化的一个很好的选择指南。SGRM原则可应用到非SOA组件化中，但是检查一下采用此类应用时有多少治理工具有用很重要。

针对不按SOA原则开发组件的治理工具最大的问题是，它们不会在建立组件功能及接口和帮助识别应用组件构成时检查Web服务描述语言（WSDL）。这是为什么将组件化治理与ALM策略关联起来绝对至关重要的另外一个原因。

ALM策略充当了将组件及组件在应用中重用的信息集中化的一种手段，这些信息在收集治理需求和跟踪组件变更的治理影响时都是必不可少的。如果你依赖于非SOA（RESTful）组件化，ALM是你填平可能会出现的严重治理鸿沟的机会。

对于那些必须适应大规模非SOA组件，要寻找多组件治理自动化支持的人来说，最好的办法是看看ALM策略与DevOps工具的集成。流行的DevOps工具Puppet和Chef可用于自动化ALM流程。

如果模型/脚本是针对记录和强制组件与应用关系而设计的，那么就可以被用于维护足够的组件化（甚至非SOA组件）信息来提供与治理的关联。可能按照Web模式（RESTful）而非SOA模型建立的组件化应用会扩散，随着时间的推移，这会鼓励把工具的选择面放宽，而不是更为针对性的治理工具。

随着无状态、松耦合的组件Web模型接管了企业应用，多组件结构正处在不稳定的状态。移动化和云可能还会加速这些变化。

那些相信SOA框架本身就能解决多组件治理问题的人会越来越失望。从当前的治理模式开始，通过利用类似SGRM的SOA治理结构，在ALM和DevOps中采纳Web模型组件，IT架构师就能管理好现在并同时准备好迎接未来。