SOA Implementation

SOA Implementation
The information overload on SOA is largely on describing the merits of SOA, principles of SOA and the vast variety of products intended to address SOA needs. There is, however, an acute scarcity of information on SOA implementation to bridge the gap between wanting to get started and actually deploying a game plan where the rubber hits the road. This document is written to identify the factors to be considered, articulate the principles and questions to be asked that will drive the decisions within each enterprise towards creating a road map for implementation.

Separating reality from hype, distilling the essential from the desirable, explicitly addressing the how-to, nuts and bolts of an SOA implementation is the topic addressed in this document. It's about getting going, showing investors the incremental rewards of SOA adoption and continuing on the straight and narrow path that links deployment of technology with business goals.

Whether you are contemplating SOA, are or actually committed and well along the way, a back to basics checklist is a good thing to have. This document includes a review of the following topics that will help to retain focus and direction.

• Your reasons to implement SOA
• First steps and short-term goals
• Long term Objective
• Products and Partnerships
• Return on Investment
• Impact on Business as Usual
• A Stable approach to Change management
• Glossary of SOA Terminology
• Summary and Help Lines

Introduction
The benefits of SOA have been described and accepted. The question faced by many is: How to get started? Where to get started? Expectations that may be deemed reasonable and the return on investment (ROI) that can be demonstrated during each phase of investment have to be identified. Further questions abound regarding the choice of products, partners and ramping up of in-house IT capability. Of course, while there is no common one-for-all solution, the implementation of SOA is much like any large-scale migration, with a few notable differences, particularly regarding governance. The purpose of this document is to identify the factors to be considered, articulate the principles and questions to be asked that will drive the decisions within each enterprise towards creating a road map for implementation.

1. Your reasons to implement SOA –Two classes

While there are several frustrating experiences with legacy architecture that serve to propel the drive towards SOA, the drivers usually fall into two classes of compelling reasons, that either singly or together form the impetus to actually get started with SOA.

• The need to respond quickly to change in business needs
• The need to reuse technical assets across a larger enterprise

Symptoms include acutely painful situations where “the business” requests rapid and seemingly endless minor changes in business processes that incessantly require significant application level code changes within time lines that seem impossible. On a less painful but equally urgent basis, mergers and acquisitions, integration with 3rd parties/partners etc. extend the borders of e-commerce to include a wider range of activity with suppliers and clients, through public information highways. These requirements, either mandated by management or simply viewed as a step to optimize development and support costs, call for the creation of standardized assets, that once created, can be run anywhere.

2. First steps and Short term Goals
Once the primary driver or business reason that compels a service-oriented approach is articulated and agreed upon by all stakeholders (from the business and technical communities), it becomes relatively easier to establish the milestones that are to be reached. This approach is consistent with one of the commonly observed principles of successful SOA implementations. SOA is almost always best realized through an evolutionary process - an ongoing conversion of services that increasingly perform autonomously and thereby can be reused. This evolutionary approach does not necessarily mean a long drawn out exercise, it simply means that a sequence of steps have to be defined. The steps could become progressively larger and address a wider range of use cases, as each successful installation is completed and seen to work.

If your reasons to SOA happen to fall into either of the two categories described above, then here are some early steps and goals towards the realization of a flexible infrastructure:

• “Which business processes are most frequently changed?” Identification of 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 us an idea of what we will be dealing with, though in small bites. A parallel run, involving both legacy and the different versions, each incorporating progressively more services being exposed in each iteration, will be required during the transition.
• Documentation of the Use cases that will be impacted by changes to these applications; this will include a study of client-based executables 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”.
• Review of server based application code with a view to identify and abstract business processes from application functionality. This exercise accomplishes the goal of allowing us to form a reasonable estimate of the work and time lines involved.
• Potential latency issues are examined as a result of re-use and content heavy XML, as well as security issues in opening these assets for access. 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.
• Start building and exposing the separate functionality that is identified to be a part of one or more business processes. At this time, it is important to get started. You need a registry and/or a repository that describes the service, so incoming messages can find them. At first, the SOA could 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.

These short-term goals represent a set of actions that will lead to a functioning SOA. The SOA can scale up - as we identify further functionality that can be reused, leading to a progressively larger implementation. We call this a Bottom-Up SOA effort.

A Top-Down effort is also required. The purpose of this is to establish some basic ground rules that the entire SOA will live by. This is much like the role-played by a Federal government. In SOA parlance, it is simply called Governance.

3. Long Term Objective

An efficient and agile technical environment is traditionally demonstrated by time and cost measures. Therefore, these measures must govern the path towards the long-term objective and determine the success of its eventual realization.

The success of the target architecture should be measured by:

• Cost and time to develop and maintain the assets that perform the required business processes and the tangible and intangible returns from executing these business processes.
• The implementation of automated triggers to fulfill a larger number of routine business activities.

The first criterion is realized through building granular components and making them available for re-use through an expanding repository, progressively made available to a larger community inside and outside the firewall. This community will include third party suppliers and partners and hence the creation and publication of these assets must adopt industry standards.

There are three aspects of the move to SOA that need to be better-understood in-terms of their relevance to each stage of SOA evolution. The purpose of doing so is to retain our long-term objectives within each, but not let them, individually or collectively, paralyze us or prevent us from getting off the ground.

Governance -
The purpose of governance is to avoid lack of conformity between applications. It is difficult to establish all the ground rules when you start. As said before, SOA is an evolving process, in terms of standards, in terms of products and its use within the enterprise. Some fundamental rules common to a federated structure will be defined at the outset and modifications are inevitable.

Service Granularity -
This is one of the most discussed and debated topics today. Since it refers to the scope of functionality that a service exposes, one would need to plan the grain of the service based on the current application infrastructure environment. Waiting until the “right” level of granularity is established can become a never-ending discussion with no perfect answer; hence, it is important to understand your environment and plan/implement the granularity of your services in a simple and generic way, based on your current and foreseeable needs. SOA is an evolution; coarse grains may have to be decomposed into finer grains at a later time depending on the business process that is required at the time. This fact should not deter us from getting started.

Tools / Products -

BPM, BAM and EDA are some of the terms associated with the realization of SOA. They form part of the second group of long-term objectives and there are a wide range of products available within these categories. It is important to note that BPM and BAM products are not an essential part of an SOA and are in fact not advisable during the early stages. An increasing awareness of their specific benefits could be developed as progress is made and they could be introduced at the right time to enhance considerably the value of an SOA.