Is an Integration Layer Right for You?

Given the potential roadblocks to moving to a SOA, it's important to evaluate whether it should be a short- or long-term goal. Because a messaging infrastructure is necessary to support grander visions of services and a SOA, most companies begin there. Many may not need to go further.

"SOA is being presented as the latest silver bullet," says B Lee Jones, vice president for IT and CIO of Stratex Networks, a wireless telephone equipment manufacturer. "I still need to be convinced that the ubiquitous interface is something I need to have. I don't look at it as a downside to have some redundancy in my applications, because my systems ain't broke." Jones says he has reduced integration costs and increased flexibility by using intelligent middleware and minimizing customizations in the packaged applications he installs. Still, he says, "If I had a problem with integration, the promise of SOA is good. I'm willing to be convinced."

Larger organizations can find convincing evidence based on the number of integration cobwebs they have hanging off their major systems. "Count up the number of point-to-point connections to a particular system and you can predict what the most popular service will be," says Wisconsin's Miszewski. That's how he chose his first service pilot. A function sitting inside one of the Department of Transportation's systems that converts addresses into pinpoints on graphical maps looked like an old mirror in the attic, enveloped in dusty point-to-point connections. At first the agency was fearful, concerned about not only the higher transaction loads on the system as it became available as a service but also the loss of ownership of the system itself - typical for organizations new to a services approach. But "once we developed two or three services, they got it", says Miszewski. "Once you take the fear away, there is only cost savings and productivity improvement in front of them, and adoption becomes much easier."

Though services can save time and effort even when they are only small pieces in applications that are otherwise traditionally developed, the real long-term strategic payback comes when they become the backbone of an important cross-enterprise business process. At Verizon, the order-placement process - at least the IT part of it - is now composed entirely of services, each representing a particular unit of work in the process. The process begins when the credit verification service qualifies the customer. The address verification service ensures that Verizon can provide telephone service at the customer's address. Next, the reserve service retrieves and locks a new phone number. The activate line service makes the actual phone line go live. Finally, the start billing service begins the phone usage collection and billing process. (The line test service comes into play if the customer has trouble with the new line.)

However, not every step in Verizon's ordering process can be transformed into an automated service. Some work still requires people. In the ordering process, those boundaries between automated services and human interventions are often marked by event notifications. For example, if a customer tries to set up a new account but fails because Verizon doesn't serve that area, Zafar has programmed an event into the system to notify customer service representatives when service becomes available.

The Final Steps: Events and Business Accountability

Think of events as the referees of the business process. For example, events can be programmed to send an e-mail notification to a customer service representative ("that phone number is not available") or to kick off a service-based unit of work ("find new phone number"). Like services, events are defined in business rather than technology terms.

If services represent what the business does, events define when those things should be done. Most enterprise business processes today have the smarts of a stump, says David Luckham, electrical engineering research professor emeritus at Stanford University and a pioneer in event-based programming. The true value of service-oriented processes will be realized only when those processes can sense and respond to events that matter to the business. This kind of capability could begin to take off by 2007, predicts Gartner analyst Roy Schulte, when standards for what he calls complex event messaging begin to emerge.

But the integration layer won't truly be all grown up until it becomes a business responsibility rather than an IT responsibility. In theory, as the links between services and events become ever simpler and more descriptive, businesspeople should be able to take over the linking duties themselves by "dragging and dropping" services they see on a screen in order to create new processes or modify old ones. That model has already been introduced by business process management (BPM) software vendors (see "Business Process Management: A New Glue or the Old Soft Shoe?", CIO March), but the packages aren't yet capable of putting an entire SOA in the hands of businesspeople.

When they are, the only remaining barrier to IT-business alignment - the sense among businesspeople that they cannot control their own destinies - will dissolve. It will take time, but the vision is there; and with the rise of Web services standards, CIOs can begin to construct that vision themselves, right now.

"We want to engage the business in a business-process-flow conversation rather than the traditional 'Tell us what you want and we'll do it' approach to development," says Redshaw.

Wisconsin's Miszewski sees that conversation already getting less awkward and more satisfying for all involved. "This is truly disruptive technology for integration," he says.

"It's about time."