Service-Oriented Architecture: Adoption Challenges

Introduction

Service-Oriented Architecture (SOA) is one of the topics being talked about in the IT field. It has been grabbing the eyes and ears of both IT and business professionals since the beginning of this century. This widespread hype is due to the fact that SOA is a promising paradigm with a number of accompanying benefits for its adopters. Some of these benefits include (Hassan, 2009; Kobielus, 2005):

• •

  Reusability: Technical components and business functionalities are abstracted, after removing redundancy and inconsistencies, in a reusable form so they could be used again and again by different systems and business units.

• •

  Data Sharing: Underlying data could be shared between different systems, by wrapping data sources with joint data service.

• •

  Location/Platform Independence: Greater interoperability is enabled between different systems and business partners. This is achieved by allowing access to services regardless of their physical locations or used platforms.

• •

  Business Alignment: Since the “service” is originally a business term, SOA enables better alignment between IT and business professionals.

The ability to realize the aforementioned benefits depends on properly addressing the challenges that SOA adopters might face. These challenges range from a prior understanding of SOA terms through implementation obstacles to management strategies. The lack of awareness of these challenges could place SOA implementations at risk and could lead to complete failure among its adopters.

Challenges

During the migration process to SOA, adopters face up to nine key challenges:

• 1.

  Misconception. What is SOA? Is it another name for XML web service? Is it a product that an organization can buy? What are its key elements?

• 2.

  Lack of Education. How is SOA different from other software methodologies? Is it essential to educate and train prospective adopters on the “nuts and bolts” of SOA? If so, what do they need to learn in order to effectively deploy SOA?

• 3.

  Over Expectations. Is SOA a panacea to all of the organization’s problems? Does it fit all needs? In which scenarios should the adopters avoid SOA?

• 4.

  High Up-front Budgets. What about the initial budgets needed for the migration process? One of the benefits of adopting SOA is cost reduction, so, how is that possible if high budgets are required during the initial migration phases?

• 5.

  Lack of Trust. How essential is the trust between SOA parties? Since trust is a human term as well as a technical term, how can the adopters build and guarantee it?

• 6.

  Inappropriate Implementation Technologies. How critical are the chosen implementation technologies to the success of the SOA migration process? Is XML the only available technology for SOA implementations? Is it always better to use standards-based technologies rather than the vendors-based ones?

• 7.

  Lack of Security Terms. How can the providers secure their services and the underlying resources against key security breaches and malicious attacks? How can confidential and sensitive information be secured against leaks either while moving between nodes or when saved at any end?

• 8.

  Slow Performance. How can implementers overcome the slow application performance that may occur due to the extensive use of document-oriented messages in SOA? Are there recommended techniques to enhance the overall performance of both services and client applications?

• 9.

  Lack of Governance Framework. How will the adoption and operation phases be monitored and audited? How will the services be controlled? Who is responsible for defining the management policies?