The Never-Ending Story: Enterprise Software Integration

Published: October 10, 2007

by Alex Woodie

Say you wanted a fresh start in IT and had to pick an aspect of the business to work in. What would you choose? These days, hardware is a tough sell, ERP providers are consolidating, and too many professional services seem to end up outsourced to India. But if you chose enterprise software integration, you'd be rewarded with a never-ending demand for your software and skills, according to Martin Fincham, LANSA's general manager for the EMEA region.

Fincham came to his realization in a round-about fashion, as is the case with any good realization. He had been working at an enterprise software company that was trying its best to predict the next wave in IT, whether it was the Oracle or SQL Server databases, client/server architecture, or the explosion in ERP systems.

"And I thought, 'Well, if you keep getting in the right place at the right time, it's not a bad business,'" he says. "I sort of fell into integration because I was always working with large clients, and they have integration needs whether I like it or not. And I really got to understand that. I said, 'Hang on a minute. This is a problem that actually never goes away.'"

Fincham watched as big companies tried desperately to standardize on a single infrastructure, and come to rude awakenings each time. "The irony of it is, by the time they even get close to being done, something new comes along. All those people who just finished off their DCE [distributed computing environment] implementation were being told by IBM, 'Ah, remote procedure call, that's old hat. Message queuing, that's the future.' So off they go for another five years, and roll out MQ Series, and just by the time they're done, they say 'Oh no, Web services, XML, open standards, open source ESB. That's the way to go. What's all this proprietary MQ stuff?'"

The popular integration technology of the day is XML-based Web services, wrapped up in a big, cozy services oriented architecture (SOA) blanket. And while the proponents of this approach promise things like the componentization of business processes, loosely coupled connections, and the Big Pipe Dream--the capability to pick and choose from an a la carte menu of Web services-based processes that just work with everything else--the lessons from the trenches of past enterprise integration wars suggest that this will never come to pass.

"Actually agreeing on the wire level stuff, the protocols and message formats, is the easy bit," Fincham says. "That's like saying, 'You and I speak English, we have a common language, we both use the telephone, so we don't have to physically present, so we have transport.' But that doesn't mean we'll agree on anything. We may have a productive conversation, we may not. We may work collaboratively, we may not. We may agree, we may not. All this semantics and syntax to do with communication is what always makes application to application integration hard. And that's not a trivial problem."

We may never achieve integration nirvana, according to Fincham. "Once you get so much stuff out there in the world, if the way to achieve interoperability is to standardize everything on one same thing, it will never happen, because there's just too many programs, systems, and databases out there, and nobody can freeze it long enough anymore to do that wholesale change."

That doesn't mean the discipline of application integration has stopped evolving. More efficient ways of connecting stuff will undoubtedly be thought up by one of the many comp-sci geniuses in the world. But when it comes to the dirty work of hooking up the old stuff to the new stuff, don't fall for the silver bullet that requires you to rip your old foundation so you can install the Integration Architecture to End All Architectures. You're probably better off just hiring a good plumber.

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot