News Stay informed about the latest enterprise technology news and product updates.

IT shop looks past SOA to Windows desktop integration

Developing new call center workflow applications, a Microsoft shop has implemented Windows-based composite service integration architecture over an API-centric service-oriented architecture.

Service-oriented architecture (SOA) was one option for integrating applications into a single user workflow on a Windows desktop, said Ken Brande, director of information technology at Afni, Inc., but it is not the one he chose.

When you look at desktop integration, the link to the backend application is via the Win32 adapter layer. So we're not actually interfacing to the backend.
Ken Brande
Director of Information TechnologyAfni, Inc.

Microsoft has a unique corporate approach to architectural problems, often eschewing SOA terminology, and, as Brande proves, Microsoft developers can also follow the road less traveled shunning the often API-centric view of SOA held by many in the Java community.

Afni, a 70-year-old company headquartered in Bloomington, Ill., with 5,000 employees who provide call center and collections services for North American-based corporations, recently hit upon a problem that presented some unique problems for an enterprise architect designing workflow applications. Brande needed to take disparate applications from an Afni client that does not want outside developers messing with its legacy back office systems. To serve the client Afni needed to integrate systems processing data for billing and collections into workflows for customer service representatives (CSRs) in the call center, but without touching the hardware or software in the back office. When contemplating this problem two years ago, Brande said he considered several alternatives.

"The first thing we needed to make a decision on was the architecture platform," he said. "When you look at systems integration there's several different basic approaches, backend integration, server integration, then there's things emerging such as SOA, and other messaging and middleware technologies that are supposed to allow applications of disparate technologies to communicate."

In the end, Brande chose none of the above and hit on an approach called composite service integration (CSI) using Microsoft tools and technologies and a development platform from OpenSpan, Inc., which specializes in desktop integration. The OpenSpan Platform 3.0, supports .NET 2.0 and the Microsoft Customer Care Framework (CCF) 2.6.

What is unique about CSI with this technology, Brande explained, is that it has nothing to do with APIs or back office systems, which his customers did not want him to touch even while integrating their applications.

"Architecturally, doing composite service integration is a very different approach to getting applications to communicate with each other, than SOA, which is more of getting APIs to the backend system to create that common layer that you can develop new applications against," Brande said.

From his point of view, CSI achieved similar results to what can be done with SOA in terms of bringing services into a unified application, but without the APIs.

"If you look at service-oriented architecture interfacing at an API level to the backend system, those interfaces are brought together in the service-oriented architecture so that as a developer you can develop new user interfaces and capabilities to that architecture," he explained. "In effect they accomplish the same thing – SOA and composite service integration. However in terms of how we would view the composite, when you look at desktop integration, the link to the backend application is via the Win32 adapter layer. So we're not actually interfacing to the backend."

Everything Brande is doing with the applications running at the corporate customer sites is based on what is happening on the Windows desktop. The OpenSpan tools, which have the look-and-feel of .NET, allow Brande to compose various Windows processes into a new workflow application for the CSRs in the Afni call center.

"The way the process works you take the OpenSpan Interrogator, which is part of their development environment," he explained. "When you run the application you want to work with on the desktop, the Interrogator exposes all the objects as methods in those applications as Microsoft sees them at the adapter level. Once they become exposed, they are put into the OpenSpan Studio, which is almost identical to the .NET Studio environment, where all of the objects that are available on the desktop are now available in a graphical development environment. So when you interrogate an application on the desktop, it exposes the objects, those objects become things you can drag onto a graphical development environment and link and pass data between the objects."

Brande said CSI provides the advantages people talk about when they talk about SOA.

"All the things you hear about – time to market, ease of deployment, simplifying the architecture, a single layer interface as opposed to multiple layers to deliver a user interface – were all part of our decision to go with a composite service integration architecture."

Asked what advantages he sees in CSI as opposed to API-centric view some hold of SOA, he said, this .NET approach provides flexibility he did not see in Java-based tools.

"When I'm looking at the desktop and what the user is visually interacting with at the desktop, my opportunities for what I'm going to do are limited in an SOA environment," Brande said. "Let's assume I go with WebSphere. I'm limited in what I can do at the desktop based on what WebSphere provides as opposed to with composite service integration where I can do anything I want. I can use any front-end tool. I can extend to any environment I need to extend to. And I don't have to do a wholesale replacement of my front end."

CSI allows him to provide CSRs with a unified desktop application with workflow that saves time, he said.

"If I've got three applications running on my desktop that are not currently talking to each other, I'm doing a lot of cut and paste," he said of the CSRs workflow problem. "And I'm making a lot of manual process decisions based on logic that I as a user have to remember or look up."

He makes the argument that desktop applications can be brought together easier with CSI.

"If I want to automate a cut and paste function I can do that and not change the UI at all," Brande said. "As opposed to if I wanted to get data from these three applications to communicate together in a SOA architecture I'm pretty much insulating those three applications almost exclusively from the UI to get the new UI that I would need for the SOA to work."

For more information
Microsoft: The SOA road less traveled

SOA gurus: .NET simpler than Java, but stuck in Windows

In terms of what Brande's Microsoft shop has been able to do for call center operations, his business side counterpart Mike Garner, vice president of call center services, said the cost savings has shown "impressive results" since first being implemented in February 2006.

The workflow processes has reduced the time it takes a CSR to handle a call on behalf of a client. "It was a baseline of 450 seconds, now we're at 395," Garner said. "So you're looking at an 11 percent savings."

Seconds are important because in the call center business time really is money. Costs per call range from one to two pennies per second, Garner said. With millions of transactions those pennies add up.

"Let's say I did 35 million transactions last year," he said, explaining what motivated him to seek help from Brande on architecting a new call center system. "If I could take 10 seconds off each one of those transactions, that's worth $3.5 million dollars. That was the compelling reason."

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.