*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.