We’ve been discussing the three pillars of an ICC, organization, process and technology, for a while now. In this segment, I’ll focus on a range of technology requirements facing ICC implementations teams, whether they are starting from scratch or morphing a set of disparate solutions into a common infrastructure. It goes without saying, to meet the demand of a broader set of enterprise needs rather than those of a single line of business, the infrastructure powering an ICC needs to evolve and mature.
High Availability
One of the first aspects related to infrastructure is the need for high availability. This pertains to the overall integration infrastructure environment. “Shared Infrastructure” by its very nature increases the need for reliability. An outage of a single point solution is acceptable and explainable but when several organizations are relying on solutions delivered by an ICC, outages can significantly impact revenue and productivity.
I call this the ICC “Tier 3” to “Tier 1” factor. Many of the larger customers that I’ve worked with have different IT application tiers, each with escalating mission critical requirements. Tier 3 applications don’t support revenue generating business processes and can rely on infrastructure that may break on occasion. Tier 1 applications underlie revenue generation and decision making and can’t go down without impacting the bottom line. This may require organizations to look at the current applications used for data integration. Hand-coded or project-based solutions usually don’t lend themselves to becoming Tier 1. It is through this direct experience with ICC customers that pushed Informatica to deliver “mission critical” support for our data integration platform.
Cost Effective Scalability and Concurrency
It goes without saying scalability needs to be a primary concern of an ICC. Flexibility and demand place a significant burden on the flow of data and the concurrency of solutions running within the infrastructure. Anticipating peak demand is often impossible and always expensive to deploy.
This is where grid can help. Leveraging an “integration grid” that allows for incremental addition of capacity, simplified administration and workload prioritization will allow an ICC to deliver successfully on existing and new business requirements.
Multiple Latencies – Same Infrastructure
Business requirements vary in their need for data freshness or latency. An ICC isn’t all about real-time, although that should be factored into the underlying infrastructure. An ICC should be flexible enough to deliver in “right time”, namely batch, change-only, real-time and increasingly on the fly using data federation capabilities.
Segmentation, Resource Tracking and BillingOne of the early demands from our ICC customers was a way to segment, track and charge-back infrastructure usage across independent internal groups. This helps with balancing the investment across sponsors and projects. Rarely does the business maintain or increase investment in an IT-provided service without usage-based metrics. This may not seem like a core technology requirement but in reality it is essential to justifying and measuring ICC success and a great way to build a business case.
I welcome comments on the maturing of data integration within your organization, whether you’ve considered an ICC to best leverage your investments and increase scope and value to the business. As outlined, without a proper foundation, the accelerated delivery and economic gains promised won’t be achieved.
Take a look at how you do data integration today. Are you ready to move to an ICC? Is the technology you’re using ready?

