Thursday, August 2, 2012

Using Cobit 5 Part 3 – The Policy Hierarchy

Many companies do not do governance well. A primary reason for this is a focus on governance “process” at the expense of policies. And, where policies are established, it is common to observe a surfeit of bad, inconsistent policies that are overlapping and generally ignored. As a result much governance is carried out by opinion; and governance decisions are not easily repeatable.

The Cobit 5 framework provides reference models for process and goals but, other than providing very general guidance, stops short of any detail at all relating to principles and policy. However in fairness Cobit 5 does recommend “a (hierarchical) structure into which all policies should fit and clearly make the link to the underlying principles”.

So what does a policy hierarchy look like? Does each organization need to invent its own unique structure and content?  Actually we need more than just a policy hierarchy, we need a model that helps us establish a consistent approach to policy search and description. And whilst every organization will have unique needs, much of the hierarchy and policy content will be reusable. What will usually be highly customized are the contexts and their relationships with policy assertions.
 
In the diagram:
- policy type - classifies the policy. It can be hierarchic.
- policy subject - identifies the focus of the policy the class of object being governed.
- policy - a strategy or directive defined independently from how it is carried out
- policy assertion  - is an atomic policy requirement, expressed as a statement that must be true or false
- policy context  - an entity that limits the reach of a Policy.
- policy effect - an intended and/or an actual outcome of a Business Policy. This can be the Principle(s), Goal(s) or Outcome(s), which of course map neatly to Cobit 5.
Let’s look at an example:

Meta Class  Example
Policy Type Architecture        
Policy Subject Application Architecture
Policy Interfacing
Policy Assertion All new Application Interfaces must be loose coupled.
Policy Context Global applicability
Policy Effect Principle: Interoperable; IT Goal: Agility



Now to put this more broadly into the Cobit 5 context, here’s a fragment of a policy hierarchy, mapped to Policy Subect and Cobit 5 IT Goals.












The policy hierarchy shown above is not rocket science. However it facilitates consistency and communication to all the various stakeholders. You could at a stretch manage policies in a spreadsheet, but in practice it would be advisable to use something like Sharepoint or an equivalent, that allows you to manage the life cycle, status and so on. In a further elaborations of this little series of blog posts I will explore policy relationships with guidance and standards, policy assertion and context development plus the broader policy management model.

Reference: 
Using Cobit 5 - Part 1: Principles
Using Cobit 5 - Part 2: Policy Nomenclature


Next Step: Talk to David about how to apply effective, policy based governance.  

No comments:

Post a Comment