SOA tools--virtually bridging the legacy divide Part I

In recent memory, there has probably not been an IT term more widely used but more vaguely defined than service-oriented architecture (SOA). In a recent IDG Research Services Group survey, almost half of IT professionals surveyed admitted they didn't know what SOA is. You'd think they could go to the people who create the components necessary for SOAs, but that is still a very immature space, and there's no real consensus on what those components are.

Jason Bloomberg, senior analyst at ZapThink, an SOA consultancy, says, "A lot of vendors just want to take the old stuff and do a tweak to it and turn it into something new, and it usually doesn't work."

To add to that instability, there are relatively few completely flexible SOA installations to learn from, and SOA standards are nowhere near being finalized. That said, however, most experts concede that SOA is the next inflection point in the evolution of IT in the last 50 years--first there were mainframes, then client/server, then thin client and now there is SOA.

Bloomberg defines SOA as "an approach to organizing IT resources to better enable the business to leverage them in a flexible manner. We see it as an enterprise architecture that [deals with] the relationship of business to IT where you organize software IT resources into loosely coupled services, which is an abstraction that represents the functionality of that software in order to provide for greater agility to the business."

The key points to pull from that explanation are these: SOA is an "architecture," a blueprint for retooling an organization's IT applications and business processes by using a loosely coupled integration method like Web services to link them so that those links can dynamically change as the processes need to. That's the technical goal. The business goal is agility--to respond to changes in the business environment to be more competitive and better serve the customer without undermining service with lengthy application development.

SOA is necessary because most legacy environments are heterogeneous. To make applications from different vendors interoperate, developers have used tactics like writing proprietary code or using enterprise application integration (EAI) adaptors or even lately Web services to create rigid, one-time links in a strategy commonly known as point-to-point integration. For example, if you added a new app to the environment or had to integrate those linked apps into a process in which they were not previously involved, you had to start from scratch, do it in a custom way, and much of your work had to be tossed if a change in the environment impacted those applications or processes. With SOA, services are loosely coupled and serve as changeable interfaces between apps and processes, so when an event happens, like an order is submitted, the automated intelligence in the services knows which service(s) need to be activated and changed to process the order.

At first, SOA has little to with technology and everything to do with creating a blueprint--"mapping" an organization's applications and processes, figuring out how that almost inevitably heterogeneous environment can be reintegrated to dynamically reconstitute itself as business needs dictate a year or two down the road. At the first stage, SOA is not about "deploying" services linking applications and processes. It's also not about "managing" that dynamic network of integration links at runtime either, though both of those latter phases are indispensable to achieving a functioning SOA environment.

Invariably, getting to an architecture is an iterative process, complicated and inherently something that can't be finalized. Change, adaptability is the raison d'etre for an SOA environment. So most organizations first target a subset of processes. For instance, Bloomberg says banks often tackle processes involved with customer information to get a single view of a customer across lines of business, and the lines of business would share the services created. They might then do a pilot that will remain in production, learn what mapping, implementation and management techniques worked, and then use what they learned to integrate another relatively contained portion of their IT environment.

But Bloomberg finds that the long-term discipline, best practices and governance required for such an extensive process is lacking in many organizations. "A lot of companies get into the implementation before they've really fully created an architecture," he explains.

Despite the time and challenges, though, all the experts agree that you should not be deterred. The benefits are just too compelling and the competitive advantages too obvious for you to wait. What's more, every major vendor has bought into SOA--the best platforms sold will be designed to yield an SOA environment.

While implementing an SOA environment presupposes creating a blueprint of the existing one and the changes that must be made, creating the architecture is unavoidably a manual process--it all depends on what's in the heads of the IT architects and on what the future needs are of the business executives.

Are Web services necessary for an SOA?

A common misconception is that Web services are required in creating an SOA. Not true. Sometimes they aren't even the best way. It all depends on the nature of the legacy environment. The general rule is that the more heterogeneous the environment, the more value Web services have in the long run. In less heterogeneous environments—for instance, ones running predominantly on J2EE that don't interact a lot with outside partners--Bloomberg says IT has more control over consumers and apps and processes have to be less flexible and dynamic. So a less loosely coupled method of creating and managing services could be used. But, he counters, if the internal environment interacts with external partners' environments on different platforms, links must be more loosely coupled and standardized because interactions will be more improvised and less predictable. Web services best allow that.

Types of tools

Daryl Plummer, group VP of software infrastructure at Gartner, categorizes SOA tools in three classes--those for creation (before being used in the infrastructure) or deployment (how they are used in the infrastructure) and management (how they are permitted to be used and interact in the infrastructure). The latter two, he says, are often performed by the same tool.