Pilot Project for Service Oriented Architecture (SOA) - 4

Posted In: Planning , SOA , Technology
By Vishal Sharma

Continuing in series of What is Service Oriented Architecture or SOA
today I reflect upon a pilot project for SOA.

Projects :
Upon establishing a SOA Reference Architecture (RA), enterprises need to begin to considering which services are need to provide functionality and ROI required by the enterprise, when and how they will be developed and deployed. This is an example of an SOA Roadmap, strategy that is intended to guide an enterprise along the SOA journey by assisting in prioritizing the tasks of developing, reusing and producing services.
Efforts must begin with an understanding of the existing projects, applications, and functionality that can be reused. This process involves creating an application inventory and project catalog. Functionality that is specific to and resides in applications or projects may be safely deemphasized. It is important to capture relevant features such as:
Current applications functionality, services and dependencies
Level and capability of existing services
Inter- and intra-dependencies of current applications, planned and in-progress projects, and any related development and maintenance issues

Current common service usage
Application development metrics including budgets
Application development information, accessed and delivered
Application process and workflows
Business information; SLAs, QoS, and related non-functional
Project schedules and delivery milestones

The product of this process analysis will provide a base understanding of the current enterprise capabilities and projects and will assist in identifying common functionality and initial service selection.
Relationships and Outcome Management :
The most significant challenges with SOA are the cultural and sociological changes required. The establishment of tighter coupling between IT divisions is essential in order to facilitate the focus on delivering overall business value rather than specific departmental value, shared services versus siloed applications.

There seem to be two recurring fundamental themes associated with this aspect of SOA. The first being, it is crucial to provide the necessary education to the organization not only in the technical aspects and concepts of SOA but also the cultural impacts of SOA.
The second theme is that relationships and governance is about considering the adoption of SOA as a change to the entire organization rather than simply the latest technical trend. By achieving and retaining sponsorship from senior executive will provide assistance for different divisions of the organization to inter operate with each other, and guarantee the appropriate level of authority to obtain compliance along with the evangelising of the SOA effort.

Organizations construct relationships and governance is various manners which suit their maturity levels and the direction of their organization. The most effective mechanism, for initial SOA implementations, is a centralized organization. This is followed by a federated, distributed, governance model and ultimately followed by an autonomous hierarchical mechanism. The governance organization must take a holistic view of organizational tenets, structure relationships, funding, process for operations and tools, standards, change management, and skills retention. This organization will assist with deciding, institutionalizing, and enhancing the processes related to answering questions such as:

Who defines and modifies the organization’s systems?
What quality of service must be provided?
Who is responsible for the payment of service development?
Who is responsible for the payment of the service ecosystem?
Who is allowed access to the services?
How are services exposed to external consumers?
How will success of the SOA be measured?
How will the inter dependencies among services be managed?

The relationship and governance phase will ensure that the maturity and business value delivered by the SOA effort can be measured as well as define the corrective action that must be taken if metrics are not being achieved.

Implementing a Pilot Project : Once an organization has developed its SOA roadmap the time comes to begin executing against that roadmap, however many organizations struggle on how to get started implementing an SOA. What is needed is a prescription that describes a mythology for selecting the appropriate project or application. Many say that this pilot project should be one that addresses some “low hanging fruit” and has minimal impact and risk to the organization and not one that would have a big bang effect on the organization. One such prescription is defined in this section.
Important Steps in a Successful Pilot Project in SOA

Step 1: Identify the Objectives for the SOA Pilot
The valuable SOA ecosystem insight gained from an SOA pilot project will be extremely informative as an organization progresses to implementing an enterprise SOA. The pilot project is an opportune time for experimentation and learning by trial and error. The organization should clearly define and articulate the objectives for the pilot, which may include this such as:
Consolidation of duplicate applications or functionality
Development of a reusable service for usage by multiple departments
Gathering lessons learned that can be leveraged in the progression along the SOA roadmap
Gaining knowledge and understanding of the tasks involved in provisioning services into production as well as the daily operational management tasks required for an SOA.
Demonstration of a successful SOA implementation in order to clearly showcase the benefits of reuse and consolidation

Step 2: Construct a Cross-Organizational SOA Team
In order for an SOA pilot, effort, to be successful there must be support and cooperation from across the organization. A key step is to establish a cross-organizational team with representation from business development, operations, engineering, security, etc. It is imperative that these stakeholders experience both the failures as well as the benefits by participating in the SOA team, even though they may not be involved with the pilot on a daily basis. By conducting regular meetings and communications, territorial issues and other concerns will be exposed.

