负责管理的人员一定已经做出向SOA过渡的决定，否则您无需制定这个工作计划。在目前的经济环境中，人们在IT方面每投入一分钱就想得到数元钱回报，这意味着，必须对这个项目仔细推敲，所以您应该确保您的工作准确无误。
　　SOA 实际上是有关接口的所有问题。透过各种使它们工作的相关技术，面向服务的架构是定义良好的、结构良好的接口。接口的一面是向上提供服务，另一面是使用这个服务。困难的部分就是使得两面统一的服务规范。随着需要的服务数目越来越多，您的工作量就会倍增，由此，您可以开始估计这项任务量的大小了。
　　在一个可能很大的项目中，让我们来看看确定一个良好开端的过程。

划定界限
　　在迁移到SOA的背后，公司的目的是什么？一种可能是在集成时降低费用。另一种可能是为和客户紧密集成提供一个平台，或者是一种强制提供电子交付的方式。或者可能某些人仅仅想把SOA技能记录到他们的简历中！
　　无论真正的原因是什么，您需要用它帮您决定首先处理什么。您必须深刻理解这一点，因为最先的任务就是划定界限，也就是您要在哪里放置接口？您会在哪里截断客户端应用程序和它们服务器之间的连接？一般来说，您应该尽量在服务少的地方划定界限。您需要最大限度地提高通用性和尽量减少定义。
　　这里有一个例子可以说明我的意思。假如您的公司有一个仓库管理应用程序。仓库中有一个允许记录材料变动的终端，也有一个胖客户端是仓库管理员做计划用的。
　　我们可以很清楚地看到许多服务，这些服务是仓库应用程序提供给两个客户端的。我们可以在客户端和服务器之间做一个假设来看有多少消息、屏幕或功能穿过它。这为我们提供了第一个服务列表。图1 显示了这些服务的地方。

图1. 划定界限
架构图一般看起来像细面条或者一条硬件总线——它只表示系统和系统之间的通信已成为任何企业架构中必不可少的部分。计划迁移到服务包括划定界限穿过这些通信路径，但是又想尽量减少这些接口的数量。

走向公用化
　　然而，这个列表还仅仅是一个开端。无论他们使用哪种现有技术，利用SOAP取代它们，实现这些接口将有效地重写那些现有的应用程序。这没什么理由——如果没有坏，就不需要修理它。
　　我们必须深入挖掘驱使这个项目的业务需求，以理解为什么我们想要重构一个现有的、正在运行的一套应用程序。返回到我们的仓库管理程序，我们可以想像许多要计划的新项目。可能目标是允许仓库应用程序直接和运输公司交谈去管理收集。一个供应商可能想通过自动检查储存量来实现一种紧密及时的机制。可能仓库工作人员将用无线设备发布命令，从而取代终端，或者现有的跟踪机制正转向无线频率识别器（RFID）。
　　无论什么原因，您需要和参与人员保持一致，因此也要和他们的需求保持一致。所有这些可能的项目需要访问仓库数据和业务逻辑——为新的服务创建需求，或者可能不需要。很可能一些新的需求将覆盖现有的应用程序——检查某一物品的库存级别，在库存中累加物品，等等。
　　所以这是一个难点。我们已不再与客户端/服务器应用程序的模式有紧密地联系——这是一个公共接口。表1显示了这种可见性的影响。您需要确保这个接口满足大多数的要求。通过做一些早期的研究使得您的新服务很通用，您将能够避免许多新的发布、改变和扩展。软件应用的一个根本准则是人们从来会不按照原来的意图去用它。

前瞻
　　查看个别服务可能导致不完整的、不一致的实现。对于任何迁移，我的起始点是在你们公司尽可能映射多的内部系统，也尽可能多的链接到外部公司。
　　如果SOA实现是所有关于接口的问题，则管理过程必定关于通信。您需要和其他的人一起工作来理解谁需要什么。那个“什么”可以是广泛意义上的。
　　参与人员可以包括执行管理人员、IT管理人员、项目经理、开发人员、分析师和您公司内外的业务人员。这意味着一个开发人员可能考虑需要学.NET，然而一个安全分析师考虑保护机密记录。
　　当企业级计划可能在您职责之外时，您仍然可以在部门或者项目级申请这个分析。无论什么等级，您需要考虑这些：

• 和要提供的主要的、公共的服务保持一致
• 辅助服务，要有少量用户
• 处理外部实体的效果
• 安全性
• 应用程序的影响，特别是迁移到无状态服务
• 要求的技术
• 开发工具
• 开发人员培训
• 适合于语言、样式和应用程序领域的设计模式
• 最佳实践和开发标准
• 测试
• 初次公开展示
• 性能
• 文档
• 基础架构，特别是带宽
• 提前更换到SOA计划

　　由于篇幅限制而无法深入讨论每一个话题，但是您将在这篇特别报告中发现许多最佳实践中的有用资料。当您开发了一套方法，并计划迁移所需的费用和时间之际，可以采用这组主题来检查它是否适用。