This article is the Planning and Execution part of the three-part Path to SOA series. Part one of the series, Assessment, introduced the service-oriented architecture (SOA) maturity model, which can help you evaluate your current level of SOA maturity and provide guidance on next steps as you progress on your path to SOA. Part two of the series, Project Selection, discussed how to select the right set of projects to meet your goals. This article guides you through various tasks and activities that are important in planning and executing a SOA project.

Planning

SOA is a broad topic that covers not only the technical aspects but also organizational and business aspects. It will be easier and manageable if the tasks spanning these different areas are scoped and addressed based on the impact they have. There are some tasks that need enterprise-wide efforts or have an enterprise-wide impact (enterprise scope), there are other tasks that are project level (project scope), and still others are more specific to application development (application scope).

Some of the enterprise-level activities, such as the SOA maturity assessment and project selection, have already been discussed in part one and part two of this series. Although most of the enterprise-level tasks have some influence on actual project execution, tasks like governance and service portfolio planning have a significant impact on projects and are discussed in this article.

Service Portfolio Planning

Service portfolio planning helps in identifying potential services across the enterprise that may be needed to build service-oriented applications. It provides a plan and techniques for building the conceptual enterprise service portfolio. A service portfolio plan lays down services acquisition, technical, and architectural policies. A good service portfolio plan should also address the service lifecycle from identification to approval to building of functionality as a service.

Without a broader view of what services may be required across the enterprise and how they would get used, various projects will acquire their own services for similar functionality, even if a service exists that meets the requirements. This may happen for various reasons -- from not knowing that such a service exists to knowing one exists but has a slightly different interface than needed. An approach based on such a narrow view would surely not help create reusable services. For example, a telecommunications company's various SOA projects ended up creating more than 50 variations of a credit check service. This could have been avoided with a proper enterprise-level service portfolio plan in place.