·第四阶段——技术架构。架构小组会开发一个基准线和目标技术架构，进行支持已有架构视图的缺口分析，决定SOA基础设施组件，例如SOA中介物，或者SOA治理平台。

　　·第五阶段——机会和解决方案。通过识别交付工具（项目、程序、组合），架构小组将在这一阶段完成架构定义。这些识别交付工具可以有效的交付他们在先前几个目标架构识别的目标架构。

　　·第六阶段——迁移规划。第六阶段的重点是和项目经理一同创建可行的实施和迁移。我们会在这个阶段为SOA措施设计全景规划，因此这个阶段涵盖了架构和实施阶段。
　　·第七阶段——实施治理。

　　·第七阶段将通过架构合同，建立架构和实施之间的联系，该服务合同可以帮助我们观察整个架构，同时检查实施情况。确保架构按照设计需求实施架构，对于SOA措施和其他的架构措施同样重要。这一阶段的活动将会对齐实施与业务目标。

　　·第八阶段——架构变化管理。架构变化管理的目标是要确保架构能够实现其原有的目标业务值。这一目标包括以紧凑的架构方式管理架构变化。为了保证持续对SOA措施进行架构描述，需要实施变化管理，这样机构便可以快速的对业务和技术变化做出回应，这样的变化往往会影响SOA实施。

　　·架构请求管理阶段。请求管理流程一直在驱动ABM。架构经常处理业务驱动器和约束条件，从本质上来说，这些都是企业所无法控制的（不断变化的市场条件，新法律法规的出台等等），缺乏控制就会产生许多无法预测的变化，ADM对于业务要求的关注对SOA措施的成功实施有着重要的影响。如果将架构定义以及实施与业务要求对齐就会实现业务目标，使整体措施的期望值得以实现。

　　不要指望TOGAF能够解决你所有的SOA问题。但是可以期望ADM能够为你的架构工作提供结构。在SOA环境下使用TOGAF可以带来的收益包括：

　　·TOGAF为SOA提供了一种架构方法。

　　·TOGAF ADM覆盖了SOA整个生命周期。

　　·使用像TOGAF ADM的标准方法可以降低项目风险。

　　·TOGAF可以更好的将业务策略与优先顺序对齐。

　　TOGAF内容框架的作用

　　除了ADM以外，TOGAF的最新版本包含了一个内容框架，通过该内容框架，可以帮助我们构建并设计架构成品。

　　当定义服务模型、目录和注册表时，可以参考内容框架，它所提供的元模型可以帮助架构小组描述并编目服务，同时将服务定义和业务架构整合在一起。在元模型中，业务和IS服务相互分离，这已经成为了一种规范，同时也高度重视对于IS服务的部署，部署IS服务支持业务价值的。

　　同时TOGAF也为内容元模型提供服务扩展，除了业务服务的核心理念之外，还创建了IS服务概念，这样可以更为准确的模拟服务组合。应用直接支持IS服务，创建IS服务抽取层，这样可以放松对业务范围的限制，同时风险承担者也能赋予IS服务目录形式。内容元模型还指导SOA实践者如何定义服务目录，如何将服务定义整合到全部业务和解决方案架构当中。

　　ZapThink采取的措施

　　TOGAF是一种通用的架构框架，并不专门针对某一个具体的行业、架构模式、布局或者技术。通过进一步了解，我们认识到业务和技术团体都可以开展SOA措施，每个小组的侧重点不同但是他们的活动是互补的，并且在服务理念这一点相交。因此TOGAF的实施需要顺应当地的文化以及机构的管理流程，同时还有架构模式以及技术策略。

　　开发小组的现有策略是令ADM类和其他模式的扩展以及SOA保持独立，这些具体模式的扩展往往局限于某个单独的章节或者单独的文档，例如开发小组SOA工作组出版的SOA源书，ADM中包含了SOA实践的许多方面，尽管还没有和SOA最佳实施完全对齐。

　　在SOA措施中，你是如何决策，到底用还是不用TOGAF ADM呢？如果你已经采用了SOA方法，并且这种方法行之有效，那么ADM短期内无法增加业务价值，但是这并不影响你对ADM做出评估，你能够从TOGAF上学到很多有价值的知识，但是如果你还没有采用SOA方法，或者在实施SOA的过程中遇到了问题，这时候就需要考虑ADM了。这时你需要投资很多时间和精力学习并修整ADM，但是和长期取得的收益相比，这一切都是值得的。