Getting Started With SOA: Staging Your First Pilot Project

Rome wasn't built in a day, and neither is SOA. Getting started with SOA is an incremental process: built 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 their overall SOA initiative. The next section of this paper will discuss the issues you need to examine when choosing and implementing a successful SOA pilot project.

Best Practices for a Successful SOA Pilot

Through many successful enterprise-class customer engagements across multiple vertical markets, Actional has compiled a set of best practices to help enterprises select and effectively implement SOA pilots.

Identifying Potential Areas of Service Reuse is an Important Aspect of Getting Started With SOA.

The following is a summary of some of the key steps to Getting Started with SOA.

Step 1: Identify the Goals of 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:

• Web service reuse that benefits 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 for SOA management 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.

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 as it lends credibility to the pilot and elicits the best feedback and participation.

Getting started with 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 as many 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.

Getting Started with SOA Involves Determining the Cross-Functional Roles Throughout the Business.

Consider the following questions when determining an appropriate pilot.

1. What is the best way to get started?
   • 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?
3. Low visibility pilots:
   • Are less critical if problems arise during implementation
   • Allows triage without constant scrutiny
4. High visibility pilots:
   • Higher visibility pilots come with multiple opinions and the associated political complications.
   • Benefits are delivered earlier and to more departments
   • Determine stakeholder requirements and whether or not a visible success is necessary
5. Choose a revenue-based or back-end application?
6. 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.
7. Choose a customer-facing or internal application?
8. There are many pros and cons 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.
9. Choose a transaction-oriented or query-oriented service?
10. 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.
11. Transaction-oriented services are inherently more risky as 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, as 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).

Step 4: Quantify the Pilot Results

The most important deliverable for a SOA pilot is quantified results. Senior management often requires ROI calculations as well as tangible proof of your pilots' success. Create a method for ongoing data capture, particularly if a pilot is conducted over a large period of time, so the data is both accurate and readily available at the completion of the project. Gathering and compiling these figures is the key to budget justification for the next phase of any SOA initiative.

The key to getting started is a clear understanding of your SOA goals and a well-defined chart to get you where you need to go. The forgoing plan lays out the essentials, including a step-by-step listing of best practices, together with a discussion of success criteria.

For More Information on How to Get Started with SOA

Get started with SOA today - Read the free white paper, SOA Introduction: IT and Business Perspectives