Can you have loose coupling without going all the way? A pragmatic, messaging-based approach can be just as good as full SOA, says one early adopter.

	express delivery
	• print  • comment
	Standards-based messaging allows flexible integration without having to roll out an enterprise-wide services architecture: Retail group KarstadtQuelle is using SeeBeyond's ICAN integration suite Core operational systems run as separate applications SeeBeyond gateways link them into a J2EE-based messaging infrastructure Messaging enforces loose coupling between the core applications Smaller, self-contained applications are offered as services
	Glossary terms: SOA, loose coupling, composite application, J2EE, asynchronous messaging, lookup tool Sponsored links: your text link here

KarstadtQuelle, Europe's largest department store and mail order group, is a participant in SeeBeyond's ICAN 5.0 early adopter programme. It recently signed a contract with the integration specialist that puts SeeBeyond at the heart of its future integration architecture. SeeBeyond's marketing for its flagship integration suite, the Integrated Composite Application Network (ICAN), is all about IT buzzwords like web services and composite applications, promising open integration as a foundation for a service-oriented infrastructure. But although the open standards approach of version 5.0 was a big selling point for KarstadtQuelle, the company insists that implementing a service oriented architecture (SOA) per se is not a goal.

"We had a big discussion about this and decided we were not designing an SOA from a global point of view," says Karl-Heinz Lach, head of technology and integration at the company's IT subsidiary, Itellium Systems and Services. "What we are developing is an application landscape based on strictly separated modules which may only speak to each other via message transfer. The idea is to integrate new modules loosely so we could for example seamlessly transfer any discrete element of the process chain to an external provider."

KarstadtQuelle is in the process of replacing its core systems for merchandising, store and logistics. Although all three systems must interact, no one vendor can match the individual requirements of each separate operation, so the company is using technology from, respectively, SAP Retail, PCMS Beanstore and a J2EE application developed in-house.

"The real aim is to build a new process chain," says Lach. "The best thing for us would be to have one system for the future process chain, but it is not in the market. So in building the system we have the problem of three new applications but very different technologies."

Message mapping

Loose integration is achieved through six SeeBeyond gateways sitting in front of each application (the three operational systems, plus finance, HR and a partner gateway). SeeBeyond was chosen because of its coverage of the various different platforms and messaging formats in use within the infrastructure. In addition, because the rollout will happen over the course of the next three years, the new applications will also have to talk to existing systems before they are replaced, including mainframe-based developments on CICS and IMS.

"We said we must have an integration layer and message-to-message routing and mapping," says Lach. But mapping message formats and their contents so that disparate systems can exchange meaningful information has turned out to be a major undertaking: "It's more than just mapping, it's like an Englishman from Texas talking to a Bushman from the Congo. It's entirely different semantics."

The point of building this messaging infrastructure is that it componentizes the infrastructure into a series of autonomous modules, and thus a future change of any of the core systems — at least in theory — will be less laborious. Even SeeBeyond itself is expendable. KarstadtQuelle saw it as important that the integration layer itself was standards based. "When we were designing the new applications we had the strict aim that they must be middleware-portable. We use the J2EE scenario to achieve that. So we will be able to write the mapping and routing in the J2EE environment and we could transfer it [to another platform]."

Local services

While not embracing SOA as the basis for its entire architecture, services do figure in KarstadtQuelle's thinking at a local, departmental level, and certain of these such as credit checking have been and will be offered to the rest of the business and externally at an overarching horizontal service layer.

Mailing address management is one example where, for reasons of simplicity, a mainframe-based CICS application has been encapsulated as a service for use by other applications and modules. Turning it into a standards-based web service means the company is able to offer it externally as well.

"We have a very good application in our mail ordering company, but really address management is very complex," says Lach. "Many web shops use a light version and we lose some of the functionality that is not really essential for them." For example, having a single field for an individual's first name is sufficient for most applications, whereas in the full application that element has five sub-fields. Providing the output as a service means it can be transformed on demand to suit the needs of each external application.

Such examples demonstrate the strengths of the service-oriented model. But while it makes sense to implement easily self-contained functions as services, service-enabling every single element of the application infrastructure would have been a mammoth undertaking with an uncertain payback. By choosing to implement a series of gateways into a shared messaging infrastructure, KarstadtQuelle has been able to move to a more loosely coupled, componentized architecture, while gaining the extra platform independence that comes from adopting J2EE. It's a pragmatic, evolutionary choice that keeps the project within a manageable scope, introducing service-oriented principles where there are clear benefits, but stopping short of indulging in SOA for its own sake.

More on this topic