|
The information overload on SOA is largely on describing the merits of SOA, principles of SOA andAbstract 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 widely 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.
1) The need to respond quickly to change in business needs
2) 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.
|
