If you are an IT decision-maker embarking on the road to SOA then here are the 6 steps that you must adopt for a successful transition.

6 Steps for Transitioning Successfully to SOA

Service-Oriented Architecture Makes IT a Strategic Partner in Achieving Business Objectives by Decreasing Dependencies, Improving Communication Across Disparate Systems and Enabling Reuse of Existing and Legacy Systems.

Successful enterprise IT managers today understand that a service-oriented architecture is not a luxury, it is a necessary IT methodology that lends to a flexible IT infrastructure capable of adapting to business needs. The next step naturally, is to select from the many implementation options available, and this process need not keep decision makers awake at night as long as they begin with a clear road-map. The following steps can be adopted by decision-makers embarking on the road to SOA.

1) Which business processes are most frequently changed?

Identify the application or sets of applications that are impacted by the most frequently required changes requested by the business. This is a first step that gives an idea of what we will be dealing with, though in small bites. Processes that are most frequently changed are appropriate candidates to pick for any SOA initiative as these processes can be re-factored based on SOA principles leading to faster adaptability to change. A parallel run, involving both legacy i.e. existing applications and the newer versions, each incorporating more services, progressively exposed through iterations, will be required during the transition.

2) Document use cases that will be impacted by changes to these applications.

The next step will include a study of client-based executable or interfaces, invoked by each user community. The purpose of this study is to allow a fuller view of the scope and establish a narrower set of “important victories.” This exercise would be the first steps towards drilling down and identifying the services that would need to be exposed.

3) Review application code to identify and abstract business processes from application functionality.

For the use cases identified the exercise of parsing business processes apart from an application’s functionality accomplishes the goal of allowing us to form a reasonable estimate of the work and timelines involved (establishes scope of work).

4) Expose potential latency issues of re-use and content heavy XML and the security issues of opening these assets for access.

When business systems operate conditionally, many of the tasks are buried deep within the rules engines. The process of separating process from systems and making each discrete will necessarily expose weaknesses. These considerations will determine the classes and types of products to be used in the enterprise architecture. Once this is done, the first sketch of the target architecture is visible. Development of Proof-of-concepts will help in deciding on the products to be used and to also come up with the governance guidelines for the subsequent development activities. An offshore partner knowledgeable in the products being investigated and technology in general can be a useful tool in this exercise.

5) Start building and exposing the separate functionality that is identified to be a part of one or more business processes.

At this time, it’s important to get started. A registry and/or a repository that describes the service is necessary, so that incoming messages can find them. The exercise of decomposition of the identified business process(es) into reusable services will help identify the services to be implemented. The SOA could at first be made available within the firewall, tested and then subsequently made available through holes in the firewall that are opened specifically with relevant security measures to allow access to nominated users. A gradual ramp up in terms of number of services exposed is recommended so that the infrastructure used can be monitored closely and any corrections required can be implemented with minimal impact.

6) Researching and selecting the right offshore SOA Partner.

The selection of a SOA partner largely depends on whether a SOA product is purchased or if a custom solution is desired. Selecting an entity that is knowledgeable in both open source and proprietary solutions affords options for cost-sensitive and time-sensitive domains. The partner can help in both identification of the solution set as well as the implementation of the desired services. Finally, knowledge, skill and expertise are of little value without client centric support. Is this merely a vendor, or a true business ally, with domain-specific expertise? Is there visibility into their process and is your support team accessible around the clock to meet your needs?