Welcome to a very special First Look podcast. I'm your host, ebizQ's Project Manager, Gian Trotta. Our guest today, Leif Davidsen, is IBM's Worldwide Product Marketing Manager for WebSphere Application Integration. Before that, he was Worldwide Marketing Manager for B2B software and the Worldwide Product Manager for WebSphere Message Broker. He's almost uniquely qualified to talk about the most efficient entry points and the role of ESBs and SOAs and IBM's continually evolving solutions in this area.

Welcome, Leif and thanks for joining us.

LD:Thank you, Gian

GT: We've been hearing a lot about ESBs lately; can you tell us what they are? Why an ESB is so important to a company's business? And how does an ESB relate to the overall topic of an SOA?

LD: I think it's probably easier to start by explaining where an ESB sits as part of SOA. We position an ESB very strongly at the heart of SOA. And it is easy then to explain it if we talk about SOA in more general terms.

SOA is not something you can buy off a shelf. It's very much a journey for many businesses. It's where they want to get their enterprise to, both their business infrastructure and their IT infrastructure. And in order that it's not too hard a transformation, we at IBM actually talk in terms of entry points to allow people to envision themselves actually starting off on this journey towards SOA.

We have five entry points to SOA. Three of them are business focused -- people, process and information and how the business might reflect those parts of itself in SOA. And then we have two more technical entry points, reuse and connectivity. Those technical entry points are about enabling the changes to the IT infrastructure that will allow it to proceed down this SOA road. Fundamentally, in the connectivity entry point for SOA is the thought of an ESB connecting applications and services together. Is that clear so far?

GT: Yes -- why then is ESB so important to a company's business?

LD: Well, the ESB, as this layer that sits between applications and services, it's really the decoupling links that otherwise might occur. What many businesses today tend to have, is a real rat's nest of connectivity links between their existing applications. What's happened is that as businesses have changed and evolved over time, they've taken their core applications, the applications that really run part of their business and they may have made changes to those applications such that more and more applications want to connect to them. By building point-to-point hard coupled links between those applications what you're doing is you're building more and more interface logic into the applications themselves.

This eventually swamps the actual business logic that the application is actually there to perform and will actually lead to more and more costs as you gradually want to change and maintain that application, and it will introduce the potential for errors or fragility. And what the problem that businesses encounter when they want to then move to SOA is, is that these applications become almost completely unusable in an SOA environment if you want to then reuse them as services, where services are actually trying to get to the core business logic itself rather than be interested in the specific way in which they are invoked in terms of an application interface.

An ESB should provide a completely decoupled infrastructure allowing a business to make use of the actual core business logic with all the interface layers being defined and managed and maintained within the ESB layer and not in the applications themselves.

GT: Do you have any wider user case studies on this?

LD:Well, we've obviously been working with quite a lot of different customers over the years, many of whom were fundamental in driving us towards creating our ESB technologies. What's always been encouraging has been that these customers span both the globe in terms of where they're running their businesses and in terms of the different industries that they exist and successfully perform in. I was actually just reviewing some of our IBM customer success services which are available on our external Web site and a few actually sprang to mind in terms of these customer examples that might be useful.

One of them, in banking, is HypoVereinsbank. Their line of business, they were finding, they were stuck in a silo. It's very much a silo mentality in terms of only wanting to connect to their own applications, which obviously restricts their growth capability. So they wanted to implement an ESB to allow them to move to a much more component-based building block model for their business, allowing their services to be more widely used across their business.

Another interesting case study is a company called Ubench, who work in auto leasing. They're using very innovative technology -- wireless telemetry devices in their leased auto fleets that allow them to offer capabilities such as automatically detecting when services or maintenance is required and sending that back to the other value chain suppliers across their leasing business to arrange that. And then there are other companies, like a media company, VRT, who wanted to put in place an ESB to connect their digital and tape-based media assets for both faster, efficient storage and retrieval of those assets. So there's all sorts of different ways in which you can use ESBs throughout your business today. And that's the way some of our customers are already looking to implement ESBs.

GT: Right. It sounds like the company could use more than one-type of ESB? What kind of ESBs does IBM offer? And what new tactics and strategies do they represent?

LD:That's actually a very good question because those examples that I gave you, we can drill a little deeper and actually see the different ways in which those business really needed an ESB technology and the different types of ESB technologies they then implemented. All of which came from IBM.

Bear in mind, IBM has been in this space for a long time. Our call messaging product, WebSphere MQ, has been at the heart of many businesses, providing decoupled connectivity between applications for more than 12 years. So that's breaking down some of that rat's nest of linkages.

