Identifying Integration's Value Gets Trickier Every Day

“Integration is like weather,” opines Gartner Research Director Thomas Otter. “The statement, 'We have weather today,' is accurate but not particularly useful. This is similar to the statement, 'Our system is integrated.'”

Otter joined Gartner last year, and in a recent blog post, he shares that he's spent that time thinking more objectively about integration. Previously, he served as the chief business solution architect at SAP, and he confesses in a recent blog post that previously, he'd chanted the mantra, “We are integrated,” like so many in IT .

The problem is, integration isn't the point. It never was, a realization that's occurred to him with some reflection:

What is integrated with what? What is the purpose of the integration? What value does the integration bring? What overhead does the integration create?

OK, that may seem like a big “No-duh” for many of you, but while you may think you're not making the assumption that integration is always right and good, take a second look. Are there times when you're pushing for integration when a better, cheaper, faster solution would be simply to retype the data?

Otter uses an example of tracking 50 top executives in a succession-planning application. You might think you need real-time integration with the 20 separate global HR systems – but really, retyping the information would be much quicker and easier:

...integration can be an excuse not to move quickly, it can hinder innovation and create overhead, it can be a reason not to do something new. ... When evaluating software, view integration rationally, don’t put it on a pedestal, but don’t dismiss it. Understand clearly what is being integrated, and what the value of that integration is. Integration doesn’t trump functionality.

The trick is knowing when integration is worth pursuing. Though it sounds like a simple question, it's becoming trickier every day, particularly when you're talking about application integration.

In a recent SD Times guest column, Cisco's senior enterprise architecture marketing manager, John Gaudin, explores why the degree of integration – which he refers to as an application's range – is more problematic now for application developers.

The short answer, of course, is that we're living in an increasingly distributed, Web 2.0 world, and it's sometimes difficult to answer questions like “What is being integrated with what?” and “What value does the integration bring?” in any definitive way. As Gaudin observes:

As SOA, composite and mash-up applications become the norm, developers must not only integrate with applications from within their own enterprise, but they may also need to incorporate functionality from external applications. It’s no longer as simple as updating a library and recompiling code to create compatibility with other applications in your organization. Web 2.0, social networking and composite applications are redefining application integration requirements.

These days, it isn't enough to do integration – you have to be ready to integrate broadly – across devices and silos, with internal and external resources. Developers also must take into account the that applications are more distributed, a trend that's only going to increase as companies adopt virtualization technologies.

The rest of the column is devoted to how “network-based application services can change the face of application development.” It's an interesting concept, but – and I'm willing to be wrong about this - it sounds suspiciously like Cisco-speak for “upgrade all your hardware.”

There's no doubt that as virtualization, cloud and service-oriented architecture catch on, there's a huge potential for integration to be part of a broader business strategy. But you can't necessarily pre-integrate and service-enable everything. How do you decide?

Ultimately, it's a question that's going to require a bit of work and deep thinking. You have to look at both the hard and soft costs of integration, as David Linthicum explained in an April interview:

In many instances, it may not be cost justified. People say, "Well, it's always a good idea to do integration, it's always a good idea to do SOA" and now they are saying, "It’s always a good idea to cloud computing." Absolutely not. It's a good idea most of the time, but not all of the time. When you do this analysis in creating the business case, in some instances, it may not be cost justified and then you don't do it.