面向服务架构（SOA）是一种架构模式，开放组织架构框架（TOGAF）是一种架构框架。将二者结合在一起似乎前途一片光明，但是现实生活中真的是这样吗？开放组织肯定是这样认为的——许多开放组的成员一直在努力将两种概念结合起来。很多成员也在SOA/TOGAF实用指南项目上花费了大量的心血，这一项目是SOA工作组在开放组方面实施的众多项目之一。

　　SOA/TOGAF实用指南项目意在TOGAF架构开发方法中开发具体的SOA扩展，该TOGAF架构开发方法是TOGAF组成的核心部分。该实用指南项目的原理是：如果SOA是一种架构模式，这样就有可能利用某种具体的SOA活动和可交付投递，扩展风格独立的TOGAF ADM方法以便生成一个服务定向ADM。

　　为什么SOA专业人员都对TOGAF感兴趣呢？如果你把SOA当作一种技术而不是一个架构，这样在架构框架中就看不到任何价值了。即便把SOA看做是一个架构，你也只是觉得自己在开发并实施SOA,并且在这个过程中没有得到来自TOGAF的任何帮助。那么TOGAF到底有哪些作用呢？

　　在SOA开发和实施过程中使用TOGAF架构开发方法（ADM）

　　例如，美国国防部多年来一直在使用TOGAF，TOGAF已经成为架构开发的行业标准，并且涵盖了许多开放小组成员的成功经验，今年发布的TOGAF 9在TOGAF 8基础上做出了更大的改进，例如可用性增强，更为关注企业整体变化，输入的协调性大为提高。TOGAF9还增加了一个模块结构，内容框架（赋予架构模型和架构定义结构），并扩展了对企业内部TOGAF的指导。

　　此外，TOGAF 9还考虑到了架构模式，尤其是SOA。TOGAF 9中专门有一章是关于用TOGAF来定义和治理SOA实施的。本文主要将SOA看作是一种架构形式，并且重点关注那些和SOA的使用以及布置相关的要素，SOA和TOGAF之间的联系以及服务合同的定义和结构。

　　TOGAF ADM代表了一种“麦田里的怪圈现象”，从初步设计阶段开始，机构建立并开发了一个架构，然后陷入了以需求为驱动的架构开发怪圈，最后是架构变更管理阶段，在这个阶段，机构会对新架构做出修改。

　　我们快速浏览一下ADM，并仔细观察SOA究竟可以从TOAAF借鉴到什么。

　　初步设计阶段。初步设计阶段就是一个架构小组要设计架构的阶段。我们可以根据企业和架构小组的具体需求指定ADM。这些需求也包括SOA这种架构模式。

　　第一阶段——架构视图。架构小组要在这个阶段定义架构项目的规模，风险承担者以及架构视图，还有继续授权，以便明确这一措施的业务目标，得到业务风险承担者的补仓。

　　第二阶段——业务架构。架构小组要在这一阶段开发出一个基准和目标业务架构，并进行支持已有架构视图的缺口分析，这个阶段的重点从SOA转移到了义务需求的决策以及业务服务的认证方面。

　　第三阶段——信息系统架构。这一阶段解决的是应用和数据架构问题。架构小组开发基准和信息系统（IS），进行支持已有架构视图的缺口分析，架构IS服务，并将它们与业务服务相关联。这也是此阶段SOA活动的主要方面。

　　第四阶段——技术架构。架构小组会开发一个基准线和目标技术架构，进行支持已有架构视图的缺口分析，决定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实践者如何定义服务目录，如何将服务定义整合到全部业务和解决方案架构当中。

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

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

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