As editor, I review a great many proposals for articles. A good portion of them deal with SOA, which is to be expected. When I review them, I'm reminded that there are two very different views of SOA, which in my opinion are both equally true. I call this the SOA Dichotomy, because these views seemingly contradict one another.

One of the views is that SOA makes things easier for the enterprise. Certainly this view has a great deal of merit and validity. Fully realized a service-oriented architecture allows an organization to fully leverage their investment in the real intellectual property of software - the service that it provides - without closely coupling that service to a single application. It's hard to overstate the impact this can make; it's truly a transformation of the way IT provides information services to the enterprise. Applications can now be assembled, and business processes composed from services and altered rapidly in response to changing business conditions. The workplace can be transformed - workers no longer need to be dependent upon a series of applications to do their work. Instead they can have a single composite application that meets all of their needs without ever having to leave to transfer to another application. Anyone who's ever been on hold with a call-center representative while they said, "Can you hold for a second, that's in a different application," knows how valuable this can be. Call centers know it as well - they know to the penny just how much a single second's delay costs them. Even before an enterprise completes its transformation to a fully deployed SOA environment, the benefits of interoperability and increased agility grow dramatically with every application that is decomposed into services in an effect similar to the very familiar Network Effect. The more services deployed, the more valuable they become. Usually, this is attributed to the fact that SOA makes things simpler, easier to do.

But the other view is the familiar devil-in-the-details argument. While not exactly contrarian, there is also a group who insist that SOA introduces increased complexity and requires greater attention to details. It's hard to argue with this when you try to create composite services and need to introduce concepts like security and transactionality to organizations that never consciously had to consider them, because they were always embedded in the application and were dictated by whatever the application vendor or in-house developers decided was the best approach. SOA requires an increased awareness on the part of the IT organization, and greater responsibility from the business side with respect to understanding the full impact of their decisions. Not that that's a bad thing, because this increased self-awareness helps a business to understand itself and adapt to changing conditions. SOA has value, but it's not as easy as it sounds at first.

How do we resolve these different views on SOA, or do we even need to? This is where the dichotomy comes into play - both views are correct. What's more, not only are they both correct, but they are both necessary. The key understanding is that SOA is a business paradigm shift, not a technology one. The true goal of an SOA is to make it easier to affect business changes and make business decisions. From that perspective the ability to work as a service distinct from an application provides strategic value. The ability to create composite services and manage them from a business perspective is a competitive advantage in today's marketplace. In tomorrow's, it will be a requirement.

That doesn't mean that a business shift makes things easier on IT. Nor does SOA. IT knows full well that while a single vendor system often has its issues, dealing with a federated heterogeneous computing environment often is more least-common denominator than best of breed. With multiple standards bodies and numerous standards and versions, the SOA landscape is cluttered and complex, and requires skilled practitioners to successfully navigate the muddy waters of a service environment. They also know it's a better place to be than the one they are leaving, which had the same problems, but no solutions, even if the solution in this case increases the complexity of their jobs.

And that's the dichotomy of SOA. It is both easier and harder, more complex and simpler. It's all a matter of perspective.