WHAT IS THE FUTURE OF SOA

For the past few years Service Oriented Architecture (SOA) has risen from being a concept promoted by few to become one of the most important architecture styles enterprises are
trying to adopt. Though many of the bases upon which SOA is founded are not new, its link to achieving business results makes it very appealing.
However, as with any new and promising concept, a great deal of excitement is associated with SOA, which could spell trouble for both its promoters and those committed to its adoption. Today there are no shortage of claims from both believers and doubters of its benefits. Many early adopters facing challenges and still missing capabilities needed to support all business needs. The next few years are critical to the success of SOA. To silence its doubters and live up to its high expectations, SOA must evolve and extend to incorporate features from other
emerging techniques and architectures.

A typical question regarding SOA is whether this is something new or revolutionary or whether it is just a new (marketing) hype that will go away pretty soon.

My answer regarding this question is as follows:

SOA does not introduce any new, invented concept. It is a model that brings together existing concepts and practices for a specific set of requirements. You might evensay that SOA is nothing but the application of brainpower and common sense for distributed systems. Look at existing
successful integrated large system landscapes, and you will find all the concepts.
One improvement with SOA might be the fact that Web Services (despite all its flaws) introduces a new standard for interoperability. However, there is another important aspect of SOA, which represents a revolutionary approach different to what we’ve typically seen before the acceptance of heterogeneity. In the past, far too many solutions were based on the idea of homogenization. Yet in systems beyond a certain size, homogeneity is simply not possible.
Homogeneity does not scale, which means that any approach that requires homogeneity will sooner or later fail. Accepting heterogeneity changes the way we design large systems landscapes. This mental shift might be a small step, but it can have dramatic consequences (similarto agile programming, which accepts that requirements change instead of trying to fight against this fact). Based on this I definitely think that there is a future for SOA (just
as there is a future for brainpower ;-).
However, that doesn't mean that SOA is easy. There are places where SOA is appropriate and places where it is not.
And in practice you have to deal with SOA appropriately. You have to find the right level of loose coupling, have to make a lot of important design and architectural decisions and have to set up appropriate processes and organizational structures. Technically, I have seen in my projects (having the size of up to 10 million service calls a day) two major technical problems:

First, there is a tradeoff between performance and reusability.
Second, testing becomes incredibly difficult because due to the distribution of the processes
you have to prepare for distributed testing which implies that all stake holders have to prepare corresponding test data and that the infrastructure (the enterprise service bus) becomes your debugger.
To summarize:
If you can avoid distributed business processing avoid it, but if you have the requirement of dealing with business processes distributed over multiple heterogeneous systems
with different owner, SOA principles are the only way to be able to be successful and still be flexible.