By Robert Fox, VP Emerging Technologies, Liaison Technologies
Recently I sat down for an interview, with Robin Smith from Virtual Logistics, for an episode of Integration Television. We had an informal discussion about what goes into building an integration stack – specifically, what kinds of things one must consider when dealing with all of the technical components that comprise an integration stack. This is intended to be a follow-up to Robin’s interview with Hollis Tibbetts, who did a nice piece on “Build vs. Buy” with regards to data integration.
Most of what I have done in the past involved implementing RFCs (Request for Comments) around communication protocols and industry standards around data formats and messaging. The explosion and proliferation of open source has made for a very interesting and different landscape than when I started this journey over 15 years ago. This readily available array of technology has reintroduced the build vs. buy model, but in a very different way. Nowadays, companies reviewing the build approach often-times become technology assemblers. The work done is in trying to weld different technologies that solve different problems into a consistent patchwork, which gives rise to new challenges. Many of these newer challenges have created a greater need for implementing a true semantic data model and a metadata technology to try and create unified order on this integration patchwork. The need to truly separate the data away from the applications that use them, e.g. promoting data as a first class citizen within the data integration stack, is gaining industry momentum (see section entitled ‘Industrialized Data Services’ in Accenture’s recent white paper: Accenture Technology Vision 2012: Emerging Technology Trends for IT Leaders).
Here we are in 2012 and the “build vs. buy” discussion has been reignited. With new tools entering the market to help with the patchwork quilt approach to modern data integration, the lines between what is built and what is bought is starting to blur. Many tools have commercialized how the technology is assembled and integrated. SOA is alive and well and there’s never been a time with richer tools at the market’s disposal. However, this flexibility and overwhelming number of technology choices can lead to paralysis – the exact opposite effect of what should be agile enablers for a company and their IT group. The need for knowledge and guidance to help reduce this complexity has created a new wave of integration enablers in the form of expertise. Build vs. buy may now mean that you “buy” the expertise to “build” the integration stack for you. The integration stack that is “built” may very well reside on the cloud as opposed to on-premise (a whole other interesting discussion with many interesting dynamics all on its own).
Regardless of where you stick your pin on the “you are here” map with regards to your business and your current integration solution, rest assured, things will continue to evolve and change. I am still waiting for a message bus architecture based on quantum queuing theory to become commercially available. Imagine all messages being available on the queue all at once – and processed that way. Until then – happy integrating!