*Editor’s note: This article was first published in the Winter ebizQ Buyer’s Guide print edition, a supplement to the Business Integration Journal.

Strategic IT planning is critical for a successful Service-Oriented Architecture (SOA) transformation. To get value from SOA, the effort must be business-focused. Yet many IT shops have historically done a poor job of aligning the IT strategy and portfolio with the business.

From a business perspective, we think of SOA benefits in terms of business process agility or the ability to create business processes from component services. But we also have to think about SOA in terms of IT strategic alignment. Are we focused on building services with the most benefits? Will our new services create flexibility for the most strategic business processes?

Consider that IT has traditionally spent a great deal of time deploying cookie-cutter “ERP style” projects or supporting monolithic legacy systems. An ERP deployment best practice is unfortunately to force a change to the business process itself to support the package out-of-the-box. We resist changes to legacy systems because it is expensive and they are brittle. But now we are required to think differently. Business processes buried in monolithic systems need to be exposed as services that can be reused by many business processes. With SOA, it is now possible to consider IT business alignment on a process by process basis automating the activities that support the business strategy in an optimal way.

But to achieve SOA business alignment we need to plan the transformation over time. We need to create a SOA roadmap (projects over time) and a Strategic Services Blueprint (the future business services catalog) that will serve as a guide for IT transformation.

The SOA Steering Committee

To support building and planning an effective SOA you need a business and IT team with a cross-functional view of the organization. However, most IT organizational structures are actually a barrier SOA success. IT organizations are typically silos with a manager and staff assigned to support functional business groups. These silos often also apply to systems - e.g. the HR IT team will support the HR functional department and the Peoplesoft application. So, when an IT functional group creates a service, it generally applies to their silo-ed view of systems. Or, given this limited view, they don't create functionality as a service, but bury the functionality in the silo-ed application with no interface at all.

To overcome organizational barriers form a cross-functional SOA Steering Committee composed of the SOA sponsor, a lead architect from each functional-application system and an enterprise architect. The figure one diagrams the cross-functional structure of the SOA Steering Committee.

Figure 1

The SOA Steering Committee also supports the SOA Competency Center. The SOA Steering Committee helps to create and approve the standards and governance policies to be used by the Competency Center. By using a cross-functional committee of respected IT leaders to establish standards, processes, and the SOA roadmap the organization can manage the dramatic changes necessary for the SOA transformation.

The Strategic Services Blueprint

The SOA Steering Committee and business leaders should consider candidate services by decomposing business functions keeping in mind the cross-functional needs (reuse potential) for each candidate. Service decomposition looks at the enterprise as a whole and seeks to define the core services needed to run the company - the future-state services catalog. This presents SOA at a high-level strategic view.

Service decomposition requires top-down and bottom-up analysis of business domains (functional areas). The top-down approach analyzes business domains and decomposes these domains into business processes, sub-processes and use cases. This method presents services in the context of the business domain, which creates clear services categories and helps to determine service granularity by considering cross-functional reuse opportunities.

By decomposing the key functional areas, one can create graphical representation of the service catalog as in figure 2. Each functional business domain is decomposed to identify core business services. These business services are added to the model to represent a business view of the services categorized by functional area. At this level, the services are easy to understand from business and technical perspectives and provide a means for IT to collaborate with the business to determine what services are of the highest value.

Figure 2

There are several ways to consider the business in functional terms. An analysis of the human factors of service orientation gives us the impact of SOA to the company’s constituents. For example, customer facing services frequently yield the greatest returns. We therefore often analyze services within the business boundaries of customers, products, suppliers and human resources, which can yield benefits such as:

• Support customer service initiatives
• Improve integration with business partners
• Streamline the supply chain
• Enable employee self service
• Facilitate global product lifecycle management

Once we have a vision for the company’s core services, we can plan how to build and deploy the services (service realization). A bottom-up analysis examines legacy systems and components in an effort to realize the services defined in the business domains and discover services that were not uncovered in the top-down approach. Looking at services from the top down and the bottom up validates the definition of useful and technically feasible services. A bottom-up analysis of every candidate service however requires a significant amount of time to accomplish.

We save time by creating the high-level service blueprint using the top-down approach and then providing more detail only for strategic services at the business process and use case level. Strategic services are defined using IT portfolio management techniques to identify strategic business processes and IT assets. This provides a fully-populated service catalog with more details for the services that will be created early in the SOA transformation.

Portfolio management techniques can be used to identify strategic services. Here, we seek to very quickly identify the top priority services by tying them back to business processes and then assessing the current effectiveness and criticality of the business processes that they will potentially support. We consider the company’s strategic objectives and how our core services and business processes support them. This step is essentially a process to prioritize, score and categorize business processes and the supporting services. Scores can be plotted in four quadrants to identify services with the most potential benefits as shown in figure 3.

Figure 3

We then examine only the high-priority candidate projects and services in more detail to avoid spending time on services and projects are not on the SOA Roadmap short-term. This results in more detail for upcoming projects and less detail for projects that are further out on the roadmap. This process creates the Strategic Services Blueprint. The blueprint and roadmap details the future-state service catalog and provides a roadmap on how to get to the future state in terms of people, processes, projects and technology.

The SOA Strategic Roadmap

Once you have the blueprint, you need to plan how the services will be built out over time. SOA is a transformation that will often take years to achieve. It is important to think of tactical projects, new packaged applications and the existing portfolio in terms of the SOA blueprint. For example, if you have a tactical project that touches an IT asset that potentially supports a strategic service, then expose the service as part of the tactical project. Without a roadmap and blueprint, such opportunities would be missed.

Build the SOA roadmap in terms of projects, services, people, processes and technology as should in figure 4. For example, early SOA projects might be based on exposing legacy applications as a foundational set of services. Later projects might be more focused on leveraging these services in automated, composite business processes. In this scenario, SOA integration technology and the people skills and processes around this technology would be earlier in the roadmap than business process management software, skills, etc.

Figure 4

The Strategic Services Blueprint provides a strategic view of services to be built over time yielding the following benefits:

• Identify services that support the required business functionality and processes.
• Align the IT projects with a services strategy and desired business process functionality.
• Establish and adhere to services architectural requirements for performance, scalability, and security.

The Strategic Services Blueprint will answer the following critical questions to the success of SOA:

• What are the core services needed to optimize the business?
• What services should be built first?
• What is the architecture and infrastructure for services over time?
• Where do we need to make strategic investments?
• How can tactical projects impact the build out of the services catalog?

The Strategic Services Blueprint provides the means to plan and communicate a SOA transformation over time. The planning approach and team organizational structure helps to manage change, ensure reuse, and align SOA with business objectives.