Benefits Of SOA May Outweigh Pains Of Reorganization

Meanwhile, other vendors, including Microsoft and Sybase, are facilitating that architecture through multiple middleware products that allow a variety of existing applications to work independent of one another and still be able to interact using XML messaging standards. Ultimately, the goal of SOA is to give every application feed an enterprise service bus (ESB) that will act as an all-encompassing interface to every system.

However, SOA still has some inherited shortcomings that can lessen its reputation as the ultimate architecture for integrating multiple applications. SOA will not work with many legacy systems that were not designed to interface with applications or that have only a limited response to other legacy systems.

The problem here lies in how these legacy applications were originally meant to work. In most cases, the only solution is to create an application bridge, a layer of integration logic that is meant to turn the legacy application into a pseudo-client/server application. Unfortunately, in many instances that requires a deep understanding of the legacy system to position code at the right modules without affecting execution. That spells many hours spent re-engineering legacy code.

Realistically, companies that are deploying SOA are going to have to make one of two tough choices: either expand integration to a point where all legacy systems will become part of the ESB, or rearchitect all the legacy systems that are difficult to integrate.

A more difficult problem to resolve is how data is formatted and accepted by a system. BPM systems sometimes can manipulate data with internal functions that can make it incompatible with legacy systems that depend on strictly formatted data inputs. Many BPM vendors give architects a lot of freedom with how their applications can intercept or analyze data in midstream. What's more, XML structures, even if validated and transformed correctly by schemas, can be wrongly interpreted by systems.

Simply put, there's no way to know whether what a system is reading is correct at any point. Having a good testing methodology is the only guarantee developers can ever hope for when working with composite applications.

On the positive side, dividing business logic into ever-smaller manageable modules, and in some instances exposing it as a service, can simplify application development. The idea is to create building blocks of reusable logic that can form Lego-like physical components that can be managed in a distributed environment by many kinds of developers. Moreover, with a BPM architecture in place, business analysts can play a larger role in developing applications because most of the code logic is abstracted and presented as high-level icons in a workflow.

A service-based architecture also makes applications more responsible for solving changing business challenges. SOA-based applications are simpler because logic is highly filtered and independent of any platform. Thus, any strategic decision made by executives can be implemented much faster if all the appropriate services are coordinated to respond to that new demand.

Since every piece of business logic is exposed, SOA virtually eliminates code redundancy because it allows developers to observe everything in one place. This reduction in code can make systems more agile and eliminate many programming metrics.

SOA is different from client/server and host-based systems and can be perceived as too disrupting. As part of SOA-based re-engineering or integration projects, solution providers should also offer training classes and even promote competency centers in which their architects can teach in-house developers how to move to this model.

Either way, it will be a daunting task to change every conceivable layer that has been put in place by several generations of developers. However, the holistic approach and benefits SOA can establish across an enterprise might justify the reorganization necessary to implement it.