Integration Efficiencies

• Reducing integration cost and complexity through the use of industry standards
• Seamlessly interoperating with, and leveraging the capabilities of, key third-party infrastructure solutions such as identity management systems, directory services, and enterprise management systems

By documenting precise goals for an enterprise SOA, teams involved in the initiative can more effectively choose the right projects, manage the projects (e.g., avoid "scope creep"), make sure the overall results are not derailed, and manage the expectations of surrounding stakeholders.

Starting with a Pilot
Rome wasn't built in a day, and neither is SOA. It is best built incrementally, project by project. By starting with an explicit SOA pilot project, your organization can learn from its successes (and failures) to increase the success of its overall SOA initiative. Before commencing your effort, there are key issues you should examine when choosing and launching a successful SOA pilot project (see Figure 2).

Key Steps to a Successful SOA Pilot
Step 1: Identify the Goals in an Initial SOA Pilot
The pilot will provide valuable insight into SOA infrastructure that will be extremely useful as you expand to building an enterprise-wide SOA. This is a great time to experiment and learn from trial and error. Goals for this initial project should be clearly articulated, and may include:

• Developing a service that can be reused by multiple departments
• Consolidating duplicate applications into one server
• Providing a showcase of successful SOA implementation to clearly illustrate the benefits of reuse and consolidation
• Learning valuable lessons that can be leveraged in the larger SOA initiative
• Understanding the tasks involved in getting services into production as well as the day-to-day tasks required to manage SOA once it is production

Step 2: Create a Cross-Functional SOA Team
Successful SOA pilots involve the cooperation of cross-functional departments, including line of business, development, operations, security, and more. While these stakeholders may not be directly involved with a typical pilot on a daily basis, it is critical that they experience both the pain points and benefits of SOA through team participation. Regular meetings and communication will expose any concerns or territorial aspects that could inhibit SOA production (see Figure 3).

Choose the team members wisely and consider their ability to participate outside of their daily responsibilities. Outline time commitments for both meeting participation and communication review and ask each team member to agree to the commitment up front. Additionally, create and share a communication strategy that includes a reasonable number of updates sent to each team member. Then it is important to stick to that schedule because it lends credibility to the pilot and elicits the best feedback and participation.

Moving toward an SOA will most certainly dictate a change in the way applications are developed and deployed. Most believe the team and organizational change is the toughest challenge in migrating to SOA because many people see this change as the destruction of the silo-based organizations that exist today. Therefore, the ability to pick the right cross-functional SOA team may be the most critical aspect of the pilot.

Step 3: Determine the Appropriate Pilot
In order to accurately and successfully exhibit the benefits of SOA to those who may be skeptical, you must first choose the appropriate pilot. It must clearly demonstrate the promise of SOA without causing material harm to any aspects of the business - that is, a service with the best risk/reward ratio. Early pilot success lends credibility and therefore leads to production SOA.

Consider the Following Questions When Determining an Appropriate Pilot

1. Create a new service or leverage an existing one?

   New services can be easier to create initially, but wrapping a Web service around an existing legacy system may provide measurable benefits in less time

2. Select a high or low visibility pilot?

Low visibility pilots:

• Are less critical if problems arise during implementation
• Allow triage without constant scrutiny

High visibility pilots:

• Higher visibility pilots come with multiple opinions and the associated political complications
• Benefits are delivered earlier and to more departments
• These pilots determine stakeholder requirements and whether or not a visible success is necessary

3. Choose a revenue-based or back-end application?
   The most common pilots are often related to user-facing systems such as portals and Web sites - for example, a portal that provides a single view for customers or employees based on data gathered from one or more different systems. These are often good choices because the end results are tangible and can provide a hands-on experience with the benefits of SOA. In comparison, back-end integration, such as synchronizing data between systems, can be valuable, but it is difficult to clearly demonstrate the benefits.

4. Choose a customer-facing or internal application?
   There are many pros and cons associated with choosing either a customer-facing or internal-only application. Internal services, such as one in Human Resources used to enable employees to update their personal information via a corporate intranet portal, can protect customers from potential issues, but feedback may not be relevant to wider-scale use of SOA. In comparison, a financial institution could use a currency exchange rate service for a limited volume (but highly visible) pilot.

5. Choose a transaction-oriented or query-oriented service?
   Query-oriented services are used primarily for making existing data available for other uses such as retrieving lab results in a healthcare environment. In contrast, a transaction-oriented service is one that creates new information records, or triggers a new business process (such as the DMV registering a new automobile).

   Transaction-oriented services are inherently more risky because problems can lead to data loss. As a result, many organizations start with query-oriented services to unlock existing data assets. Later, they extend these with transaction-oriented operations, since many services require both. For example, in telecommunications, a self-service Web site should be able to provide both self-service provisioning (transaction-oriented operations) and information on service requests, billing history, and more (query-oriented operations).