Competency Centres: The important subsequent implementation phases

by Jose Herrera

July 29th, 2014

For the second installment of this month's blog series on Competency Centres, Enabling Governance as the First Stage of an Integration Strategy, we'd like to touch on further key components of Competency Centres and what makes them successful in implementation.

As a preface for this post, it may help to backtrack and re-read our first blog posted last week which serves as a 'Competency Centre 101' of sorts.

As you will recall, we capped off that post by sharing the foundational components of a Competency Centre: Governance Committee, Integration Inventory, Governance Process, Reference Architecture, Design Patterns, Development Guidelines & Methodology. However, it is important to note that additional components can be added to the Competency Centre in subsequent phases, as required.

Governance Committee

A Governance Committee needs to be established early, and it will:

Be constituted by stakeholders representing different Information Technology (IT) business-facing groups.
Meet regularly to review integration progress, challenges and exceptions to any of the foundational components of the Competency Centre.

Integration Inventory

The Integration Inventory is a very important component of the Competency Centre, since it will allow:

Identification of existing integration patterns, technologies utilized, documentation availability.
Clarity around technical and functional ownership and the business data objects being integrated.
Consistency of information, since as integration projects are implemented or retired, the inventory requires to be updated.

Governance Process
A Governance Process is crucial for the proper execution of the Competency Centre, and must be created to adapt to the current processes of the organization. The process will ensure that all the components of the Competency Center depicted here work in unison, and that benefits are measured when the process is completed. This process is usually depicted in a Cross Functional Flowchart, or utilizing Business Process Management Notation.

Reference Architecture

The Reference Architecture is intended to become an abstract representation of the permissible patterns within specific domains (i.e. EI, ETL, SOA, BPM). This deliverable must be technology independent, and must be updated on a regular basis in order to identify new or deprecated domains. Additionally, any pattern identified within the organization that does not belong to a domain; must be considered an anti-pattern.

The Reference Architecture will also include a set of Principles to be followed for all integration work across the organization. Alongside these Principles, a set of Policies will also be outlined in the Reference Architecture for proper Governance to take place.

Design Patterns

The Design Patterns derive from the domains outlined in the Reference Architecture, and are also technology independent. Each domain defined in the Reference Architecture, will have a permissible set of Design Patterns; that are intended to provide consistency across the organization. These Design Patterns will serve as the foundation for all integration work performed within the organization.

Development Guidelines

The Development Guidelines are technology specific, and must be derived from the Design Patterns. Each one of the technologies aligned to each domain depicted in the Reference Architecture, must have a set of Development Guidelines. These Development Guidelines will serve as the baseline for all code/configuration reviews that will take place through the integration development lifecycle, as defined in the Governance Process.

Methodology

The implementation of a Methodology is also essential, and it will dictate the type of deliverables expected throughout the entire integration development lifecycle. The Methodology will provide each team with guidance, and the proper templates to be utilized to complete a project. The Methodology can be utilized or merged with any other existing methodologies in the organization.

Some of the templates provided by the Methodology are:

Project Assessment
Requirements Document
Architecture Impact Assessment
Risk Assessment
Architecture Document
Detailed Design
Architecture Fit Assessment
Test Plan and Strategy
Test Cases
Code Reviews
Deployment
Cut-Over
Decision Records
Technical Recommendations

Governance Process

A Governance Process is crucial for the proper execution of the Competency Centre, since it will:

Confirm that the proper Methodology is followed for all integration projects.
Make sure that compliance with the Reference Architecture takes place.
Ensure that the proper Design Patterns are followed in all integration projects.
Ensure that the code or configuration created for integration projects meets the proper Development Guidelines and standards, in order to ensure its quality.
Make certain the Governance Committee is engaged when necessary.
Confirm that the process to ensure Governance is followed and takes place for every project.
Ensure the Integration Inventory is kept up to date with new, changed and retired integrations.

The Governance Process, as mentioned before; must be created with the specific needs of the organization in mind. An overly complex process may be too overwhelming and not be followed, and a process that is too simple may not be respected.