介绍敏捷模型

　　在理想的敏捷模型中ZapThink所提倡的是一个对个别SOA实现的敏捷性的灵活度容量测定的措施。而不是为了用成熟度的任意五个层次衡量一个工程，这个成熟度模型假设是顶层最好的，它的初衷是想衡量业务和这个工程目标的敏捷性。

　　按1到5的级别(像几乎所有成熟度模型一样)衡量敏捷性是无针对性的练习。不是简单地把所有面向服务的工程都放到和别的工程一样有相同敏捷性的层次。有些工程要求深层次的松耦合，可能包括我们之前讨论松耦合的七个层次的ZapFlash中所有的层次。既然每个耦合层次在复杂性和有效性的潜在开销上加入了灵活性，其他工程可能就不需要这么多的松耦合层次。好的架构师知道什么时候让服务和流程轻松地充分耦合来满足业务需求和敏捷性的原需求，但现在已不是这样。照这样，我们就应该考虑将敏捷性的衡量看作是一连串的分类，它结合满足业务需求的期望的敏捷层次。

　　照此而言，公司应该争取“最佳的”,也就是次优之外的。说的明确些，如果一个业务瞄准一个特别层次的敏捷性，但这些工程已经以一种比期望更灵活的方式被实现，他们很可能被过度工程化。同样，不能达到期望的敏捷衡量的工程是次优以及正在进行中的工程。一般来说，一个系统越敏捷，就越昂贵，所以对一个能够区分敏捷性需求优先级的组织很重要，以便这些敏捷性需求能决定支付哪个来使其满意，给予预算和其他约束。照此而言，我们不推荐合作范围内的敏捷模型，因为那会对不同时间和组织内的不同部门的敏捷性和有各种各样的需求。

　　回答敏捷性模型的关键问题在于如何衡量敏捷性？一个衡量敏捷性的方法是确定各种自由性和允许有问题系统的变异性的度数。考虑这些敏捷性衡量，自由性和易变性的度数越少，作为整体系统的敏捷性就越少。根据松耦合七个层次作为出发点，可以建立下面这个基本的敏捷模型：

• 　　实现的变异性——相对于实现变更，位于成熟度衡量底部的工程是非弹性的，然而，顶部那些则允许对服务消费者和生产者在不影响彼此的前提下改变。
• 　　基础设施的变异性——在松耦合方面呈现较差敏捷性的工程都严重依赖当前基础设施来为SOA基础设施提供所有需求，然而这些显示敏捷性的工程能够任意调节变更，替换，或在不忽略干扰情况下附加基础设施。
• 　　契约的变异性——在这个系列最末端的工程不允许对服务契约做灵活的变更，而在另一端的则不受变更的影响。
• 　　过程的变异性——在这个敏捷衡量底部的SOA倡议不容许动态和连续过程变更，而在顶部的则能处理任何新过程的变更或配置需求。
• 　　策略变异性——对于策略变异性来说，呈现弱敏捷性的SOA工程只能通过二次开发，重新部署，甚至基础设施变更来处理策略变更，然而这些显示最佳敏捷性的SOA工程能处理任何策略改变或新策略需求的灵活性。
• 　　数据结构的变异性——呈现较差数据结构变异性的SOA倡议不能对数据表示法调节变更，然而显示最佳敏捷性的SOA工程不必在重构服务消费者和提供者的情况下处理变更。
• 　　语义的变异性——相对于信息语义含义的改变而言，在这个系列最底端的工程是弹性的，然而哪些显现最佳灵活性的工程能够在不需要人为参与的情况下处理不同系统间语义的差别。

　　以上分析的结果是分类的热图。每个工程都将呈现某一个层次上可能更灵活的敏捷特性，然而另一个就很少。这个关键在于不是为了对所有衡量都达到敏捷性的最高层次，而是为个别SOA工程创建敏捷模型，并和特殊工程或更宽泛的敏捷模型对比，这些更宽泛模型作为后续所有SOA工程的基线。从某种程度上来说，这些公司就能像为工程计划和审计测量一样来使用敏捷模型。这些公司也可以选择和在同行业中或跨行业中的公司对比，但是这显然不是敏捷建模的目标。

　　当然，为了确定敏捷性的层次，1500字的ZapFlash很难真正地总结机制和方法。ZapThink已经在计算和上面敏捷模型的度量上建立了重要的知识和知识产权，这些敏捷模型和帮助公司为它们的战略和各个工程基础业务建立的方法论一样。如果你想为你的公司成功地应用敏捷模型，你就应该把它作为工程计划工具与审计测量工具一样对待，牢记工程在某一个层次应该是灵活和敏捷的，但在其他层次不是。这个观点没有达到某些抽象的“顶层”衡量，而是达到最合适的。这个秘方是确定你最佳状态，并找到衡量企业内分布式工程的具体方法。