SOA Disadvantages

SOA Disadvantages
Service Oriented Architecture Disadvantages & Applicability

Service Oriented Architecture may not always be the best architectural choice because optimal utilization of SOA requires additional development and design attempts as well as infrastructure which translates into costs escalation.

When it comes to applications, Web Services and Service Oriented Architecture is not recommend for the following:

Stand alone, non distributed applications that do not necessitate application or component integration; that would include, for instance, a word processing application that does not require request and response based calls.
.
Short lived applications or applications that are in any way limited in scope. This would include, for instance, an application that has been built as an interim solution that is not intended to provide full functionality or reuse for future applications.
.
Applications in which one way asynchronous communication is necessary, and where loose coupling is considered undesirable and unnecessary.
.
Homogenous application environments, like, for instance, an environment wherein all applications were built utilizing J2EE components. In these instances, it is not a good idea to introduce XML over HTTP for inter-component communications rather than utilizing Java remote method invocation.
.
Applications that need GUI based functionality. Like, for instance, a map manipulation application that has lots of geographical data manipulation. Such an application is not suited for heavy data exchange that is service based.

Of course, vast majority of these scenarios do not even apply to enterprise applications. Service Oriented Architecture is a network centric approach that requires complex service auditing and monitoring. Owing to the fact that service reuse and sharing tend to be the main features of Service Oriented Architecture, the quantity of service consumers will be rather high. This give raise to issues, as well as versioning and change management problems. Such problems necessitate a management infrastructure, that may become too costly for certain projects.

Service Oriented Architecture is a strategic solution with a lot of meaningful benefits and tactical applications. At the same time, however, you have to pass over a threshold in order to reap the full benefits of Service Oriented Architecture. Service Oriented Architecture typically entails an analysis of both costs and benefits.

The question then becomes: Will Service Oriented Architecture make the application integration process go smoother? Most of them will tell you, Yes. The Information Technology managers are currently utilizing Service Oriented Architecture to tie together legacy, custom, and commercial applications as a means of improving mission critical Business Processes.

The fact is, compared to past integration approaches, Service Oriented Architecture provides numerous benefits to a company. These include reusable Business Services that are independent of platforms, development based in standards, as well as the ability to make changes fast when it is necessary to keep with the speed of Business.
Service Oriented Architecture Road Blocks

It is quiet normal to feel impatient while adopting Service Oriented Architecture. It is essential not stress out by expecting an overnight success – like all things, Service Oriented Architecture takes time to start functioning properly.

The truth is that a lot of companies are finding it difficult to put Service Oriented Architecture in to practice. While most Businesses nowadays possess a keen awareness of what Service Oriented Architecture is, that does not mean they always know how to go about implementing it so that it yields the best results right away.

In fact, a lot of Businesses are finding that a combination of architectural, organizational, and technological issues are bringing their Service Oriented Architecture implementation efforts to a standstill. Still, other Businesses may lack the sufficient buy-in from the company executives that they need to take Service Oriented Architecture to the next level.

Below, we will explore some of the most common road blocks to Service Oriented Architecture implementation.

First of all, users must keep in mind that true interoperability is still out of reach. Today’s Service Oriented Architecture vision depends largely on loosely coupled interactions among heterogeneous systems. This vision is largely dependent upon standards based interoperability.

After all, cross platform and cross product interoperability is the modus operandi of Web services. In order to get past this particular road block, businesses have to push their vendor suppliers to become compliant with at least a few of the most basic service standards.

What is more, a lot of businesses do not have architects that contain the necessary skills to successfully implement Service Oriented Architecture. In order to be a service oriented architect, one must possess a solid grasp of enterprise wide architecture, while also being familiar with information architecture, technical architecture, data architecture, and business process architecture. Individuals with all these skills are indeed hard to find.

Another major Service Oriented Architecture road block is the fact that standards tend to be incomplete, badly conceived, or otherwise limited in some way. A lot of standards bodies have compiled elaborate maps of proposed standards that cover such components as security, integration, and management. While they continue to make progress on assembling standards on such maps, there is still a long way to go before a coherent set of interoperability standards for Service Oriented Architecture evolves.

Then there is the issue of corporate politics. For a lot of businesses, the relationship between the Information Technology side and the business side is strained – if not outright hostile. A lot of times, the business side of the operation will view Information Technology as a high risk, costly enterprise that places numerous limitations on the business’s ability to execute its strategic goals. At the same time, a lot of Information Technology individuals admit that their Information Technology history is littered with failed projects, overruns in cost, and a lot of activities do nothing to aid the actual requirement.

A Service Oriented Architecture that lasts twenty two months might be eighteen months too long. It is best to be take a shorter time and get things done right. That way, you will not have to deal with business management’s attempts at blocking your progress towards Service Oriented Architecture optimization.

Then, you might have to deal with the nasty three S’s – that is, selfishness, stubbornness, and skepticism. While one should always remain realistic in the face of the numerous problems posed by Service Oriented Architecture, in every business there will always be an individual whose skepticism transcends all reason and wants to turn it in to an emotional issue.

A lot of people also resist new approaches, not because they really think there is anything wrong with the approach, but just because they are too lazy to learn new skills. Businesses who want to have a chance with implementing Service Oriented Architecture should identify who the road blockers in the organization are and take them aside for a long conversation about the potential benefits of Service Oriented Architecture.

While these road blocks may seem problematic, they can each be overcome with a little bit of effort. In fact, none of these road blocks should prevent you from taking the first steps towards the implementation of Service Oriented Architecture. Road blocks very well might slow you down, but for the vast majority of businesses utilizing Service Oriented Architecture methods today, the advantages, by far, outweigh the disadvantages – and that is a fact.