除软件开发以外的信息

　　要把握如何权衡灵活性/质量，我们先要回顾一下软件开发的历史（比如说，十多年前），并完全去除脆弱的软件开发结构。任何SD项目都有三个主要变量：成本，时间和规模。其中的两个变量很容易锁定，而第三个变量则随着这两个变量的变化而变化。例如，如果你决定了成本和项目时间，你也许会交付项目的要求，也许不会之类等等。

　　要用这三个变量限定其它相关的变量，就需要一定得质量。换句话说，如果软件开发商想锁定所有的成本，时间以及规模，剩下的就是布置后的质量问题了，我要说的是，SD三角结构实际上是方形的，质量就是其第四个顶点。

　　SOA项目四者之间的关系就不尽相同了：他们在等式中有添加了灵活性，这样就变成了五边形，正如下图所示，下边较低的三个点构成了传统的SD三角结构：

　　现在我们假定的情况是这个SOA质量五边形向人们展示了五种方式的对称，你可以通过其中的一个变量来锁定其它四个变量，但是如果仔细观察的话，你会发现情况并非如此简单，实际上在这个五边形之上还嵌入了一个三角形结构，这个三角形向我们展示了SOA质量的一些基本原则。这个三角形将灵活性，质量以及时间三个要素联系在一起，这就是我们所说的尽其所能SOA三角，因为其它展示了我们在上文中提到的美国国防部当前所面临的问题：SOA实施越灵活，就需要更多的时间保证质量。如果保证质量如此耗费时间，实施的灵活性也会受到威胁。

　　将SD三角形和尽其所能SOA三角形一起放入SOA质量五边形当中，不能使我们得出这个结论，即通过改变第五个顶点而决定其它四个顶点。因为时间限定了我们能够实现的最大灵活性。结果是，我们无法确定的两个顶点是那两个不在尽其所能三角上的顶点，即规模和成本。换句话说，如果我们在依据尽其所能三角的基础上可以确定所需的灵活性，质量，和SOA项目所需的时间，我们就可以通过调整规模确定成本或者，通过成本确定项目规模。

　　结论很明显：要想在业务所需的灵活性和质量之间保持平衡，就要在SOA措施中采用迭代方法，每一种迭代都是由规模和成本所决定的。因此，SOA项目和传统的SD项目的不同之处在于，包含时间的迭代（即时间顶点已被确定）是不切实际的，因为时间的封装并没有被当作灵活性对产生质量影响的一个要素，相反，尽其所能SOA结构的一大特点就是时间顶点取决于灵活性/质量之间的平衡。

　　ZapThink采取的措施

　　也许这里所学到的最重要的课程和以上得出的结论不同：“宇宙大爆炸 ”如果SOA项目以非迭代的形式实施抛弃了全局性，企业范围内的SOA方法，就可能牺牲灵活性/质量之间的平衡。因为相应测试所需的时间就会对灵活性有所消减。只有当灵活性不是要求以后，这个大爆炸项目才会在理论上具有可行性——但是是不是所有的SOA措施都有一定的灵活性要求呢？否则，你怎么会最先考虑SOA呢？

　　你也许要说一个表面上一个没有灵活性要求的SOA项目实际上是一个集成项目，因为这里不需要松耦合服务。不幸的是，我们总能看到这样的项目：一些机构认为它们可能因为一个原因或者其它原因实施SOA，而不是考虑首先购买 ESB或者其它集成中间件或者交付成为大型大爆炸集成项目。这种混乱就会导致业务风险承担者因为缺少灵活性而绞尽脑汁，并担心自己可能没有从中获取到期望的业务价值。因此在SOA中采取迭代措施可能是避免这种不良后果的最佳办法。