It’s essential that buildings be constructed on solid foundations, and enterprise integration efforts are no different. Having well-planned and executed integration architectures virtually assures companies of getting the best performance and ROI from those efforts.

In the ebizQ webinar Developing an Application Integration Architecture, ebizQ Vice President for Strategic Services Beth Gold-Bernstein and Candle Corp. Senior Architect Peter Rhys Jenkins present the building blocks of an integration architecture, explain its advantages to organizations, and offer best practices for putting one together.

The Candle-sponsored hour is part of the Mapping Out the Right Integration Solution series, whose name is no accident: The series goes into detail on different aspects of ebizQ's Roadmap to Integration Technology. The map, Gold-Bernstein pointed out, “is designed to help companies struggling to understand how to deploy the plethora of integration technologies now available.” What’s more, all components of the map are clickable, leading ebizQ.net visitors to the vendors offering those products or services.

In a presentation peppered with real-life examples, Gold-Bernstein and Rhys Jenkins discussed various patterns of application integration. Gold-Bernstein called it “the baseline technology for all integration architectures.” Those patterns, she pointed out, are not mutually exclusive and in fact overlap and are used in various combinations in integration architectures.

Rhys Jenkins began by telling of a recent incident in which he booked a room at a swanky Manhattan hotel through hotels.com, only to be told when he arrived that his reservation wasn’t in the hotel’s computer system. Why? Because, even though hotels.com is an online operation, its reservations with that hotel are faxed over and hand-keyed in later. And that hadn’t happened yet. A striking example, Rhys Jenkins said, of the abundance of “low-hanging fruit” out there where better integration between systems, in this case, B2B integration, would benefit customers and companies alike.

• Message Brokers: Generally, they have hub-and-spoke designs, with a server in the middle performing services such as translation, transformation and routing, with adapters connecting them to applications. They provide basic messaging services, which Gold-Bernstein dubbed “an underlying technology that enables integration,” often through integration with IBM’s MQ series, which Rhys Jenkins called the “de facto standard” in this sector (with some 75 percent of the market). Gold-Bernstein observed that “you always want to design for agility and change.” Along those lines, Web services are becoming a standard application integration interface but, Gold-Bernstein said, they don’t provide all integration needs, such as transformation, translation, routing, and messaging.
• Enterprise Service Buses (ESBs): Rather than a hub-and-spoke design, ESBs feature a distributed bus architecture, making them “inherently more scaleable” than message brokers, Gold-Bernstein commented. In addition, “You don’t have a single point of failure. You can distribute and federate these services.”
• Legacy Systems: “What’s most important here,” Gold-Bernstein stressed, “is that there are different ways to get at legacy systems.” Among them: through the data level, through messaging interfaces, screen-scraping (“a of last resort,” Gold-Bernstein opined), and through service interfaces, which she described as “a long-term architectural approach to enabling the mainframe to participate in newer applications for the future.” That involves making services out of those legacy apps, which is where Web services come in. Rhys Jenkins added that Web services enable you to bridge the .NET and Java worlds, something he sees as “becoming a lot more prevalent.”
• Portals: They take information from different back-end systems and make it available from one, easy interface. “Application at the glass,” Gold-Bernstein quipped. Rhys Jenkins noted the emerging importance of portlets, and added that portals are “meant for businesspeople. They’re for business solutions, where you care about the end-to-end view, looking at the whole thing.”
• Mobile Solutions: They involve many back-end integration services, Gold-Bernstein noted, and use a mobile server “to rationalize the presentation of the different services to various types of mobile devices. There are additional requirements for mobile integration that layer on top of other integration infrastructure services.” Security is of particular concern here, she pointed out, something Rhys Jenkins wholeheartedly agreed with. He also urged viewers to turn on encryption abilities that come standard with mobile systems, but arrive in the “off” position as their default mode.
• B2B: These systems enable companies to hook up with customers, suppliers and partners outside the firewall. Back-end integration is needed to automate transactions. Other B2B services are required, such as partner management, detailing how partners will communicate with you and the terms of service level agreements. EDI, Rhys Jenkins observed, isn’t going away anytime soon, but is trending more toward real-time rather than batch. Gold-Bernstein pointed out that EDI is expensive, so only large organizations can afford it, but B2B connectivity is slowly being extended to smaller partners through such less expensive means as Web browsers and XML. Another possibility: outsourcing B2B connectivity through vendors such as Grand Central Communications and Hubspan.

For much more detail on structuring your company’s integration architecture, tune in to a replay of Developing an Application Integration Architecture.