People, Process & Politics: Integration Competency Centers

In our “People, Process & Politics” series we have discussed how non-technical aspects of business intelligence, data integration or data warehousing projects are the critical components of success. Sorry product vendors, but no matter how impressive the tool, if a company fails on the 3 Ps, then the projects using those tools will fail to produce reasonable business value.

On the technology side, enterprises need to organize their integration efforts using an integration competency center (ICC) approach. An enterprise needs to identify the scope of its data integration efforts, define its vision and architecture, and then implement that vision. A blueprint is necessary to build what you want but you also need your resources to effectively execute to build what the business needs. 

ICC Organizational Models

Too often people envision an ICC to be a centralized group that controls all integration work. In addition, ICCs are perceived to be a large corporation creation that just does not fit in a small to medium enterprise. On both counts, they could be but they do not have to be. 

There is a wide spectrum of choices from simply …

In our “People, Process & Politics” series we have discussed how non-technical aspects of business intelligence, data integration or data warehousing projects are the critical components of success. Sorry product vendors, but no matter how impressive the tool, if a company fails on the 3 Ps, then the projects using those tools will fail to produce reasonable business value.

On the technology side, enterprises need to organize their integration efforts using an integration competency center (ICC) approach. An enterprise needs to identify the scope of its data integration efforts, define its vision and architecture, and then implement that vision. A blueprint is necessary to build what you want but you also need your resources to effectively execute to build what the business needs. 

ICC Organizational Models

Too often people envision an ICC to be a centralized group that controls all integration work. In addition, ICCs are perceived to be a large corporation creation that just does not fit in a small to medium enterprise. On both counts, they could be but they do not have to be. 

There is a wide spectrum of choices from simply agreeing on common practices to actually having a centralized integration development group. The options fall into four categories:

• Common practices
• Technology standards
• Shared services 
• Centralized development

Although the ICC organizational choices above are listed in an increasing level of control, scope and size, it is neither necessary nor recommended for an enterprise to step up the ICC organization ladder. The organizational approach that best fits an enterprise is dependent on its situation rather than some esoteric, one-size-fits-all model.

Common Practices

The simplest ICC model is one that documents and shares common practices across integration projects. Each independent project is able to leverage what was learned from previous integration development efforts without reinventing the wheel. It saves time, reduces costs and enables each project team to concentrate on expanding the overall enterprise’s integration expertise, thereby contributing new or improved 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. 

In addition, there is a considerable amount of industry knowledge gained from successful and unsuccessful integration projects that has formed a set of data integration best practices. Tapping into that pool of best practices should improve an enterprise’s integration efforts and help avoid many of the learning mistakes everyone new encounters. Just to set expectations: there is no single recipe that applies to all situations, but rather a data integration cookbook of best practices that an enterprise needs to pick which recipes apply to them.

Technology Standards

The second ICC model involves not only establishing common practices that can be used by all integration projects, but standardizing on a common integration platform. This approach goes beyond sharing ideas by creating a technology platform each independent integration project can tap into. This approach avoids the costly and time-consuming tool evaluation and selection process; avoids the cost of redundant or overlapping software and supporting infrastructure; and, if the integration standard is followed, provides the potential for a common pool of expertise in the enterprise that might be enlisted to work on various projects. 

Standardizing on integration technology enables the integration projects to concentrate on creating business value rather than continually tying up resources in the evaluation, selection, purchase, training, development and deployment of multiple integration technologies.

Shared Services

The third organizational ICC model involves creating a group of dedicated people, but in a virtual or decentralized manner, to develop the integration components of all projects. The ICC determines the strategy, designs the architecture, establishes the common practices and selects the technology platform as prerequisites to its development efforts. The individual integration project teams are still responsible for the development activities and deliverables, however, the ICC assigns resources from their common pool of talent to work on those project. This is a terrific approach to developing and nurturing integration talent and expertise (from an employee perspective) and a very productive manner to leverage individual skills thus reducing costs (from an enterprise perspective.)

Centralized Services

The final organizational model is a completely centralized ICC operation. Typically, with this approach, an enterprise-wide integration program is established with a business governing group to fund and prioritize the integration portfolio. 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, establishes the common practices, and selects the technology platform as prerequisites to its development efforts. However, unlike the previous model, the ICC operates the entire integration program.

Next

We will examine the pros and cons of each ICC model so that you can determine what may work best for your enterprise in follow-up posts in this series.

Link to original post