You have the sponsorship and budget, now how do you set up your Integration Competency Center (ICC)?

There are several approaches to organizing the role and responsibilities of an ICC. The approach you take depends on your enterprise’s people, politics and processes. As mentioned in the last post, one approach is a centralized organization or centralized services model. However, that approach does not work in every situation or corporate culture, so don’t think you  need to make it an ultimate goal.

The four organizational models most often used to implement ICCs are:

• Best practices
• Technology standards
• Shared services
• Centralized services

Although the models are organized in an increasing level of control and scope/size of an ICC, it is neither necessary nor recommended for every enterprise to “progress” up the ICC organization ladder. The best fit model is dependent on your situation, not some esoteric ideal model.

Best Practices

The simplest ICC model is one that documents and shares best practices across integration projects. This enables each project to leverage what was learned from previous integration development efforts without reinventing the wheel. It saves time and allows enables each project team to concentrate on expanding the overall enterprise’s integration expertise, thereby contributing new or improved best practices based on what they’ve learned. In this manner, enterprise integration expertise continues to grow project-by-project rather than being lost as each project is completed and resources inevitably scatter.

Technology Standards

The second ICC model involves not only publishing best practices that can be used by all integration projects, but also recommending standardizing on a common integration platform. This approach goes beyond sharing ideas by enabling new project teams to leverage existing technology platform recommendations and avoid the costly and time-consuming selection process. And, if the integration standard is followed, it is possible that there is a potential pool of expertise in the enterprise that might be enlisted to work on this project. Standardizing on software platforms brings the potential for sharing infrastructure across projects (and avoiding costs for independent infrastructure.)

Shared Services

The third organizational ICC model involves creating a group of dedicated people to develop the integration components of individual projects. In this services model, the ICC operates as a subcontractor that can be tapped for the individual integration projects. The ICC determines the strategy, designs the architecture and selects the technology platform as prerequisites to its development efforts. The individual project teams are still responsible for the development effort; the ICC assigns resources for the project to complete its integration portion.

Centralized Services

The final organizational model is a completely centralized ICC operation. Integration work is elevated to a status as its own program. In the centralized services model, the ICC operates as the systems integrator responsible for all integration work throughout the enterprise. All data integration components are pulled out of projects and placed into the integration program. Just as with the shared services model, the ICC determines the strategy, designs the architecture and selects the technology platform as prerequisites to its development efforts. However, unlike the previous model, the ICC operates the entire integration project.

The next post will examine some of the pros and cons of each ICC model so that you can determine what may work best for your enterprise.