The Integration Competency Center — Is It Really Necessary?

Do we need an Integration Competency Center (ICC)? The short answer is, “Yes.” The long answer is, “Yes, of course.”

Integration is arguably our most critical IT function. Back when IT developed most of our applications, we spent 25 percent of our development dollars on integration. Now, it’s likely 40 percent. This is partly cyclical. With the recession limiting budgets, we’re more likely to patch, mend and extend existing applications rather than implement new systems. This means we must allocate more of our budget to updating interfaces and building new ones.

Another reason for the increase in integration investment is the demise of the green field application. We don’t build applications anymore; we buy them. When we buy an application, we don’t spend money on development (rewriting a large chunk of a packaged application’s code is a fool’s errand). Instead, we change business processes to match the packaged application and spend most of the (reduced) IT portion of our implementation budget on integrating the new application with our other systems.

Moreover, we’re increasingly buying into the real value better integration delivers. We improve customer satisfaction by reducing the time between when a buyer calls with a new shipto address and when that data is entered into our multiple customer information systems. We reduce expenditures on clerical personnel by automating many manual tasks. We reduce latency in our business by creating links between customers’ purchasing systems and our orderentry systems. We improve the marketability of our products and services by automating and better managing multistep processes that previously took days to complete.

OK, we’re spending a lot on integration and it’s money wellspent. So, why do we need an ICC?

Consider the experience of a can company. The CIO knew her developers were spending a lot of time building and maintaining interfaces. She knew she could save a ton of money if she could speed up interface development by even a small amount. But how?

The CIO decided to find out. She moved six of her best developers to a secluded warren of cubicles and told them to think deep thoughts about integration.

They did. They evaluated the oldfashioned way of developing interfaces and didn’t like what they saw — different developers building each interface, with no opportunity for developers to climb a learning curve and with no consistency in interface development techniques. Continuity and consistency looked like the key elements in a better integration approach.

So, they developed an integration methodology they could consistently implement. Then, they pulled together a modest toolkit/framework to assist in interface development. It was merely a collection of prebuilt modules they could use to help develop wrapper, transformation and routing logic.

But they didn’t stop there. They knew you can’t manage what you don’t measure. So, after each project, they reviewed how much time they needed to build interfaces and then compared those results against numbers from previous projects. They also reviewed and improved their methodology and governance.

When they returned, they showed the CIO their work. Admittedly, their toolkit was unimpressive by today’s standards. Still, they figured that if they could keep their integration team together and continually refine their methodology and integration skills, they could build interfaces for 25 percent less than before.

The CIO agreed. She told her project leaders that they were out of the interface development business. From that day forward the integration team would build all interfaces — for 25 percent less than what those interfaces would have cost built the old way.

Of course, there was pushback from some project leaders. They didn’t like having to rely on an external group for a critical part of their projects. But the CIO was adamant.

So, the project leaders turned their interface development over to the integration team. A year later, the numbers were in. Over that first year, the team covered the 25 percent reduction in interface development costs and saved enough additional money to pay back the CIO the money she’d invested upfront to build the team, its methodology and toolkit.

Now, does this mean that you should build an ICC? I think so. But do it right. Use skilled people, a continually measured and refined methodology, and one of the integration broker suites that have matured nicely over the past five years.