Integration competency center
The integration competency center (ICC), sometimes referred to as an integration center of excellence (COE), is a shared service function within an organization, particularly large corporate enterprises as well as public sector institutions, for performing methodical data integration, system integration or enterprise application integration.
Data integration allows companies to access their enterprise data and functions, fragmented across disparate systems, in order to create a combined, accurate, and consistent view of their core information as well as process assets and leverage them across the enterprise to drive business decisions and operations. System integration is the bringing together of component subsystems into one system and ensuring that they function together effectively. Enterprise application integration enables efficient information exchanges and business process automation across separate computer applications in a cohesive fashion.
Overview
The term may be better understood by examining each of the three words that comprise the acronym. Integration refers to the objective of the ICC to take a holistic perspective and optimize certain qualities such as cost efficiency, organizational agility and effectiveness, operational risk, customer (internal or external) experience, etc. across multiple functional groups. Competency refers to the expertise, knowledge or capability that the ICC offers as services. Center means that the service is managed or coordinated from a common (central) point independent from the functional areas that it supports.
Large organizations are usually sub-divided into functional areas such as marketing, sales, distribution, finance, human resources to name just a few. These functional groups have separate operations and are vertically integrated and are therefore sometimes referred to as "silos" or "stovepipes". From an organizational perspective, an ICC is a group of people with special skills, who are centrally coordinated, and offer services to accomplish a mission that requires separate functional areas to work together.
Key objectives of an ICC are:
- Lead and support enterprise integration (data, system and process) projects with the cooperation/coordination of subject matter experts
- Promote Enterprise integration as a formal discipline. For example, data integration will include data warehousing, data migration, data quality management, data integration for service oriented architecture deployments, and data synchronization. Similar system integration will include common messaging services, business service virtualization etc.
- Develop staff specialists in integration processes and operations and leverage their expertise company-wide
- Assess and select integration technology and tools from the marketplace
- Manage integration pilots and projects across the organization
- Optimize integration investments across the enterprise level
- Leverage economies of scale for the integration tools portfolio at enterprise level
ICCs allow companies to:
- Optimize scarce resources by combining integration skills, resources, and processes into one group
- Reduce project delivery times and development and maintenance costs through effectiveness and efficiency
- Improve ROI through creation and reuse of enterprise assets like source definitions, application interfaces, and codified business rules
- Decrease duplication of integration related effort across the enterprise
- Build on past successes instead of reinventing the wheel with each project
- Lower total technology cost of ownership by leveraging technology investments across multiple projects
An ICC may be a temporary group in support of a program or a permanent part of the organization. Furthermore, ICC’s can be established at various scales or levels; within a division of a company, at the enterprise level, or across multiple companies in a supply chain.
History
The term "integration competency center" and its acronym ICC was popularized by Roy Schulte of Gartner in a series of articles and conference presentations beginning in 2001 with The Integration Competency Center [citation needed]. He picked up the term from one of his colleagues, Gary Long, who found some of his clients using it (they took the established term “competency center” and applied it to integration). Prior to that (from 1997 to 2001) Gartner had been referring to it as the central integration team. The concept itself (even before it was given a label) goes back to 1996 in one of Gartner’s first reports on integration. [citation needed]
A major milestone was the publication in 2005 of the first book on the topic: Integration Competency Center: An Implementation Methodology[1] by John G. Schmidt and David Lyle. The book introduced five ICC organizational models and explored the people, process and technology dimensions of ICC’s. Several reviews of the book can be found at IT Toolbox and at Amazon. The concept of integration as a competency in the IT domain has now survived for over 10 years and appears to be picking up momentum and broad-based acceptance.
These days, ICC’s are often called, integration center of excellence, SOA center of excellence, the data management center of excellence and other variants. The most advanced ICC's are using Lean Integration practices to optimize end-to-end processes and to drive continuous improvements. Universities are also beginning to include integration topics in their MBA programs and computer science curricula. For example, The College of Information Sciences and Technology at Penn State University has established a Enterprise Informatics and Integration Center with the following mission:
"The Enterprise Informatics and Integration Center (EI²) will actively engage industry, non-profit, and government agency leaders to address critical issues in enterprise processes, knowledge management, and decision making."
Operating models
There are a number of ways an ICC can be organized and a wide range of responsibilities with which it can be chartered. The ICC book[1] introduced five ICC organizational models and explored the people, process and technology dimensions of ICCs. They include:
Best practices ICC
The primary function of this ICC model is to document best practices. It does not include a central support or development team to implement those standards across projects, and probably not metadata either. To implement a best practices ICC, companies need a flexible development environment that supports diverse teams and that enables the team to enhance and extend existing systems and processes. Such a team might be a subset of an existing enterprise architecture capability and generally consists of a small number of staff (1-5).
Standard services ICC
A standard services ICC provides the same knowledge leverage as a best practices ICC, but enforces technical consistency in software development and hardware choices. A standard services ICC focuses on processes, including standardizing and enforcing naming conventions, establishing metadata standards, instituting change management procedures, and providing standards training. This type of ICC also reviews emerging technologies, selects vendors, and manages hardware and software systems. This style of ICC is often tightly linked with the enterprise architecture team and may be slightly larger than a typical best practices ICC.
Shared services ICC
A shared services ICC provides a supported technical environment and services ranging from development support all the way through to a help desk for projects in production. This type of ICC is significantly more complex than a best practices or Standard Services model. It establishes processes for knowledge management, including product training, standards enforcement, technology benchmarking, and metadata management, and it facilitates impact analysis, software quality, and effective use of developer resources across projects. The organizational structure of a Shared Services ICC is sometimes referred to as a hybrid or federated model which often includes a small central coordinating team plus dotted-line reporting relationships with multiple distributed teams.
Central services ICC
A central services ICC controls integration across the enterprise. It carries out the same processes as the other models, but in addition usually has its own budget and a charge-back methodology. It also offers more support for development projects, providing management, development resources, data profiling, data quality, and unit testing. Because a central services ICC is more involved in development activities than the other models, it requires a production operator and a data integration developer. The staff in a central services ICC does not necessarily need to be a central location and may be distributed geographically; the important distinction is that the staffs have a solid-line reporting relationship to the ICC Director. The size of these teams can vary and may be as large as 10%-15% of the IT staff in an organization.
Self service ICC
The self-service ICC represents the highest level of maturity in an organization. The ICC itself may be almost invisible in that its functions are so ingrained in the day-to-day systems development life-cycle and its operations are so tightly integrated with the infrastructure that it may require only small central team to sustain itself. This ICC model achieves both a highly efficient operation and provides an environment where independent development and innovation can flourish. This goal is achieved by strict enforcement of a set of application integration standards through automated processes enabled by tools and systems.
Key challenges
ICC as a concept is fairly simple. It is embodiment of the IT management best practices to deliver shared services. However, being an organizational concept, it is far more challenging to implement in practice than the conceptual view because every organization has different DNA and it takes specific personalization/customization effort for ICC that makes the ICC initiative successful. Here are some of the common challenges in ICC establishment journey:
- Change management in terms of technology, processes, organization structure
- Ability of the organization to deal with the pace and quantum of change
- Alignment of stakeholders and process owners for ICC strategy
- Inappropriate ownership level for ICC program and lack of senior management sponsorship
- Highly tactical focus and business program level constraints
- Ignoring foundation elements and jumping to implementation directly
- Inappropriate funding
These issues are important to consider when embarking on the ICC investment since the last leg of the implementation of ICC that's what matters most. Intellectual definition of ICC that is not implemented in the organisation has no real value for the enterprise.
See also
- Lean Integration
References
- ↑ 1.0 1.1 John G. Schmidt and David Lyle (2005), Integration Competency Center, An Implementation Methodology, ISBN 0-9769163-0-4
Further reading
- Maurizio Lenzerini (2002). "Data Integration: A Theoretical Perspective". PODS 2002: 243-246.
External links
- Integration Competency Center book: (http://www.amazon.com/Integration-Competency-Center-Implementation-Methodology/dp/0976916304)
- Informatica ICC Blog: (http://blogs.informatica.com/perspectives/category/data-integration/integration-competency-centers/)
- Gartner paper (http://www.ebizq.net/topics/tech_in_biz/features/5360.html)
- Integration Consortium: (http://www.integrationconsortium.org)
- Infosys ICC Blogs (http://www.infosysblogs.com/bpm-eai/integration_competency_center_icc)
- ICC Handbook (http://www.unthink.fi/Global/PDF/ICC-Handbook.pdf)
- Integration Warstories - article about avoiding ICC pitfalls (http://integrationwarstories.com/2013/10/25/avoiding-pitfalls-of-integration-competency-centers/)