Torry Harris Business Solutions Presents “Six Steps to Transitioning Successfully to SOA”
Enabling reuse of existing and legacy systems by at once decreasing dependencies and allowing for improved communication across disparate systems, service-oriented architecture makes IT a strategic partner in achieving business objectives.
Iselin, NJ, May 09, 2007 --(PR.com)-- Torry Harris Business Solutions (THBS), a global niche technology services and solutions provider for mission-critical distributed enterprise computing and middleware presents six steps to embarking on a service-oriented architecture (SOA) implementation in a cost effective offshore model.
“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 infrastructure capable of adapting to business needs,” said Thiru Sivasubramanian, Country Manager USA, Torry Harris Business Solutions. “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 roadmap. Our attempt is to help de-mystify the methodology.”
Torry Harris Business Solutions has its heritage in middleware and distributed enterprise computing, which has naturally evolved to become the basis of SOA methodology. The company has worked and partnered with myriad SOA product vendors, and provides advice on the use of open source software in SOA implementation. The following steps are designed to help 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. A parallel run, involving both legacy and the different versions, each incorporating more services, progressively exposed in each iteration, will be required during the transition.
2) Document 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.”
3) Review server based application code to identify and abstract business processes from application functionality.
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.
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 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.
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. 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?
About Torry Harris Business Solutions
Torry Harris Business Solutions (THBS) is a global niche IT service provider that creates and maintains mission critical systems for the telecommunications, banking, financial services and insurance (BFSI), government, health care, manufacturing, utilities, automotive and travel industries. Founded in 1998, THBS is headquartered in New Jersey with offshore development centers in Bangalore, India, Shenzhen, China, and sales offices in Europe, Middle East and Asia-Pacific regions. THBS employs 1,000+ staff members worldwide. For more information, please visit their website.
“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 infrastructure capable of adapting to business needs,” said Thiru Sivasubramanian, Country Manager USA, Torry Harris Business Solutions. “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 roadmap. Our attempt is to help de-mystify the methodology.”
Torry Harris Business Solutions has its heritage in middleware and distributed enterprise computing, which has naturally evolved to become the basis of SOA methodology. The company has worked and partnered with myriad SOA product vendors, and provides advice on the use of open source software in SOA implementation. The following steps are designed to help 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. A parallel run, involving both legacy and the different versions, each incorporating more services, progressively exposed in each iteration, will be required during the transition.
2) Document 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.”
3) Review server based application code to identify and abstract business processes from application functionality.
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.
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 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.
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. 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?
About Torry Harris Business Solutions
Torry Harris Business Solutions (THBS) is a global niche IT service provider that creates and maintains mission critical systems for the telecommunications, banking, financial services and insurance (BFSI), government, health care, manufacturing, utilities, automotive and travel industries. Founded in 1998, THBS is headquartered in New Jersey with offshore development centers in Bangalore, India, Shenzhen, China, and sales offices in Europe, Middle East and Asia-Pacific regions. THBS employs 1,000+ staff members worldwide. For more information, please visit their website.
Contact
Torry Harris Business Solutions
Diganta Barooah
91-80-41827200
www.thbs.com
For further information, write to us at info@thbs.com
Diganta Barooah
91-80-41827200
www.thbs.com
For further information, write to us at info@thbs.com
Contact
Categories