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
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.
A Governance Committee needs to be established early, and it will:
The Integration Inventory is a very important component of the Competency Centre, since it will allow:
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.
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.
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.
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.
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:
A Governance Process is crucial for the proper execution of the Competency Centre, since it will:
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.