在IT和软件开发中，SOA生命周期的定义与生命周期这一术语的传统用法有所不同，Infravio公司技术标准副总裁Miko Matsumura如是说。在讨论SOA时，生命周期这一术语的不同涵义可能会引起混淆，尤其是在他感兴趣的领域—策略和治理中。虽然，这似乎仅仅是关于术语如何定义的争论，但是，根据他的反驳，在高层大范围的SOA生命周期中，对策略生命周期的关注能够为业务提供更具优势的竞争力。

　　为了澄清原因，Matsumura写了一份50页的关于SOA生命周期治理的白皮书。在分析讨论SOA生命周期时，他将其分为三个部分:

　　·设计时，当把服务集合起来形成商业应用程序时
　　·运行时，当SOA实现已经能够工作、并且商业活动已经开始时
　　·变更时，当为了利用SOA的敏捷性承诺，商业需求改变导致发生不可避免的变化时

　　然而，与开发人员熟悉的、传统的软件开发生命周期(SDLC)相比，这个SOA生命周期很少或者几乎没有类同之处，Matsumura辩解说。

　　“有点讽刺意味的是:软件开发生命周期(SDLC)与SOA生命周期居然没有一点重合之处，”他说。“传统的软件开发生命周期(SDLC)是开始于某种设计或者蓝图。从本质上说，结束于服务或者软件的配置。如果是SOA项目中的服务，那么，在某种程度上，公开发布事件是生命周期结束的标志。我知道，某些开发人员了解软件开发生命周期(SDLC)包括更多的含义。但是，我认为，一些传统的开发人员可能会认为配置就是生命周期的结束点。完成配置时，他们会欢呼:‘好了，我们完成了，欢呼吧!’”

　　在Matusmura看来，软件开发生命周期(SDLC)的结束点正是SOA生命周期的开始点。他认为SOA设计时是SOA生命周期的第一阶段，而且，他对设计时的定义包括——把当前发布的Web服务组合起来，成为商业应用程序。

　　“我知道，甚至有一个更早的阶段——人们构建架构、制定计划、画出宏伟的蓝图，以及讨论互操作性、标准、安全和其他事项，”他说。“因此，还存在着一个架构设计阶段。”

　　但是，在他看来，SOA生命周期是从“SOA设计时”开始的，而这个架构设计阶段是开始之前的初始阶段。

　　“SOA设计时实际上包括:找出等级较低的服务，并把它们组合成为商业级服务，”他说。“因此，这并不同于一般意义上的设计。”

　　SOA设计时引导SOA运行时和变更时，SOA变更时结束就完成了生命周期。生命周期是需要从外部进行观察，Matsumura说，SOA生命周期包含着两个方面。第一个方面更为明显，就是Web服务的生命周期包括设计时、运行时和变更时。但是，当他谈论到SOA治理时，他辩解说，策略层有其自己的生命周期，但在SOA实现中，这一内部的生命周期却常常被忽略。

　　“这一层有其自身的生命周期，有其独有的设计时、运行时和变更时，但是，这一层却是经常被人们忽略的，”他说。

　　策略也需要被设计、运行和变更，而且它是处于策略生命周期中的，Matsumura坚信对SOA敏捷性的承诺一定能够实现。维持策略生命周期以及快速变更的能力能够提供有竞争力的优势，他说。

　　“从相反的角度来思考的话，在策略方面，你基本上可以作为公司参与竞争，”他承认。

　　注意到，在SOA应用程序中的商业活动会受到策略治理的限制，如它们如何与商业合作伙伴交流。Matsumura说，因为策略治理能够确保商业活动按照一定的规范进行，所以，这并不是一件坏事，正如他举的例子“火车不仅是按时运行，而且也要按照轨道运行。”

　　在他看来，SOA的敏捷性需要——Web服务活动的操作必须要有策略的限制。

　　“Web服务活动有可能会是敏捷的、灵活的，但是没有策略的限制，它也有可能会非常糟糕、完全失控，”他讽刺地说。

　　我们拿铁路来类比，如果商业大环境发生变化的话，通过维护一个策略生命周期，一个组织就能够快速切换到另外一个轨道并且采用不同的路线。

　　“如果你的约束模型比其他公司的适用性更强，灵活性更高，那么，你就可能具备了一个可以保持的、有竞争力的优势，”他说。“随着情况的改变，策略需要改变，而且活动流也需要改变。但是，所有这些变化都是为了保持你的目标的一致性。”