面向服务架构（SOA）的概念已经成为一个非常时髦的技术术语。尽管技术确实扮演了重要角色，但是正确的SOA方法要求对软件开发方法进行重新设计（或重构）。我们习惯采用基于组件或基于项目的方法来进行应用程序开发，但是SOA要求采用自顶向下（top-down）的方法。这意味着我们应以全新的眼光来看待应用程序设计和项目管理。

　　让我们来探讨一下成功实施SOA的非常重要的10个关键要素。

　　1. 企业架构团队

　　SOA是企业范围的长期战略。因此，大多数公司都通过成立中心团队（企业架构团队）来实施SOA，该中心团队掌管并向前推动SOA。在大多数情况下，该团队是一个小而严密的工作组，具有多样且互补的技术，掌管企业的总体架构。企业架构团队负责制定内部标准、蓝图、参考架构、设计模式、模板、一些共享和水平服务等。它与业务线专家紧密合作，或者拥有领域专家作为该团队的一部分。这个高瞻远瞩的中心团队对于减少各个工作组和部门重复开发工作策略以及制定其自己工作方法的风险十分重要。

　　企业架构团队是成功实施SOA的最关键要素。没有一个理解如何操作和掌控SOA的优秀团队，实施SOA的工作很难成功。

　　2. 实施路线图

　　一旦成立了企业架构团队，接下来的主要任务是与业务和IT团队合作，然后制定实施路线图。就像任何一个好的项目，计划得越细致，成功的机会就越大。

　　一个常见策略是开始创建当前状态和未来状态的文档，这些文档使得查看整体情况和理解系统的交互变得更加容易。这一方法还能帮助确定哪些是公司“痛点”的系统。

　　下一步是确定可行的里程碑（在大多数情况中，为6个月、12个月、24个月或36个月）。

　　一些遗留下来的关键任务系统会随着时间的推移而修修补补，包括“粘缝在一起的借助于绷带”的解决方案。像这样的系统就是定时炸弹。有时候，这些就是实现SOA的很好的初始候选项目。通常，根据系统功能的紊乱情况如何、修复它的可行性如何以及投资回报率（ROI）来挑选初始候选项目。

　　该路线图应与公司的战略利益联系在一起。诸如项目进度、资金筹集、人员安排、业务驱动因素和业界竞争等因素都可能影响实施的进程。由于一些因素可能使得SOA脱离正确的轨道，应当仔细地定期追踪进程。记住，最初的一些成功对于赢得对SOA的支持和给机构带来的重构十分重要。因此，从策略的角度看，在初始阶段选择正确的候选项目十分重要。

　　SOA路线图一般具有多个阶段。在第一阶段中，公司进行前期摸索并试图了解技术挑战。在这一阶段，实施诸如验证、授权、确认和数据转换等简单的水平服务。在第二阶段中，制定更多的面向业务的服务。这些服务常常从门户中冒出来，因此很容易获得收集在后端系统中的信息。第三阶段包括聚合服务、开发工作流和集成各个不同的系统。

　　3. 架构

　　只有具备健全的架构基础才可发挥SOA的主要优点（松散耦合、重用以及技术和服务的抽象）。企业架构团队是一个中心机构，掌控着整个企业的架构。从SOA的立场上看，架构和设计的以下方面十分重要。

　　平台：最根本的决定之一是使用什么技术。来自底层平台的支持很重要，因为它能帮助我们避免自己编写解决方案。用户还需要考虑团队对具体平台的满意度。一个好的平台能显著减少开发和维护的总体成本。一些公司也使用多个平台的组合。SOA的优点是，当服务成熟到一定程度之后，界面比底层技术更加重要。由于ROI的原因，技术也变得“可插拔”，即可以任意选用技术。

　　标准：对于SOA来说，Web服务是业界最常选用的技术。在这一领域，标准正在不断发展，并且多个相互竞争的标准解决的是同一个特定问题。良好地掌握这些基本原理和要素的实施方向可确保资金不会花在错误的技术上。遵从标准的平台能够保护投资，并且使得与外部合作伙伴和软件开发商的的集成变得更轻松。

　　第三方：公司总是和外部合作伙伴保持联系。尽管我们不能控制第三方的架构，但是我们应试图使他们遵循SOA，这样在长期内使得每一方都更轻松和经济高效。这一点同样适用于系统集成商和开发商。尽量减少战略合作伙伴的数量对于控制复杂性非常有帮助。

　　服务：一个机构可能有几种服务。有一些是垂直的和以业务为中心的，而其他的更加广泛。后一类别中的服务——例如安全、数据转换、翻译和事件服务——一般是较好的初始SOA候选项目。企业架构团队负责在实现“横切”服务中提供设计模式和指导准则。

　　企业架构团队（与各垂直团队相合作）还负责培养Gartner所说的“生产力层”，该“生产力层”促进服务的重用和聚合。Garner称：“没有它，在Web服务和其他服务方向中的投资将很难得到回报。”因此，其中一些服务属于该类别。

　　像Web服务这样的技术使得这些服务独立于环境。这种独立性使得服务可以跨多个水平项目而方便地使用。消息传递可以使应用程序松散地耦合联结，但是为了实现最佳的重用，甚至环境也应被抽象掉。

　　强烈建议这些服务要经过具体计划和架构审查。这将为与之合作的垂直开发团队提供一致的和相似的模式样式、名称空间以及其它。较好的策略是，在利用架构模式的同时，采用业界或领域模式。

　　管理服务：一旦开发和测试了这些服务，就需要将它们部署在生产环境中。正如Web开发世界中那样，开发应用程序是一回事，在生产环境中管理它们完全是另外一回事。服务水平目标（SLO）、服务质量（QoS）、安全、访问控制、故障转移、监视、灾难恢复、审计和通知仅仅是需要管理的长长列表中的一小部分。特定于行业的管理方法，如HIPAA和Sarbanes-Oxley（SOX）可能需要用于控制更改、审计、监视关键系统的附加基础设施。其他需要注意的事情包括：循环负载处理、版本管理、服务的生命周期管理和伸缩性等。

　　您应为服务的健康增长和发展制定规划。因此，应具备良好的变更管理策略。如果您需要遵照HIPAA和SOX等，则这可能是强制性的要求。

　　4. 技能

　　优秀的技能分类对于任何软件项目的成功都是必要的，这一分类包括深入理解领域、垂直技术和过程、业界和技术标准、新兴技术和趋势、编译要求、开发平台的专门知识、模式、最佳实践、项目管理和测试。

　　为了能够提供强有力的指导和领导，企业架构团队应该是熟知这些核心技术的一个精干的小组，。而在那些垂直团队中，其成员应深刻理解业务流程并应能够协助EA团队确定和设计良好的服务。

　　5. 交付模型

　　交付模型包括三个主要方面：团队组成和规模、项目持续时间和开发方法。由于项目、技术方案、对技术的满意度和专业知识的不同，每个组织的交付模型都不相同。该模型应在各个工作组和项目中保持一致，这样当开发人员跨项目进行转移时，会有相似的经验和最低限度地减少学习弯路。

　　交付模型的示例包括对于中型项目的6 x 12（6个开发人员12周），以及对于小型项目的4 x 6（4个开发人员6周）。该团队一般包括诸如项目经理、质量控制（QA）人员或业务分析人员的附加支持成员。支持团队成员理解总体SOA目标很重要。他们需要和企业架构团队紧密合作，并帮助确保工作具有策略意义。公司还已经尝试了不同的SOA常用方法，如敏捷建模（Agile Modeling）和极限编程（Extreme Programming）。