What an ESB is required to do, however, is that it might leverage that transport layer the MQ provides. It really provides much more intelligence in terms of routing the information between applications and services and also transforming and performing intelligent processing based on the content of the flow, based on awareness of each application that's actually both sending and receiving the information.

Now if you look at it from a company's point of view, they woule want an ESB to really meet their specific business needs. Let's take, for example, another company, called Grohe, who's a supplier of premium fittings for bathrooms and kitchens faucets and showers, that sort of thing.

LD:I bet we all have. So they along with many other businesses use SAP for their ERP systems, and that's a critical part of their infrastructure but they also have many other business critical applications. In trying to make the most use of their investment in their SAP system they wanted to make sure they coule actually connect their applications very swiftly to SAP, and they were finding that because of the complexity of their business model, there was a lot of work to be done in making these connections.

But by putting in place WebSphere Message Broker, which is one of our ESB products, which is really capable at connecting heterogonous applications and ERP systems such as SAP, they coule actually speed up the way in which they connected SAP to their applications and then they found that they reduced the time by up to 84%. So that's one example using the WebSphere Message Broker product, which is our advanced Enterprise Service Bus.

The company that I mentioned before, VRT, the media company, is actually using one of our other ESB products, WebSphere ESB, that's ideally designed for service-based integration. They had built an almost completely Web services-based infrastructure and the data types, the metadata, were all easily describable in terms of XML and sort of more open data structures, so they could use WebSphere ESB to provide the intermediation between the different applications and data types.

Now, WebSphere ESB is also running at the heart of our process server product at another company, Macrovision, who provides digital rights management. They were using a process server and had an e-commerce front end to their business. What they did, was they actually implemented the third ESB product that we have, the WebSphere DataPower XI50 Integration Appliance to front end and offload the traffic flowing from their e-commerce site, handling all of the web services and XML data types to their back office and process server implementations. That allows them to speed up those applications and that process server layer, so that they don't overload it with the heavy processing involved with XML and the data power application device is a very different sort of ESB, it's sort of unique within IBM.

GT: It seems that there's a range here, ranging from simple Web service integration, all the way to the offloading of XML and Web services in application integration.

LD: That's right, it's a range as dramatic as those of our customers business needs.

GT: So why then, would others in the market place only offer one type of ESB?

LD: Well, I guess you got to bear in mind, that IBM's been doing this for a long time now. We've been working with tens of thousands of customers in this space. We're therefore very aware of the needs of our customers. IBM has been investing more than a billion dollars in WebSphere software development for quite a number of years now, and this is really to make sure that we focus the WebSphere product deliverables to really meet the customer need as our customers evolve their business models toward SOA and some of the other changes in technology and business development.

And because of this sort of wide-ranging view that IBM has in terms of business needs, we've been trying to make sure our products fit our customers' needs. We believe that it will be much more difficult to really meet our customer needs by building a single ESB that tried to do everything, because those customers that needed a simpler product would probably be overwhelmed and it's like if you tried to cut these things back too much, you're going lose some of the capability and flexibility and scalability that many of our really large enterprise customers find that they need. And of course the flexibility that we now have with our DataPower hardware ESB appliance is just a tremendous bonus that we've now added into our product line.

GT: So WebSphere ESB, WebSphere Message Broker, WebSphere DataPower can all be used by the same company as its integration needs change?

LD: Yes. What we find in terms of the implementation model is that businesses would typically implement a particular ESB from our portfolio for a particular departmental or project needs as part of an overall ESB strategy, in the full knowledge that any combination of these ESBs woule work together. So you can have WebSphere ESB connected to WebSphere Message Broker, or DataPower connecting to either of those two. In fact, the example that we talked about with Macrovision had the DataPower ESB appliance connecting into WebSphere ESB, which sits at the heart of WebSphere process server.

GT: Well Leif, I'd like to thank you for taking time from what I know is a busy schedule to talk at such length about I think a range of products that will really benefit our listeners.

LD: Thank you, Gian.

GT: In the meantime where can listeners go for more information?

LD: To find out more, you can go to the IBM Website that covers all these issues. You can find it at http://www.ibm.com/software/integration. And there are links on the right-hand side that will take you straight to our IBM Web pages on ESB and application integration, or you can visit the various other links on that page.

GT: OK. For our listeners I will also add that Leif was a very engaging guest during the "Leverage the Value of Existing IT Investments with SOA Reuse and Connectivity" webinar. That webinar replay can be heard at http://www.ebizq.net/webinars/7595.html.

This is Gian Trotta thanking you and reminding you that for more cutting edge blogs, podcasts, webinars, whitepapers, and everything else to do with IT integration the address is as always http://www.ebizq.net. Thank you.