Selectively determine SOA adopters
A key differentiator between program-based and the ad hoc approaches is the methodology used to determine which projects should adopt SOA based on a strategy rather than leaving SOA adoption up to each individual project or department. With the organic approach, an initial project is selected opportunistically - after a quick survey of planned projects, a reasonable candidate is chosen based on subjective evaluation. In contrast to this, the strategic approach demands an extensive evaluation, with weighted criteria, and will produce a more objective evaluation scorecard based on agreed upon criteria. Within any organization, criteria for project selection will be unique to the business. Figure 4 suggests a two-step process for identifying and evaluating SOA opportunities.

Address organizational barriers to adoption
There is no generic SOA organizational structure that will meet the needs of every business. It's clear, however, that traditional IT organization structures aren't well suited to support SOA. Whether the organizational structure is functional, project-based, or matrix, traditional IT organizations can impose the following barriers to adoption:
• Silo alignment of applications, processes, and organizational structure
• Weak architectural governance
• Orientation to project goals, not long-term solutions
• No incentive for strategic investment
• Teams oriented around project lifecycles as compared to service lifecycles

When evaluating a particular organization and associated processes SOA implications should be considered broadly:
• How business problems and requirements get defined
• How solutions are envisioned
• Finally, how they are assembled, deployed, and monitored

SOA touches every aspect in this spectrum and will therefore impact the processes of PMO, enterprise architecture, SDLC, ITIL, and IT/architecture governance.

When planning new roles and responsibilities, a SOA strategy will involve multiple tiers of involvement including but not limited to:
• Stakeholder leadership - a senior-level management group that initiates and drives the SOA vision and strategy
• Strategy execution - promotes the successful adoption of SOA across the enterprise and helps the organization see ROI from the SOA strategy. At a high level, they oversee strategy, development, operations, and governance
• Technology - owns SOA standards and best practices and provides architecture leadership for the organization. Development of standards and guidelines. Responsibility for all centralized components of the SOA
• Governance - review boards that enforce SOA architecture governance policies on a project-by-project basis and is integrated with entire SDLC.

Whether these responsibilities are centralized or distributed - whether they are part of one or many organizational units - depends on the SOA objectives, scale of adoption, and existing organization model.

Organic SOA adoption will address organizational barriers in a different way than the strategic approach. The organic model puts heavy emphasis on technology and project-level architecture governance early in the adoption cycle. Strategy and overall leadership will evolve with each successive project as learning is applied on how SOA will best benefit the organization. By contrast, the strategic approach involves greater effort in organizational transformation. Emphasis is placed first on building out the leadership and strategic value of the SOA organization to support the long-term plan.

Define and Measure Success
A SOA program should be assessed and monitored through well-defined performance measures based on internal baselines and/or industry benchmarks. The strategic component of the SOA organization should be tasked with selecting, monitoring, evaluating, and maintaining performance measures and targets. Ideally, the performance measures are derived from SOA objectives that are measurable.

Measures can be established across various aspects of the enterprise including business, financial, quality, process, timeliness, pervasiveness, and compliance. Table 3 lists examples of measures across these aspects.

Conclusions
SOA provides a powerful set of technologies and approaches that have the potential to make IT more effective in meeting the needs of business. But grassroots technology-driven SOA initiatives run the risk of proliferating a new patchwork of EAI hardwiring that satisfies only short-term project-level needs. This will complicate the overall IT landscape. There are benefits to SOA, such as enterprise reuse and business alignment, that cannot be achieved effectively through such an ad hoc approach.

A number of good organic and strategic adoption models exist. The key to success is controlled and planned growth that includes involving the business. A good starting point for program-based adoption is to identify the SOA maturity level of the enterprise and then create a SOA strategy that aligns SOA technology adoption with business priorities.

Getting started with a SOA program can be accomplished with minimal investment. A quick assessment can identify and prioritize SOA opportunities. This will give the business a handle on how SOA is currently being adopted. It will also provide an understanding of the degree of SOA standardization and identify new opportunities to collaborate across departments and projects. This will help an organization establish general SOA goals and commit to an adoption model.

For those organizations that have already established a compelling case for enterprise SOA, a more substantial investment can be made in developing a full SOA strategy including a complete opportunity assessment and analysis, future-state architecture, and adoption roadmap.

Whether organic or strategic adoption is the course, an organization should be prepared for service transformation. Agility, interoperability, business service standardization, and reuse - some of the key tenets of SOA - don't happen by accident and require an organization to provide the roles, responsibilities, and processes to drive SOA effectively. Besides organizational structure, assess SDLC, PMO, enterprise architecture, and governance processes to determine how they factor in SOA.