Team members must be selected wisely considering their ability, and willingness, to participate in addition to their on-going responsibilities. Time commitments for both meeting participation and reviews must be outlined and the team members need to be asked for commitment agreements in the beginning. Another key element is a communication strategy, which needs to be established and shared that includes a manageable amount of updates and should be sent to each team member. It is essential that the organization adhere to its schedule in order achieve credibility for the SOA pilot and obtain feedback, continued support, and participation.
SOA migration involves a major shift in the development and provision of applications paradigm. The most difficult challenge in migrating to SOA revolves around the cultural and sociological aspects of organizations because many organizations see SOA as a disruptive technology and view it as the demolition of traditional silo-based organization. Selecting to appropriate demographics for the cross-organizational SOA team is probably the most crucial aspect of a pilot.

Step 3: Ascertain the Appropriate Pilot Project
Selecting an appropriate SOA pilot is essential in order to dispel any misconceptions by those who may be skeptical of the SOA paradigm. The SOA pilot must exhibit the benefits of SOA and demonstrate the potential without greatly impacting the organization. A successful SOA pilot provides credibility and could result in wider SOA adoption and deployment.

There are many questions to consider when selecting an SOA pilot project some of which are:
1. Develop new services or reuse existing?
While developing new service may be simpler initially, the typical first step, by many organizations, is to wrap existing legacy systems with a Web service interface. Wrapping legacy systems provides benefits that can be measured quickly.

2. Should the pilot be of high or low visibility?
Organizations struggle with the visibility of application to utilize in an SOA pilot and must weigh the benefits and risks of choosing a pilot that would possess a high level of visibility across the organization against those of a lower visibility pilot.

Low visibility pilots
Are not as critical to the organization if issues should arise
Allow for triage without constant inspection

High visibility pilots
Organizational benefits are achieved sooner and across multiple departments
Determine stakeholder requirements and if a visible success is warranted
Come with various attitudes and associated political agendas

3. What type of application should the pilot address?
Portals are the typical SOA pilot applications selected. Portals provide a provide users a single view based on data gathered from multiple sources. Portals are often good selections because they provide a tangible results and a hands-on way of experiencing the benefits of SOA. In direct contrast are back-end integration pilots, which can be valuable, such as data synchronization systems which make it difficult to experience the benefits of SOA.

4. Who should the audience be for the pilot?
The selecting the audience of a pilot offers many advantages and disadvantages when choosing between internal and external users. If the audience is only internal to the organization users can be protected from any potential issues, however the expressed reactions may not be as valuable in furthering SOA adoption. In direct contrast with this is an external facing pilot where the reaction could provide greater value to SOA adoption across the organization.

5. What type of service should the pilot be?
Along with selection appropriate type of application for the SOA pilot, for example user-facing applications like portals or back-end application like data synchronization, organizations must select the type of service the pilot should offer. Two possible options are services that expose existing data for use by new consumers and transaction-based services that generate new information or initiate new business processes.
Many organizations select query-based services to remove barriers to existing data assets and avoid transaction-based services due to their higher risk of issues that can lead to data loss. Over time, these query-based services are extended with transactional operations, since most services require both. As an example, a telecommunications self-service web site should be able to provide information related to things such as service requests and billing history as well as self-service provisioning (transactional operations).

Step 4: Measure Results
The organization’s management staff often requires tangible proof of pilot success and ROI. A technique is required in order to continuously capture data, especially is the pilot timeline in a significant in length, in order to possess accurate and readily available data at pilot completion.
Measuring factors for SOA

Business Agility :
Organizations can compare the time required to modify or add a feature to a non-SOA application against performing the similar tasks to a service in order to determine its ability to respond to every changing environments and requirements.

Shared Service Reuse : Determining the number of reuse instances of shared services can be an effective measurement of the ROI provided by an SOA. Reusing shared services leads to cost avoidance or reduction of developing, maintaining, and operating services that are only useful for a specific purpose or organizational element. For organizations to calculate ROI of shared services there are some additional fundamental metrics required:
Cost to build/maintain/operate a shared service. Cost of having a shared service
Cost to build/maintain/operate pinpoint service. If organizations have deployed an effective SOA ecosystem this should be similar to that of a shared service.
Cost to reuse an existing service developed externally. This cost is incurred by organizations when services, developed by someone else, are reused. It is crucial that organizations control this metric in order for an SOA to succeed. Reusing a service is in essence integration and an SOA must be structured to manage the costs of integration.

Web Services Adoption : The number of Web services can provide an indication of the breadth of adoption for the underpinning technology for SOA. It can also be a negative indicator as well, the larger number of Web services would indicate that the reuse of services is low and that the SOA effort needs to be revising.

Consumers of Shared Services
The number of consumers reusing shared services can assist organizations in measuring the SOA adoption level and breadth. This indicates the level of shift in the cultural, sociological, aspects of the organization. While this metric may not be directly correlated to the business benefits for SOA, it is an important measurement nonetheless.
Other useful tips on Java, JEE/J2EE