Tuesday, July 31, 2012

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

Monday, July 30, 2012

Using COBIT 5 - Part 1: Principles

I am impressed with Cobit 5. The leap from 4.1 to 5 is significant and useful. Points to note:
- the level of detail has been REDUCED!
- Cobit has discovered POLICIES! The framework is no longer a purely process perspective, but recognizes a defined set of enablers including people, principles, policies etc.
- the structure is deliberately constrained to framework level. There is no attempt to define policies, just the processes and objectives.
- alignment with TOGAF and ITIL has brought Cobit some way into the real world

The framework therefore encourages users to develop the enablers. I started by re-examining Principles. Interestingly there is (to my mind) no single good source of Principles. I have therefore attempted a set, below. My next task is to review the SAE Policy hierarchy and to develop the hierarchy and our existing set of CBDI-SAE policy instances within the Cobit framework. We already have a good set of instances and this will be an interesting exercise. I anticipate evolving the Principles - inevitable when you do mapping I guess . . .

Primary Principles Supporting Principles
Maximizes Business Value Affordable, Sustainable
Enables Agile Business Responsive,  Just in Time Solutions,
Incremental Delivery, Continuous Release 
Secure Business Continuity, Risk, Reliability, IP protected
Compliant Compliance with Law and regulatory requirements
Ensures High Quality Information Data is an Asset, Shared, Accessible,
with defined accountability for quality
Ease of Use Transparent technology, minimum training requirement
Business Driven Requirements based Change, Pull/Demand System,
Business is fully Accountable 
Service Oriented Architecture Interoperable, Componentized,
IT Services directly support Business Services
Innovating Accommodate Diversity
Managed standardization Technology independence, Shared services
and components

Feedback welcome. I shall continue very shortly.
See also:  Using Cobit 5 - Part 2: Policy Nomenclature
                Using Cobit 5 - Part 3 - The Policy Hierarchy

Tuesday, July 24, 2012

The Integrity Unit Pattern

Down the years I have advised customers on the use of an Integrity Unit pattern on numerous occasions, yet strangely this incredibly useful pattern seems to remain a best kept secret.

It's pretty simply really. I define it as: A defined group of capabilities that comply with common policies and common level of trusted behavior. 

In a Service Context, it can be immediately useful to cluster services with common security or rollback capabilities. In an automation unit context it can be used to rubber band units that are tested and certified together. In effect it is an organizing concept that can be overlaid on the technical architecture. Whilst it might be seen as compromising elements of technical integrity - for example the encapsulation of services, in practice it is a sensible level of compromise. The service behaviors remain encapsulated at the individual service level, and indeed permit plug and play at that level, but the overall IU remains the unit of certification and trust. It's important to note that the IU certification level should address both SLA and behavioral characteristics. 

I'm interested to hear whether others use this as a pattern!