许多学生在学习Licensed ZapThink Architect(LZA)课程的过程中，当我们一点点的改变了他们对面向服务架构的看法时，经常会发出“原来如此”的感叹。可能最让他们感到惊奇的是当他们意识到SOA实施不再是传统系统工程学(TSE)，而是处理IT环境复杂性的一种完全不同的方式。这种新思想为那些有着多年传统系统工程学(TSE)背景的人指引了一片更为广阔的天地。这种思想变化的核心就是：传统工程学侧重用小组件建成大系统。然而这些系统则完全依赖这些组件的功能，尤其TSE可以被视为一种思维方式即将分散式数据处理看做是相互联系的一组事件，而集成化则是其核心内容。集成的最后结果也就是你所预期的最佳结果。

　　而SOA则需要一种完全不同的方法。在SOA环境中，我们关注业务服务抽取的建立和维护，当业务组成服务支持基础动态业务流程时，业务服务抽取也会为那些无法预测的工作状况提供支持。我们在做SOA时，是求新求异，而做TSE时，则是追求稳定和稳妥。单靠稳定性，业务只能做到这个地步，如果机构对业务灵活性有要求，最好还是采用SOA。

　　作为资产的业务灵活性

　　ZapThink将业务灵活性定义为能够在业务环境下快速的对变化做出反映，并将变化变为自己竞争的有利条件，对于SOA来说，这是最主要的战略动机。那么什么是SOA？SOA如何能够实现业务灵活性？TSE做出的系统功能完全依靠组件的功能。而SOA实施中单个要素：包括服务，服务组合，策略，合同多少都会影响到灵活性。尽管它们本身并不能体现灵活性。

　　我们并不把特定系统所展示的特性称为资产，我们将展现资产称为复杂系统。复杂系统这个理论是最近的热门话题，资产包罗万象，从摩擦到交通堵塞再到人脑，复杂系统这一概念帮我们解释了许多深奥复杂的问题。

　　复杂系统工程学：实施SOA的关键

　　用理论解释自然现象是一码事，建立复杂系统则是另一码事了。我们将这项措施称为复杂系统工程学(CSE)，如果你要设计一个系统，如果你所希望的结果是一个类似业务灵活性的资产，那么TSE就不管用了，你需要采用CSE。事实上，当设计师实施SOA时，必须使用这种方法，业务灵活性是一项至关重要的emergent property，在很大程度上定义了SOA成功实施的标准，如果能充分利用复杂系统这项措施，能帮助我们更好的交付业务灵活性，更重要的是帮助我们躲过阻止SOA实施的项目障碍。