When Simple Won't Do - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Software // Information Management

When Simple Won't Do

Our new column begins with a warning: When it comes to integration, beware the "magic bullet" delusion.

Welcome to my new column on application integration issues. I'm excited to share my thoughts on this topic, and I'm looking forward to interactions with all of you, so please feel free to email me. If you've been following my application integration work for the last several years, you'll find that this column is more innovative and forward looking, written for those of you that have to make decisions now and understand the strategic nature of this technology. So, let's get started.

Have you ever heard the phrase "If you sell a hammer, everything looks like a nail?" That's a good description of how many people approach application integration today, looking to a single technology or standard to solve problems that typically need a very different or more complex technology solution.

The fact is, application integration, for all but the smallest and most simplistic organizations, is difficult and complex, typically requiring in-depth requirements gathering and a group of complex technologies applied in specific ways to create the proper solution. However, many people still hope to find that magic bullet that will meet all their application integration needs, forcing a single solution pattern, technology, or enabling standard as a cure-all. I'm not sure such a thing exists. Let me explain why.

The Magic Bullet Delusion

The trouble with the magic bullet theory is that the source and target systems, complexity of the interfaces, and most business requirements are all very different from enterprise to enterprise. Thus, proposing a single solution, be it Web services or messaging, could quickly get you in trouble. While ABC Corp., a logistics company, is focused on information-oriented integration due to its need to leverage XML and EDI with trading activities, XYZ Corp., a financial services company, is focused more on service-oriented integration due to its need to leverage financial application services (that is, risk analytics) found in its local and remote systems.

What's more, you also need to consider the subdomains, groups within the larger domain that may have different requirements, as well as the limitations of the interfaces provided by the applications. For example, although some application interfaces provide access to services (such as Web services interfaces), most only produce and consume simple information. As a result, leveraging Web services as your application integration solution won't do you much good because the services aren't exposed.

A Better Way

You can make better sense of your requirements by understanding the common integration patterns or approaches that are applicable. That is, once you understand your business requirements as well as the properties of the source and target systems present, you can break these patterns into basic categories: information-oriented, service-oriented, and process-oriented integration, as well as hybrids leveraging two or more approaches.

Information-oriented integration is required for those problem domains that need only replicate information between two or more systems. Truth be told, most of the organizations I deal with only need to leverage information replication to meet their requirements. Information-oriented integration is less expensive and complex than the other forms of integration because you're merely extracting information out of a source system (an application interface or database), transforming it to account for the semantic differences, and placing it in a target system. With information-oriented integration, you don't have to deal with application behavior, which increases the cost and complexity of an application integration project to a large degree. In other words, don't go service-oriented unless you need to.

Technology applicable to information-oriented integration include message brokers and integration brokers from vendors such as SeeBeyond, Mercator (now part of Ascential Software), and WebMethods; messaging middleware such as IBM's MQSeries or Sonic Software's SonicMQ; database replication servers; and other technologies that deal with the replication of information between two or more systems. Integration technology that's contraindicated when it's a pure information-oriented requirement includes Web services, CORBA, and application servers.

Service-oriented integration is required for those problem domains that need to share both application services and information. This approach provides the infrastructure that lets applications leverage behavior through service access from other applications, creating a composite application. The idea is to use application services that already exist vs. recreating them over and over. If done properly, this approach can reduce maintenance costs and make the outcome of the application integration project that much more valuable. Assuming, of course, there is a legitimate need. If it isn't needed, it only serves to add significant and unnecessary cost to an integration project.

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
1 of 2
Comment  | 
Print  | 
More Insights
Data Science: How the Pandemic Has Affected 10 Popular Jobs
Cynthia Harvey, Freelance Journalist, InformationWeek,  9/9/2020
The Growing Security Priority for DevOps and Cloud Migration
Joao-Pierre S. Ruth, Senior Writer,  9/3/2020
Dark Side of AI: How to Make Artificial Intelligence Trustworthy
Guest Commentary, Guest Commentary,  9/15/2020
White Papers
Register for InformationWeek Newsletters
Current Issue
IT Automation Transforms Network Management
In this special report we will examine the layers of automation and orchestration in IT operations, and how they can provide high availability and greater scale for modern applications and business demands.
Flash Poll