Using Cobit 5 – Part 2: Policy Nomenclature
As discussed in Part 1, for me the primary value in Cobit 5 is the formalization of policy as a concept that has a life cycle and management process. In CBDI-SAE we have focused very strongly on defining the policy hierarchy and instances as the mechanism by which consistency is delivered and governed. Consequently over the years I have been critical of Cobit 4.1 because it was essentially promoting process based governance – if you are executing this process, with some nodding in the direction of general outcomes, then everything’s OK.
So I am very pleased to see policy introduced in a more coherent manner in Cobit 5. The 4.1 definition of policy was: “Generally, a document that records a high-level principle or course of action that has been decided upon. A policy’s intended purpose is to influence and guide both present and future decision making to be in line with the philosophy, objectives and strategic plans established by the enterprise’s management teams.”
In Cobit 5 the definition changes to: “Overall intention and direction as formally expressed by management.” This is better, but still not quite there. Contrast it with the CBDI-SAE definition: “A strategy or directive defined independently from how it is carried out.” I could ask what does management mean? If it was really necessary to include, then a reference to Governance Board, Design Authority or equivalent might have been helpful.
However, minor irritations aside, what Cobit 5 does is lay down a clear requirement for policy “to be part of an overall governance and management framework providing a (hierarchical) structure into which all policies should fit and clearly make the link to the underlying principles”. Further Cobit 5 separates Policy from Principle – a very important step. Also very sensibly Cobit 5 does not attempt to define policy instances, nor indeed the hierarchy and this allows specialists (such as ourselves) to map and or align our pre-existing hierarchy to the Cobit framework. I will return to and expand upon the hierarchy in the next part of this series. But first I want to consider policy nomenclature and structure in a little more depth.
Cobit 5 says “Policies provide more detailed guidance on how to put principles into practice . . .” This is potentially misleading. Yes policies are practical strategies and directives that support and realize principles, but to suggest they must be detailed is incorrect. Good policies should be formed as assertions that are true or false and should not be detailed with “how” they are achieved. The best policies are those that are mandatory – providing unequivocal direction to architects and service delivery teams. The detail is best left to Guidelines – or recommendations that indicate use of patterns and practices.
This simple error in Cobit 5 is actually a fundamental flaw that I would like to see fixed. Time and time again I come across confusion over the nomenclature being used by our clients to support governance. Confusion in this area leads to poor implementation and inconsistent governance. The terms policy, standard and guideline are very commonly used, but frequently mean very different things.
In this context, the good news is Cobit 5 has at least defined policy as the overall intention and direction. I will certainly be using this to advise my clients to standardize on this terminology. Guidelines should then be regarded as practice recommendations. These are not policies with a lower level of mandatory status. At some stage they may evolve to become policies, but not necessarily.
Standards are perhaps a little easier. The CBDI-SAE definition is “A collection of rules or practices which are relevant in Service Architecture or Engineering.” And for good measure the meta type Protocol is a subtype of Standard. Standards therefore are clearly defining the mandatory requirement to comply with specific protocols and practices in given contexts.
To summarize, Cobit 5 is a major step forward. It encourages a policy framework and nomenclature standardization on “policy” for the major directives and strategy assertions and doesn’t preclude complementary Guidelines and Standards under a common management process. In addition Cobit 5 provides the outline framework for development of a policy hierarchy and policy instances, which I will cover in some detail in the next part of this series of blogs.
References: Using Cobit 5 – Part 1 – Principles
Using Cobit 5 – Part 3 – The Policy Hierarchy
