|
Offshore implementation of software projects has for several years been accepted as an effective manner to overcome constraints in terms of cost and time. The selection of an offshore partner and the role played by the partner in projects involving a migration towards service oriented architecture are discussed in this document. The topics addressed include a description of the benefits, challenges and governance involved in such a partnership. Tasks and responsibilities of each of the partners, the client and the service provider, specific activities that are better executed within the onsite environment and those that can safely be transferred to an offshore location, thereby effectively utilizing the resources at both ends are explicitly described.
This document is written as a guide to an alternative mechanism for project implementation for business owners holding responsibility to deliver IT solutions in the SOA space. It could also be of interest to enterprise architects, project managers, and others involved in creating and executing software projects who would like to know more about how the phenomenon of offshore/onsite coordination, that emerged in the nineties, can be effectively applied towards realizing the promise of SOA . Offshore/onsite partnerships rightly managed, with an awareness of the pitfalls and the correct set of mutual expectations established early in the project cycle, help considerably in realizing these projects, be it a full scale enterprise adoption, or a series of small iterative steps towards increasing reuse of technical assets.
The concept of using offshore resources towards implementing IT solutions has been increasingly adopted by large and medium enterprises during the past two decades. In the early eighties, large monolithic systems that demanded coding at the client site required a model where technologists from overseas worked on the system performing tasks on a time and material basis under day-to-day supervision. The advent of distributed computing in the nineties, larger and improved connectivity through public and private channels, allowed a gradual shift towards a model where certain parts of IT projects were executed by the service provider in foreign locations. India is by far today the world's largest offshore provider of IT services to enterprise clients in North America and Europe. Other locations that offer such services are South America, the Eastern bloc, Northern Ireland and China.
Service providers in these locations, who were in the past and even today primarily chosen because of their cost benefits, are moving up the ladder in terms of developing larger and more sophisticated delivery skills. They offer a variety of programming language skills and are adept in the configuration and use of products from most major product manufacturers. Most of them practice good testing procedures with some going so far as to build environments that duplicate the client's onsite environment. All of this permits finite parts of the project to be executed in part overseas under fixed prices and adhering to mutually agreed service level agreements, as opposed to older tightly controlled time and material model. Adoption of standards facilitated such delegation.
Thinking of Service-oriented Architecture (SOA) as a methodology of implementing IT solutions, rather than a technology, allows significant benefits to an enterprise that seeks to adapt to change. The concepts and designs behind SOA are not new, they are derived from distributed n-tier systems that have been adopted and are functioning well in most large enterprises all over the world. The nature of SOA mimics the model of offshore development where services are provided on demand for finite discrete parts of the whole. These units of service are atomic, created as single reusable units of logic that can be combined when required to fulfill business functionality. Therefore the model of constructing such units in offshore locations, away from the client environment, within tightly defined parameters of construction and acceptance, mirrors the eventual use of these independent units in a business model. Further adoption of SOA is almost always through an iterative process that gradually replaces existing tightly bound applications. These iterations are mapped to the business priorities and are created under the discipline and standards that are first created in a plan that governs the enterprise architecture.
|
